SwitchyOmega 访问 127.0.0.1 被拒绝连接：loopback 代理绕过排查

遇到这类问题时，很容易先怀疑 SOCKS5 代理挂了，或者远端服务根本没起来。这个案例里的真正根因并不在代理本身，而在 Chromium 对 localhost、127.0.0.1、::1 这类 loopback 地址的默认直连策略。

一句话结论：在 SwitchyOmega 的固定代理配置里加入 "<-loopback>"，把 loopback 地址从浏览器的隐式直连规则里移出去，127.0.0.1 请求才能真正走到 SOCKS5 代理。

1. 场景

本文场景里，ssh lab-desktop 这个别名会拉起一个本地 SOCKS5 入口，比如已经在 ~/.ssh/config 里配置了 DynamicForward。

本地代理入口：

127.0.0.1:51888

目标服务地址：

http://127.0.0.1:5173

命令行测试可以成功：

curl --socks5-hostname 127.0.0.1:51888 http://127.0.0.1:5173

但在 Edge 浏览器里通过 SwitchyOmega 访问同一个地址时，会直接报：

127.0.0.1 refused to connect

2. 为什么 curl 能通，浏览器却不行

表面上看，两边都在访问 http://127.0.0.1:5173，但请求路径并不一样：

• curl --socks5-hostname 会显式把请求交给 SOCKS5 代理处理。
• Chromium 内核浏览器对 localhost、127.0.0.1、::1 这类地址有默认的 loopback 直连规则。
• 所以浏览器即使启用了代理，也可能根本没有把请求发给 SOCKS5，而是直接尝试连接“当前机器”的 127.0.0.1:5173。

如果本机 5173 没有服务监听，就会看到 refused to connect。

3. 根因

问题的核心不是 SOCKS5 不可用，而是浏览器默认绕过了 loopback 地址。

从现象可以直接推出两件事：

• curl 走代理成功，说明 SOCKS5 入口 127.0.0.1:51888 是正常的。
• 浏览器访问失败，说明 127.0.0.1:5173 没有按预期进入代理链路。

4. 解决办法

在 SwitchyOmega 的固定代理配置里加入下面这条规则：

{
  "conditionType": "BypassCondition",
  "pattern": "<-loopback>"
}

这条规则名字看起来像“绕过”，但在这里的作用恰好相反：

• 它不是新增一个绕过规则。
• 它是把 loopback 地址从 Chromium 的隐式绕过列表里移除。

加上它之后，下面这些地址才有机会真正进入你配置的代理链路：

• 127.0.0.1
• localhost
• ::1