Clash 代理协议与内核选型参考

Ⅰ协议谱系总览:从 SOCKS5 到 QUIC 世代

代理协议是客户端与远端服务器之间的一套约定:数据以什么格式封装、用什么方式加密、凭据如何校验、传输走 TCP 还是 UDP。Clash 系客户端的定位是规则的执行者与协议的实现者——它本身不发明协议,而是把各社区已经公开的协议逐一实现,交给规则引擎统一调度。因此选用哪个协议,实际上是在选用服务器端与客户端共同支持的一种封装格式;客户端能力再强,也运行不了服务器不提供的协议。

还要区分协议的两个方向。入站方向是本地应用如何连进客户端:浏览器与系统代理走 HTTP 或 SOCKS5 端口,这两个协议只负责进门,不出现在订阅里。出站方向才是本卷的主角:客户端把流量封装成 SS、VLESS 等格式发往远端服务器。日常所说的选协议,选的始终是出站一侧。

谱系与诞生背景

SOCKS5 与 HTTP 代理是最早的通用代理形式,只负责转发、不定义加密,今天仍作为 Clash 的本地入站协议使用。约 2012 年,Shadowsocks 把对称加密引入代理协议:把流量加密后发给远端,服务器解密再转发,协议本体保持极简,十余种编程语言都有实现。约 2016 年 V2Ray 项目发布,其原生协议 VMess 走了另一条路:全量加密、时间戳认证、可更换传输层,把可配置性推到很高的位置。约 2018 年出现的 Trojan 提出伪装优先:让代理连接在外形上与一次普通 HTTPS 访问一致,认证只靠一个密码。约 2020 年,VLESS 作为 VMess 的简化版问世,把加密职责交还给 TLS,头部更轻;同一时期,基于 QUIC 的 Hysteria 与 TUIC 先后出现,用 UDP 换取弱网下的吞吐,Hysteria2 是前者的修订版。六条线索,构成今天 Clash 配置里 proxies 段的主要候选。

条目速览

下表把六类协议并排著录,先建立整体印象,细节见后续各章。

读这张表抓住三个维度就够:封装与外形——协议是否自带伪装、流量呈什么形态;开销与性能——握手几个往返、加密占用多少处理器、弱网下吞吐保持如何;生态与支持度——服务端是否普遍提供、客户端内核是否实现、订阅格式是否覆盖。后文每一条目都按这三维展开。

与规则引擎的关系

必须分清两个层面:协议决定单个连接怎么发,规则决定哪个连接走哪条协议。Clash 的规则引擎在协议之上工作:一份配置里可以并存 SS、VLESS、Hysteria2 三种节点,由规则按域名、IP 段、进程名把流量分给不同策略组,策略组再绑定具体节点。因此选协议与配分流是两件事,前者看本卷,后者的完整实战参见《Clash 规则分流配置实战》一文。

ⅡShadowsocks:轻量加密的起点

Shadowsocks(缩写 SS)是 Clash 支持历史最久的代理协议,也是订阅里出现频率最高的一类。它的设计目标一句话可以说完:用尽可能少的握手与尽可能简单的格式,把 TCP 与 UDP 流量加密转发到远端。

设计目标与封装格式

SS 的会话没有握手阶段:客户端把目标地址、端口与负载一起加密后直接发出,服务器用同一把预共享密钥解开,读出目标地址再转发。密钥由用户密码经密钥派生函数生成,主密钥之外每个连接再派生子密钥,避免重放。因为无握手,SS 的首字节延迟在 TCP 系协议里最低;因为格式简单,一个完整实现只需几百行代码,从路由器固件到浏览器插件都有移植。

SS 原生定义了 UDP 中继:客户端把 UDP 数据报加密后送到服务器代为收发,游戏、语音通话与 QUIC 建连都依赖这一能力。Clash 配置里的 udp: true 即打开此开关;节点若用于游戏,除打开开关外还应确认服务商一侧未限制 UDP 中继。

