V2Ray 协议与内核选型手册

连接配置的四个层次

先区分客户端、内核和远端服务

在客户端里选择协议之前，先确认三个对象。v2rayN、v2rayNG、v2flyNG 是图形客户端，负责保存配置、展示设置、启动连接与管理订阅；内核负责解释配置、建立连接、匹配路由和处理数据；远端服务则按照约定的协议接收连接。三者不是同一个软件层级。界面能够保存一条记录，只能说明客户端接受了输入，不代表内核认识全部字段，更不代表远端使用了相同参数。桌面端优先从 v2rayN 的平台入口选择安装包，安卓端再根据配置所需内核选择对应客户端。

一条连接通常可以拆成服务器地址、代理协议、传输方式、安全层四组信息。服务器地址回答连接到哪里；代理协议回答如何认证和表达目标地址；传输方式回答协议数据如何承载；安全层回答连接怎样获得机密性与身份验证。把这些信息全部叫作“协议”，会使排查失去层次。例如 VLESS 是代理协议，WebSocket 是传输方式，TLS 是安全层，三者可以共同出现在一条配置里，并非三个互斥选项。端口只是远端监听入口，也不能单独证明它使用哪种协议。

界面字段之间存在对应关系

客户端中的“地址”一般用于建立底层连接，“服务器名称”或 SNI 用于 TLS 握手中的名称信息；两者可能相同，也可能由服务端配置决定为不同值。WebSocket 的 Host 与路径属于另一组应用层参数，不能因为名称相似就复制 SNI 填入所有位置。直接连接某个 IP 时，证书验证仍可能需要一个域名。应保留服务提供方给出的字段分工，不要把地址、Host、SNI 当成三个可以任意交换的别名，也不要通过关闭证书验证来掩盖配置错误。

路由规则不改变远端协议

路由设置决定请求进入内核之后交给哪个出站处理，可以直连、代理或阻断；它不会把 VMess 自动改成 VLESS，也不会补齐缺失的 TLS 参数。安卓 VPN 模式与桌面系统代理属于本地接入问题：前者通过系统提供的虚拟网络接口接收选定流量，后者告诉遵循系统代理设置的应用去访问本地监听端口。客户端显示运行中但某个程序没有走代理，应先确认接入方式，而不是立即切换远端协议。相关层级区别也可参阅系统代理与路由模式说明。

阅读分享链接时，可以按同样顺序做一份字段清单：地址与端口是否存在，认证字段属于哪种协议，传输是否有专用路径，安全层是否启用，最后再检查路由和 DNS。这样即使更换客户端，也能明确哪些是远端连接的必要条件，哪些只是本机的使用偏好。不要从链接长度、备注文字或协议名称判断配置是否更先进；备注只是标签，真正决定连接行为的是内核最终收到的配置。

VMess 与 VLESS 的设计取舍

VMess 将认证与数据保护纳入协议

VMess 是 Project V 生态早期形成的代理协议，围绕用户标识、请求认证与数据保护设计。客户端里常见的 UUID 用来标识用户，并不是服务器域名，也不是订阅地址。配置中的加密或安全选项需要与内核支持的方式匹配，不能因为导入成功就随意改成另一个值。VMess 可以使用不同传输承载，也可以叠加 TLS；协议本身的加密与外层 TLS 有不同职责，不能把其中一个字段直接等同于整条连接的安全状态。

现代 VMess 部署通常采用 AEAD 认证机制。旧教程中出现的额外 ID、旧认证模式或历史兼容选项，不应被当成当前配置的通用推荐值。已有配置能否继续使用，取决于两端实现是否仍接受同一种机制。遇到旧订阅时，正确步骤是确认服务端实际使用的认证方式，获取更新后的连接参数，再检查客户端与内核支持情况；反复修改额外 ID 或套用网络上的固定数值，通常只会增加不一致项。

系统时间也值得单独检查。某些协议认证流程涉及时间窗口，设备时间偏离较大时可能表现为认证失败，而底层 TCP 连接仍然成功。先启用系统自动日期、时间与时区，再尝试连接，比反复重装客户端更有针对性。时间正确也不意味着认证一定正确，UUID、端口和远端配置仍要逐一对应。日志如果停在认证阶段，应优先核对这些条件，而不是先修改 DNS 或路由规则，因为请求可能尚未进入后续转发过程。

VLESS 将数据保护交给外层安全机制

