V2Ray 协议与内核对比手册

01 / Configuration layers

节点配置的四个层次

客户端列表里的一条节点记录，实际上是几组配置的组合。服务器地址和端口回答连接到哪里；VMess、VLESS、Trojan 或 Shadowsocks 回答如何表达代理请求与验证身份；TCP、WebSocket 等传输方式回答数据如何承载；TLS 或 REALITY 则涉及连接的安全保护。把这些内容统称为一种协议虽然方便，却容易导致选型错误：同样显示 VLESS 的两条记录，可能因为安全层和传输不同而具有完全不同的连接条件。

代理协议不等于传输协议

代理协议需要告诉远端目标地址，有时还要提供用户身份、请求类型和数据编码方式。传输层则负责把这些数据送到远端。同一个代理协议可以搭配不同承载方式，但并不是任意组合都被内核和服务端实现支持。阅读节点详情时，应分别记录协议类型、传输类型、安全类型和附加字段，不要只根据节点名称中的缩写判断。名称是订阅维护者填写的标签，不是能够约束实际连接行为的技术定义。

例如 WebSocket 为连接增加了 HTTP 升级过程，通常还涉及路径和请求主机；直接使用 TCP 承载时，不会自动具有这些字段。选择 WebSocket 并不能替代代理协议的用户认证，也不能保证连接已经加密。反过来，打开 TLS 也不会把一个普通代理请求自动转换成另一种代理协议。客户端界面将它们放在相邻选项中，是为了便于编辑，不代表这些选项处于同一技术层次。

安全层与流量入口分别判断

本地入站是浏览器等应用接入客户端的位置，远端出站才是本手册主要比较的对象。常见本地 SOCKS 或 HTTP 监听端口并不是节点服务器端口。系统代理通常把应用指向本地 HTTP 入口；支持 SOCKS 的应用也可以单独指定入口。流量进入内核以后，路由规则还可能把一部分请求直接发送。因此，看到系统代理已开启，只能说明入口设置发生变化，不能据此认定所有连接都经过当前选中的节点。

还要把身份认证和传输保护分开。用户标识、密码等字段用于判断是否允许使用服务；证书验证用于判断 TLS 对端身份是否可信。这两类验证失败的日志和修复方法不同。身份字段填错时，不应通过关闭证书检查来处理；证书名称不匹配时，也不应反复更换用户标识。先确定故障位于哪一层，才能避免同时改动多个参数后失去对照条件。

建立可以复查的配置清单

比较节点前，可以在本地记录这四层信息，并补充所用内核和客户端。无需抄下敏感字段的内容，只要确认字段是否存在、来源是否一致即可。若订阅提供了完整配置，优先保留原始组合，不要凭印象将传输改成另一种类型。服务端并不会因为客户端下拉框发生变化而自动切换配置；即使地址和身份正确，错误的路径或安全层也足以使握手失败。

这套分层方法也适用于查阅术语与日志。看到握手、认证、路径或路由命中等提示时，先定位到对应层次，再检查该层参数。在术语表中可以补充入站、出站与分流的定义；接下来的章节则集中解释这些配置为什么被设计成不同组合，以及用户实际需要为哪些差异作出选择。

02 / Proxy protocols

VMess 与 VLESS 的设计取舍

VMess 是 Project V 生态中较早形成的代理协议，围绕用户身份验证、请求头与数据保护建立了完整机制。VLESS 的出发点不同：精简代理层的额外处理，把连接保护更多交给外部安全层，并为后续扩展留出空间。二者不能仅按名称的新旧排序，更不能认为把节点类型从 VMess 改为 VLESS 就完成了升级。服务端必须提供相应入口，客户端也必须保留匹配的身份、传输和安全参数。

VMess：关注认证模式与时间条件

VMess 配置通常包含用户标识和安全相关选项。旧资料中经常出现额外身份数量等历史字段，而现代配置更多采用 AEAD 认证机制。导入旧节点时，最重要的是确认服务端实际使用的认证方式，以及当前内核是否仍支持它，而不是照着旧截图逐项补齐所有曾经出现过的字段。对已经由订阅生成的现代配置，随意加入历史参数可能制造兼容问题，不能把参数更多理解为配置更完整。