SS 还有一组插件生态(如 simple-obfs、v2ray-plugin),可在 SS 外层再包一层混淆或 WebSocket 传输,mihomo 通过 plugin 与 plugin-opts 字段支持其中一部分。插件属于叠加层,不改变 SS 本体格式。

加密套件:迁移到 AEAD

早期 SS 使用 aes-256-cfb、chacha20-ietf 这类流密码,只加密不校验完整性,后来被证明存在可被主动探测利用的缺陷,社区遂整体迁移到 AEAD(带认证的加密)。当前可用的三件套件是 aes-128-gcm、aes-256-gcm 与 chacha20-ietf-poly1305:前两者在有 AES-NI 指令集的桌面与服务器处理器上几乎零开销;后者不依赖硬件指令,在手机与低端路由器的 ARM 芯片上反而更快。其后社区又提出 2022-blake3-aes-128-gcm 等新套件,shadowsocks-rust 与 mihomo 均已实现,用 BLAKE3 做密钥派生并强化重放保护,新部署可优先考虑。

适用场景与局限

SS 的局限同样来自它的简洁:协议没有伪装层,加密流量在外形上是长度随机、内容高熵的数据流,与正常 HTTPS 的 TLS 记录形态不同;协议也不定义服务端的多用户管理,一个端口对应一把密钥。因此 SS 适合作为够用就好的通用选项——实现广、开销低、维护省心;追求外形伪装时,则看第四章的 Trojan 与第三章的 VLESS。

客户端配置要点

在 Clash 配置里,SS 节点只需 server、port、cipher、password 四个必填项,udp 控制 UDP 转发。cipher 必须与服务器端严格一致——写错套件是 SS 节点连不上的首要原因,排查时先核对这一行,再核对密码与端口。若服务商给出的是 ss:// 分享链接,导入客户端时会自动展开成下列字段,无需手写。

proxies:
  - name: "ss-aead"
    type: ss
    server: example.com
    port: 8388
    cipher: aes-128-gcm
    password: "your-password"
    udp: true

ⅢVMess 与 VLESS:V2Ray 系的两次迭代

VMess 与 VLESS 同出 V2Ray 项目(其后分裂出 V2Fly 与 Xray 等分支):前者是项目的原生主力协议,后者是反思前者复杂度之后的减负版。理解这两代之间的取舍,就理解了代理协议的一个核心分歧——加密应该放在哪一层。

VMess:全量加密的设计

VMess 的思路是协议自身完成全部安全:请求头含用户 UUID、时间戳与校验,整个会话用 AES-128-GCM 或 ChaCha20-Poly1305 加密,不依赖外层 TLS。时间戳认证要求客户端与服务器时钟误差在约两分钟以内,这是 VMess 排错时最先要检查的点——设备时区错乱、未开网络对时都会触发认证失败。早期 VMess 的 alterId 参数用于派生多份密钥,后来被证明削弱安全性,新版实现已将其废弃,配置里见到 alterId 非零应视为过时写法。

VMess 的 UUID 同时承担用户标识,服务器端据此做多用户分流与流量统计;这也是 vmess:// 分享链接字段最多的原因——一段 Base64 编码的 JSON,要装下地址、端口、UUID、传输层、TLS 开关与伪装域名。

VLESS:把加密交还给 TLS

VLESS 的命名即态度:去掉 VMess 的加密层,协议头只保留 UUID 与极少控制字段,加密完全交给外层 TLS。好处是双重的:头部更短,处理器不再做二次加密;配合 XTLS Vision 流控(flow: xtls-rprx-vision)时,TLS 记录可以直通转发,再省一次加解密拷贝。代价是 VLESS 必须搭配 TLS 使用——裸跑的 VLESS 没有保密性可言,mihomo 等内核也只接受 TLS 形态的 VLESS 节点。

