Clash 协议与内核参考

协议、传输与连接层次

先区分界面、内核与服务端

在客户端列表中选择一个节点，实际选择的是一组连接参数，而不只是协议名称。客户端负责展示订阅、管理配置与设置系统代理；内核负责解析规则、连接服务端并转发数据；服务端再代表客户端访问目标。三者由不同项目实现，更新节奏也不一致。因此，界面能够保存某个字段，不等于内核能够使用；内核支持某种协议，也不等于当前服务端开放了相应入口。

一个典型节点至少包含服务器地址、端口、协议类型与身份凭据。有些还需要加密方法、TLS 服务器名称、传输路径或 QUIC 参数。这些字段共同构成协议约定，必须与服务端逐项对应。把一个 Shadowsocks 节点的类型改成 Trojan，并不会完成协议转换；即使二者服务器地址相同，也需要服务端存在对应监听，以及另一套正确的认证与传输参数。

协议名称不等于底层网络

Shadowsocks、VMess、Trojan 与 VLESS 描述代理通信中的认证、封装或转发约定；TCP、UDP 是承载数据的传输层协议；TLS 为连接提供经过认证的加密通道；WebSocket、HTTP/2 等又可能成为额外的承载方式。Hysteria2 与 TUIC 则以 QUIC 为重要基础。判断兼容性时，要把这些层次拆开，不能看到两项都写着 TLS，就认为它们可以相互连接。

还要区分应用需要 UDP 与节点底层使用 UDP。语音应用可以产生 UDP 数据报，但代理可能把它们封装进另一种通道；浏览器主要访问 HTTPS，也可能经由 QUIC 型代理传输。节点详情中的 udp 开关通常表示是否允许转发 UDP，并不意味着 TCP 连接会被自动改造成 QUIC。应用、代理入口和服务端出口三个位置都可能影响最终行为。

一次访问经过哪些判断

请求进入内核后，通常先根据域名、目标地址与规则选择策略组，再由策略组选择实际出口。域名解析可能发生在本地、内核或远端，具体取决于配置及规则需求。随后内核建立到服务端的连接，完成必要的认证与握手，最后才传递应用数据。如果此时访问失败，问题可能出在 DNS、规则、服务端连接或目标网站，不能只凭超时提示判定协议失效。

系统代理与 TUN 也属于请求入口，不属于节点协议。系统代理依赖应用主动使用本地 HTTP 或 SOCKS 入口；TUN 通过虚拟网络接口接收符合路由条件的流量。启用 TUN 可以扩大接管范围，却不会修复错误的密码、证书名称或服务端端口。若只有某个应用无法连接，应先确认它的流量是否进入内核，再考虑更换协议。

选型顺序：先确认服务端提供什么，再确认内核支持什么，最后比较网络适应性。协议能力、客户端功能和流量入口是三个独立维度。

本手册中的快慢与资源比较均为条件性判断，不给协议排列固定名次。相同协议在不同线路、服务器负载、处理器和运营网络下，表现可能完全相反。首次配置可沿入门指南完成连接闭环，再用本页的方法做单变量比较，避免同时修改 DNS、TUN、协议和规则后无法定位原因。

Shadowsocks 与 VMess

Shadowsocks：较直接的加密转发

Shadowsocks，常缩写为 SS，起点是将本地代理请求通过加密通道转发到服务端。其常见配置较紧凑：服务器、端口、加密方法和密码构成核心参数。相较于需要外层 TLS 与额外传输封装的组合，直接传输的协议栈通常更短，便于理解和部署。不过，字段少并不等于安全性只由密码长度决定，具体加密方法、实现质量和密钥管理同样重要。

历史上 Shadowsocks 使用过不同加密方案。面向现有服务时，应优先采用服务方明确支持的现代 AEAD 方案，避免为了兼容旧客户端而随意改用陈旧方法。AEAD 同时处理加密与消息认证，可检测数据是否被篡改。部分较新的协议变体还引入不同密钥格式和会话处理方式；它们不能仅靠修改一个方法名称，就与旧服务端互通。