时间也是 VMess 排查中容易遗漏的条件。某些认证过程依赖时间窗口，系统时钟明显偏差可能使认证失败。应检查设备的实际日期、时间和自动同步状态，而不只是界面选择的时区。修改时区但保持同一个正确的绝对时间，通常不等于产生认证偏差。若所有 VMess 节点同时失败、其他协议正常，可以把时间同步列入检查分支，但仍需结合日志确认，不能仅凭协议名称下结论。

VMess 的数据保护会增加一定处理工作，但真实资源占用还受到算法实现、处理器能力、外部 TLS、连接数量和流量模式影响。若节点额外套用 TLS，安全保护不再只来自 VMess 自身。是否保留这类组合，应由服务端设计和兼容需求决定。普通用户不应为了减少一次加密而自行关闭已有的安全层，因为协议能否连通与部署是否合理，是两个需要分别验证的问题。

VLESS：精简不等于独立完成加密

VLESS 负责代理请求表达与用户认证，但经典配置本身不承担应用数据加密。常见界面中的 encryption 为 none，是该类配置的正常字段含义，不代表外层 TLS 或 REALITY 被关闭。应继续查看安全类型，而不是只截取这一行评判连接是否受到保护。对于跨越不可信网络的实际连接，需要按服务端要求使用合适安全层；不要把未加保护的配置当作通用部署建议。

VLESS 常与 Xray 的扩展能力一起出现，例如 flow 字段中的 Vision。flow 不是随意填写的速度档位，而是具有协议语义和实现要求的配置。服务端未启用对应流程、传输组合不符合要求，或所用内核没有实现该能力时，照填同一个值也不会得到相同效果。保留订阅提供的原值，并检查客户端最终选用的内核，比盲目追求某个字段名称更重要。

如何在客户端里做出选择

如果已有 VMess 配置长期稳定、提供方仍维护该入口，继续使用通常比手动改造更稳妥。若新配置明确提供 VLESS 与匹配的 TLS 或 REALITY，可以按完整组合使用。比较时应尽量让两条节点拥有相同服务器地区、相近网络线路和相同测试时段，否则测出的差异很可能来自网络路径，而不是代理协议本身。连接失败率与重连表现，也应和下载速度一起纳入判断。

在 v2rayN 中，先通过节点编辑窗口核对协议与安全设置，再查看该配置实际调用的内核；在 v2rayNG 中，同样需要确认导入后附加字段是否保留。若目标组合超出当前实现范围，应换用能解释完整配置的客户端或内核，而不是把不认识的字段清空。涉及两种内核的具体边界，可以继续阅读内核兼容章节。

03 / Alternative designs

Trojan 与 Shadowsocks 的适用边界

Trojan 与 Shadowsocks 经常被放在同一张节点列表中，但二者解决身份认证与数据保护的方式不同。Trojan 通常以 TLS 作为连接安全基础，并在其中承载代理请求及密码认证；Shadowsocks 则围绕轻量代理和预共享密钥构建自身的数据保护机制。选型时应先看具体协议代际、算法和传输组合，再比较网络表现。只看到 Trojan 或 SS 的短标签，不足以判断完整兼容性。

Trojan：TLS 参数与密码同样重要

Trojan 的常见配置需要服务器地址、端口、密码，以及与 TLS 有关的服务器名称。密码正确并不能弥补证书验证失败；能够建立 TCP 连接，也不代表 TLS 与后续认证均已完成。若连接日志在证书阶段停止，应检查服务器名称、证书链与设备时间。若 TLS 已完成但远端拒绝请求，再核对密码及服务端入口。按阶段检查，通常比反复更换端口更有效。

