Quantumult X 的链式代理配置 避免机场审计的一种方案
最近因为 Clash for Windows 作者被请喝茶的缘故，Clash 从内核到各平台客户端的仓库大部分都删库或者归档了，这也不能怪开发者太过风声鹤唳，毕竟还身在国内，写开源而已，犯不上和自己的人身安全作对。之前我一直都是使用 Clash 作为主要的科学上网工具，不过经此一役后我也在考虑是否应该放弃 Clash，于是我仔细梳理了一下目前对科学上网的需求，最终决定将 Clash 切换成 Quantumult X。
Clash 的缺点
其实我很早就觉得 Clash 在 macOS 上使用有一些不便：
- 如果想要修改订阅加上分流规则或者自定义的服务器，需要更改机场的配置文件，但是机场的订阅一般又会定时更新去覆盖掉；使用第三方的工具转化或者合并机场的订阅文件算是一个解决方案，但是机场一般出于隐私考虑都会禁止使用第三方工具转换订阅；
本质上 Clash 只是一个代理工具，无法确保在电脑上运行的各个程序的流量都由代理转发——很多软件的网络设置是不经由系统代理的，尤其是在终端的应用：pnpm，go get，curl，brew，ssh，这在软件开发的时候其实还挺烦人的，还需要单独为每一个应用设置代理，不同应用的配置方式还不一样。Clash X Pro 提供的增强模式算是一个解决方案，不过同样也已经下架了。
对于第一点，其实 Quantumult X 就做得很好，分流的规则以及机场的节点是分开配置的，而且无论你有多少不同机场的节点，你都可以通过新建一份分流规则来在所有节点之中切换，而且新建的分流规则并不会被机场本身定时更新的订阅所覆盖。
对于第二点，其实是代理工具和 VPN 的区别，像是 Cisco Anyconnect 这种 VPN 工具，会新建一个虚拟网卡，并新增一条路由规则让所有应用的流量都流经此网卡，也就不再需要单独为不同的应用设置代理选项了。Clash X Pro 的增强模式也是使用这样的解决方案。
注意，这种强制所有应用走代理与 Clash 提供的全局代理是不一样的概念，Clash 的全局代理意思是所有通过 Clash 的流量不经分流直接转发到机场节点。
机场的审计
对于稍微大一些的机场，都会添加各种各样的审计规则，也就是在服务条款里写的禁止访问政治敏感或者新闻等类型的网站。大部分的机场并不会写明具体是哪些网站被禁止访问，甚至也有些正常的网站会被「误伤」。
对于机场的审计规则我在一开始时表示很不理解，毕竟都科学上网就是为了突破封锁，怎么机场还又给上了一道锁。后来我想明白了，这类机场一般都是在国内有中转入口的机场，而中转服务器架设在国内一般情况管理会比家宽更加严格，本质上也只是机场主规避风险的一种手段。所以目前没有审计规则的机场，要么是直连境外的机场，要么是机场的规模不大，或者机场主愿意承担这种风险。对于前者，访问速度比不上中转机场，对于后者，我只能说：而你，我的朋友，你才是真正的英雄。
不过，机场的审计规则对用户来说，也确实也有隐私泄露的风险存在。有审计规则，那必然就有记录审计日志，也就意味着你访问的浏览记录都会被机场所记录，最坏情况下，机场因为某些不可抗力的因素或者是被黑了，流出了所有用户的浏览记录……
链式代理的原理
那么，何为链式代理？
其实和机场本身提供的中转类似，我们可以在机场线路外，再加上一层中转，也就是把机场的落地节点也当作是二次中转，而由我们自己的境外 VPS 提供真正的落地。网上有很多关于如何配置 Clash 的链式代理的教程，不过 Quantumult X 的却很少，所以我就来抛砖引玉了。
以日常使用的中转机场来举例：
先看不加上 VPS 的情况，我们的电脑到机场国内的中转服务器（Relay Proxy）是通过公网通信，中转服务器通常是国内的公有云（阿里云，华为云），然后再由中转服务器通过 IPLC/IEPL 等内网专线连接到海外落地服务器上，从而实现科学上网的功能。
需要注意的是，虽然 IPLC/IEPL 不会被墙，但是因为它仍然有一端是处于国内，因此从你的所在地到中转服务器的线路也直接影响到了科学上网的使用体验。而当你请求被机场封锁的域名时，连接在中转服务器时就会被丢掉，根本不会再往专线另一端发了，因为中转服务器才是运行 Shadowsocks 的服务端，它可以直接拿到访问请求的域名。
而在有 VPS 的情况下，我们就可以把机场线路的整体当成是中转服务器，由 VPS 来做落地（Final Proxy）。这样做的好处就是，流量会被加密两次，一次是中转机的加密，另一次是 VPS 的加密，而中转机拿到流量后，因此还存在一次加密，所以也根本看不到你具体的访问，只能看到是对 VPS 的访问，只有 VPS，才能看到你真正访问的域名。这样也能解决机场审计记录的隐私问题。
经过了两次加密和转发，性能可能会有些损耗，不过这在浏览网页时一般是感知不到的（跑测速可能有细微差异。
链式代理的配置
Quantumult X 配置链式代理不复杂，而且配置完成后，并不会被机场的定时更新的规则所覆盖：
VPS 配置
VPS 的服务端并不需要开启什么流量伪装或者混淆等复杂的配置，因为 VPS 与机场节点之间的连接并不过墙，设置一个稍微复杂一点的密码，选一个安全的加密方法即可，因此 Shadowsocks 就够用了，你可以参考我的配置。
添加 VPS 节点
在 Quantumult X 点击设置 -> 节点 -> 添加，把以上配置填进去，标签可以随意，我填的是 hh-jp。
或者在 Quantumult X 的 设置 -> 节点 -> 节点资源，这里可以加上 fast-open 和 udp-relay 参数：
shadowsocks=xx.xx.xxx.xxx:xxxxx, method=aes-256-gcm, password=xxxxxxxxx, fast-open=true, udp-relay=true, tag=hh-jp修改分流配置
在 Quantumult X 设置 -> 配置文件 -> 编辑，会弹出一个编辑框，在分流规则部分的尾部加入以下规则：
ip-cidr, xx.xx.xxx.xxxx, ♾️ Relay
# 有两种选择，直接给 final 加上中转
final, hh-jp, via-interface=%TUN%
# 或者针对特定域名加上中转，我比较推荐这种
host-suffix, xxx.xxx, hh-jp, via-interface=%TUN%其中第一行 ip-cidr 的规则，是为了让所有流经 VPS 的流量，都通过机场的节点进行中转，♾️ Relay 这个策略组是我新建的，你可以把它重命名为你目前现有的规则策略或者新增一个策略组来专门做转发。
我比较推荐后者，选择新建一个策略组并把与 VPS 在同一个地区的节点都加进来，这样从中转节点到 VPS 的延迟就会更低。
如果你觉得一个域名一个域名加比较麻烦，也可以直接针对 final 添加中转，需要注意如果已经存在 final 的规则，把原有的删掉。不过我并不推荐直接给 final 规则加上中转，因为我觉得 final 规则应该设置成距离自己最近、延迟最低的节点。
我为此写了一个简单的工具，可以更方便的管理需要链式代理的域名，可自行部署在 VPS 上。
如何确认配置成功
有两种方式：
在 Quantumult X 查看流量日志
在 Quantumult X 的网络活动菜单栏，请求配置后的中转域名，应该会有两条流量记录产生：一条记录的目标服务器是 HH-JP，也就是我配置的 VPS 节点名称；另一条记录的目标服务器就是 JAPAN 17，也就是机场的节点。
在 VPS 节点查看
在 VPS 运行命令：
$ lsof -i:[listen_port]
COMMAND PID USER FD TYPE SIZE/OFF NODE NAME
ssserver 21286 shadowsocks 11u IPv4 0t0 TCP [listen_ip]:[listen_port] (LISTEN)
ssserver 21286 shadowsocks 13u IPv4 0t0 UDP [listen_ip]:[listen_port]
ssserver 21286 shadowsocks 14u IPv4 0t0 TCP [listen_ip]:[listen_port]->[relay_ip]:[port] (ESTABLISHED)你需要查看，与 VPS 建立连接的这个 relay_ip 是否是你选择的中转策略的 IP，或者确认它不是你目前宽带的 IP 就行。
机场的选择
最后，还是谈谈机场的选择，我并不建议把机场是否有审计规则作为评价机场好坏的标准，因为可能科学上网 99% 的情况下都不会碰到被审计规则封锁的网站。而我在过去一年自费购买了差不多 10 家机场，其中只有一家规模不是很大的机场没有审计规则，这家机场的线路比较少但是流量又比较贵，因此我并不会推荐这家。
如果你不知道机场有审计规则这回事，那你就继续安心用；如果你目前的机场用的挺满意但是带有审计规则有点膈应，所以想换一个没有审计规则的机场，请慎重考虑。
目前的科学上网工具大部分都是支持链式代理的，我也比较推荐你用链式代理 + VPS 来绕过审计规则，如果你用的科学上网工具不支持链式代理，那么我推荐你换掉工具而不是换掉机场。