Xray 分支后来在 VLESS 之上又提出 REALITY 形态:不签发自己的证书,而是借用真实站点的 TLS 外形完成握手,省去域名与证书维护,mihomo 以 reality-opts 字段支持。它属于 TLS 层的又一类取舍:部署更简,配置项更多,普通使用方仍以服务商给定的订阅为准。

传输层:WS、gRPC 与中转

V2Ray 系的另一块拼图是传输层(network):ws 把流量装进 WebSocket 帧,grpc 装进 HTTP/2 流,二者都能套 TLS 并伪装成普通网站流量。这套组合的实际价值在于可以挂在 CDN 后面:域名解析到 CDN,CDN 回源到服务器,真实地址不外露,还能借用 CDN 的接入点改善绕路线路。Clash 系内核完整支持 ws 与 grpc 传输,配置里以 network、ws-opts、grpc-opts 字段描述。

二选一的结论

新部署选 VLESS + TLS,旧节点维持 VMess 即可。VMess 的全加密在无 TLS 场景仍有意义;但有证书的条件下,VLESS 的低开销与直通转发全面占优。对应配置形如:

proxies:
  - name: "vless-vision"
    type: vless
    server: example.com
    port: 443
    uuid: "00000000-0000-0000-0000-000000000000"
    network: tcp
    tls: true
    udp: true
    flow: xtls-rprx-vision
    servername: example.com

ⅣTrojan:伪装优先的设计哲学

Trojan 的设计文档开篇即给出判词:与其费心把代理流量混淆成别的样子,不如让它直接是别的样子。Trojan 连接在外形上就是一次标准的 TLS 会话,协议本体藏在 TLS 之内,认证只靠一个密码的散列值。

TLS 即本体

Trojan 服务器监听 443 端口,对外表现为一个正常的 HTTPS 站点:证书有效、握手标准;收到无法认证的连接时,可以把流量回退(fallback)给一个真实网站处理。认证通过后,TLS 记录内承载的是极简的 Trojan 请求头:密码散列、目标地址、负载。协议自身不做任何加密——加密完全由 TLS 提供。这与 VLESS 的思路一致,只是 Trojan 出现更早、格式更简。

Trojan 的伪装还依赖一个细节:服务器必须真的像网站。仅有有效证书、443 端口上却没有任何网页内容的站点,在主动访问探测下反而显眼,因此多数部署会在 fallback 后挂一个真实页面。这一层属于服务器运维,客户端无需关心,但选型时应知道:像不像,取决于服务端的完成度。

与 VMess + TLS 的异同

同样是 TLS 里跑代理,Trojan 与 VMess + WS + TLS 的差异在层次数量:后者是 TLS 套 WebSocket 再套 VMess 三层封装,前者只有 TLS 套 Trojan 两层。层次少意味着开销小、实现短,也意味着可配置项少——Trojan 没有传输层花样,只有 TCP + TLS 一种形态。需要 CDN 中转时,Trojan 也可以走 WebSocket(多数内核支持),但那就回到了多层封装的老路。

Trojan 的 UDP 支持走协议内命令字:UDP 数据报被封进 TLS 流内传输,客户端配置同样以 udp: true 打开。因为 UDP 被裹在 TCP 里,丢包敏感场景下它继承了 TCP 的全部特征——这一点与第五章原生 QUIC 的 UDP 转发形成对照。

部署前提与客户端配置

Trojan 的简洁是有价格的:部署者须持有域名与有效证书,证书通常经 ACME 自动签发,域名解析到服务器。对纯使用方而言这些由服务商完成,客户端侧只需 server、port、password 与 sni 四项。sni 必须与证书域名一致;skip-cert-verify: true 会关掉证书校验,等于放弃 TLS 的防伪能力,只在自签证书的测试场景临时使用,正式配置应保持 false。

proxies:
  - name: "trojan-tls"
    type: trojan
    server: example.com
    port: 443
    password: "your-password"
    sni: example.com
    skip-cert-verify: false
    udp: true