服务器地址与服务器名称可以在配置中承担不同角色：前者决定网络连接的目的地，后者参与 TLS 握手与证书名称验证。使用地址字段中的 IP，并不意味着服务器名称也应改成同一个 IP。订阅提供的名称应完整保留。证书验证失败时开启跳过验证会改变信任边界，不应作为普通修复步骤；应优先排除名称填写、系统时间或服务端证书配置的问题。

一些实现会为 Trojan 叠加不同传输方式，这时路径、主机名和传输参数同样影响连接。不能把一种客户端中导出的扩展组合，直接视为所有支持 Trojan 的实现都能使用。评估兼容性时，需要问的是目标内核是否支持这一套具体组合，而不仅是类型下拉框里有没有 Trojan。若导入后传输自动变回默认值，应在连接前核对，避免把解析损失误诊为节点失效。

Shadowsocks：算法名称属于必要配置

Shadowsocks 的关键字段通常包括地址、端口、加密方法与密码。经典 AEAD 方法和后续的二〇二二系列方法具有不同规范，密钥要求与实现支持也不完全相同。名称相似不代表可以互换；一端选择一种方法，另一端必须按同一规范工作。尤其不能把任意长度的普通密码，直接套入对密钥长度和编码有特定要求的配置，再把失败归因于网络质量。

旧文档中的传统流加密方法不应成为新配置的默认选择。实际使用时，应采用提供方明确维护且双方内核支持的方法，而不是为了兼容旧截图回退到过时设置。部分订阅还会携带额外的传输扩展信息，这些扩展并不等于 Shadowsocks 基础协议的一部分。目标客户端即使理解地址和密码，也可能无法解释扩展字段，所以导入成功仍然需要检查详情。

不要按“轻量”直接推导体验

Shadowsocks 的基础处理路径可以较为简洁，但并不意味着每个实际节点都更快、更省电。加密算法是否获得硬件加速、网络丢包、服务器负载以及客户端保持连接的策略，都可能改变结果。Trojan 依托 TLS 也不意味着每次请求都重新承担完整握手成本，连接复用和会话恢复会影响实际开销。应把设计特点当作分析线索，而不是替代测量的固定排名。

如果提供方同时给出这两类节点，优先选择客户端能够完整解析、日常应用可以稳定使用的组合。需要依赖 UDP 的应用，应另外确认客户端、内核、服务端与当前模式的支持情况，不能由网页能打开推断。关于响应时间、地区距离与流量倍率的综合判断，可参照节点选择与测试方法，将协议因素放回完整的网络条件中考虑。

04 / Security layers

TLS、REALITY 与传输方式

REALITY 经常与 VMess、VLESS、Trojan 并列出现在营销标签或节点名称中，但从配置层次看，它不是独立完成代理请求表达的同类协议。常见组合是 VLESS 搭配 REALITY，由代理层处理目标请求，由安全机制处理连接保护与对端认证。TLS 则是更通用的安全协议。比较时应写出完整组合，避免出现“VLESS 和 REALITY 二选一”这种把不同层次放在一起的问题。

TLS：连接名称、证书与应用协商

TLS 为连接提供加密、完整性保护与对端认证。客户端需要按照配置的服务器名称检查对端证书，同时验证证书链与有效期。网络连接地址、TLS 服务器名称和 WebSocket 请求中的主机字段可能相同，也可能分别配置。不能因为看起来都是域名，就把三处字段统一替换。服务端如何分配证书、接收传输和处理请求，决定了哪些字段必须一致。

ALPN 用于协商应用层协议，不是地区选择或加速参数。传输方式依赖某种应用协议时，客户端和服务端的协商结果必须符合要求。指纹设置则可能影响 TLS 握手的呈现方式及实现兼容性，也不是越特殊越好。若订阅已经给出这些字段，应先按原值测试；若没有提供，不宜照搬其他节点的参数。不同服务端入口的要求可能完全不同，复制局部设置常常破坏原本可用的组合。

REALITY：按配套参数理解认证

REALITY 由 Xray 生态实现，使用与常规证书链验证不同的配套认证机制。客户端通常需要服务器名称、公钥相关参数、短标识及指纹等信息，具体界面名称会随实现演进而变化。这些参数必须来自同一份有效配置，不能从不同节点拼接。公钥用于验证配对的服务端，短标识也需要与服务端允许的值匹配；它们不是可随意省略的装饰字段。

