Clash 协议与内核选型

选型判断顺序：先区分五个层次

Clash 配置里出现的 SS、VMess、Trojan 等名称，描述的是代理端点之间如何认证、封装和转发数据，并不直接说明应用流量如何进入客户端。浏览器使用系统代理、应用连接本地 SOCKS 端口、TUN 接管系统路由，是不同的入口。入口可以改变接管范围，却不会把服务器上的一种协议变成另一种。选型首先要分清本地入口与远端协议，避免把接管问题误判为协议性能问题。

客户端界面与内核能力分开判断

客户端负责订阅管理、代理组界面、系统代理开关和权限申请；内核负责解析配置、匹配规则、解析域名并建立出站连接。界面里显示一种协议的名称，不代表当前运行的内核一定支持全部扩展。反过来，内核能够读取某个字段，客户端的编辑器也可能尚未提供对应输入框。查看支持范围时，应同时记录客户端名称、实际运行的内核名称，以及节点使用的传输组合。

协议名称下面还可能叠加传输层与安全层。以 VLESS 为例，连接可以使用不同传输方式，也可能配合 TLS 或 REALITY；VMess 则需要区分协议认证与外层传输。只比较两个节点的协议简称，相当于忽略了连接路径中的重要组成。服务器地址、线路距离、运营商互联、出口拥塞和服务端限制，都可能比协议自身的处理开销更显著。

连接成功、首字节与持续吞吐不是同一指标

连接建立时间包括域名解析、传输握手、认证和可能的安全握手。网页首字节还受到目标站响应与规则处理影响；大文件吞吐则更多受到拥塞控制、带宽和服务器资源影响。一种协议可能首次连接较慢，却在复用连接后表现稳定；另一种协议可能短请求迅速，但长时间下载受到服务端速率限制。测试前应明确任务，而不是只看客户端显示的一项延迟。

UDP 支持也需要逐层核对。节点协议支持转发 UDP，不代表当前应用已经通过 UDP 入口进入代理；节点配置启用了 UDP，也不代表服务器端接受相应转发。游戏、语音与部分实时通信应用尤其需要检查这一点。对于基于 QUIC 的出站协议，客户端到服务器本身还依赖 UDP 可达性，它与代理内部承载的应用流量是否为 UDP 是两个独立问题。

建立能够复查的选择依据

实际操作可按四步进行：先核对服务端提供的完整参数，再检查客户端内核是否支持，随后验证入口与规则是否命中，最后比较相同任务的体验。记录成功率、首次加载、持续传输和切网恢复，而不是记录一次偶然的最低延迟。若两个节点不在同一服务器或同一路径，结果只能说明这两条服务的差异，不能推出协议整体优劣。将这些边界写进测试记录，后续更换客户端时才有可沿用的判断标准。

Shadowsocks 与 VMess：轻量转发与协议认证

Shadowsocks 通常缩写为 SS，设计重点是以相对直接的方式提供加密代理转发。常见客户端将 TCP 连接和 UDP 数据报分别处理，不强制引入网页传输层，因此配置结构通常较短。它的简洁来自明确的协议边界，而不是自动解决所有网络问题。实际安全性与可用性取决于加密方法、密钥管理、客户端实现及服务端配置，不能只凭 SS 这个总称下结论。

区分传统 AEAD 方法与 Shadowsocks 2022

常见 AEAD 方法将加密与消息认证结合，接收端可以检测密文被修改的情况。Shadowsocks 2022 是另一组需要明确支持的协议方法，不应当作旧方法的别名。它对密钥格式等参数有不同要求，有些服务还涉及多用户相关约定。把原节点的加密方法名称改成另一种方法，并不能完成迁移；服务端和客户端必须使用相匹配的实现与凭据。

排查 SS 节点时，先检查 cipher 是否受支持，再检查密码或密钥格式、服务器端口和 UDP 开关。部分节点还依赖插件，插件承担的传输封装并不是 SS 核心协议本身。订阅转换如果丢失插件参数，可能出现节点名称正常、地址正常却无法连接的情况。此时应回查原始节点说明，而不是反复更换本地监听端口。

VMess 的设计重点与认证边界

VMess 来自 V2Ray 生态，将用户身份认证与代理请求封装纳入协议设计，并可组合不同的底层传输。它与 SS 的区别不只是把密码换成 UUID。VMess 有自身的请求格式、认证机制及数据保护方式，连接还可能叠加 TLS、WebSocket 等层次。需要同时匹配用户标识、协议设置和外层传输参数，任何一层不一致都可能使握手失败。

