用户故事：一个运营经理的“网络切换疲劳”
林澈是跨境电商运营经理，早上看 Gmail、Slack，中午查 Shopify 后台，下午用 Notion 写周报，晚上还要测试 TikTok 与 Netflix 区域内容。他之前的流程是：Mac 上开一个代理客户端，全局模式；iPhone 上再研究“小火箭下载”和“Shadowrocket怎么用”。结果是国内网盘变慢、公司内网打不开、流媒体偶尔识别失败。
从产品体验看，他的核心痛点不是“有没有代理”，而是流量没有按任务分流。当前工作流：打开客户端 → 全局代理 → 遇到慢再手动切换。优化后工作流应是：启动 Surge Mac → 规则自动判断 → 工作站点走代理，国内服务直连，广告和追踪域名拒绝。
Surge Mac 客户端配置教程：从订阅到规则落地
先说免费/官方路径：Surge 官方文档、机场订阅说明、公开规则集都能完成基础配置，限制是需要你理解规则顺序；Clash Verge 等免费客户端也能分流，但在 Mac 端抓包、策略组可视化和调试体验上不如 Surge 细。
- 导入订阅：Surge Mac → Profiles → New Profile from URL，粘贴机场订阅地址。导入后在 Proxy 页面确认节点延迟。我在 500M 宽带下测试，日本节点延迟 42ms，新加坡 68ms，美国 148ms，测速用 Surge 内置测速和 fast.com 交叉看。
- 建立策略组：建议至少三组：PROXY、MEDIA、DIRECT。工作站点进 PROXY，Netflix/Disney+ 进 MEDIA，国内域名走 DIRECT。
- 写入基础规则：规则顺序从精确到宽泛，最后用 FINAL 收口。
[Rule]
DOMAIN-SUFFIX,google.com,PROXY
DOMAIN-SUFFIX,github.com,PROXY
DOMAIN-SUFFIX,netflix.com,MEDIA
DOMAIN-SUFFIX,bilibili.com,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY如果你在找“Surge分流规则怎么用”，记住一个原则：越具体的规则越靠前，兜底规则越靠后。否则 Netflix 可能被 GEOIP 或 FINAL 提前命中，导致区域不对。
UX 截图描述：理想的 Surge 首页应看到三块信息——左侧当前 Profile，中间策略组延迟，右侧 Recent Requests。调试时盯 Recent Requests，看域名命中了哪条规则，比盲目改配置高效得多。
分流矩阵、故障边界与验证方法
| 客户端 | 适合人群 | 分流体验 | 主要限制 |
|---|---|---|---|
| Surge Mac | 重度办公、开发、抓包用户 | 规则清晰，调试强 | 学习成本和价格较高 |
| Clash Verge | 预算敏感用户 | 订阅导入简单 | 细粒度排障依赖配置经验 |
| Shadowrocket iOS | 移动端用户 | 适合 iOS翻墙方案 | Mac 端不可用 |
我给 Surge Mac 的 UX 评分：导入订阅 8/10，分流可解释性 9/10，故障定位 9/10，新手友好度 6/10。最常见失败模式有三类：一是 DNS 污染，表现为域名解析到异常 IP；二是规则顺序错误，表现为站点走错策略；三是节点本身不可用，表现为所有规则都正确但连接超时。
建议在 DNS 段加入加密 DNS，并关闭不必要的增强模式后再测：
[General]
skip-proxy = 192.168.0.0/16, 10.0.0.0/8
dns-server = system, 1.1.1.1, 8.8.8.8
encrypted-dns-server = https://dns.google/dns-query如何验证已修好：打开 Surge 的 Recent Requests，访问 google.com 应命中 PROXY；访问 bilibili.com 应命中 DIRECT；打开 Netflix 搜索区域片源，确认 MEDIA 节点生效；再用 ping 或网页测速看延迟是否稳定在你可接受范围，比如日本节点低于 80ms 通常适合日常办公。
节点来源可以选择官方自建、朋友共享、免费试用或付费机场，各有维护成本与稳定性差异。如果你想少花时间筛选，也可以把 Roxi 作为候选之一，但仍建议先用上面的规则和验证流程自行测试。