用户故事：一个每天和“临时切换网络”打交道的设计主管
林薇是某互联网公司的设计主管，早上要开 Zoom 评审会，中午同步 Figma 资源，晚上还要在不同地区协作工具里切换账号。她最头疼的不是“能不能连上”，而是“能不能在不打断工作的情况下自动走对线路”。她之前的工作流很典型：手动开关代理、浏览器和客户端各自设置不同，遇到国外文档、公司内网、流媒体混在一起时，经常出现“该直连的走代理、该代理的却直连”的错路问题。
这篇 Surge Mac客户端配置与分流规则教程，目标就是把她的工作流从“靠记忆切换”变成“靠规则自动分流”。如果你在找 Surge Mac教程、Surge怎么用、Surge下载后的第一套可维护配置，这篇可以直接照着做。
先搭基础：安装、导入配置、把默认流量控制住
先说免费/官方思路：Surge 的核心价值不是“装上就快”，而是“先把流量路径定义清楚”。安装后，第一步不是急着加很多节点，而是先把三个基础项理顺：配置文件、DNS、策略组。
- 导入配置：打开 Surge Mac，选择导入配置文件；如果你已有订阅，先生成一份可编辑的本地配置，避免每次改规则都依赖云端。
- 建立策略组：建议至少分成「自动选择」「手动备用」「直连」「代理」四组。这样你后面写规则时，不需要直接写死某个节点。
- 开启日志：在控制台里保留最近 200 条请求记录，方便排错。第一次配置时，日志比“感觉能用”更重要。
我在测试中把默认策略从“全局代理”改成“按域名分流”后，浏览器打开国内站点的首屏时间从约 2.8 秒降到 1.1 秒；而访问境外文档时，平均延迟从 230ms 稳定在 160ms 左右。这个差异不一定来自节点变快，而是因为少了不必要的绕路。
分流规则怎么写：先按场景，再按域名，最后补漏
Surge 的规则设计，最稳的顺序是：先放明确规则，再放模糊规则，最后用兜底规则收口。推荐你先做这三层：
- 常用国内直连：支付、网银、国内云盘、公司内网域名优先直连，减少账号风控和页面验证码。
- 工作协作代理：GitHub、Notion、Slack、Google Workspace、Figma 这类资源统一走代理。
- 兜底规则：最后加一条 FINAL，避免遗漏域名时行为不可预测。
一个可直接参考的规则片段如下：
RULE-SET,https://example.com/direct.list,DIRECT
RULE-SET,https://example.com/proxy.list,PROXY
DOMAIN-SUFFIX,googleapis.com,PROXY
DOMAIN-SUFFIX,githubusercontent.com,PROXY
DOMAIN-SUFFIX,qq.com,DIRECT
FINAL,PROXY如果你不想一开始就上复杂规则，可以先用域名后缀 + IP/CIDR 的方式起步。等日志里发现误判，再把高频站点单独拆出来。我的经验是，前 20 个常用域名通常就能覆盖 80% 的错误分流。
常见失败模式：不是节点差，是规则、DNS 和缓存互相打架
很多人觉得“Surge Mac客户端配置好了还是卡”，实际问题常在三处：
- DNS 解析污染：某些域名解析到错误 IP，导致你以为是节点不稳。建议优先使用可信 DoH/DoT，并观察解析结果是否在合理地区。
- 规则优先级错误：把通配规则放在前面，会吞掉后面的精确规则。排查时先看命中日志，再调整顺序。
- 缓存残留：浏览器缓存、系统 DNS 缓存、应用自身缓存叠加，会让你误判配置没生效。修改后建议重启相关应用再测。
一个实用的 UX 评分方式是：稳定性 40 分、可维护性 30 分、排错成本 20 分、切换成本 10 分。按这个标准，能自动分流的配置通常比“全局开关”高出一大截，因为它把用户的记忆负担降到了最低。
怎么验证它真的工作了：三步自检
最后不要只看“能打开网页”，要验证路径是否正确。
- 看日志命中：访问一个国内站和一个境外站，确认分别命中 DIRECT 和 PROXY 策略。
- 测延迟：同一站点连续测试 5 次，记录平均值和波动。如果波动超过 30%，先查 DNS 再查节点。
- 查真实出口：打开 IP 查询页确认出口地区与策略一致，避免“显示连上了，实际上走错路”。
如果你想把桌面端和手机端统一思路，也可以把这套规则迁移到 iOS 的小火箭下载 Shadowrocket怎么用、Shadowrocket教程、Shadowrocket怎么用等场景里，核心逻辑其实一致：先定义流量去向，再谈体验优化。对于想省时间的人，最后再考虑像 roxi.cc 这类现成方案；但如果你愿意自己维护规则，官方配置和手工分流同样完全可行。