阅读旧配置时可能遇到 alterId 或 alter-id。这些字段涉及旧有兼容路径，当前常见的 VMess AEAD 配置通常使用零值，但不能据此随意修改服务提供方给出的其他参数。不同软件对字段命名的表示也不同。旧教程中的写法应放回具体内核语境理解，避免将另一种配置格式里的对象直接粘进 Clash YAML。

VMess 的认证机制与系统时间有关。设备时间明显偏差时，即使地址和 UUID 正确，也可能无法通过认证。排查时应检查系统自动校时是否正常，而不是放宽证书验证。系统时钟与 TLS 证书有效期同样有关，但两者属于不同的失败环节。日志若指向时间或认证，应先修复设备时钟，再重新建立连接。

如何比较资源开销与适用范围

在稳定网络、端点实现成熟且没有额外封装的条件下，SS 的处理路径通常较直接，适合需要广泛兼容的日常转发。VMess 的实际开销则必须连同传输组合一起评估：直接传输与经 WebSocket、TLS 的连接，握手数量和封装路径不同。不能把经过多层封装的 VMess 与直接连接的 SS 测试结果，简化为两个协议天生存在固定速度差。

移动端还应关注连接数量和后台行为。持续下载时，加密运算可能成为资源消耗的一部分；零散消息场景中，无线模块唤醒、DNS 请求和连接维持往往更重要。选择 SS 或 VMess 时，优先采用服务端明确支持、当前客户端能完整解析的组合。如果旧节点只能依赖已经缺乏维护的客户端，应评估服务端迁移方案，而不是长期固定在旧程序上。

Trojan 与 VLESS：认证与安全传输的分工

Trojan 与 VLESS 常与 TLS 一起出现，但两者并不是同一协议换了名称。Trojan 的常见部署以 TLS 连接承载代理请求，通过密码相关的认证信息识别用户；VLESS 更强调精简代理协议本身，将传输保护交由外部安全层处理。比较时应区分认证、防止传输内容被读取，以及服务器身份验证这几个目的，它们并非由同一个字段统一完成。

Trojan：先完成 TLS，再核对代理认证

标准 Trojan 的连接依赖正确的 TLS 配置。客户端访问的服务器地址可以是域名或 IP，但 TLS 校验涉及证书所代表的身份。sni 通常用于发送服务器名称并参与相关连接处理，不能填入任意域名期待自动匹配。服务器证书、预期名称、端口和密码需要共同正确。某些部署通过前置服务分配连接，额外约定也必须由提供方说明。

Trojan 可以承载 UDP 转发，但应用数据报在常见实现中仍经 TLS 所在的可靠字节流传送。这意味着本地看似使用 UDP 的应用，远端传输路径仍可能受到 TCP 队头阻塞影响。是否适合实时通信，应测量实际丢包和交互体验，而不是仅检查节点的 UDP 标记。不同扩展实现可能增加其他传输方式，不能将其行为反推为所有 Trojan 服务的共同特征。

VLESS：协议精简不等于传输天然加密

VLESS 的身份参数通常使用 UUID，但 UUID 是认证标识，不是能够替代 TLS 的加密开关。经典 VLESS 配置中常见的 encryption: none 表示该协议层不提供相应的数据加密，并不代表整条连接一定没有保护；是否安全要看外层实际使用的 TLS、REALITY 或其他明确支持的方案。反过来，缺少安全层的配置也不能因为使用 VLESS 就被视为已经加密。

VLESS 的传输组合较多，客户端支持必须细化到所需功能。flow 不是随意填写的优化标签，而是与特定数据流处理机制及端点实现相匹配的参数。例如使用 Vision 相关流程时，需要核对服务端、内核、传输方式和安全层是否共同满足要求。把其他节点的 flow 复制过来，可能直接使原本能够建立的连接失败。

REALITY 也不是普通 TLS 开关的另一种拼写。使用相应方案时，公钥、短标识、服务器名称及相关握手参数需要与服务端设置相符。字段名称在不同软件格式中可能不同，应以当前内核文档为准。浏览器指纹类参数影响特定握手行为，但不会修复错误的端口、无效的用户标识或不匹配的公钥，也不应被当作通用提速选项。

传输选项如何影响选择

WebSocket、gRPC 等传输常用于适配已有服务架构，它们会引入自己的路径、服务名、请求头或中间层要求。多一层封装并不必然更慢，因为实际瓶颈可能位于线路而非处理器；但配置面更大，排错时需要检查的条件也更多。普通使用者如果没有明确的架构约束，应优先选择提供方说明完整、客户端原生支持且参数较少的组合。