性能上,Trojan 的开销几乎等于一次纯 TLS 会话:握手两到三个往返(TLS 1.3 可复用会话缩短),传输期一次对称加解密。桌面与服务器上这与 HTTPS 浏览无异;在移动端,TLS 会话保持与 TCP 保活是主要的电量来源,详见第六章。

ⅤHysteria2 与 TUIC:QUIC 世代的速率协议

前四章的协议全部跑在 TCP 上。TCP 的可靠传输是有代价的:丢包时整条流排队等重传(队头阻塞),高丢包线路上吞吐断崖式下跌。QUIC 把可靠传输搬进用户态、跑在 UDP 之上,允许按流独立重传,还附带 0-RTT 握手与连接迁移两件基础设施礼物。Hysteria2 与 TUIC 是 QUIC 代理协议里实现最广的两个。

Hysteria2:速率优先

Hysteria2 是 Hysteria 的修订版,协议做了一次大瘦身:认证简化、控制面收敛,核心卖点落在拥塞控制上。它自带的 Brutal 拥塞控制不随丢包退让,按用户声明的带宽目标持续发送;在丢包率高但物理带宽充足的链路上(跨洲无线、拥塞的晚高峰出口是典型),吞吐可达 TCP 系协议的数倍。代价同样直白:Brutal 不看网络脸色,带宽目标填高了会挤占同链路的其他流量,也可能触发运营商对 UDP 的限速策略。配置里的 up 与 down 字段就是这条速率声明,单位 Mbps,应按服务器实际带宽填写,而不是越高越好。

Hysteria2 生态还有一个 mihomo 已实现的实用特性:端口跳跃。服务器监听一个端口段,客户端按约定在段内跳动发包,配置里以 ports 字段写成区间形式。该特性用于规避单端口限速,属于链路层技巧,不影响协议本体格式。

TUIC:低开销的 QUIC 封装

TUIC 的目标与 Hysteria2 不同:追求 QUIC 之上尽可能少的附加开销。协议原生支持 UDP 转发,且提供两种 UDP 模式——native 把 UDP 数据报直接映射进 QUIC 数据报,quic 则把 UDP 包也纳入可靠流传输;前者适合游戏、语音这类对延迟敏感的真实 UDP 场景。TUIC 沿用 QUIC 自带的拥塞控制,不做激进加速,行为更守规矩,在 UDP 被限速的网络里退化得更平缓。

QUIC 把拥塞控制做成了可插拔:TUIC 的 congestion_control 字段可选 bbr、cubic 等算法。粗略地说,cubic 是保守的通用默认,bbr 按带宽与延迟建模、在缓冲较大的链路上更稳。普通使用者保持默认即可;知道有这个旋钮,速度不对时便多一个排查方向。TUIC 的 heartbeat_interval 控制心跳间隔,直接影响待机耗电,移动端可放宽到数秒以上。

连接迁移与 0-RTT

QUIC 的两件礼物值得单独著录。0-RTT:再次连接同一服务器时,首个数据包即可携带负载,省去握手往返,代理的冷启动体感接近直连。连接迁移:连接以 Connection ID 标识而非四元组,手机从 Wi-Fi 切到蜂窝、或基站间切换导致 IP 变化时,连接不断线、不重建,正在进行的下载与通话无感知。这两条对移动端的意义远大于桌面,第六章会再次引用。

proxies:
  - name: "hy2"
    type: hysteria2
    server: example.com
    port: 443
    password: "your-password"
    up: 30
    down: 200
    sni: example.com

Ⅵ速度、资源占用与移动端电量:横向对比

协议对比最容易被误读成哪个最快。诚实的答案是:线路良好时,六类协议的吞吐差异通常小到难以察觉,瓶颈在服务器带宽与运营商线路;协议差异只在三个边缘场景显形——握手延迟、弱网吞吐、设备开销。本章按这三轴对照。