填写配置时，cipher 必须与服务端精确一致，密码也可能受到格式要求约束。尤其某些 Shadowsocks 2022 方法使用规定长度的 Base64 密钥，不能把普通短密码直接填入。选择 AES 还是 ChaCha20，应结合设备是否具备相应硬件加速；桌面处理器上的优势不一定会复制到低功耗路由器。实际吞吐测试比根据名称猜测更可靠。

插件与 UDP 是额外的兼容点

带插件的 Shadowsocks 节点需要客户端内核支持相同插件及其选项。分享链接能够被导入，只说明解析器识别了基本结构，未必意味着插件参数完整保留。遇到连接立即关闭，可对照原始资料检查插件名、主机字段与传输选项，而不是反复重输密码。插件还会改变协议栈与部署条件，因此不能把所有 SS 节点都当作同一种性能模型。

UDP 支持也需要两端共同具备。客户端允许 UDP、服务端开放转发、主机防火墙放行相关流量，三项缺一都可能导致语音或游戏异常。网页能够打开只能说明对应的 TCP 请求成功，不代表 UDP 路径可用。若使用的是带插件方案，还要核实插件对 UDP 的处理边界，不能把直连传输的能力直接套用到插件通道。

VMess：认证机制与传输组合

VMess 出自 V2Ray 生态，设计中包含用户身份认证和代理数据封装，并可配合不同传输方式使用。讨论 VMess 时，至少应说明是否使用 TLS、是否经过 WebSocket 等中间层，否则“VMess 较慢”这样的比较没有明确对象。直接 TCP 与多层封装的握手、缓冲和服务器处理路径不同，最终开销往往不只来自 VMess 本身。

现代 VMess 配置通常使用 AEAD 认证方式，旧资料中的 alterId 与旧式认证设置不宜照搬。兼容字段存在，不代表应当主动启用历史行为。设备时钟也应保持准确，因为认证机制对时间有要求；明显的系统时间偏差可能造成认证失败。排查时先同步时间，再核对 UUID、传输方式、TLS 和服务端路径，比不断切换加密选项更有效。

两者适用边界可以概括为：已有可靠 SS 服务时，配置简洁是实际优势；已有 V2Ray 传输部署时，VMess 的生态兼容可能更重要。没有必要为了协议名称更新而重建整套服务。新选型则应同时查看客户端支持、服务端维护状态和订阅能否完整表达参数，不应仅凭“字段更多”或“协议出现更晚”判断价值。

Trojan、VLESS 与 TLS

Trojan：在 TLS 通道中进行代理认证

Trojan 的设计重点之一，是将代理通信放在 TLS 通道内，使用密码进行协议层认证。与一些自带数据加密封装的协议相比，它更多依赖成熟的 TLS 体系保护传输。因此，证书、服务器名称和 TLS 握手不是可有可无的附加项，而是连接成立的重要部分。传统 Trojan 配置通常比较直观，但实际部署仍可能叠加其他传输形式，需要按服务端说明填写。

服务器地址可以是 IP，而证书通常签发给域名。此时客户端可能需要单独提供服务器名称，使 TLS 握手使用正确的名称，并据此验证证书。这个名称常被称为 SNI，但客户端字段命名可能不同。它不能随便填写一个可访问域名，也不一定等于 WebSocket 的 Host；后者属于另一个协议层，二者在某些部署中相同，在另一些部署中则不同。

证书错误应按具体原因处理：检查系统时间、证书有效期、名称是否匹配、证书链是否完整，以及是否存在本地 HTTPS 检查工具。不要把关闭证书验证作为长期解决办法。关闭验证会失去确认远端身份的重要保障，网络中间位置的设备可能因此更容易冒充服务端。相关处理顺序可查阅HTTPS 证书报错原因与排查。

