Clash

概念

节点

我理解每个节点就对应一个独立的 VPN Server（具体内容可见 Tunnel）。不同的 VPN Server 效果不一样。其中比较好的有两种：

• IPLC (International Private Leased Circuit)：最好的，即私网传输
• CN2 (China Telecom Next Carrier Network)：本质是公网业务，但是似乎带宽比较高

协议

我理解协议就是建立宿主机到 VPN Server 的隧道所使用的协议，这些协议有的比较复杂，安全性有保证，但是性能就差一些，反之也是同理。

比较出名的协议包括 ShadowSocks 和 VMess：

对比项	Shadowsocks	VMess
开发者/项目	独立项目，后被社区维护	V2Ray 项目内置协议
设计重点	轻量加密代理，追求简单高速	高伪装、抗封锁、灵活组合
流量伪装	早期无伪装，后来有插件（如 obfs）	原生支持伪装成多种常见流量
加密方式	固定加密套件，一次设定	支持动态协商加密，可随时间变化
传输层支持	通常是 TCP/UDP 直连	可运行在 TCP、mKCP、WebSocket 等多种传输上
部署难度	很简单，服务器一个命令加客户端即可	相对复杂，需要配置 JSON 文件
抗封锁能力	较弱，容易被主动探测阻断	较强，设计时考虑了各类防火墙手段

当然传统的 HTTPS 也可以算一种协议。

订阅

我理解就是一组节点的集合。

机场

即卖订阅的服务商。

客户端

Clash 和 V2RayA 本质上都是 VPN 客户端。为什么我们不能像在 shell 中一样，简单使用一个环境变量就完成配置呢？

export https_proxy=http://127.0.0.1:7897 http_proxy=http://127.0.0.1:7897

这是因为 client 本质是 Tunnel 的一端的建立者，它需要兼容多种协议。

此外，client 还可以提供路由规则，将不同请求路由到不同的节点上。

最后 client 还可以使得不同应用程序都使用代理，也就是下文提到的“模式”。

模式

并不是说我们配置好代理了（本质是 LocalHost 上的一个端口），程序就会自己主动使用了，将自己原本发往墙外的请求自动发送到本地的 VPN 端口上。因此我们才需要让程序意识我们启用了代理。

System 模式

System 模式采用了一种类似于“设置环境变量”的方式来通知程序，如果程序开发者考虑了这个环境变量，那么就会主动把 request 发送到本地的 VPN 端口；而如果开发者没有考虑，那么程序就不会主动发送了。

因此 System 模式在浏览器等大型 APP 中表现较好，但是在一些小型程序中表现较差。

TUN 模式

开启 TUN 模式会更加全面地代理程序。原理是基于 TUN-TAP，也就是虚拟网卡，所有的流量都会经过这张虚拟网卡，进而代理会变得更加全面。

TUN 模式相比于 System 模式要更加全面，但是缺点是会比较重。

开启 TUN 后有可能会导致 wifi 图标显示感叹号，此时可以通过关闭“强制门户（captive portal）检测”来去掉感叹号。“强制门户”就是酒店或者机场 WIFI 使用的机制，它会将 HTTP 流量劫持到“登录界面”。“检测”会向一个 HTTP 网址发送信息，主动出发劫持，相当于主动触发登录界面。

可能是因为 TUN 也类似于“劫持”，导致触发了这个功能吧。我们可以通过创建 /etc/NetworkManager/conf.d/20-connectivity.conf 来关闭检测：

[connectivity]
enabled=false