本文档适用于：Surge 1.2

在定制自己的规则之前，首先我们快速学习一下 Surge 分析模块的使用方法：

• 通过查看 Recent Requests 中的网络访问记录，了解当前 App 的网络请求状况（因为内存占用的限制 Surge 中会显示最近 20 条请求记录）；
• 打开你想观察的 App，然后切换到 Recent Requests 界面，刷新后就能直观地看到 App 的网络访问情况。

展开 Recent Requests 中的具体条目，可以了解以下几个关键信息：

• 具体是哪个应用发起的请求，时间戳前的方括号里显示着软件名称，（UserAgent，并不一定准确，仅供参考）;
• Policy，匹配当前配置文件中的哪一条规则，这里能看到访问是走代理（Proxy）还是直连（Direct）；
• Timing，创建连接的时长（Establishing connection） 传递时长（Transferring），通过时长可以判断连接的速度；
• Traffic Usage，流量使用情况，下行（Download）和上行（Upload）的数据量，如果这里显示 zero，说明没有实质地联通。

了解 Recent Requests 日志记录的具体作用以后，可以有目的地跟踪某个应用的网络访问。感觉某个应用的网络访问出现问题时也建议优先到这里来判断。

一、规则列表中的最后两项

规则列表中只有必要的一些域名或 IP，大多数时候 Recent Requests 记录的 Policy 部分，能看到的是规则配置文件最后两项判断：

• DIRECT（GEOIP CN → DIRECT），域名判断结果如果是中国走直连；
• Proxy（FINAL → Proxy），兜底规则，前面规则判断完还没明确的基于这条规则走代理。

从这里也能看出规则表的自定义中，至少要保留最后一条「FINAL,Proxy」规则体系才是完整的，而倒数第二条国别判断可以根据你所在的国家进行修改。

二、Recent Requests 记录和规则添加

规则按照顺序从前往后执行，根据规则判断后的行为（REJECT、DIRECT、Proxy）决定是拒绝、直连还是走代理。

每条具体的 Recent Requests 记录能告诉我们很多信息。例如，请求的具体软件是哪一个，连接采用的 HTTP 方法是 GET（请求数据）还是 POST（提交数据），由 Proxy Server 模块处理的连接显示是 HTTPS，由 TUN Interface 处理的连接显示则是 TCP（IP 地址的连接）。

展开具体的 Recent Requests 记录（点击记录展开和收缩），我们能看到匹配的具体规则是哪一条，如果是上述提到的最后两个判断，可以考虑是否需要添加新的规则。

规则添加中我们会用到的几种判断方式：判断域名（DOMAIN）、域名后缀（DOMAIN-SUFFIX）和关键词（KEYWORD）。关键词的覆盖面是最广的当然也很容易导致误判，其次是域名后缀，最准确的是基于完整域名的判断。

根据 Recent Requests 记录添加基于域名的规则是最准确的，但是很多时候软件公司有多个二级域名，例如：m.163.com、api.163.com、log.163.com，如果用域名匹配的规则要写 3 条，但是换成域名后缀的方式 1 条 163.com 就能涵盖。

少数情况下需要添加基于 IP 地址的规则，如果请求的是主机名（Hostname），需要在规则后加上「 no-resolve」，告诉 Surge 不要去尝试解析来匹配这条规则，只处理「直接 IP 访问」的请求。

最后，在正式将规则加入到配置文件之前，建议先在规则结果测试（Rule Test Results）里找到具体的规则，临时调整规则（点击某条记录选择 REJECT、DIRECT 或 Proxy）观察一下对现在运行的 App 是否有影响。

网上分享的规则配置大多数是根据各自使用情况添加完善的，并不一定具有普遍适应性。

借鉴他人的配置文件，可以将其复制到 Numbers 中进行排序，这样能有效检查出重复条目，Gist方式分享的配置文件中可以从网站右侧选择「Revisions」查看版本变动情况。

三、Force-remote-dns 选项

Force-remote-dns 选项主要是为了解决有些域名在本地查询有障碍的问题（如公司内网域名）。

当域名带有 force-remote-dns 选项时，Surge 会直接返回一个 240.1.x.x 的 fake IP 并反向查出真正的域名是什么，避免本地的 DNS 查询动作。

这样虽然避免了本地 DNS 可能带来的干扰问题，但是因为返回了一个 fake IP，而 Surge 没有权限去强制清除系统或者应用的 DNS cache，所以在 Surge 关闭后可能导致一些问题，所以请谨慎的只给确实需要的域名开启这个选项。

四、「SKIP PROXY」和「BYPASS TUN」

配置文件最开始的几行，也是高级选项中的两项设置「SKIP PROXY」和「BYPASS TUN」目的是用来解决一些应用的兼容性问题。

通过指定具体域名（apple.com或者*apple.com）或者 IP（192.168.2.* 或 192.168.2.0/24）让这类请求绕过 Surge 代理服务器和 TUN 接口。因为 Surge 启用后整个系统只有 TCP based 的协议可以使用，UDP 和 ICMP 等其他协议将被丢包（DNS 除外），对于部分国内的使用 UDP 的应用 （微信语音、小蚁摄像头），可以用 bypass 掉所有国内 IP 的方式来解决兼容问题（范例配置文件中已经包含）。

Bypass-tun 之后对应 IP 地址的访问就不再走 Surge 了，所以规则中基于 IP 地址的规则如果已经被 Bypass-tun 中的地址段覆盖会无效。

SKIP PROXY 里域名或IP会直接跳过代理，当然也意味着它们不走规则判断。日志里我们经常会看到 Surge 自己发送到 e.crashlytics.com （统计 Crash 的工具， Twitter 旗下的 Crashlytics 服务）的网络请求， 这个不建议 REJECT ，但是又不想在 Recent Requests 记录里看到它，可以把它加入到「SKIP PROXY」。

skip-proxy = 192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12, 100.64.0.0/10, localhost, *.local, e.crashlytics.com

五、合理使用 REJECT 规则

规则中添加 REJECT，可以用来拦截隐私和广告请求，但是有些应用会无限制的尝试重新连接。

由于 REJECT 速度很快，这会导致 Surge 短时间内收到大量请求，最后因为内存使用过多被系统 Kill。

同样因为 Surge 在内存使用上的限制，不建议创建过多的规则。

六、直连和代理都能联通的情况

很多服务直连或者代理都可以访问，访问速度主要取决于你连接的网络运营商或代理服务器，两者速度差不多的情况下没有必要单独添加规则来指定究竟是走代理还是直连。

Recent Requests 具体记录的 Timing 部分是可以看到连接响应的时长，通过这里可以有针对性的判断哪些服务走代理，哪些走直连。不过切换不同的代理服务器以后这里的数据也会随之变化，白天网络流量高峰期和晚间也会有差别。

 小结

总之，规则定制是一个可大可小的坑，建议结合自己的使用环境适度调整和定制，保持手机应用环境的良好是根本的解决之道，不必要的、功能重复的、免费国产的（特别是游戏类）应用少装或者不装。

转自：Medium