VLESS：轻量认证不等于独立加密

VLESS 由 V2Ray 相关生态发展而来，侧重较轻量的认证与转发结构。理解它最重要的一点，是 VLESS 本身不提供通用意义上的独立传输加密，需要结合 TLS、REALITY 等合适的安全承载方案判断整体保护。只看到节点类型为 VLESS，无法知道它的安全属性和连接成本，还需要查看传输方式、安全层以及可选的流控设置。

REALITY 是特定安全传输方案，不是把 TLS 开关换个名字。公钥、短标识、服务器名称与相关握手设置需要配套，并受内核实现限制。Vision 这类 flow 选项也有适用组合，不能对任何 VLESS 连接统一开启。服务端未使用对应组合时，客户端加上参数只会导致连接失败；从其他节点复制一段看似完整的设置，通常也无法替代服务端实际参数。

选用 VLESS 时，应先确认提供的是哪种明确组合，再核对当前内核是否支持。某个客户端能够导入 VLESS 分享链接，不代表其内核支持链接中全部扩展。尤其在旧客户端、转换后的订阅或经过覆写的配置中，字段可能被忽略、改写或删除。诊断时要看最终交给内核的配置，而不是仅看订阅列表里显示的协议标签。

握手复用与延迟的实际含义

TLS 通道一般需要建立底层连接并完成安全握手。首次连接与已建立连接上的后续请求，耗时结构并不相同；会话恢复、连接复用以及目标网站自身的 HTTP 连接，都可能改变体感。因此，客户端一次延迟测试主要反映该测试路径的建连和响应过程，不能单独说明长时间下载、视频播放或多应用并发的表现。

Trojan 与 VLESS 都可以成为合理选择：前者在传统 TLS 部署下容易按密码和证书定位问题，后者在合适安全承载下提供较灵活的组合。实际选择以现有服务端和维护能力为准。不要把启用更多扩展视作必然优化；每增加一种传输或特殊选项，都需要多核对一层兼容性，也增加日后排查时必须解释的变量。

证书验证、服务器名称、应用层 Host 和协议认证凭据分别解决不同问题。某项填写正确，不能抵消另一项错误；出现证书告警时应先查原因。

Hysteria2、TUIC 与 QUIC

为什么引入基于 UDP 的传输

QUIC 在 UDP 之上实现安全连接、可靠传输与多路流等机制，并集成 TLS 握手能力。它并不是“不保证送达的快速 TCP”，而是把许多原本由传输层处理的功能放进用户态协议栈。Hysteria2 与 TUIC 都利用 QUIC，但二者的认证、拥塞控制选择、数据报承载与配置结构不同，不能相互连接，也不能仅凭同样使用 UDP 就混用参数。

QUIC 的一个重要特点是多条流之间不必共享 TCP 层面的有序交付约束。某条流发生丢包时，其他流的数据有机会继续交付，减少某些跨流阻塞。不过，它仍受共同的拥塞控制、链路容量和处理器能力约束。若所有流都在争用同一条拥塞链路，或者服务端负载过高，协议本身无法提供额外带宽，更不能保证所有业务同时提速。

Hysteria2：带宽参数与拥塞控制

Hysteria2 的设计关注复杂链路上的吞吐表现，支持基于配置和协商条件使用相应的拥塞控制行为。部分部署会要求填写上行、下行带宽，这些值是算法或服务端限制判断的输入，不是测速结果，也不是填得越大越快。若把明显高于真实上行能力的数值写入，可能引起排队、丢包和其他应用体验下降，特别是在家庭宽带或共享移动网络中。

不同实现和服务端策略可能采用带宽估计、显式速率参数或其他拥塞控制路径。用户应按服务端要求决定是否填写，不能从一份通用示例推断所有 Hysteria2 节点都必须设置相同参数。密码、TLS 服务器名称、可选混淆设置和端口范围也需与服务端对应。端口跳跃不是基础连通性的替代品，服务端未开放时启用并不会增加可用入口。