VLESS 的设计方向是减少协议自身承担的加密工作，把数据保护交给 TLS、REALITY 等外层机制。它仍需要认证与目标地址表达，并不等于没有协议开销。常见 VLESS 配置中的加密字段为 none，这是该字段的协议语义，不表示所有数据都会以明文跨越网络。判断完整连接时必须同时检查安全层。反过来，如果没有外层保护，也不能只凭 VLESS 这个名称推断连接具有机密性。

VLESS 配置可能带有 flow 字段，例如 xtls-rprx-vision。它不是可以通用粘贴到所有连接的提速开关，而是与特定处理流程、传输组合及内核能力相关的参数。客户端和服务端需要同时满足对应条件。将它加到不支持的传输组合上，可能直接导致配置拒绝或握手失败。服务提供方没有给出 flow 时，不应凭名称自行补上；给出了 flow 时，也不能因为另一个客户端界面没有输入框就认为可以省略。

从现有配置迁移时保留完整参数

VMess 与 VLESS 不是修改下拉框就能互换的格式。即使两条记录使用相同的服务器地址与用户标识，服务端也需要配置对应的入站协议。迁移时应获取服务端提供的新链接，分别检查安全层、服务器名称、传输、路径和 flow，再建立一条独立记录测试。保留原来的可用配置，能够在新配置失败时迅速区分“迁移参数错误”与“本地网络变化”。不要直接覆盖订阅管理的记录，否则下一次更新还可能把手工改动恢复。

已有 VMess 连接稳定、远端暂时没有迁移计划时，没有必要为了协议名称更换整个环境。新部署若明确采用 VLESS 与指定安全层，则选择能表达这些字段的客户端和内核。两种情况下都应以端到端兼容为先，再考虑开销差异。若服务方只给出“支持 VLESS”而没有说明传输和安全层，信息仍不完整，应先补齐参数再导入，避免把兼容性问题误判为服务器不可达。

Trojan、Shadowsocks 与 REALITY

Trojan 依赖正确的 TLS 连接

Trojan 的设计以 TLS 为基础，将密码认证与目标请求放在受保护的连接中。常见配置需要服务器地址、端口、密码和用于名称验证的相关参数。这里的密码属于远端连接凭据，不应贴到公开日志或讨论区。TLS 握手成功与代理认证成功是两个阶段：证书名称不匹配时，应检查服务器名称与证书部署；握手完成后仍被拒绝，则继续核对密码及远端服务设置。将两个阶段混成“连不上”，会让排查范围过大。

证书验证不仅是一个可以随手关闭的开关。它用于确认连接所面对的服务身份，关闭后即使暂时能够建立连接，也改变了原本的安全假设。设备时间错误、证书链配置不全、名称填写不一致都可能引起验证失败，应分别修正。Trojan 的具体扩展能力也取决于实现，某个客户端能导入基本密码配置，不代表它理解其他实现附加的全部选项。分享链接中多出来的字段需要单独确认，而不是默认为装饰信息。

Shadowsocks 要同时匹配方法与密钥语义

Shadowsocks 通常在客户端中显示为 Shadowsocks 或 SS。它采用预共享秘密与加密方法的组合，配置看起来简短，但方法名称属于连接协议的一部分。两端必须使用相同方法，不能在客户端里把方法改成看起来更熟悉的一项。传统 AEAD 方法与 Shadowsocks 2022 系列也不是只改名称即可互换。后者对密钥材料有特定格式与长度要求，不能把任意日常密码当作有效密钥，更不能期待客户端自动转换成服务端需要的值。

选择 Shadowsocks 时，还要检查订阅是否附带插件参数。基本协议支持与插件支持是两项能力，缺少插件实现时，地址、端口、方法和密码全部正确也可能无法使用。不同内核对方法和插件的支持范围可能不同，应以本机内核实际接受的配置为准。需要 UDP 的应用还要确认远端允许 UDP 转发、客户端接入路径能够承载它，以及路由没有另行阻断。只看到网页打开，不能证明这些条件已经满足。

REALITY 是安全机制，不是独立代理协议

REALITY 常与 VLESS 一起出现，因此分享记录可能以“VLESS + REALITY”命名。它承担安全层相关职责，不是与 VLESS 平级的另一种账号类型。常见客户端字段包括服务器名称、公钥、短 ID 和指纹；其中公钥用于对应服务端的密钥配置，短 ID 用于匹配服务端允许的标识，指纹涉及客户端握手特征。字段的格式和是否必填取决于具体配置，不能从另一条连接中任意借用，也不要把公钥误当成 UUID。

