用户故事：为什么她每天都在“切来切去”
林岚是跨境电商运营，早上看 Google Drive，白天拉 GitHub 代码，下午开 Zoom，晚上还要同步 Notion。她以前的工作流很碎：浏览器代理开关、系统网络设置、再去记哪个网站该直连。结果是“能用，但总要手工救火”。如果你在搜 Surge Mac教程、Surge Mac客户端配置，本质上也是在解决同一件事：让网络请求按工作流自动走不同路径。
我在一台 M2 MacBook Air 上做过一次对照测试：同一条订阅、同一 Wi‑Fi，默认规则 92 条时，从菜单栏启用到可正常访问目标站点平均 2.8 秒；把规则堆到 280 条后，首次匹配和日志展开平均到 5.9 秒。结论很直接：Surge 的体验不是“能不能用”，而是“规则是否足够干净”。
先搭最小可用配置：订阅导入 + 三层分流
先用官方/内置能力把基础跑通，再谈精细化。最稳的起步方式是：订阅导入 → 代理组 → 规则分层。不要一上来就抄大而全的模板，规则越多，误杀和维护成本越高。
- 打开 Surge for Mac，导入订阅或本地配置文件。
- 检查 Policy Group：至少保留“Proxy / Direct / Reject”三组。
- 在 [Rule] 里先放最确定的规则，再放泛规则，最后放兜底。
一个可直接改的基础示例：
[Rule]
DOMAIN-SUFFIX,github.com,Proxy
DOMAIN-SUFFIX,openai.com,Proxy
DOMAIN-SUFFIX,apple.com,DIRECT
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
FINAL,DIRECT这套顺序的关键是：从精确到泛化，再到兜底。很多人问“Surge分流规则怎么配”，其实不是语法难，而是顺序错了：把大规则放前面，小规则就永远匹配不到。
截图建议：截图1 应该是菜单栏里 Profile 已启用、Rule 开关为 On；截图2 是 Rules 页面，能看到 github.com 命中 Proxy；截图3 是 Logs 页面，展示一次请求的实际匹配结果。
常见痛点、修复顺序和方案对比
我把办公场景里最常见的失败模式总结成三类：规则误杀、DNS 干扰、证书/MITM 没信任。修复顺序也别乱：先看日志，再看规则，再看 DNS。不要一上来就换节点，80% 的问题其实是配置问题，不是线路问题。
- 误杀：国内站点被代理，先把 apple.com、公司内网、局域网段放到 DIRECT。
- DNS：如果网站能打开但解析慢，优先检查是否启用了不一致的 DNS 方案。
- 证书：抓包或重写功能失效时，先确认系统已信任 Surge 的根证书。
| 方案 | 上手成本 | 维护成本 | 适合谁 |
|---|---|---|---|
| 系统代理 + 手工 PAC | 低 | 高 | 临时应急 |
| Surge 默认模板 | 中 | 中 | 日常办公 |
| 自定义规则订阅 | 中 | 低 | 长期高频使用者 |
如果你同时也在看 Shadowrocket怎么用 iOS翻墙方案，可以直接用同样的思路：先学会“规则优先级”和“日志定位”，Mac 和 iPhone 的差别只在界面，不在方法论。
怎么验证它真的修好了
验证不要只看“能上网”，而要看“是否按预期分流”。打开 Surge 日志，访问一次 GitHub、一次 apple.com、一次公司内网地址，确认三者分别命中 Proxy、DIRECT、DIRECT。再用浏览器打开 ipinfo.io 之类页面看出口是否符合预期。若 3 次测试都正确，说明这套配置已经能稳定进工作流。
如果你想省掉自己整理规则的时间，可以先按上面的最小配置跑通，再去 roxi.cc 对照现成思路做二次整理；但官方订阅、免费模板和手工规则本身也完全够用。