名称相似也不表示协议代际兼容。Hysteria 与 Hysteria2 在协议上存在差异，客户端中的类型必须选对。转换工具若只根据名称猜测，可能生成表面完整但实际无法认证的条目。遇到握手失败，应先确认服务方提供的协议代际，再检查 UDP 到达性、证书及认证字段，而不是先调整带宽和高级选项。

TUIC：连接复用与数据报转发

TUIC 同样以 QUIC 为基础，常见配置包含 UUID、密码与 TLS 相关参数，并可能提供 UDP 转发方式、拥塞控制和连接维持选项。协议演进中存在不兼容的历史实现，不能假定所有名为 TUIC 的服务都能被任意客户端使用。实际应依据服务端给出的协议要求与内核支持范围核对，不要凭分享链接的前缀判断全部兼容性。

对交互式应用而言，数据报如何承载尤其重要。将数据报放入可靠流，可能在丢包时等待重传；采用不可靠数据报则更接近原始 UDP 语义，但会受到路径 MTU、数据报大小和实现策略影响。不同应用对丢包与等待的容忍度不同，语音、游戏和文件传输不能用同一项开关一概优化。保持默认设置通常比盲目启用高级模式更稳妥。

UDP 不可用时的边界

公共 Wi-Fi、企业网络、路由器或运营链路可能限制 UDP，NAT 也可能较快清理空闲映射。此时基于 QUIC 的节点可能无法握手，或在息屏后恢复较慢。应保留一个经过验证的 TCP 型出口作为独立备选，而不是期待内核自动把 Hysteria2 或 TUIC 改造成 TCP 协议。自动回退必须由明确的策略组及可用节点共同实现。

QUIC 型协议适合纳入实测候选，但前提是 UDP 路径可用。它们的优势来自具体传输机制与链路条件，而不是协议名称本身。

连接速度、资源与移动端电量

把“速度”拆成不同指标

连接速度至少包含首次建连耗时、首字节等待、持续吞吐和并发响应。首次打开网页慢，可能来自 DNS、代理握手或目标网站；大文件速度低，则可能受链路带宽、丢包、服务端限速或 CPU 约束。游戏和语音更关注时延波动及丢包，不能用下载吞吐替代。测试前先定义要改善的业务，才能知道应该观察哪个指标。

延迟测试通常会经过代理请求一个指定地址。它测得的并非纯粹的设备到服务端往返时间，还可能包括解析、安全握手、目标站响应及连接复用情况。不同客户端若使用不同测试地址，数字也不能直接比较。测试成功说明特定路径在当时有响应，不等于所有站点都可用，更不意味着该节点支持应用所需的 UDP 转发。

协议开销如何落到硬件上

直接传输的 SS 通常封装较少；使用 TLS 和额外传输的组合会增加握手或帧处理；QUIC 实现需要处理加密、拥塞控制、定时器和用户态数据包。以上是机制差异，不是固定性能排序。现代桌面设备可能轻易承担这些工作，而低功耗路由器或手机在高吞吐时更容易先触及单核处理、温控或内存带宽边界。

内存占用也不只由协议决定。并发连接数、连接缓冲、规则集、DNS 缓存、日志级别和界面本身都会贡献占用。两个客户端使用相同内核，若一个加载更多规则并保留更详细的日志，内存也可能明显不同。进行比较时应固定配置规模、关闭不必要的调试日志，并区分 GUI 进程与内核进程，避免把界面资源错误归因给节点协议。

手机耗电首先是连接行为问题

手机耗电受到无线信号、数据量、唤醒频率与连接维持方式共同影响。弱信号环境下，无线模块发射与重传的成本可能大于协议加密本身。过于频繁的健康检查、订阅更新、保活和日志写入，会让设备难以保持低功耗状态。因此，选择协议前应先检查是否开启了高频测速，以及多个代理或 VPN 应用是否在反复争用网络入口。