常见的 VLESS、REALITY 与 Vision 组合还要求内核实现和传输条件相匹配。看到客户端支持 VLESS，并不能推导它支持 REALITY；支持 REALITY，也不意味着任何 flow 与任意传输叠加都可使用。应将服务端明确支持的组合视为整体。连接异常时，先核对内核、服务器名称、认证参数与 flow，再检查网络可达性，而不是单独更换其中一个字段反复试错。

REALITY 并不是用来补救错误服务器地址的工具，也不会自动保证某个远端的运行质量。安全协商成功只能说明这一阶段条件满足，后续代理认证、目标连接和路由仍可能失败。对于使用者，合理做法是保存提供方的完整参数，使用支持该组合的内核，并在更新后重新核对解析结果。不要将它理解为忽略时间、忽略身份或绕开所有证书概念的通用开关。

直接承载与 WebSocket 的成本

直接使用 TCP 承载时，中间处理层通常较少；WebSocket 则通过 HTTP 升级和消息封装提供另一种接入方式，常用于已有反向代理或应用服务架构。额外封装会带来开销，但实际体验也取决于部署路径是否合理。不能仅凭封装层数预测吞吐，更不能为了减少层数，擅自把服务端只提供的 WebSocket 改成 TCP。那是更换连接入口，不是客户端内部优化。

还有一类常见误区是把多路复用当作所有传输都适合的默认增强。多路复用试图让多条逻辑连接共享底层资源，但在丢包、长流量占用或特定协议流程下可能产生相互影响，有些组合也有明确限制。是否启用应以当前内核文档和服务端组合为准，并通过真实应用验证。配置界面出现某个开关，只表示客户端提供编辑入口，不代表它对每种节点都适用。

05 / Performance and battery

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

协议比较最容易被压缩成一张速度排名表，但缺少测试条件的排名无法复用。应用体验至少包含首次建立连接的时间、请求响应、持续吞吐、失败重试与长时间稳定性。代理协议只是其中一个变量；网络往返距离、解析过程、拥塞、服务端负载和目标站点响应，同样可能占主导。合理的比较应先固定这些条件，再观察协议组合和客户端设置带来的差异。

把延迟、握手与吞吐分开测量

客户端的 TCP 连通测试通常只覆盖到节点入口的连接，不能证明代理认证和目标请求成功。实际请求测试会更接近应用行为，但也受到测试地址的地区、缓存与服务状态影响。持续下载主要反映吞吐，不等于短请求响应快。应了解测试名称对应哪一种过程，在相同条件下比较同一指标，而不是把一种测试的结果与另一种测试直接相减。

首次连接通常还要完成域名解析、传输连接与安全握手，随后相同目的地的请求可能受益于连接复用。测试时既要观察首次打开，也要观察连续使用，避免只比较已经预热的一组连接。若一个节点首开慢、后续正常，优先分析握手与解析；若开始正常而持续传输逐渐变差，则应关注拥塞、丢包、服务端限制与设备温度。不同现象对应的优化方向并不相同。

资源开销取决于实现与工作负载

数据加密消耗处理器资源，额外封装增加处理与内存复制，连接复用和缓冲策略也会改变内存占用。具备硬件加速的算法可能在某类处理器上表现良好，在另一类设备上却不占优势。客户端界面进程和代理内核还可能分开运行，观察系统资源时要区分两者。不能仅看到界面进程占用较低，就认定整条代理链路的资源消耗也很低。

内存较高有时来自活动连接、缓存或缓冲区，并不自动代表故障。更有意义的是在相似负载下观察是否持续增长、停止流量后是否趋于稳定，以及是否伴随系统回收或进程退出。频繁断开重连可能比保持少量稳定连接产生更多握手工作；过于激进的连接复用也可能让多个请求共享一个受阻通道。设置应围绕实际负载调整，而不是单纯追求某个资源读数最小。