REALITY 的参数组合需要由服务端设计并提供。远端地址可以访问，并不代表公钥、短 ID 与服务器名称组合正确。连接失败时，先核对链接是否被完整复制，特别是含有特殊字符的查询参数；再确认客户端当前使用的内核能识别这些字段。不要先尝试随机指纹、随机短 ID 或不相关的域名。某个字段在界面上为空，也可能是导入器没有解析出来，而不是服务端不需要它，应回查原始分享内容。

这三项不能按“新旧”排成一条替换链。已有 TLS 基础设施、现有订阅格式、服务端实现以及移动端支持情况，都影响最终选择。对于只使用客户端的用户，最可靠的操作是保持服务提供方给出的参数组合，先检查本机是否完整支持，再用相同网络与相同业务做比较。安全层与代理协议的名字越多，并不自动意味着配置越合理；减少不必要的中间层，通常更有利于理解和维护。

连接速度、吞吐与资源占用

将首次连接与持续传输分开观察

“速度快”至少包含三种不同体验：点击后多久得到首个响应，长时间传输能维持多大吞吐，以及并发请求时是否稳定。首次响应受到本地 DNS、远端地址解析、底层连接和安全握手共同影响；持续吞吐更受路径带宽、丢包、拥塞控制、远端负载与设备处理能力影响。某条配置首次打开页面较慢，却可能在大文件传输中表现正常。因此不能拿一次页面加载与另一条配置的一次测速互相比，必须先确定要比较的指标。

代理协议本身的处理开销只是完整链路中的一部分。加密算法是否能利用处理器指令、外层是否叠加 TLS、中间是否经过反向代理，都可能改变 CPU 使用与连接建立成本。低功耗设备上可观察到的差异，在性能充足的桌面设备上可能很小。不能脱离硬件条件宣布某个协议永远最省资源，也不能把远端拥塞导致的低吞吐解释为本机加密算法慢。先检查网络与服务负载，再讨论协议开销，判断顺序更稳妥。

传输封装与连接复用各有边界

直接 TCP、WebSocket 与 gRPC 的差异，主要涉及承载方式、中间设施兼容性与连接管理。WebSocket 可能需要 HTTP 升级和正确路径，gRPC 通常依赖 HTTP/2 及匹配的服务名，中间转发配置也必须相应支持。这些机制为部署提供灵活性，同时增加需要维护的参数。选择它们应有明确的服务端需求，而不是把封装层数当成性能增强项。路径或服务名错误时，底层端口仍可能可达，但代理会话无法真正建立。

客户端中的“启用 Mux 多路复用”尝试让多个逻辑请求共享较少的底层连接。它可能减少频繁建立连接的开销，也可能让不同请求共享同一连接上的拥塞与故障影响。与传输自身复用机制叠加时，收益不一定增加；某些协议、flow 或内核组合还有明确限制。先保留配置默认值，在服务端明确支持且业务确有大量短连接时再测试。不能把 Mux 当成遇到卡顿就必须打开的通用修复项。

用可复查的测试代替单次排名

可以先用一个普通网页观察首次响应，再用允许测试的稳定资源观察持续传输，最后运行真实业务检查并发与长连接。重复测试时应区分首次连接与已复用连接，因为缓存和会话恢复会改变结果。测试期间暂停其他大流量任务，记录是否发生网络切换与休眠。不要只保留最好的一次结果，也不要把应用显示的连接测试时间当作端到端下载速度；不同测试方式测到的对象可能完全不同。

CPU 与内存的观察也需要上下文。规则数据库、连接数量、日志级别和 DNS 缓存都可能增加资源占用，不应全部归因于协议。若客户端空闲时正常、打开大量页面后占用上升，应先看并发连接与规则处理；若单个持续传输就使设备明显发热，再比较加密与封装条件。排查结束后关闭不必要的详细日志，保留原始设置记录，才能知道后续变化来自哪一项配置，而不是依赖印象做判断。

实时通信尤其需要额外检查 UDP 路径和抖动。网页正常只证明部分 TCP 请求可用，并不代表通话、游戏或名称解析所需的 UDP 都能顺利通过。若业务出现间歇停顿，应检查接入方式、服务端转发和网络丢包，而不是只换一个协议名称。对于长期使用，稳定完成真实业务比某次峰值吞吐更有参考价值；选择时应把失败恢复能力与可维护性一起纳入判断。