两者都不能用关闭证书验证来弥补部署错误。证书过期、服务器名称不匹配和系统时间偏差应分别处理；跳过验证会改变安全边界，并且常常掩盖真正问题。若节点导入后需要额外填写敏感参数，应在本地客户端完成，不将完整订阅和凭据放进公开截图。分享排查信息时保留协议类型、报错类别和字段名称即可。

Hysteria2 与 TUIC：基于 QUIC 的不同取舍

Hysteria2 与 TUIC 都利用 QUIC，但不能因此相互导入或共用认证参数。QUIC 在 UDP 上实现加密传输、可靠流和连接管理，为协议实现提供了区别于 TCP 的基础。Hysteria2 更突出面向复杂链路的传输与带宽利用设计；TUIC 则围绕 QUIC 构建代理请求与数据转发，并提供自身的认证和 UDP 处理机制。二者的配置字段与服务端必须分别匹配。

QUIC 能解决什么，不能解决什么

QUIC 可以在同一连接中承载多条流，一条流发生丢包时，不必像单条 TCP 字节流那样让所有流都等待同一段缺失数据。但连接内的拥塞控制、可用带宽和部分资源仍然共享，因此不能理解为各请求完全互不影响。它也无法消除物理距离、严重拥塞或服务器性能限制。网络直接丢弃 UDP 时，基于 QUIC 的连接甚至可能无法建立。

连接迁移是 QUIC 的能力之一，实际能否在无线网络与蜂窝网络切换后继续使用，还取决于代理实现、服务端策略和客户端生命周期。移动系统可能暂停进程或回收资源，客户端也可能主动重建隧道。测试切网恢复时应观察应用请求是否重新成功、恢复是否稳定，不应仅凭协议具有连接标识就断言所有切换都能保持业务会话。

Hysteria2：带宽参数需要符合真实链路

Hysteria2 与早期 Hysteria 不是可随意互换的配置格式。选择 hysteria2 类型后，应使用对应的认证、TLS 与其他可选参数。涉及混淆的设置也必须与服务端一致，不能为了尝试连接而任意开启。标准连接仍需要正确处理服务器身份与证书验证，QUIC 的存在并不免除这些要求。

Hysteria2 的带宽协商及拥塞控制行为与两端配置有关。客户端可能使用 up、down 等字段表达方向性带宽信息，但并非所有部署都要求手动填写。数值填得越大不会自动得到更多可用容量，反而可能造成排队、丢包和对同网设备的干扰。应先阅读服务端要求，若需要显式设置，再依据实际可持续带宽保守调整，而不是依据无线连接的标称速率填写。

TUIC：认证、拥塞控制与数据报模式

TUIC 的常见配置包含 UUID、密码及 TLS 相关参数，并可能暴露拥塞控制和 UDP 转发模式。具体字段受到 TUIC 协议代际与客户端实现影响，因此“支持 TUIC”仍需要进一步核对服务端实现。不能把 Hysteria2 的认证字符串放进 TUIC 密码字段，再期待相同的 QUIC 基础使连接兼容。

拥塞控制算法影响发送节奏和对链路反馈的响应，并不是面向所有网络的速度档位。UDP 数据报通过哪种机制转发，也会影响可靠性、延迟和额外开销。可靠承载可以避免部分应用数据报直接丢失，却可能增加等待；非可靠承载更接近数据报原本语义，但要求应用能够处理丢包。选择前应明确业务需求，而不是把所有选项都设成看似激进的模式。

先检查网络条件，再比较协议体验

公共无线网络、企业网关和移动网络对 UDP 的处理可能不同。若 TCP 类节点可用而两个 QUIC 类节点都失败，应优先检查 UDP 可达性、端口策略及路径问题，再考虑认证。长时间运行后才中断，可能涉及 NAT 映射、空闲超时或移动端后台限制。使用固定网络完成基线测试后，再在实际使用场景验证，能减少多个因素同时变化造成的误判。

Hysteria2 或 TUIC 值得在高时延、有丢包且 UDP 可达的环境中纳入候选，但这不是固定推荐排名。更积极的发送可能提高吞吐，也可能增加处理开销和无线活动时间。设备发热、同网设备体验以及业务稳定性，都应与下载速度一起记录。

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