另一个常被高估的指标是跑分。测速站点打满带宽的能力,更多取决于服务器出口与晚高峰拥塞;协议跑分的参考价值,不如同一线路换协议各测三次的朴素对照。若要做自己的实验:固定服务器与时段,只换协议类型,各测三次取中位数,再换时段复测一轮——变量只剩协议时,结论才有意义。

握手与首字节延迟

TCP 系协议先完成 TCP 握手(一个往返),带 TLS 的再加 TLS 握手(TLS 1.3 一个往返,复用会话可归零);SS 无协议握手,总开销最低,Trojan 与 VLESS 次之。QUIC 系首次连接一个往返,再次连接 0-RTT。在 200 毫秒级延迟的跨洲线路上,再次访问场景下 Hysteria2 与 TUIC 的首字节能比 TCP + TLS 系快出近半秒——刷网页、短连接接口调用时体感明显。

处理器、内存与设备开销

传输期的处理器消耗主要是对称加密:有 AES-NI 的 x86 设备上,AES-GCM 单核可跑数 Gbps,协议开销可以忽略;无 AES 指令的 ARM 设备上,ChaCha20-Poly1305 比 AES-GCM 快约两到三倍,这是移动端推荐 chacha20 系套件的原因。内存方面,各协议单连接占用都在 MB 级以下,真正的内存大头是内核的规则集与连接跟踪表,与协议无关。路由器等百兆级处理器的设备上,避开双层加密(VMess 内加密再套外层 TLS)能省出可观余量——这是 VLESS 与 Trojan 相对 VMess 的实在优势。

移动端电量

移动端的耗电大头不是加解密,而是射频模块的唤醒次数。TCP 长连接依赖保活包维持地址映射,每次唤醒都耗电;Wi-Fi 切蜂窝时 TCP 连接断裂,重连握手又是一轮射频活动。QUIC 的连接迁移让切换不断线,0-RTT 让必需的重连更快,两者叠加,Hysteria2 与 TUIC 在频繁移动的使用日里,电量与流量开销都低于 TCP 系。反向因素也存在:心跳间隔若设得过短,待机唤醒反而更密,相关参数应按宁长勿短调整。

六维对照表

表中没有全能冠军:SS 赢在实现广度与低延迟,QUIC 系赢在弱网与移动场景,Trojan 与 VLESS 赢在外形与低开销。实际选择时先看服务商提供什么(第八章),再在已提供的协议里按本章三轴取舍。

Ⅶ内核家族:原版 Clash、Meta 与 mihomo

Clash 一词在生态里同时指三件事:一个内核、一类配置格式、一族客户端。分清这三层,是理解一切兼容性讨论的前提。内核是实际干活的程序:监听本地端口、解析规则、按协议发包;客户端是内核的图形外壳;配置格式是两者之间的契约。

原版 Clash 的归档

原版 Clash 内核由 Dreamacro 维护,用 Go 写成,确立了 YAML 配置格式、规则引擎与策略组体系——今天所有 Clash 系客户端的语法都源自它的定义。2023 年末,作者将仓库归档、停止维护,闭源的 Premium 分支同步停更。归档不是失效:原版内核至今能跑,SS、VMess、Trojan 等老协议照常工作;但 Hysteria2、TUIC、VLESS 等新协议与 rule-set 规则集等新特性,永远不会再出现在原版里。

Clash Meta 与 mihomo 的继承

Clash Meta 是社区在原版停更前就已开始的增强分支,目标是补齐原版缺失的协议与能力;原版归档后,它成为事实上的继承者,并在其后更名为 mihomo。相对原版,mihomo 的主要增量包括:VLESS、Hysteria2、TUIC、WireGuard 等协议支持;rule-set 规则集,把大量规则编译成二进制格式按需加载,替代逐行文本匹配;DNS 模块的 nameserver-policy、fallback-filter 等细粒度控制;以及 TUN 入站、进程名匹配等系统级能力。今天活跃的客户端——Clash Plus、Clash Verge Rev、FlClash、Clash Nyanpasu、Clash Meta for Android——全部以 mihomo 为内核。生态各项目的来龙去脉,《Clash 开源生态梳理》一文有完整谱系,本卷只取与选型相关的部分。