移动端更应观察无线电与后台行为

在 Android 上，耗电不仅来自协议计算，还来自无线网络活动、应用后台请求和唤醒。短间隔保活、频繁自动测速、失败后的持续重试，都可能使设备难以进入低活动状态。信号较弱时的蜂窝网络传输也可能放大耗电。比较 v2rayNG 或 v2flyNG 的电量表现时，应固定网络类型、屏幕状态和应用负载，同时检查是否存在自动更新或测试任务。

系统的后台限制会影响长期连接，放宽限制可能改善驻留，却也改变电量条件。因此不能在一组测试中允许后台运行，另一组保持严格限制，然后把差异全部归于内核。建议分别观察前台使用、息屏待机和无线网络切换三个场景，记录连接是否恢复、是否重复建立以及应用是否真正传输数据。只测屏幕亮着时的一次下载，无法覆盖移动端日常体验。

需要对比时，每次只改变一个变量，选择相近时段重复测试，并保留原来的可用配置作为回退。不要把连续满速下载作为唯一标准；它会让温度、流量和系统调度一起变化。对于日常浏览，稳定完成短请求通常比峰值吞吐更有参考价值。最终结论应表述为某设备、某网络和某配置组合下的观察，而不是适用于所有用户的协议排名。

06 / Core compatibility

V2Fly、Xray 与客户端的关系

V2Ray 最初属于 Project V 生态。V2Fly 延续了相关项目的社区维护，Xray 则从这一技术基础分支发展，并围绕 VLESS、XTLS 与 REALITY 等方向形成自己的实现路径。它们共享一部分概念与历史配置习惯，但已经不是可以任意互换的同一个程序。选择内核的首要问题是能否实现目标配置，其次才是在特定设备上的资源表现和维护便利程度。

图形客户端与内核承担不同工作

图形客户端负责订阅管理、节点编辑、系统代理与启动控制；内核解释运行配置并执行连接、路由和传输。v2rayN 是桌面首选入口，可按所用平台与软件包情况管理相应内核配置。v2rayNG 面向 Android，以 Xray 为主要内核方向；v2flyNG 则提供基于 V2Fly 的备选。客户端名称本身不是代理协议，同一条协议记录能否运行，最终仍取决于它生成的配置和实际调用的内核。

客户端界面支持某字段，并不总能证明当前运行内核也支持该字段。反过来，内核已有某项能力，界面可能尚未提供相应编辑方式。排查时需要同时看导入结果、运行日志与当前内核选择。尤其是在迁移旧配置或切换内核后，要确认不是沿用了先前的默认项。界面显示“已启动”只表示启动动作完成，不能代替一次真实的目标请求验证。

共同支持的协议也有配置边界

两种内核可能都支持 VMess、VLESS、Trojan 或某些 Shadowsocks 方法，但具体传输、安全扩展、字段名称和默认行为仍可能不同。REALITY 与 XTLS Vision 属于 Xray 路线的重要能力，不应假设 V2Fly 能照原样解释。若配置依赖这些能力，应选择匹配的实现；删掉关键字段以通过解析，会改变连接语义，并不等于获得了兼容配置。

JSON 外形相似也是常见误导。两种内核都可能使用入站、出站、路由等结构，但同名字段的取值范围、扩展字段和 DNS 处理方式可能随各自实现变化。迁移时应从功能需求出发，逐项核对对应设置，而不是将一份完整文件直接交给另一种内核运行。尤其要复查路由标签是否存在、出站引用是否正确，以及依赖的数据资源是否能够加载。

下面只是用于解释路由语义的局部片段，不是可单独启动的完整配置。它表示匹配指定域名集合后选择名为 direct 的出站；运行时还必须存在同名出站，并能加载相关域名数据。这个例子也说明兼容性不仅涉及代理协议，还涉及配套资源和标签关系。复制一个规则对象却没有相应出站，不能得到预期的直连行为。

{
  "routing": {
    "rules": [
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      }
    ]
  }
}

切换内核应采用小范围验证