保活存在权衡：间隔较短可能减少 NAT 映射失效后的重连，却会增加后台数据和无线唤醒；间隔过长可能省去维护成本，但首次恢复连接更慢。QUIC 的连接迁移能力也受协议实现、服务端和客户端配置限制，不能据此承诺 Wi-Fi 与蜂窝网络切换时永不断连。对移动用户，待机恢复可靠性常比单次峰值速度更有意义。

建议使用同一设备、同一网络、同一目标和相近时段，分别记录冷启动访问、持续传输及一段待机后的恢复表现。每次只换一个节点或协议，重复几轮观察趋势，并留意设备温度变化。电量比较需要相近使用负载和足够长的观察窗口；十几秒测速的电量变化太小，不能作为某协议更省电的证据。

如果长时间传输导致通话或网页响应恶化，应先限制大流量任务、检查本地排队和带宽设置，再考虑换协议。协议能改善某些链路行为，却无法让同一条已饱和的上行同时承载无限任务。把稳定性、恢复速度和可维护性纳入结果，通常比追求一个最高测速数字更接近日常体验。

Clash、Meta 与 mihomo

名称关系与功能边界

原版 Clash 建立了以 YAML 描述代理、策略组和规则的使用方式。Clash.Meta 是沿这一生态发展的分支，扩展了协议与网络能力；mihomo 延续了 Meta 这一分支的发展。旧资料、订阅格式选项和客户端设置中仍可能保留 Meta 名称，因此看到 Clash Meta 教程时，应进一步确认文章所指的内核功能，而不是只根据名称判断内容是否适用。

原版 Clash 的不同历史发行形态也并非完全一致，开源实现与历史上的其他发行形态不能混作同一能力集合。阅读旧教程时，规则集、TUN、脚本或特定字段的说明可能只适用于当时某种实现。当前选择新协议，应直接核对实际运行的内核及其配置文档，不能把某篇旧教程中的功能列表当作所有 Clash 客户端的共同标准。

mihomo 增加或延续了对多种现代协议及 DNS、TUN、规则功能的支持，但支持范围仍会随实现演进。某个字段存在于配置文档，不保证较早的二进制已经实现。反过来，客户端名称没有 Meta 字样，也不能据此断定不使用 mihomo。可靠依据是客户端内核信息、启动日志和实际加载结果，而不是应用图标或安装包名称。

配置兼容是逐项兼容

基础端口、常见策略组和规则具有较多共同语法，这使部分配置能够迁移；但兼容通常是逐项的，而非整个文件无条件通用。原版配置迁移到 mihomo，仍需检查已废弃行为、路径和平台功能；包含 VLESS、Hysteria2、TUIC 或扩展 DNS 字段的配置，则不应期待旧内核完整识别。未知字段有时会报错，有时会被忽略，二者都需要检查。

客户端还可能在加载前生成最终配置：合并订阅、加入本地端口、写入控制接口、覆写 DNS 或注入规则。编辑订阅源文件后没有看到效果，不一定是内核不支持，也可能是后续覆写覆盖了修改。排查时应找到运行配置或导出功能，确认最终字段，再对照日志判断；不要反复修改一个从未直接交给内核的中间文件。

客户端选择与操作系统集成

桌面与移动端优先查看 Clash Plus 下载与平台选项，同时确认所需协议能否在目标系统上使用。Linux 桌面可按下载页选择 Clash Verge Rev 或 FlClash；Windows 还可比较 Clash Nyanpasu。Clash for Windows 与 ClashX Meta 属于已停止维护的归档选项，不宜仅为沿用旧界面而把它们作为新协议需求的默认方案。

