最近被一个问题反复折磨：
在 Mac 上开了代理后，Antigravity 里的 browser_subagent 怎么都调不起来，接口几乎全是 400。
查到最后，问题不在 MCP 本身，而在代理配置把本地回环地址也一起代理了。这里做个记录，避免更多人踩坑。
现象
我的环境里，代理开启后（怀疑和 TUN 模式有关），browser_subagent 调用内置 Playwright MCP 时会持续报错：
- 子代理能发起请求，但浏览器相关接口返回
400 - 同一套配置在 Windows 11 上没有复现
- 关闭代理后问题消失
根因
settings.json 里本来就有一条代理配置，指向本地代理端口 7890。
（Antigravity 这类 VS Code 系客户端，通常是 http.* 这组字段）
{
"http.proxy": "http://127.0.0.1:7890"
}
看起来没问题，但副作用是：
对 127.0.0.1 / localhost 的请求也被转发到代理。
而 Antigravity 内置的 Playwright MCP 需要走本地回环地址通信（本机服务）。
本地请求被错误代理后，就会出现协议不匹配或请求链路异常，最终表现为接口 400。
修复方法
核心就一句话：给代理配置加 no proxy，把本地地址绕开。
按你截图这个配置体系，建议直接写成：
{
"http.proxy": "http://127.0.0.1:7890",
"http.proxyStrictSSL": false,
"http.noProxy": [
"127.0.0.1",
"localhost",
"::1"
]
}
有些版本也支持逗号分隔字符串：
{
"http.proxy": "http://127.0.0.1:7890",
"http.noProxy": "127.0.0.1,localhost,::1"
}
不要混用成 proxy / no_proxy 这种键名，否则在该类 settings.json 里可能不会生效。
验证步骤
- 保存配置并重启 Antigravity（必要时重启代理客户端）
- 再次调用
browser_subagent执行一个最小浏览器动作（如打开页面） - 确认不再出现批量
400
如果仍有问题，再检查是否同时设置了系统级环境变量：
HTTP_PROXYHTTPS_PROXYNO_PROXY
确保 NO_PROXY 也包含 127.0.0.1,localhost,::1。
关于为什么 Mac 更容易中招
我这边的体感是和代理客户端的 TUN/全局流量接管策略有关： Mac 下更容易把回环地址请求也纳入代理路径；而我在 Windows 11 上同样配置没有复现。
这部分和具体代理软件实现有关，不同客户端行为可能不一致，但「本地回环不要走代理」这个原则是通用的。
总结
这次问题本质不是 MCP 挂了，也不是 browser_subagent 本身有 bug，
而是代理配置里缺了本地地址绕行规则。
遇到 browser_subagent 持续 400，优先先看 http.proxy + http.noProxy：
把 127.0.0.1/localhost/::1 排除掉，通常就能直接恢复。