安卓后台、网络切换与电量

耗电来自整条处理路径

安卓端的耗电不能仅按 VMess、VLESS 或 Trojan 分类。无线网络唤醒、连接保活、DNS 查询、后台应用请求、加密处理和详细日志都可能影响电量。持续高吞吐会增加无线模块与处理器工作时间；大量零散后台请求则可能频繁唤醒设备，即使总流量不大也有明显影响。比较协议时，应保持代理应用范围、远端服务、网络类型与屏幕状态一致，否则测到的往往是使用方式差异，而不是协议设计差异。

v2rayNG 的 VPN 模式通过系统 VPN 接口接收流量，再交由内核处理。分应用代理可以缩小进入处理路径的应用集合，但“选择应用”究竟表示仅代理所选应用还是绕过所选应用，需要看当前模式与界面说明。修改之后应重新建立连接，并实际打开目标应用验证。仅代理模式则需要应用能够主动使用本地代理入口，不等于系统会自动把所有应用流量交给它；使用模式不匹配，常被误认为连接不稳定。

后台限制应按症状调整

如果切到后台或熄屏后连接立即停止，先检查系统是否结束了客户端服务、是否允许后台运行，以及其他 VPN 应用是否替换了当前连接。不同安卓设备的电池管理入口和名称存在差异，可以从应用信息中的电池与后台权限开始查。不要一开始就关闭所有节能设置；先确认问题是否发生在熄屏、锁屏清理或特定省电模式之后，再对客户端做必要调整。网络仍在但某个应用收不到消息，也要检查该应用自身的后台限制。

如果客户端仍在运行，只有 Wi-Fi 切换到移动网络后连接失效，应优先考虑原有底层连接已经中断。旧连接不能因为协议名称相同就自动跨网络继续存在，内核和应用需要重新建立会话。先停止并重新启动连接，观察能否恢复；若能恢复，再检查自动重连行为、系统网络状态及远端对连接的处理。流媒体或通话应用还可能保留旧会话，需要重新进入业务界面，不能只根据状态栏图标判断恢复结果。

复用、保活与 DNS 不宜盲目加码

保活可以帮助发现失效连接或维持某些网络设备上的会话，但更频繁的探测也可能增加无线唤醒。没有明显空闲断连问题时，不必主动追求极短间隔。Mux 同样需要按照协议组合判断，不能因为手机功耗敏感就认为共享连接必然省电。大量数据持续传输时，减少一点握手并不一定改变主要耗电来源；而连接异常后反复重试，反而可能成为额外负担。调整后必须观察真实使用，而不是只看开关是否点亮。

DNS 配置错误可能造成重复查询、超时与连接重试，看起来像客户端一直工作却没有有效请求。遇到这种情况，应先区分地址解析失败和安全握手失败，再检查解析服务器是否可达、路由是否形成循环、域名策略是否引入额外解析。启用本地 DNS 不代表所有应用都会自动使用同一解析路径，应用自己的加密 DNS 也可能影响结果。相关问题可在FAQ 故障排查分类继续核对，避免同时修改 DNS、安全层与路由。

电量对比可以按相同条件分为两个观察窗口：先在屏幕关闭、业务基本空闲的情况下检查后台稳定性，再在固定业务下观察发热与耗电趋势。记录连接是否重建、网络是否切换、应用是否持续下载；不需要给出脱离设备条件的固定耗电百分比。若空闲时异常，重点查唤醒、重试与日志；若只有高负载时异常，重点查吞吐、加密和设备散热。这样得到的结论才能指导实际设置。

V2Fly、Xray 与客户端兼容边界

共同来源不等于功能完全相同

Project V 是理解这套生态的起点，V2Fly 与 Xray 是相关内核家族中的不同发展路线。它们共享部分概念与历史基础，例如入站、出站、路由和 DNS 的配置思路，但会独立演进协议能力、传输实现和配置字段。判断兼容性时，不能仅凭“都属于 V2Ray 生态”推导出完全通用。某个字段在一个内核中有效，在另一个内核中可能不存在、名称不同，或具有不同约束，应逐项确认而不是整份照搬。

v2rayNG 以 Xray 内核为主要连接能力基础，v2flyNG 面向 V2Fly 内核路线；v2rayN 则提供桌面图形管理与相应的内核运行配置。图形界面的功能与实际选择的内核必须一起看。客户端存在某个导入入口，不代表当前运行的内核一定能执行导入内容。详细生态关系可结合Project V、V2Fly 与 Xray 家族说明阅读，避免把客户端名称直接当成协议能力清单。

