本页目录
机场只让用自家客户端，浏览器能访问目标网站，Homebrew 的网络请求却失败，Discord 上的机器人也掉线？我在 Mac 上碰到的就是这个情况：客户端开放了本地代理，却没能可靠地接住那些不按系统网页代理设置走的应用。最后我让 Surge 管流量入口和分流，机场客户端只当本地上游出口，把两边擅长的事分开。前提是客户端确实提供可连接的 HTTP 或 SOCKS5 本地代理；若服务商给了可直接导入 Surge 的节点，没必要绕这一圈。
先确认问题是不是出在客户端的接管范围
我用的服务商不再提供普通节点订阅，必须保留它的客户端。客户端连接后浏览器可用，但终端与 Discord 相关连接失败；它虽有 TUN 开关，在那台 Mac 上一开反倒断网。这些只是这款客户端在那次环境里的表现，不是对所有服务商客户端的判断。
先保持机场客户端单独运行，记录浏览器、一个终端网络请求和你实际使用的 App 的结果。然后到 macOS 网络设置 → 当前连接详情 → 代理，核对客户端启用后写入的本地代理地址、协议与端口。我的机器当时显示了一个本地端口，换电脑、客户端或版本就可能不同，别照抄任何截图里的数字。
效果先看：Surge 接管入口，客户端继续提供线路
在已检查好上游协议和规则的配置下，我启用了 Surge 的设置为系统代理和增强模式；回到 macOS 代理设置，能看到系统代理入口已经换成 Surge。随后 Discord 连接恢复，Homebrew 的网络请求也能执行。这比单纯“浏览器能打开”多验证了两类原本出问题的应用，但不能据此宣称所有应用、DNS 和 IPv6 都自动正确。
整条路是这样走的：
应用请求 → Surge 接管 → 命中分流规则
├─ DIRECT → 目标服务
└─ 上游代理 → 客户端本地端口 → 服务商线路Surge 的增强模式负责让更多流量进入规则链，不负责凭空提供节点；真正的出口仍是已经连接的机场客户端。下面把这份配置拆开，你就知道为什么两款工具一起开时没有互相绕晕。
配置核心：本地上游、策略组和防环路规则
我在示例配置里定义了一个指向本机代理端口的上游。演示使用的是 SOCKS5；如果你的客户端只提供 HTTP，必须按实际协议改写并先确认另一程序能连接该地址。配置会变化，下载前自己查看端口、远程规则、脚本与 DNS，不要把旧文件直接当现行安全默认值。
广告
上游代理被放进策略组，后面的规则决定哪些请求直连、哪些转发给它。最重要的一条规则放在宽泛规则之前：机场客户端自身的进程走 DIRECT。否则客户端为连接服务商发出的请求又被 Surge 转回同一个客户端，就形成代理环路。我从 Surge 请求查看器找到实际进程名再填写，从 07:18 可对照进程识别与规则位置；界面自动生成的绝对路径也许带版本号或安装目录，升级后可能失效，选用进程名还是路径要结合当前版本测试命中结果。
这套转发链路还要求Surge 保持规则分流模式，不开不区分请求的全局代理；全局模式若绕过上面的直连规则，环路又会回来。想让某个目标网站走代理，明确给它加一条分流规则即可。上游客户端自身可以按服务商的要求保持连接，让 Surge 已筛选的请求通过其本地端口出去；两边的“全局”开关不是一回事。
下载、导入和逐项验收
- 备份 Surge 原配置，从上面的仓库查看并下载配置，在本机把上游协议、地址、端口与客户端进程直连规则改成自己核对过的值。
- 在 Surge 主窗口 → 更多 → 配置 → 导入 中选择文件，双击并应用；启动客户端后再开启 Surge 的系统代理与增强模式。若一开启就全面断网，先停用增强模式、切回原配置，再检查端口是否在监听以及直连规则是否抢在转发规则前面命中。
- 重做“客户端单独运行”的那组测试：浏览器、终端、目标应用分别发起新请求；从请求查看器核对客户端进程直连、目标请求命中上游策略，而不是只凭 VPN 图标。
如果服务商客户端更新后改了端口或进程名，这份配置也得跟着核对。方案解决的是“被迫保留上游客户端，却想用 Surge 的增强模式和分流”；它不保证匿名性，也不能替你检查解析链路。还不熟悉分流规则，可从图形界面分流开始。你若卡在“浏览器可用、某个 App 还是不通”，欢迎在评论里说说本地代理协议、命中的规则和应用现象；带凭证的配置与服务商账号请遮好。
广告