协议性能比较应建立在尽量一致的条件上。同一个客户端、同一设备、相同入口模式和相近时段，是最基本的控制项。若服务器位置、出口带宽与目标站不同，测试结论只能描述整条服务路径。协议处理本身确实存在差异，但在普通网页场景中，域名解析和远端响应可能占据更大比例，不能把所有等待时间都归给加密或握手。

将短连接、复用与持续传输分开测量

首次请求可能包含 DNS 查询、TCP 或 QUIC 建连、TLS 与协议认证；后续请求可能复用已经存在的传输连接。测试前应说明是冷启动还是连接已热身。连续点击延迟测试得到的数字，可能因缓存与连接复用而越来越低，但真实应用在空闲后未必享受相同条件。比较短请求时，可分别记录首次加载和重复加载是否稳定。

大文件传输需要足够长的观察窗口，避免只记录开头的突发速率。还应区分单连接和多连接下载：后者可能同时使用更多网络与处理资源，不能直接证明协议单流效率更高。重传、拥塞反馈与服务器限速也会影响曲线。测速会消耗网络流量并改变当时的负载，不宜在每次节点切换后自动进行大流量测试。

处理器与内存没有跨设备固定名次

加密算法是否利用硬件加速、内核如何管理缓冲区、并发连接有多少，都会改变处理器占用。某种算法在一台处理器上高效，并不代表在老旧移动芯片或小型路由器上同样占优。QUIC 实现通常需要在用户态处理较多传输逻辑，但这也不能推出它在任何工作量下都更耗资源。需要结合实际吞吐与系统调度观察。

内存占用还受到规则集、DNS 缓存、连接跟踪、日志等级和界面框架影响。将包含大型规则集的客户端与简化配置的客户端比较，不能得出协议内存结论。路由器出现内存压力时，应先检查连接规模、规则加载和日志，再决定是否更换协议。桌面客户端显示的整个进程占用也可能包含界面，不等于代理内核单独占用。

移动耗电主要看无线活动与后台策略

手机网络模块被频繁唤醒、连接保活过密、弱信号下反复发送，以及应用后台请求，均可能提高电量消耗。维持一条空闲连接与持续传输视频的耗电结构不同，因此不存在可信的通用协议耗电排行榜。判断时至少分开记录屏幕点亮浏览、锁屏待机和持续传输，并尽量固定亮度、信号、网络类型和应用负载。

Android 上的电池优化可能暂停客户端，表现为锁屏后连接中断；解除相关限制可以改善持续运行，但也允许更多后台活动。iOS 的网络扩展受系统生命周期管理，不能照搬桌面后台策略。遇到中断应检查系统设置和客户端日志，不要直接提高保活频率。过于频繁的探测即使保持了连接，也可能用额外耗电换来不必要的在线状态。

出现代理已连接但网页仍失败时，先按系统代理到 DNS 的逐项排查清单验证链路，避免在接管尚未生效时开始性能比较。最终选用稳定达到业务要求的组合，比追求一次最高吞吐更有意义。

Clash、Meta 与 mihomo：内核家族和界面分工

原版 Clash 建立了以 YAML 配置、代理组和规则分流为核心的使用方式。后续生态中出现不同内核分支与扩展实现，Meta 通常指 Clash.Meta 这条演进路线，mihomo 是其延续使用的项目名称。三者不是三个可以任意叠加的功能插件。配置是否能够运行，取决于实际内核支持的节点类型、规则语法和相关模块，而不是文件名里是否含有 Clash。

基础语法相近，不代表功能完全相同

许多常见字段在不同实现中保持相似结构，例如 proxies、proxy-groups 与 rules，这使基础配置具备一定迁移便利。但协议扩展、DNS 行为、TUN 参数及规则能力并不保证相同。原版配置中可以使用的基础节点，不意味着较新的扩展节点也能被原版内核读取。出现未知代理类型时，应先查支持范围，而不是修改 YAML 缩进掩盖错误。

阅读资料还要区分历史上的开源版本、Premium 相关功能和 Meta 路线的实现。旧文章可能把某项能力简称为“Clash 支持”，实际只适用于当时的特定内核。不能把这些表述累计成一张所有客户端都具备的能力清单。尤其是 TUN、规则提供者、脚本或特定规则格式，应回到正在使用的内核文档逐项确认。

客户端名称不是内核名称

普通用户可从下载页首推的 Clash Plus 开始，按系统选择对应客户端，再查看其实际协议与导入支持。Clash Verge Rev、FlClash 等也是界面客户端，需要结合它们实际内置的内核判断配置能力。Clash Meta for Android 的名称体现生态关联，但仍需检查当前安装程序的具体实现。不能仅凭品牌相似推断配置扩展全部一致。