Android 上可比较 Clash Plus、Clash Meta for Android、FlClash 与 Surfboard，但这些应用并不意味着采用完全相同的内核或配置格式。iOS 的网络扩展和后台行为也受系统机制影响。跨平台迁移时，应按“是否支持所需协议、能否接收当前订阅、如何接管流量”重新确认，而不是假定同一份桌面运行配置可在手机上原样使用。

Ubuntu：图形界面与独立服务

Ubuntu 桌面用户通常更适合通过 GUI 管理系统代理和配置。服务器或需要开机运行的环境可以单独部署 mihomo，但要自行处理配置目录、服务用户、日志与 TUN 权限。不要同时让桌面客户端和 systemd 服务使用同一端口或争用路由。详细步骤见Ubuntu 部署 mihomo 内核。

mihomo -v
mihomo -t -d "$HOME/.config/mihomo"

第一条命令查看实际可执行文件的信息，第二条检查指定目录中的配置能否通过内核测试；前提是已安装命令且目录内有 config.yaml。测试通过只证明加载阶段未发现相应错误，不证明节点可连接。升级前应保存配置和原有可执行文件，测试后再替换运行服务，避免把内核升级、订阅刷新与路由修改同时进行。

订阅格式与配置兼容

分享链接、节点列表与完整配置

分享链接一般描述单个节点，协议前缀后可能包含编码后的身份信息和查询参数；节点列表可能是一组链接，也可能是 YAML 中的代理条目；完整配置则进一步包含策略组、规则、DNS 与本地监听设置。三者承担的任务不同。一个应用支持导入分享链接，不意味着可以读取完整 Clash YAML；能够读取 YAML，也不代表支持其中每一种代理类型。

订阅地址本身只是获取内容的入口。同一服务可能根据所选格式或请求参数返回不同数据，文件扩展名并不能可靠说明真实结构。导入后若显示空列表，应先检查客户端要求的订阅类型，再查看是否返回登录页面、错误文本或不兼容格式。不要把含有个人订阅标识的完整地址贴到公开页面，它通常足以让他人获取订阅内容或消耗相关额度。

订阅转换的能力与限制

订阅转换工具可以改变表示形式，例如把分享链接映射为 YAML 节点，再组合策略组和规则。它不能替服务端增加协议能力，也不能让不支持 TUIC 的内核获得 TUIC 实现。转换器对某个字段不了解时，可能丢弃插件参数、TLS 名称或特殊传输选项，结果是基础节点仍显示在列表中，但真正握手所需的信息已经缺失。

优先使用服务方直接提供、与当前内核匹配的配置格式。必须转换时，应选择可信且确有必要的处理方式，并理解订阅内容会被谁接收。在线转换不仅处理协议标签，也可能接触服务器地址与认证信息。检查转换结果时，重点比对协议类型、认证字段、安全层和传输选项，而不是只看节点名称与数量是否一致。

YAML 根层级与策略组引用

教程中的 general 常用来表示基础设置分段，并不是应写入文件的真实顶层键。端口和模式等字段应直接位于 YAML 根层级。下面的最小示例不含远程节点，可用于理解本地监听、策略组引用与兜底规则；它选择直连出口，不会凭空建立远程代理。真实节点必须由有效订阅或服务端参数提供，不能通过示例推导凭据。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

proxy-groups:
  - name: 出口选择
    type: select
    proxies:
      - DIRECT

rules:
  - MATCH,出口选择

YAML 使用空格表达层级，列表前的短横线和同层字段缩进需要保持一致。策略组引用的是准确名称，改名后也要同步修改规则及其他组中的引用。重复名称、引用不存在的节点或组之间形成循环，都可能让配置无法加载或产生意料之外的行为。若 7890 已被另一进程占用，可按端口占用排查定位原因，再同步调整应用代理设置。

订阅更新为何会覆盖修改

直接编辑远程订阅下载得到的内容，下一次刷新时往往会被新内容替换。较稳妥的做法是使用客户端明确支持的本地覆写、合并配置或规则扩展功能，并记录生效顺序。proxy-providers 适合按约定载入代理集合，rule-providers 用于规则集合；它们不是任意完整配置的通用导入口，不能把一个包含全部顶层设置的文件随意当作节点提供器。