协议、配置与界面是三种兼容性

协议兼容表示双方能够按同一协议交换数据；配置兼容表示内核能够理解配置结构和字段；界面兼容表示客户端有办法录入、保存并传递这些字段。三者缺一都可能导致无法使用。例如内核具备某项能力，但图形导入器没有保留新参数，最终生成的配置仍然不完整。反过来，界面保留了原始字符串，但实际内核不认识它，也不会因此获得能力。排查应查看最终失败发生在哪个阶段。

REALITY 与常见的 VLESS Vision 组合，是需要重点检查 Xray 能力与字段完整性的情况。不能假定另一内核具有同名、同义且可直接替换的实现。V2Fly 路线中的协议和传输功能也要以其实际实现为准，不应把某个家族描述成另一个家族的全部功能子集。选择内核不是抽象评选谁更先进，而是回答当前服务端要求的组合能否被准确执行，以及客户端是否能维护这份配置。

短配置也要检查运行上下文

下面是 Xray 风格的路由片段，用于解释规则职责，不是独立可运行的完整配置。使用时需要合并进相应完整配置，并确保存在标签为 direct 和 block 的出站，同时已配置对应规则资源。第一条阻断指定广告域名集合，后两条分别将私有地址与指定域名集合交给直连出站。规则按顺序匹配，后面的规则不能覆盖已经命中的前项，因此调整顺序可能改变结果。

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "domain": ["geosite:category-ads-all"],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      }
    ]
  }
}

IPIfNonMatch 表示域名规则未匹配时，路由阶段可以尝试解析域名，再继续检查 IP 条件；它不是“所有域名优先按 IP 分流”。规则资源缺失、出站标签写错或 DNS 不可达，都可能使片段不能按预期工作。这说明配置兼容不仅是字段名称相同，还包含资源、标签和解析路径等上下文。普通使用优先在客户端提供的路由界面维护规则，只有明确理解生成结构时再使用自定义片段。

订阅、分享链接与导入兼容性

订阅地址与连接凭据不是同一对象

订阅链接通常是一个用于获取配置集合的地址，单条分享链接则描述一条连接。把单条分享链接填到订阅地址输入框，或把订阅地址当成连接记录导入，可能导致获取失败或没有有效条目。订阅还可能包含访问令牌，其权限范围可能覆盖整组配置，应按敏感信息处理。排查时不要公开原始订阅地址，日志或截图中也应遮住认证查询参数、账号标识和远端密码，避免因求助暴露整组连接权限。

Base64 是编码方式，不是加密协议，也不负责保护订阅内容。常见订阅把多条分享链接组成文本后再编码，客户端需要先还原文本，再逐条解析链接。有些接口则直接返回明文链接列表或某种结构化配置。服务器返回网页、登录提示或错误消息时，客户端未必能把它识别为有效订阅。更新失败应先区分请求失败与内容格式不兼容，而不是简单理解成 Base64 编码坏了。

同一协议也可能有不同分享约定

VMess 分享内容常见编码后的结构化数据；VLESS 与 Trojan 常见带查询参数的 URI；Shadowsocks 链接又可能采用不同的用户信息编码形式。这些属于客户端之间的分享约定，不完全等同于内核配置格式。即使底层协议可用，导入器也可能因为编码形式、参数命名或扩展字段不同而无法完整识别。不能只看链接前缀是否认识，还要检查导入后传输、安全层与认证字段是否确实落在对应位置。

链接中的路径、备注和查询值可能经过百分号编码。手工复制时，换行、空格、聊天工具自动截断以及重复解码，都可能改变原始值。特别是路径中含有问号、井号或与号时，这些符号在 URI 中有结构意义，不能一律当作普通文字粘贴。优先使用客户端的剪贴板导入或扫描入口，不要先在文本编辑器里做多轮转换。导入后需要比较字段含义，而不是仅比较备注文字是否相同。

按分组入口更新，再检查结果

v2rayNG 通常从“订阅分组设置”添加分组备注与订阅地址，保存后再执行订阅更新；v2rayN 在订阅分组相关菜单中管理地址与更新。实际菜单名称可能随客户端界面调整，但应区分“保存订阅地址”和“获取订阅内容”这两个动作。保存成功不代表远端内容已经下载。详细操作可阅读订阅入口与 Base64 格式说明，第一次操作则沿着入门指南完成主线。