桌面端更新界面程序，不一定意味着正在运行的内核已经切换成功；有些客户端允许独立管理内核，也有些随安装包统一提供。排查时可从关于页面、运行日志或内核管理页核对实际运行信息。若存在多个配置目录，应确认客户端正在读取哪个文件，避免修改了备份文件，却把运行行为未变化解释成内核缺陷。

Clash for Windows 与 ClashX Meta 在本站下载清单中作为已停止维护的归档客户端展示。归档适用于理解旧环境与迁移，不应作为获取新协议能力的默认方案。停止维护不等于原有连接立刻全部失效，但后续系统变化、协议扩展和修复不能假定会继续跟进。迁移前保留原配置，先用副本验证新客户端。

跨内核迁移按模块进行

迁移时先保留最少节点与一个手动选择代理组，确认认证与传输能建立，再恢复规则、DNS、提供者和 TUN。这样可以将失败缩小到具体模块。若一次导入复杂配置后无法联网，节点错误、DNS 回环、路由接管冲突和规则引用错误会混在一起，日志难以解释。基础连接验证成功后再增加功能，通常比整份配置同时试错更快。

服务模式与管理员权限属于系统集成条件，不属于远端协议属性。内核支持 TUN，并不代表普通权限进程能够直接建立虚拟网卡或修改路由。需要接管更多应用时，可继续查阅TUN 模式与虚拟网卡说明。服务器与路由器用户则应区分图形客户端和单独内核部署，结合OpenWrt 与旁路由部署概览评估资源和拓扑。

订阅格式兼容：链接、节点与完整配置

订阅是配置的交付方式，不是独立的代理协议。一条订阅地址返回的内容，可能是完整 Clash YAML、若干分享链接、编码后的节点列表，或者其他软件的配置格式。客户端能够下载这个地址，只能证明请求取得了响应，不代表返回内容可以直接作为当前内核配置。导入前先确定内容类型，比看到“格式错误”后反复更新更有效。

单节点分享与完整 YAML 的信息范围不同

ss://、vmess://、trojan:// 等分享形式通常表达单个出站节点，具体字段编码还可能受生态约定影响。它们不一定包含代理组、分流规则、DNS 和本地端口。完整 Clash 配置则通常围绕这些模块组织运行环境。把节点链接文本保存为 .yaml 并不能让内容自动成为 YAML 配置，文件扩展名不会改变格式。

同样，其他内核的 JSON 配置不能只转换括号和缩进就变成 Clash 配置。模块边界、路由表达式和 DNS 语义可能根本不同。转换工具只能映射它理解的部分，不能保证保留全部行为。涉及 REALITY、特定流控、插件或新协议参数时，转换后尤其需要逐字段确认。节点数量一致，也不代表连接所需信息完整。

代理提供者不是第二份顶层配置

proxy-providers 允许从外部来源加载节点集合，再由代理组引用。提供者文件通常只承担节点列表职责，不应默认把另一份完整订阅中的端口、DNS 和规则一并合并进来。若来源实际返回完整配置，是否能够提取节点需要看客户端或内核支持的处理方式。应按提供者所要求的结构准备内容，避免把“主配置导入成功”的经验套用到提供者。

下面是能够独立解析的本地分流基线，没有远端节点。它用于确认端口、选择组与规则结构，不用于衡量代理性能。导入真实节点后，再将节点名称加入对应代理组；如果直接使用完整订阅，应先确认客户端合并策略，避免本地规则被覆盖。

mixed-port: 7890
mode: rule
proxies: []
proxy-groups:
  - name: 手动选择
    type: select
    proxies: [DIRECT]
rules:
  - MATCH,手动选择

配置解析成功以后还要检查引用关系

YAML 对缩进、列表层级和字符串表示有要求，含有特殊符号的值应使用正确引号。协议字段类型也重要，布尔值与字符串不能随意混用。但语法正确仅是第一步：代理组引用的节点名称、规则引用的组名、规则提供者名称，都必须真实存在。更新订阅后节点被改名，本地手写组仍使用旧名，就可能出现引用失效。

客户端常通过覆写、合并或脚本保留本地设置。每种机制的执行时机和覆盖范围不同，最终生效文件可能并不是下载到的原始文件。排查时应检查运行配置，确认节点和规则最终如何组合。不要只在订阅编辑器中搜索字段，就认定内核已经读取。必要时临时停用本地覆写，在副本上验证原始订阅，再逐项恢复。

