Surge完全指南

10804 0 2016-04-27

Surge 这个是 iOS9 上的神器，作者虽然在官网说明 Surge 是开发者的网络调试工具，但是这个工具自打上架以来，其最广泛的应用场景绝对包括 iOS9梯子 这一刚需，iOS9 上有了 Surge 之后，iPhone 越狱的理由又少了一条。

Surge 会接管全局的（几乎）所有通信，所以所有网络方面的电量消耗都会被算在 Surge 头上，实际上 Surge 的运行功耗很少，使用中也不会感到 Surge 对电量有明显影响。

一、主要功能

Surge 的主要功能包括以下：

  • 截获 iOS 上的所有应用程序的 HTTP/HTTPS/TCP 流量，将其重定向到 HTTP/HTTPS/SOCK5 代理服务器转发。
  • 重载 iOS 蜂窝网络下的 DNS 服务器配置，使得 iOS 设备工作在蜂窝网络之下时，开发者也能够配置 DNS 服务器。
  • 记录设备所发出/接收的 HTTP 请求/应答首部信息。
  • 配置基于 domain, domain suffix, domain keyword, CIDR IP 以及 GeoIP 的过滤规则。
  • 对设备上 WIFI、蜂窝网络以及代理连接会话的流量进行统计以及测速。
  • 从 URL 或 iTunes 导入/导出配置文件。
  • 重度使用场景下有很高的性能以及适应性。
  • 基于 domain 规则屏蔽广告。
  • 完全兼容蜂窝网络。

二、软件构架

为了让使用者能够更好地理解 Surge 的各项配置的作用，作者在官网上特意花了一个章节描述其软件构架surge -guide