切换前保留原有可用配置，先选择一条明确被目标内核支持的节点测试。随后检查域名解析、常用站点、需要 UDP 的应用以及系统代理恢复。若只有某一类节点失败，优先检查该类协议的扩展字段；若所有节点都失败，再看内核启动错误、监听端口和配置生成过程。这样能把“内核未启动”与“某个协议不兼容”区分开，减少误判。

内核更新与客户端更新也可能分别发生。更新后若出现异常，应先查看变更涉及的协议、配置解析或默认行为，再用已有可用记录做对照，不应立即重建全部订阅。本站安装包页面按平台整理三款客户端入口；更深入的家族差异可结合Xray-core 与 V2Fly-core 对比文章查阅。选择标准始终是实际配置需求，而不是把分支关系当作质量排名。

07 / Subscription formats

订阅格式、分享链接与迁移检查

订阅是配置的分发方式，不是新的代理协议。订阅地址通常返回一组节点信息，客户端再将其解析为内部记录；分享链接则经常只表达一条节点。二者都可能使用编码封装，但编码不等于保密。订阅地址及节点中的认证字段应按敏感信息保管，不宜放进公开截图、论坛帖子或完整日志。排查时只需要描述字段是否存在，不需要公开实际内容。

获取成功不等于解析完整

订阅更新包含网络请求、内容识别、字段解析与记录写入几个阶段。请求返回内容，并不保证内容就是客户端理解的节点列表；某些情况下可能返回登录页面、错误提示或另一种配置格式。若更新后没有节点，应先区分请求失败与解析失败。前者检查地址有效性和请求所走网络，后者检查提供方输出的格式是否与目标客户端兼容，而不是反复点击更新。

常见分享形式包括 VMess、VLESS、Trojan 与 Shadowsocks 各自的链接约定，但即使前缀相同，扩展字段的表达方式也可能存在差别。传输路径、服务器名称、flow、指纹及 REALITY 认证参数，在某个解析器中可能被完整识别，在另一个解析器中却被忽略。因此导入数量看起来正确，也需要抽查节点详情。最危险的情况往往不是彻底导入失败，而是关键字段丢失后仍生成一条看似正常的记录。

节点列表与完整运行配置不能混用

一组节点列表通常只提供出站连接信息；完整配置还可能包含入站、DNS、路由和策略。客户端的普通订阅入口未必接受后者，完整配置入口也未必会套用界面中的所有设置。应先判断导入对象是什么，再选择对应功能。如果完整配置接管了路由，而用户仍反复切换界面预设，可能出现设置看似变化、实际行为不变的情况，这不是协议本身的故障。

从 v2rayN 迁移到 v2rayNG 或 v2flyNG 时，优先使用提供方明确给出的兼容订阅或分享格式。复制桌面端生成的运行配置，不一定能保留移动端所需的入口与运行环境。移动端接入应用流量的方式、文件路径和后台限制与桌面不同，即使出站协议相同，也不能假设整份配置直接适用。迁移应保留节点语义，而不是强行保留所有平台相关字段。

更新策略需要考虑覆盖与网络路径

订阅分组通常帮助客户端识别哪些节点来自同一来源，更新时可能替换、删除或重建对应记录。对订阅节点直接做的手动修改，下一次更新后可能不再保留。若需要临时比较参数，应先使用客户端提供的复制或独立记录方式，并注意复制行为是否仍与原订阅关联。保留原始分组有助于判断问题来自提供方变更，还是本地修改。

更新请求走直连还是代理，会影响可达性，但“通过代理更新”也可能形成依赖：当前节点已经失效，客户端便无法通过它获取新配置。遇到这种情况，应使用可用网络路径或已有的独立可用节点完成更新，而不是无限重试。自动更新间隔也不宜过短；更新频率应与提供方的变更节奏和设备后台条件匹配，频繁请求并不会使节点性能自动提升。