更新完成后，先确认条目所属分组、协议类型和关键安全参数，再尝试连接。若更新前可用、更新后失败，应比较远端是否修改了认证、传输或安全层，而不是立即重置整个客户端。某个分组的更新可能替换其管理的条目，手工修改订阅记录也可能在下次更新时被覆盖。需要临时验证字段时，应建立独立测试副本并明确标记用途，验证完成后回到订阅源修正，避免长期维护两份互相冲突的信息。

格式转换工具只能转换它理解的内容。源订阅包含的插件、flow、REALITY 参数或特殊传输字段，如果目标格式没有对应表达，转换结果可能仍能导入，却失去关键能力。增加转换步骤还会增加敏感配置被其他处理方接触的机会。优先使用服务端提供的原生兼容格式；确需转换时，逐项核对转换前后的字段，不要把“转换成功”当成端到端兼容证明。订阅负责分发配置，不能修复服务端与内核能力之间的差异。

按使用场景选型与定位失败阶段

先确定硬条件，再比较体验

已有服务配置时，选择空间首先由服务端限定。拿到的是 VMess，就先使用支持其认证与传输组合的客户端；拿到的是 VLESS 与 REALITY，就先确认 Xray 能力和必需字段。只有服务端同时提供多种完整配置，才适合在相同条件下比较。桌面端首推 v2rayN，按系统和处理器架构选择安装入口；安卓端通常从 v2rayNG 开始，需要 V2Fly 路线配置时再检查 v2flyNG。对应文件说明统一放在下载页，本页不替代安装包选择。

日常网页与办公使用更重视首次响应、证书验证和长期稳定，通常没有必要为了理论开销增加复杂封装。开发工具与终端则要先确认应用是否遵循系统代理，是否需要单独设置代理环境变量；浏览器可用而终端失败，往往是本地接入差异，不是远端协议不适合终端。可结合浏览器与终端分别排查的说明定位，避免在已经可用的远端配置上反复修改认证与安全参数。

涉及实时通信、互动业务或依赖 UDP 的应用时，需要把 UDP 支持作为硬条件。先检查客户端接入方式，再检查内核、远端转发和路由，最后测试实际业务。移动网络经常切换的场景则更关注重连、后台存活和会话恢复，而不是短时吞吐最高值。长时间传输可以重点观察持续速率、处理器负载与稳定性，但仍应保持远端位置和测试资源一致，否则无法区分网络差异与协议差异。

按阶段缩小故障范围

第一阶段看配置能否加载。若日志提示未知字段、无效方法或缺少参数，先检查客户端导入与内核兼容，不要先调整路由。第二阶段看远端地址能否解析并建立底层连接。解析失败重点查 DNS，连接超时重点查地址、端口、网络路径和远端监听；端口可达只证明底层入口有响应，并不表示代理认证成功。每次只修正当前阶段的问题，能避免多个不相关改动互相掩盖。

第三阶段看安全握手与认证。证书错误先查时间、服务器名称与证书链；REALITY 相关失败先查公钥、短 ID、指纹和名称参数；认证拒绝再核对 UUID、密码或协议专用字段。第四阶段看请求是否进入正确出站。握手完成但目标打不开时，检查路由命中、DNS 结果、出站标签与目标服务状态。若只有个别应用失败，再回查系统代理、分应用代理和应用自己的代理设置，不要将局部故障直接归类为整条连接失效。

把测试结论转成维护记录

可以为每种候选配置记录用途、必要字段、客户端与内核、测试网络及观察结果，不需要记录公开可见的账号秘密。用途写清楚是网页、开发工具还是实时通信；观察结果写清楚是首次响应慢、后台断开还是仅 UDP 失败。这样的记录比“某协议不好用”更有价值，也能在更换设备后重建正确配置。更新客户端或订阅后先复测基线业务，发现变化再逐层比较，而不是用全量重置替代定位。

最终选择应同时满足三个条件：服务端组合被完整支持，安全验证保持正确，真实业务在目标设备上稳定运行。在这些条件成立后，再根据资源占用、维护难度与网络切换表现作取舍。协议名称不能替代这些验证，也不存在适合所有设备与业务的固定冠军。常见症状的短答案见FAQ；需要重新走一遍导入、连接和验证流程时，返回入门指南按步骤操作即可。