配置兼容还涉及 DNS。节点成功导入后，域名解析异常仍可能表现为网页打不开；fake-ip 也需要请求入口与解析路径配合，不能只开一个字段就断言 DNS 已被接管。完整解析关系见nameserver、fallback 与 DNS 劫持字段详解。迁移订阅时应先验证基础连接，再逐步恢复自定义 DNS 和规则，便于发现是哪一层引入差异。

按场景选择与验证结果

日常桌面：先选择可解释的连接

日常浏览、文档同步和开发工具访问，首先需要稳定的连接与容易维护的配置。若已有经过验证的 SS、Trojan 或其他 TCP 型入口，不必为追逐协议名称而更换。客户端可优先考虑 Clash Plus，再按操作系统与所需功能比较其他选项。用规则模式区分需要代理和直接访问的请求，往往比启用更多传输扩展更能减少不必要的绕路。

开发工具还可能只读取环境变量或独立的代理设置，而不使用系统代理。遇到浏览器正常、终端失败，应先检查工具的代理入口和证书环境；企业软件则可能有自己的网络栈或访问策略。TUN 可以作为适当场景的入口方案，但启用后仍应确认路由、DNS 与本地网络访问。不要把应用未使用代理的问题归因于节点协议。

移动网络：同时测试恢复和待机

经常切换 Wi-Fi 与蜂窝网络的用户，应观察切网后首次请求、待机后恢复、语音持续性和后台耗电。Hysteria2 或 TUIC 可以参与比较，但要保留一个在目标网络上确认可用的 TCP 型备选。若只有特定公共网络上的 QUIC 入口失败，优先判断 UDP 路径限制，而不是立即修改认证信息；同一参数在另一网络成功，是有价值的定位线索。

移动端还要考虑系统对 VPN 或网络扩展的管理。后台限制、其他 VPN 应用启动、系统省电与网络权限变化，都可能中断连接。降低不必要的健康检查频率，避免过短保活，通常比反复换协议更值得先做。只有在入口、权限和后台状态一致的条件下，协议之间的电量差异才有比较意义。

大流量与低功耗设备：识别瓶颈

持续下载、远程备份或较高并发，应观察服务端负载、上行排队、设备温度与单核占用。若处理器先满载，可以比较封装较少且有硬件加速支持的方案；若主要是丢包和链路波动，可测试 QUIC 型方案。路由器还要确认处理器架构、内存容量和 UDP 处理能力，不能把桌面设备上的测试结论直接移植过去。

Ubuntu 服务器部署通常更重视服务管理、可恢复性与最小权限。先用普通本地代理验证内核和节点，再按需求添加 TUN、路由和开机服务。每次修改后检查配置、重启对应服务并读取日志，避免桌面客户端与服务同时接管网络。远程操作涉及路由时，应保留独立管理路径和可撤回方案，防止一次错误修改中断自身维护连接。

建立可重复的排查闭环

一次完整验证可以分四层：先确认请求进入本地内核，再确认服务端能够连接，随后确认目标域名解析和规则命中，最后验证真实业务。日志中的认证失败应回查凭据；证书错误回查时间和名称；连接超时则结合网络、端口与协议判断。不同错误分支对应不同变量，盲目重装客户端通常无法提供额外证据。

保留一份能运行的配置作为比较基线，修改时记录改了哪个字段、在什么网络测试以及产生何种变化。日志分享前隐藏订阅地址、凭据与个人访问记录；不要关闭安全验证来换取表面上的成功。若需要回到操作步骤，继续阅读入门指南；若问题只发生在某类应用或配置阶段，可在常见问题查找对应分支。协议选型的最终依据，是需求得到验证、故障能够解释，以及配置能够长期维护。