Surge 主要包括 Surge proxy server 与 Surge TUN interface 这两个组件，分别负责 HTTP/HTTPS 代理以及 IP 代理。

  • Surge Proxy server：Surge 功能开启后将自动代理 iOS 设备上所有的 HTTP/HTTPS ，同时对所有的 HTTP/HTTPS 代理使用同一个代理会话，以最高限度提高 Surge 的代理性能。Surge 可以通过 skip-proxy 指定哪些流量不被 proxy server 所代理
  • Surge TUN interface：iOS 上大部分应用程序的网络交互使用 HTTP/HTTPS，但也存在部分应用程序(如：iOS邮件客户端、Facebook客户端）等应用程序使用其他的通讯方式（如：SPDY等），这些应用无法被 Proxy server 所代理，这就需要使用更为底层的TUN interface 隧道方式。Surge 可以通过 bypass-tun 指定哪些数据流量不送 TUN interface 处理

注意：当前 Surge TUN interface 只能处理 TCP 流量，对于 ICMP、UDP 流量将被直接丢弃，因此需要通过配置 bypass-tun 选项来放行这些流量。

三、配置文件

Surge 可以通过 URL下载 、 iTunes更新 、iCould共享、Dropbox分享等多种方式导入配置文件——.conf（Uncode UTF-8），配置文件由多个段构成，主要包括：General、Proxy、Rule、Host等几个部分。

1.General——通用配置

通用配置段[general]的主要配置如下:

[General]
loglevel = verbose
bypass-system = true
skip-proxy = 192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12, localhost, *.local
bypass-tun = 192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12
dns-server = 8.8.8.8, 8.8.4.4

1）loglevel

这个是记录日志的几种方式，按日志输出从多到少分别为 verbose > info > notify > warning，默认为 notify。Analytics 模块中可以查看具体的 Logs，日志对分析 Surge 的使用状况很有帮助，打开具体日志能看到 Surge 的行为和动作。

一般情况下不要设置为 verbose ，这会大幅度降低 Surge 的性能，如果只是做为梯子使用，建议设置为输出最少的 warning 级别。

2）bypass-system

全局忽略配置，此配置列表中指定的服务器请求流量将不会被 Surge 所处理（包括 Proxy server 与 TUN interface），在一般使用中，请将以下服务器列入 bypass-system ，否则可能会出现一些奇怪问题（比如：应用程序的推送被延迟），添加 Apple 常用的服务器域名清单：

api.smoot.apple.com
configuration.apple.com
xp.apple.com
smp-device-content.apple.com
guzzoni.apple.com
captive.apple.com
*.ess.apple.com
*.push.apple.com
*.push-apple.com.akadns.net

同时也将 Apple 的服务器 IP 地址段过滤规则加上 IP-CIDR, 17.0.0.0/8, DIRECT, no-resolve 。

3）skip-proxy

skip-proxy 用于指定哪些服务器的 域名 和 IP 不被 Proxy server 代理，常用的有以下配置方式

  • 顶级域名，如 apple.com
  • 包含特定关键字的域名，如 *apple.com
  • 特定子域名，如 store.apple.com
  • 特定的IP地址以及IP地址段，如 192.168.2.11,192.168.2.*,192.168.2.0/24

做梯子使用时，可以考虑在这里添加常用的应用的域名以及整个中国区域的 IP 地址段。

需要特别说明的是主流应用程序，特别是现象级的应用，一般都广泛采用 CDN 技术对服务器请求进行加速，这种情况下同个域名在不同的地区及同地区不同时间都可能会请求到不同 IP 地址，因此要通过添加域名的方式匹配，而不能采用简单地添加指定 IP 地址。

4）bypass-tun

bypass-tun 用于指定哪些服务器的域名/IP不被 TUN interface 转发，配置的方式同 skip-proxy，需要特别注意的是 Proxy server 所代理的流量不会被 TUNN interface 代理，因此在配置 bypass-tun 时需要结合 skip-proxy 进行综合考虑。

5）dns-server

dns-server 用于指定 iOS 设备所使用的域名解析服务器，iOS 本身是不允许修改蜂窝网络下的域名解析服务器，通过使用 Surge 的 dns-server 配置则可以达到修改蜂窝网络域名解析服务器的目的。

2.Proxy——代理配置

代理配置段 [Proxy] 用于配置 HTTP、HTTPS 以及 SOCKS5 代理服务器（梯子的关键），配置的例子如下:

[Proxy]
ProxyA = http, 1.2.3.4, 3128
ProxyB = https, 1.2.3.4, 443, username, password
ProxyC = socks5, 1.2.3.4, 3129
ProxyD = custom,1.2.3.4,443,chacha20,password,module,ota=true

这个例子中，配置了四个服务器，分别对应于 HTTP、HTTPS、SOCKS5、SS这三种代理机制，Surge 可以针对这四个代理指定多套不同的配置：

  • 指定 HTTP/HTTPS 代理的用户名与密码（可选）
  • 指定 HTTPS 代理的加密机制，如 ProxyC = https, example.server.com, 443, username, password, cipher=TLS_RSA_WITH_AES_128_GCM_SHA256
  • 指定 TLS 会话重传，HTTPS 代理默认打开 False Start与ECN功能。（未来版本将支持 on/off 配置）
  • 如今最流行的shadowsocks，不必多说

3.Rule——过滤规则

[Rule]段用来配置 Surge 的过滤规则，规则按序存储，匹配时从上到下，先匹配先生效。因此对于常用的规则应该放在前头，以提高性能，配置的例子如下:

[Rule]
//基于域名判断并屏蔽（REJECT）请求
DOMAIN,pingma.qq.com,REJECT

//基于域名后缀判断屏蔽（REJECT）请求
DOMAIN-SUFFIX,flurry.com,REJECT
//基于关键词后缀判断走代理（Proxy），强制不尊重系统代理的请求走 Packet-Tunnel-Provider
DOMAIN-KEYWORD,google,Proxy,force-remote-dns
//基于域名后缀判断请求走代理A（Proxy）
DOMAIN-SUFFIX,google.com,ProxyA

//Telegram.app 指定“no-resolve”Surge 忽略这个规则与域的请求。 
IP-CIDR,91.108.56.0/22,Proxy,no-resolve 

//判断是否是局域网，如果是，走直连
IP-CIDR,192.168.0.0/16,DIRECT

//判断服务器所在地，如果是国内，走直连
GEOIP,CN,DIRECT

//其他的走代理B
FINAL ProxyB

Surge 支持 DOMAIN、DOMAIN-SUFFIX、DOMAIN-KEYWORD、GEOIP、IP-CIDR、FINAL 这六种规则，每条规则都由 类型、匹配域、行为 这三个部分构成（除了 FINAL 类型外），每个部分使用逗号隔开，每条规则可指定的行为包括：代理(Proxy)，不代理（DIRECT）和丢弃（REJECT）这三种。

六种过滤规则的配置如下：

  • DOMAIN，精确指定域名，DOMAIN,www.apple.com,Proxy，匹配所有发往 www.apple.com 的流量
  • DOMAIN-SUFFIX，按域名后缀匹配，DOMAIN-SUFFIX,apple.com,Proxy，匹配所有发往以 apple.com 结尾的流量，如 store.apple.com,mail.apple.com等，但不包括 issue-apple.com
  • DOMAIN-KEWORD，按域名关键字匹配，DOMAIN-KEYWORD,google,Proxy，匹配所有域名中包含 google 的流量，如: www.google.com, issue-google.cn 等
  • IP-CIDR，按 IP 地址无类匹配，IP-CIDR, 192.168.0.0/16,DIRECT，匹配所有到内网 192.168.0.0/16 的流量
  • GEOIP，按地理位置IP匹配，GEOIP,US,DIRECT 匹配所有美国IP的流量
  • FINAL，最终匹配的行为，这个必须放在最后，指定不能在前面任意一个规则匹配的流量行为

规则配置的高级选项中，「Force Remote DNS」的作用主要是用来解决本地 DNS 解析受到污染的问题，在添加针对 Google、Twitter 的规则时可以开启。

注：REJECT 过滤规则结合广告域名匹配可以过滤掉应用程序内部广告，这个真的很棒。

1）no-resolve

当有 Rule 中有 GEOIP 和 IP-CIDR 配置时，Surge 将对所有基于域名的请求流量进行域名解析代理，通过可选配置no-resolve 可以指定特定流量不运行域名解析代理，如：

GEOIP,US,DIRECT,no-resolve
IP-CIDR,172.16.0.0/12,DIRECT,no-resolve

2）force-remote-dns

基于 TCP 协议的应用程序在 TUN interface 模式中需要请求服务时，首先会发送域名解析请求，之后再发送 TCP 数据，如果域名无法在本地被解析，可以通过 force-remote-dns 配置域名在远程代理上进行解析，如：

DOMAIN,www.apple.com,Proxy,force-remote-dns
DOMAIN-SUFFIX,apple.com,Proxy,force-remote-dns
DOMAIN-KEYWORD,google,Proxy,force-remote-dns

注意: 这个仅对 TUN interface 有效，对于 Proxy Server 而言，所有的请求的 DNS 都是在远程代理上解析的。

4.保护配置

所有以#!REQUIRE-PROTECTED开头的配置都是保护配置，保护配置在 Surge 软件中将不会被显示，在你将私人配置发送给其他人共享时可以将私有信息设为保护配置。

注：这其也没啥用，配置文件本身是可读的，下载文件直接看就是了。

5.URL Scheme

Surge 支持 URL Scheme 满足重度/效率使用者的需求，不过按我估计，大概是作者不想被喷，于是就做了最基本的 URL Scheme，不然怎么会不支持切换配置文件的 URL Scheme，当前 Surge 仅支持三种行为以及一个选项：

  • 行为：start,stop,toggle
    • surge:///start，使用预先选定的服务器配置开启 Surge 服务
    • surge:///stop，关闭 Surge 服务
    • surge:///toggle，打开/关闭 Surge 服务
  • 选项：autoclose=true，当行为执行完毕时，自动退出 Surge 软件 surge:///toggle?autoclose=true

四、分析网络活动

Surge 分析模块中能直观看到 Surge 启动后最近地访问请求（Recent Requests）。

surge change rules01

还可以通过规则结果测试（Rule Test Results）临时调整规则（点击某条记录），REJECT、DIRECT 或者指定它走某个代理。临时调整的规则会在停用 Surge 并再次打开 Surge 后失效。

通过规则结果测试（Rule Test Results）可以方便地跟踪当前 App 的网络访问，临时改变规则后可以观察 App 的实际运行情况，如果有效随后就能补充到主配置文件中。

在 iPad 分屏模式的使用场景中，我经常干的一件事就是打开某个国产应用，然后分屏查看 Surge 里 Test Results 的网络访问情况，侦查那些和应用功能无关的隐私或广告请求，然后记录下来添加到自己的规则列表中。更多规则设置的内容可以阅读《Surge -如何抓包定制规则》

如果说 Surge 最吸引人的地方在哪里，估计就是这种透明的网络访问方式，在轻松访问各种网络服务以外还是一个强有力地调试工具。安全和隐私已经变成只有少数人才能掌控的东西，学习掌握一款这样的工具还是很重要的。

五、Dump Traffic to Disk

Surge 2.0 版本 Replica 已经被完全合并入 Surge 中，在设置中启动 Dump Traffic to Disk 后，所有 HTTP 协议的流量将会被抓取并存储。再也不用因为 Request 中只显示 20 条记录而担心采集不到想跟踪的 URL 了。

Dump Traffic to Disk 启用后，对应的配置文件中的 replica = 0 会变成 replica = 1，如果不想通过 Edit 来启用 Dump 模式，也可以通过修改配置文件的方式来启用它。

启动 Dump Traffic to Disk 后，请求列表中，可以直接看到图片缩略图。

六、AUTO GROUP

当 Proxy 中选择使用 Auto Group 时，Surge 会并发尝试通过该 Group 下所有的服务器去发起到目标 url 的请求，并根据最优结果选择哪个服务器将被使用。默认间隔 600 秒后需要重新发起测试，更多详细的参数介绍可以参阅这里 trello.com。

    • 不建议修改默认配置中的 URL 测试地址；
    • 为保证测速的基本公平，默认 URL 目标设置的是 gstatic.com 这样的在全球都有节点的 URL 作为测试目标；
    • 基于性能考虑，只支持使用 http 协议的 URL；
    • 为了避免资源浪费，Auto Group 中不应放入太多的线路，2–3 个即可。如 US 这样的线路不应该放入，因为几乎不可能赢得测试；
  • 不要使用 google.com 作为测试目标，这么做可能导致 proxy 服务器 ip 被加入黑名单，导致各种操作需要输入验证码；

七、Surge 2.0 配置上的变化

Surge 2.0 在功能上有了很多变化，配置文件很多部分会随着你升级自动更新，例如[URL Rewrite] 网址后自动添加上「header」，[General]字段部分自动添加 ipv6 = true、replica = 0，[Proxy] 字段部分自动给 HTTPS 代理添加「tls=true」等等。

还有些特性需要手动添加才可以，如：SSID 群组的支持、Surge-Cli 命令行的支持。

版本更新

    • 1.1.3 More 标签中摇一摇获取 Mac Beta 版本。
    • 1.2.0 (471) 版本加入 URL Rewrite 功能，用于解决 Google.cn 跳转问题。
    • 1.2.0 (476) 版本加入 Proxy Group 特性，废弃原「服务器覆盖文件方式」，解决了持续已久的 UDP 问题，Bypass-tun 设置只需保留内网段即可，不再需要加入中国段的全部 IP。
    • 1.2.0 (494) 版本加入服务器测速，修复 Cannot alloc memory 问题，界面变的更扁平化
    • 1.2.0 (497) 版本可以在通知中心切换服务器
    • 1.2.0 (508) 如果正在使用的配置文件通过 iCloud 被更新，Surge 会主动退出
    • 1.2.3 (545) 增加 Auto Group 群组，自动测速切换服务器。
    • 1.2.3 (560) Shadowsocks 协议加入 OTA 支持
    • Surge 2.0，Surge iOS 有了很多变化，具体细节可以看这里。
  • Surge 2.0 (610)，GEOIP 规则可以正确作用于 IPv6 和 IPv6 Mapped IPv4 地址了（解决最近微信刷新缓慢问题，之前 skip-proxy 加入的 ::ffff 可以删掉了）

参考：Alick的简书、scomper的medium