配置兼容性

兼容方向是单向的:为原版写的配置,绝大多数能在 mihomo 上原样运行;为 mihomo 写的配置,用到新字段的部分原版不认。实务上只需记住两条。其一,老客户端(Clash for Windows、旧版 ClashX)只认原版字段,订阅里出现 hysteria2 类型节点会被跳过或报错。其二,mihomo 对个别字段做过语义调整,例如 dns 段的 default-nameserver 必填化;从原版迁移配置时若启动报错,按报错行逐项对照官方文档即可,通常是字段补齐而非改写。

客户端与内核的对应

安装包页的包清单按此编排:全平台首推的 Clash Plus,桌面主流的 Clash Verge Rev 与 FlClash,安卓的 Clash Meta for Android,均为 mihomo 系;标注已停止维护的 Clash for Windows 与 ClashX Meta 停留在旧内核时代,仅作归档保留。在图形客户端里,内核切换通常是一个开关:Clash Plus 与 Clash Verge Rev 在设置页提供内核版本与更新通道,FlClash 把内核内嵌、随客户端整体升级。普通使用者无需手动替换内核二进制;手动替换属于进阶操作,替换后先用 -t 参数校验配置再启动。实用结论是:新装一律选 mihomo 系客户端,旧客户端能跑则跑、坏了再迁。

Ⅷ订阅格式与配置兼容性

