先看用户路径：从“全局代理”改成可控分流
林岚是一名远程产品经理，每天在 Mac 上使用 Notion、GitHub、企业邮箱、在线视频会议和国内办公系统。她原先采用全局代理：打开会议时延迟升高，访问国内文档变慢，切换节点后又忘记恢复，平均每天要花 10 分钟处理网络问题。
我把她的目标拆成三个可量化指标：国内网站直连、海外工作站点按规则代理、单个应用出现异常时能在 3 分钟内定位。与其先研究复杂配置，不如先建立最小可用流程。免费方案可以使用系统代理、浏览器扩展或官方 VPN，但通常只能按设备或浏览器切换，无法精确处理 Git、终端和视频会议等不同流量。
在 Surge Mac客户端下载后，首次配置建议只导入可信订阅，先不要叠加多份规则。打开配置文件，确认代理组、节点名称和 DNS 设置均已加载。随后在“规则”区域按以下顺序组织：局域网直连、国内域名直连、工作相关域名代理、其他流量直连或按需代理。规则是从上到下匹配，顺序错误比规则缺失更常见。
可复制的配置与调试步骤
- 进入 Surge 的配置编辑器，备份当前配置，再新增自定义规则组，例如“WorkProxy”。
- 先添加局域网和国内规则，再添加工作域名。示例结构如下：
[Rule]
DOMAIN-SUFFIX,github.com,WorkProxy
DOMAIN-SUFFIX,githubusercontent.com,WorkProxy
DOMAIN-SUFFIX,notion.so,WorkProxy
DOMAIN-SUFFIX,notion.site,WorkProxy
GEOIP,CN,DIRECT
FINAL,DIRECT
如果企业服务使用多个子域名，优先使用 DOMAIN-SUFFIX；只有单个固定主机名时才使用 DOMAIN。不要直接把所有海外流量交给代理，否则无法判断到底是节点问题还是规则问题。
- 打开“请求查看器”，访问目标网站，确认命中的规则、最终节点和响应时间。截图应包含域名、匹配规则、策略组和延迟四列，便于后续复盘。
- 在终端执行：
curl -I --max-time 10 https://github.com
scutil --proxy
networkQuality -v
前两条用于确认请求是否成功及系统代理是否生效，networkQuality 用于观察基础网络质量。我的测试中，同一节点连续测试 5 次，GitHub 首包延迟约 180 至 240ms；若波动超过 100ms，先换节点，再修改规则。
故障边界、竞品取舍与验证
| 方案 | 按应用分流 | 规则可调试 | 适合场景 |
|---|---|---|---|
| 系统代理 | 弱 | 低 | 临时浏览 |
| 浏览器扩展 | 中 | 低 | 单一浏览器 |
| Surge Mac | 强 | 强 | 办公、开发、多应用 |
| 自建脚本方案 | 可定制 | 依赖维护 | 熟悉网络配置的用户 |
常见失败包括 DNS 污染、规则被前置条目拦截、节点可连但 TLS 握手失败，以及企业软件不读取系统代理。遇到“浏览器正常、终端失败”，检查终端是否继承代理变量；遇到“域名能开但登录失败”，重点检查时间同步、证书和企业域名是否被错误直连。
如何验证已修复：分别访问一个国内站点、一个工作站点和一个未配置域名，记录请求查看器中的命中规则；连续执行 5 次 curl，成功率应达到 100%，延迟波动控制在 100ms 内。完成后再测试 Git 拉取、视频会议和企业登录，确认真实工作流没有回归。作为产品建议，免费系统代理适合低频用户，官方 VPN 适合企业统一管理，付费客户端适合需要细粒度规则和可视化排障的用户；选择时应优先比较维护成本，而不是只看节点数量。