完成迁移后，先选一条节点验证，再检查分组、路由与日常应用，不必一次修改所有配置。若出现更新时间正常但字段缺失，可以向提供方说明目标客户端、协议类型与缺失字段名称，不发送完整认证内容。更新失败的具体分支可参照订阅更新排查文章；常见概念问题则可返回使用文档中的导入步骤，保持获取、解析与运行三个阶段的区分。

08 / Selection workflow

按场景选择协议与验证配置

实际选型不需要从所有协议中找一个永久最优答案，而是先确定设备、客户端和服务端提供的有效组合，再在其中选择稳定满足需求的一项。桌面优先使用 v2rayN 管理配置；Android 通常从 v2rayNG 开始，明确需要 V2Fly 行为时再考虑 v2flyNG。客户端只是配置入口，最终决定连接能力的仍是内核与完整参数。不能仅凭同一个节点名称判断两台设备运行条件相同。

日常浏览与长期稳定使用

以网页浏览、文档和即时消息为主时，应优先观察短请求成功率、首次响应和后台恢复，而不是只看满速下载。若已有协议组合稳定，服务端持续维护且客户端能够完整解析，没有必要为了标签更新频繁迁移。若需要更换，可以先在相同网络条件下测试新组合，确认常用目标、解析与重连正常，再将其设为日常使用项，并保留原有可用配置。

连接频繁建立的小请求场景，需要特别留意握手和连接复用，但不要把所有慢响应都归因于握手。目标站点本身响应慢、路由误选直连或 DNS 返回不合适地址，也会产生类似现象。先确认请求确实经过预期出站，再比较协议差异。否则测量得到的可能是两条不同网络路径，而不是两个协议处理相同工作负载的表现。

移动网络、持续传输与特殊应用

经常切换无线网络与蜂窝网络时，恢复能力比一次测试中的最低延迟更重要。应观察网络切换后旧连接是否释放、新请求是否自动恢复，以及后台限制是否阻止客户端继续运行。如果只有切换后出现异常，可以先重新建立连接，检查解析与当前网络，再决定是否换协议。反复更改安全参数通常无法解决旧连接没有恢复的问题，反而会增加额外变量。

大文件传输、长时间视频等场景更看重稳定吞吐与温度表现。选择时要控制服务器地区和测试时段，观察持续传输是否频繁中断，不宜以某一次峰值作为唯一依据。对需要 UDP 的应用，应明确确认整条链路的支持：本地接入方式、内核出站、服务端与远端目标都可能成为限制。网页请求成功只验证了其中一部分能力，不能代替应用本身的测试。

资源有限的设备可以优先选择实现成熟、附加层较少且双方明确支持的组合，但这不是要求删去必要的安全保护。更有效的措施往往是减少过于频繁的自动测速、保留合理日志量、避免重复后台任务，并检查异常重连。若设备持续发热，应区分真实流量、后台更新与连接失败重试，再比较协议计算开销，防止把应用负载变化错误归因于内核。

用固定顺序定位连接失败

第一步确认应用进入客户端：系统代理是否指向正确入口，本地监听是否启动，应用是否遵循该代理设置。第二步确认路由选择了预期出站，不要将直连失败误认为节点失败。第三步确认远端地址可达，再根据日志检查安全握手、代理认证与目标连接。这个顺序从本地到远端逐层缩小范围，通常比先换一整套节点设置更容易得到可靠结论。

如果日志显示配置无法解析，应先解决内核兼容与字段问题；若安全握手失败，核对服务器名称、时间与配套认证参数；若认证失败，核对身份字段及入口类型；若认证完成但目标不可达，再看 DNS、路由与服务端访问目标的条件。测试时只改一项并保留结果，恢复原值后再进入下一分支。这样即使没有立即修复，也能明确排除了什么，而不是陷入多项设置同时变化的循环。

路由的先后命中与域名处理策略可以继续查阅自定义路由规则语法；客户端显示已连接但网页打不开时，可按系统代理、路由与 DNS 排查清单逐项核对。需要重新安装或更换平台时，前往安装包页面选择对应入口。协议选型的结果应是一份能解释、能验证、能恢复的配置，而不是一个脱离设备和网络条件的名称排名。