订阅是服务商与客户端之间的运输格式:一个 URL,客户端定期拉取,得到一批节点与规则。生态里并存两种形态:Clash 原生订阅(一份完整 YAML)与通用分享链接(一组 ss://、vmess:// 链接的合集)。mihomo 系客户端两种都能导入,但二者信息量不同。

Clash 原生订阅

Clash 订阅返回的是一份完整或近乎完整的 config.yaml:proxies 段列节点,proxy-groups 段预置策略组,rules 段带分流规则。服务商在订阅里预排好自动选择、手动选择、兜底等策略组,用户导入即用。好处是规则与节点同源维护,服务商更新规则时用户无感;代价是各家规则取向不同,换服务商等于换一整套分流习惯。mihomo 系客户端导入 Clash 订阅时,通常允许选择仅导入节点或整份采用:前者保留本地规则,后者连规则一起换成服务商版——理解这个开关,能避免规则突然被覆盖的困惑。

通用分享链接与订阅转换

通用订阅返回按行排列的分享链接:ss:// 与 trojan:// 是 URI 格式,vmess:// 是 Base64 编码的 JSON,vless://、hysteria2://、tuic:// 各有 URI 约定。这类订阅只含节点、不含规则,客户端导入后套用自己内置的规则模板。把通用订阅翻译成 Clash 格式的服务叫订阅转换:在线服务或自托管程序按模板生成 YAML。转换的隐私含义要清楚:订阅链接里包含服务器地址与凭据,经第三方转换等于把节点信息交给对方——敏感节点应使用自托管转换,或客户端内置的解析能力(mihomo 系客户端大多支持直接导入通用订阅)。

字段层面的内核差异

同一节点在不同内核里的字段写法大体一致,差异集中在三处。其一,新协议字段:hysteria2 的 up 与 down、tuic 的 udp_relay_mode 等只有 mihomo 认识。其二,传输层嵌套:ws-opts 下的 headers、grpc-opts 的 service-name,各家解析器对缺省值的容忍度不同。其三,规则段:rule-providers 与 rule-set 是 mihomo 扩展,原版内核遇到会报错。手动改订阅 YAML 时,改完用客户端的配置校验或内核的测试参数跑一遍,比直接重启排错更快:

mihomo -d /etc/mihomo -t

订阅在 mihomo 配置里还有更工程化的形态:proxy-providers 把节点清单声明为外部来源,按 interval 定时刷新,health-check 定时测速,配合 url-test 策略组实现自动择优。服务商订阅本质上就是一个远程 proxy-provider;理解这层抽象后,多订阅并存、本地节点与订阅混合编排,都是同一机制的排列组合。

订阅解决节点从哪来,规则解决流量往哪去。订阅自带的规则若不合用,可在客户端覆写或自建规则集;规则语法、匹配顺序与 MATCH 兜底的完整写法,参见《Clash 自定义规则写法详解》与《Clash 规则分流配置实战》两文,本卷不再展开。

Ⅸ按使用场景选型:决策表与总原则

前八章的事实归并成决策表之前,先立一条总原则:协议选择的自由度大半在服务商一侧。纯使用方的真实决策顺序是——先看订阅提供了哪些协议,再按场景在已提供的协议里挑;自建服务器的一方才有完整的协议选择权,其考量也列在本章。

桌面日常:以稳为先

桌面场景线路稳定、设备性能充裕,协议差异最小,直接用订阅默认节点即可;同一订阅提供多协议时,优先 VLESS 或 Trojan(低开销),或 SS(低延迟)。客户端层面,全平台首推 Clash Plus:mihomo 内核、中文界面,配置覆写与可视化编辑齐全,下载与安装细节见安装包页。

移动端:电量与切换

手机场景的两个痛点是网络切换与待机耗电。订阅里若有 Hysteria2 或 TUIC 节点,移动网络下优先使用:连接迁移让 Wi-Fi 与蜂窝互切不断线,0-RTT 缩短必需的重连。若只有 TCP 系节点,把保活类参数放宽、关闭用不到的 UDP 转发,也能省下一截电量。iOS 与 Android 的具体客户端与导入步骤,入门指南有分平台主线。

游戏与实时音视频

游戏、语音与视频会议对 UDP 与延迟最敏感。优先选 udp: true 可用的节点;QUIC 系(尤其 TUIC 的 native 模式)在移动网络下表现最稳。若希望游戏走代理,记得把游戏进程或域名定向到延迟最低的策略组——协议决定单连接质量,规则决定它有没有被用上。

弱网与高丢包线路

跨洲、晚高峰、无线中继这类丢包率常年偏高的链路,是 QUIC 系的主场:Hysteria2 按声明带宽持续发送,吞吐保持能力显著优于 TCP 系;TUIC 行为温和,适合 UDP 可能被限速的环境。使用 Hysteria2 时 up 与 down 务必按真实带宽填写,虚高会让拥塞恶化。若 UDP 整体不可用,退回 SS 或 Trojan 并接受吞吐折损——这是物理限制,不是配置问题。

路由器与服务器

路由器、NAS 与服务器上没有图形界面,直接跑 mihomo 内核是最干净的方案:一份 config.yaml 加一个开机自启服务即可。低性能路由器的协议取舍遵循第六章:优先 SS(chacha20 系)或 VLESS,避开双层加密;内存紧张时用 rule-set 替代大文本规则。OpenWrt 旁路由的完整部署记录见《OpenWrt 路由器部署 mihomo 内核》一文。

自建服务器

自建一侧的决策链是:有域名与证书,选 Trojan 或 VLESS + TLS,外形与开销俱佳;不想维护域名证书,选 SS(2022 系套件),最省心;线路丢包严重且 UDP 通畅,加挂 Hysteria2,与 TCP 系并存按场景切换。协议之外,自建更要紧的是系统更新、密钥强度与管理面暴露,这些超出本卷范围,但权重不低于协议本身。

决策表

协议是链路的一环,不是全部:规则决定分流是否聪明,DNS 决定解析是否干净,内核与客户端决定能力边界——三者与协议同等重要。DNS 的 nameserver 与 fallback 分工见《Clash DNS 配置详解》,常见连接异常的排查路径收在常见问题页。读完本卷仍不确定时,回到入门指南先把默认配置跑通,再逐项替换实验,是最不容易迷路的次序。