This post is moved from istorie.net.
1. 前言
Shadowrocket / Quantumult / Quantumult X 这几款都是 iOS 上比较完善的网络加速 App，日常使用的话没有太大问题，但都有一个很大的共同问题：没有官方的详细说明文档，以至于具体的运行机制不甚明了，以至于各选项的具体含义需要靠自己探索。
这对于强迫症患者来说是极其难受的。本文就来列举一些在折腾过程中已经探明的运行机制、选项含义、以及遇到的 Bugs。
注意：由于现在网上已经充斥了一大堆这几款软件千篇一律的介绍科普文章，本文主要列举一些其他地方都找不到的选项含义以及 Bugs 。
2. Shadowrocket
这是我使用时间最长也是最喜欢的一款App，界面简洁明晰，iOS风格浓厚，但经历了几次大的更新之后却不太稳定了，Bug忽多忽少。另外，选项间的逻辑也不甚明确，有些选项令人费解，甚至已经失去了意义。
2.1. 运行机制
当前版本号 Version 2.1.37 (Nov 9, 2019)
完整支持 Shadowsocks 与 ShadowsocksR 的协议、插件、混淆。TCP与UDP使用相同的服务器与规则，这也导致了对大部分用户来说最有用且最值得夸赞的一个特性：UDP转发 (UDP Relay) 无需单独指定服务器节点，会使用当前使用的节点进行UDP转发，并且也会跟随设定好的分流规则进行转发；UDP连接也会记录日志以便调试。
2.2. 选项解析
1) DNS覆写
选项位置：底栏配置 ->选择一个本地文件编辑 -> 通用 -> DNS覆写
选项含义：
- 如果不设置，
- 则使用系统默认 DNS。 - 如果设置，
- 关键字system表示系统 DNS；
- 如果设置多个会同时查询，采用最先返回的那个，多个返回结果按照 ttl 缓存。 - 注意：指定的 DNS 均应为本地 DNS，故不要指定你想使用的远程 DNS 服务器地址。
2) 强制远程 DNS
选项位置：底栏配置 ->选择一个本地文件编辑 -> 任意一条域名规则 -> 强制远程DNS
该选项已失效（已与作者确认）！现在无论开不开启，都会对非直连的域名规则进行远程DNS解析。
这个选项应该是 Shadowrocket 以前的老版本中仿造 Surge App 运行机制时候的选项，当时是有效的。
现在 Shadowrocket 改变了运行机制之后，对所有在域名规则里面指定的域名都会默认进行远程DNS解析，所以这个选项已经没有意义了。
注意：对于 Final 规则而言，即使设置为 Proxy 也是不会走远程 DNS 解析的。该特性导致了一个后果：若使用白名单策略，无法对抗 DNS 污染。唯一解决方案：无论是黑名单还是白名单规则，都需要把已经被 DNS 污染的域名加入规则列表，否则被污染的域名无法被代理或被代理的是被污染后的错误IP地址。
3) IP-CIDR规则里面的 no-resolve （新版已经翻译为“不解析域名”）
选项位置：底栏配置 ->选择一个本地文件编辑 -> 任意一条IP规则 -> 不解析域名
- 如果勾上这个选项，则
- 若通过域名访问到了规则内定义的IP ，那么忽略这条规则；
- 若通过IP直接访问到了规则内定义IP，则满足这条规则； - 如果没有勾上，则
- 不管通过域名和IP访问到了指定IP，都满足这条规则。
4) 设置->服务器订阅->禁用随机
若关闭，则会从订阅返回的列表里随机选择几个节点。
5) 设置->用户代理->隐藏User-Agent（新版已变为“隐藏我的用户代理字符串”）
不隐藏的时候，请求订阅列表或者规则文件会使用Shadowrocket/*作为User-Agent，这样远程资源提供者就会知道你使用了Shadowrocket及相应的版本。
6) 场景/分组功能的使用与URL测试
说实话，全局路由里面的“分组”、“场景”、“速度测试”是逻辑最不清晰的几个功能，在这里先把逻辑说清楚。
a. 速度测试（URL 测试）是独立的一个功能，与场景功能无关
如果想简单实现自动根据延时大小切换节点（这应该是能够满足大部分用户的基本需求），那么需要按如下操作
- 在全局路由->分组设置中，对想要实现自动根据延时大小切换的节点建立一个单独的分组；
- 在全局路由->速度测试中，选择该分组，并启用URL测试；
- 在全局路由中，按需选择“配置”或“代理”；
- 返回到首页，任意选择一个包含在刚刚分组内的服务器节点；
- 运行。
b. 若在某个场景中选择了某个分组，那么无论是否启用了速度测试（URL测试）， Shadowrocket 都会对定期对场景内的分组进行URL测试。
因此，如果在全局路由里面选择了场景，请关闭速度测试（URL 测试）功能。是不是有点反直觉呢？
2.3. Bug汇总
2.3.1. 关于UDP转发的Bug（已修复）
即使指定为全局代理，UDP仍然不经过服务器中转，这是个严重的泄露问题。
当前状态：这个是很早之前的Bug，当前已修复。
2.3.2. 场景功能失效（已修复）
写这段话时的软件版本V2.1.37 (865)
这是个非常玄学的Bug，表现为App能够根据场景的不同选择正确的节点，App首页里面也显示了根据场景得出的正确节点，但在实际访问时，却仍然使用首页里面手动指定的节点进行代理。相当于场景功能完全失效，此时场景的实际效果=全局路由里面的“配置”。
当前状态：
- 已反馈给作者，作者已修复，但因尚未发布新版本，当前版本V2.1.37 (865)仍存在这个Bug。
- 该Bug在V2.1.39 (Nov 24, 2019) 中已修复。
2.3.3. 多跳代理功能不能使用AEAD加密（已修复）
写这段话时的软件版本V2.1.39
Shadowrocket 现以支持多层链式代理，即可以手动配置以达到“流量经过多个服务器跳转之后到达目的地”。方法也很简单，在编辑节点中有个转发选项，可以指定上一跳的服务器节点。
这个Bug比上个Bug更加玄学，表现为中转节点（即在转发选项里面设置的节点）不能使用AEAD加密算法（如AES-GCM、chacha-poly1305等），而使用AES-CFB等非AEAD加密算法时正常。
当前状态：
- 已反馈给作者，已修复。
3. Quantumult
3.1. 优点
Quantumult 作为后起之秀，也连续更新了好几年了。其最引人注目的特性是可以设置相互嵌套的策略。所以可以实现一些苛刻的针对不同场景自动切换节点以及自动分流的需求。
另外一个解决痛点的特性是其服务器延时检测使用的是“访问Google服务器成功得到HTTP响应的时间”，因此要比Shadowrocket的延时测试准确的多。
3.2. 缺点
Quantumult 对我最重要的一个问题就是其UDP转发机制的设计。这个设计对于日常使用影响不大，但对我来说可以认为是一个缺陷。
具体来说，Quantumult 的 UDP 转发只能单独指定服务器节点，并且不遵循规则。这造成如下问题：
- 当服务器节点根据场景自动切换时，用于 UDP 转发的节点是不会自动切换的，只能一直保持手动指定的那一个；
- UDP转发不遵循规则，所有的UDP包都会发往远程服务器进行转发。因此，即使发往国内的 UDP 包也都进行了远程转发（这点已经抓包验证过了），导致一些国内使用 UDP 协议的服务的质量严重下降（例如微信语音，相当于给国内的人打电话 UDP 包却在国外绕了一圈）。
解决方案：目前没有好的解决方案，对我而言我只能将 UDP 转发功能完全禁用（设置为 Reject ），即丢弃所有的 UDP 包。这样对于微信语音影响不大，因为微信在 UDP 不可达的情况下会让微信语音和视频通话的流量全部通过 TCP 发往腾讯服务器中转（这样至少是在国内中转了，影响不是特别大）。
4. Quantumult X
等待研究…