更新失败与格式不兼容分别处理

HTTP 错误、重定向到登录页、响应为空和 YAML 解析失败属于不同问题。订阅地址有时携带访问凭据，不应发送给不可信的在线转换服务；转换会让该服务接触完整节点信息。优先使用客户端内置导入或可自行控制的处理方式。详细的更新顺序可查阅订阅更新失败与自动更新设置。

更新前保留可工作的配置副本，更新后先检查节点类型与代理组，再验证规则和 DNS。若服务端新增了当前内核不支持的类型，应选择兼容的订阅格式或更新受支持客户端，不要单纯删除报错字段。字段被删除后解析可能通过，但认证或传输语义已被改变，反而会制造更难定位的连接失败。

按场景选协议：保留基线，再做对照

实际选型应从已有服务条件出发，而不是先指定一个协议名称再寻找所有参数。协议需要服务器与客户端共同支持，本地更改 type 不会让远端自动升级。如果服务提供方只提供一种经过验证的组合，先确认它能否满足当前任务。只有发现明确的限制，例如 UDP 不可达、切网恢复不稳或设备资源不足，再引入另一种组合做有目的的比较。

桌面浏览与移动日常使用

桌面网页和办公应用通常先看稳定性、域名解析与规则命中。SS、VMess、Trojan、VLESS 的成熟兼容组合都可以成为候选，不需要为了更新的名称更换已经稳定工作的连接。客户端优先从 Clash Plus 及下载页对应平台清单选择，检查架构和系统要求后，再确认目标节点的完整传输支持。安装后的主线操作可回到使用文档继续。

移动设备应额外测试锁屏、网络切换和后台恢复。先固定无线网络测试，再切换蜂窝网络；如果问题只在切换后发生，应观察客户端是否重建连接，而不是立即替换认证参数。若使用 TUN 接管，还要检查系统的 VPN 权限及其他网络扩展是否冲突。客户端被系统暂停，与代理服务器拒绝认证，处理方向完全不同。

高时延链路与实时业务

当链路时延较高且存在丢包时，可以在 UDP 可达的前提下比较 Hysteria2、TUIC 与现有 TCP 类方案。测试重点是交互等待、连续传输和对其他应用的影响，而不仅是下载峰值。若 QUIC 类连接在公共网络频繁中断，保留一条经验证的 TCP 类候选更实用。备用路径应事先测试，不要等主路径失效后才首次导入。

语音、游戏等实时业务需要验证数据报转发是否贯穿整个链路，并查看是否出现长时间等待或周期性中断。可靠承载会改变丢包表现，但不一定改善实时体验；某些应用宁可丢弃过时数据，也不希望等待重传。应使用真实业务观察，同时留意目标服务是否对地址变化敏感，避免把业务端会话失效解释为代理协议异常。

路由器与低资源设备

路由器应先评估处理器架构、可用内存、并发规模和规则集体积。资源有限时，精简规则、降低不必要日志、避免重复健康检查，往往比单纯更换协议更直接。不同加密实现和 QUIC 处理开销需要在目标硬件上测试。不能以桌面电脑的表现推断小型路由器，也不能把硬件网口速率当成启用代理后的必达吞吐。

旁路由场景还要确认网关、DNS 和返回路径。终端请求未经过代理设备时，协议选择不会产生作用；DNS 指向错误或路由回环也可能让所有节点同时失败。先用最小拓扑验证单台终端，再扩展到全网。对已经稳定运行的设备，更换内核和更换协议最好分两次进行，便于判断变化来自哪一层。

一次完整的对照记录

1. 记录设备、系统、客户端和实际内核，确认没有同时运行多个接管程序。
2. 保存原配置，选择固定网络和固定业务，核对节点认证、传输与证书参数。
3. 分别观察首次请求、持续使用、空闲恢复与网络切换，不混用不同任务的结果。
4. 逐次只改变一个条件，失败时保留报错类别，再回到正常基线确认网络仍可用。
5. 采用能够稳定满足需求的组合，保留经过验证的备用项，并在重要更新后复测。

最终判断可以归纳为三项：配置能否准确表达服务端要求，设备能否在可接受资源消耗下持续运行，实际网络能否稳定承载该传输。三项都满足后，再比较体验差异。协议名称是查阅入口，不是质量保证；对具体设备与业务可重复的结果，才是长期保留某个节点和客户端组合的依据。