V2Ray 协议
与内核参考

VMess 的认证与传输取舍

VMess 是 Project V 生态中较早形成的代理协议，设计中包含用户身份、请求封装和数据保护相关机制。它的历史应用广，许多旧订阅和部署说明仍以它为基础。理解 VMess 时，要区分协议仍可使用与旧教程仍然适用这两件事。早期配置中出现的认证方式和辅助字段，可能已不适合当前内核。选型首先看服务端实际实现，不能仅按教程年份或节点名称推断兼容性。

用户 ID、加密方法与时间

“用户 ID”通常填写 UUID，用于身份认证，不是随意取的备注名。客户端生成一个新 UUID 不会让它自动获得服务端授权，必须与服务端用户配置一致。“加密方式”同样有协议含义，不能和 TLS 开关混为一谈。常见的自动选择会由实现决定合适的方法；手动固定算法前，应确认双方支持。处理器是否具有相应硬件加速，会影响算法的实际开销，名称本身不能给出稳定的速度排名。

VMess 的认证包含时间相关检查，系统时钟严重偏差可能导致认证失败。排查时应先启用系统时间同步，并确认日期、时间与时区显示是否合理。时区只影响显示方式，真正需要准确的是系统时间基准。若只修改界面显示而没有修正实际时间，问题仍会存在。不要在尚未核对时钟前就连续重建订阅或更换加密方法，这会引入新的变量，让错误难以复现。

旧分享信息里常出现 alterId。当前常见的 VMess AEAD 配置通常使用零值或由客户端按相应方式处理；它不是越大越安全的调节项。遇到保留旧字段的订阅，应该确认服务端是否已经采用相应认证方式，以及客户端如何解释该字段。不要照搬多年以前的非零取值。若服务端说明和导入结果冲突，应以服务端实际部署及所用内核文档为依据，而不是让两边各改一项碰运气。

WebSocket 与 TLS 为什么常一起出现

VMess 可以承载在不同传输上。WebSocket 与 TLS 的组合常见于需要反向代理的部署：客户端先完成 TLS 握手，再发起正确的 HTTP 升级请求，最后进入 VMess 会话。因此端口可达并不代表路径正确。WebSocket 的 path 与 Host 必须符合部署要求，反向代理也必须把请求交给对应后端。路径拼写、结尾斜线或目标站点选择错误，都可能表现为握手失败或收到普通网页响应。

这种组合多了一些封装与握手步骤，但不意味着每次访问都重新承担完整成本。长连接复用、连接池、应用访问方式和中间代理的超时设置都会改变结果。反过来，直接 TCP 的封装更少，也不等于它在所有环境下都有更短的页面加载时间。如果服务器位置、链路质量或 DNS 不同，仅凭两条不同部署的结果，无法得出 VMess 本身快慢的可靠结论。

保留现有部署还是迁移

如果现有 VMess 配置在维护中的客户端与服务端上工作正常，协议名称较早并不是必须迁移的理由。更值得检查的是旧认证方式是否仍在使用、配置能否稳定导入、传输参数是否清楚，以及服务端是否持续维护。迁移到 VLESS 时，需要服务端创建相应入站并提供新的参数，不能只把客户端下拉框改成 VLESS。两种协议的认证和请求格式不同，不存在单方面改名的兼容捷径。

新建部署时，若目标功能依赖 Xray 的 VLESS 与 REALITY 组合，可以按相应方案配置；若需要继续接入既有 VMess 服务，应优先保持协议与传输一致。遇到“导入成功但连接失败”，先比较原分享内容和编辑窗中的加密方式、传输、安全层及路径，再查看日志。更多通用排查入口见常见问题，避免把本地系统代理问题误判成 VMess 协议不兼容。

Trojan 与 Shadowsocks 的边界

Trojan 与 Shadowsocks 提供了另外两种常见选择，但设计着力点不同。Trojan 的常见部署围绕 TLS 链路和密码认证展开，证书与服务器名称是配置的重要部分。Shadowsocks 则以较精简的代理转发与认证加密机制形成广泛实现，其协议方法有不同代际。比较它们时，不能把“只需密码”理解为安全层完全相同，也不能把所有写着 SS 的节点视为一个固定算法、固定功能的协议实现。

Trojan：密码之外还有证书与名称

在 v2rayN 或 v2rayNG 中添加 Trojan 时，通常需要地址、端口、密码和 TLS 相关设置。密码应保持原样，包含的符号不能被输入法替换；备注名不参与认证。服务器名称要与部署要求及证书验证关系一致。地址可以是 IP，而验证使用域名，但前提是服务端部署确实如此。遇到证书名称不匹配，先检查 SNI 与服务端证书，不要把错误归因于密码长度。

Trojan 的初次连接通常包含 TCP 建连和 TLS 握手。访问大量短请求时，连接是否复用会影响体验；访问长时间持续传输时，链路吞吐和服务器资源又更重要。TLS 是成熟的通用安全基础设施，但实际表现仍受实现、证书部署、中间代理和握手恢复影响。不能仅因为使用 TLS 就断言它一定更慢，也不能因为常见配置字段少，就认为排错时只需要检查一个密码。

Shadowsocks：加密方法必须精确对应

Shadowsocks 常见设置包括服务器、端口、密码和加密方法。较新的 AEAD 方法与更早的流式方法并非同一代设计，AEAD 方法在加密之外还处理数据认证。服务端指定的方法必须被客户端及运行内核支持，不能把下拉列表中的相近名称当作等价项。方法选错时，即使密码正确也无法正常通信。旧配置能导入，只说明客户端识别了分享结构，不代表相应算法仍被当前内核接受。

AEAD 2022 等方法还可能对密钥格式提出明确要求，不能沿用普通文本密码的直觉随意输入。某些部署具有多用户密钥等扩展形式，需要分享信息完整保留。遇到这种配置，应先确认服务端方法与客户端支持范围，再逐字复制密钥。把含分隔符的内容截成一段，或让订阅转换工具重新解释成传统密码，都可能破坏其含义。密钥的格式是协议条件，不是可自由选择的显示格式。

基础 Shadowsocks 配置中的 TCP 与 UDP 能力，也要结合客户端接入方式判断。服务端允许 UDP，不代表通过系统 HTTP 代理进入客户端的程序就会获得透明 UDP 转发。部分分享链接还携带插件参数；如果本站所用客户端和内核没有实现该扩展，仅保留服务器与密码并不能构成等价配置。此时应要求提供双方支持的完整方案，而不是删掉无法识别的字段后继续使用。

按既有部署选择，而不是按字段数量

如果服务端已经提供正确维护的 Trojan 配置，客户端完整支持其传输与 TLS 设置，就没有必要为了减少几项参数改成另一种协议。若服务端采用 Shadowsocks，则应优先记录准确的方法与密钥格式，尤其注意不同代际之间的差异。两者都不应该依靠关闭安全检查或删减未知参数来“提高兼容性”。保留错误提示，比把连接改成不再报错但含义已经变化的配置更有排错价值。

实际选型还要看管理成本：证书更新是否有可靠流程，密钥变更是否会同步订阅，目标内核是否支持所需扩展。对只接入既有服务的新手而言，最重要的是匹配现有部署而不是自行重设协议。若密码或订阅内容可能已暴露，应在服务端撤销并重新分发，不能仅改本地备注。客户端日志和分享链接也可能包含敏感参数，提交问题前应先删除身份信息与完整订阅地址。

连接开销、资源与移动端电量

“哪种协议最快”需要先定义测量对象。首次连接关注解析、建连和安全握手；网页体验还受目标站点、连接复用与资源数量影响；持续下载更关注吞吐、丢包和服务器容量；语音或实时应用又在意抖动与 UDP 路径。这些指标可能相互独立。客户端显示的一项延迟测试，不足以代表所有应用表现，更不能从不同服务器的两个数字推导出协议本身的速度差异。

握手成本与持续传输要分开看

DNS、TCP 建连、TLS 或其他安全握手会带来连接前置等待，WebSocket、gRPC 等承载也有相应建立过程。但连接复用与握手恢复可能减少重复开销，网络重传又可能放大一次失败的成本。对于频繁新建连接的应用，减少不必要的往返可能有价值；对已经维持长连接的数据流，初始握手在总耗时中的比例会变小。测试应保留这一区别，不能用一次长下载替代短连接体验。

CPU 消耗与加密算法、硬件指令、数据复制和实现优化有关。某种算法在一台桌面处理器上开销较低，换到不同架构的手机上未必仍然如此。内存则受到连接数、缓冲、路由数据、DNS 缓存和日志规模影响，不只由协议决定。看到客户端占用增加时，应先判断是否正在下载规则、保留大量连接或输出详细日志，再讨论协议本身是否需要更换。

移动端为什么不能只比较加密开销

手机耗电的重要来源包括无线模块唤醒、弱信号重传、后台连接、频繁重连和其他应用活动。协议加密确实消耗计算资源，但未必是主要部分。一个连接稳定、唤醒次数少的组合，可能比理论封装更轻却不断重试的组合更省电。蜂窝网络与无线局域网的能耗条件也不同，不能把不同网络、不同屏幕亮度下的电量下降直接归因于 Xray 或 V2Fly。

Android 上通过 VPN 接口接入流量时，客户端还承担数据包读取与转发工作。桌面 TUN 也会引入虚拟网卡、路由和 DNS 配套处理。它们改变的是流量接入范围和处理路径，不是某种服务器协议的升级模式。若系统代理已经覆盖目标程序，开启 TUN 未必改善速度；如果目标程序不遵循系统代理，TUN 才可能解决接入范围问题。具体步骤见v2rayN TUN 模式设置。

Mux、保活与 UDP 的实际约束

多路复用尝试让多个逻辑请求共享较少的底层连接，在特定短连接场景下可能减少重复建立成本。但共享连接遇到拥塞或丢包时，也可能让多个请求互相影响。某些协议与流控组合对 Mux 有约束，不应默认打开。保活同样存在取舍：过于频繁会增加后台活动，过于稀疏可能无法维持某些网络中的空闲映射。优先采用兼容的默认值，只有确认具体问题后才调整。

实时应用若使用 UDP，要验证整条路径是否支持，包括本地接入、内核转发、服务端与目标网络。把 UDP 转发到代理并不保证抖动更低，服务器绕路或链路拥塞也可能使体验变差。DNS 解析方式会影响目标地址与路由选择，因此测试中也应保持一致。FakeDNS 涉及域名映射和缓存行为，不能作为通用加速按钮；相关原理可查阅FakeDNS 适用场景笔记。

比较时每次只改变一个变量，分别记录启动、首个请求、持续传输与待机表现，重复观察而不是只留最好的一次。若没有可控的同服务器部署条件，就把结果描述为“当前两条配置的体验差异”，不要上升为协议排名。对日常使用而言，稳定连接、完整支持和易于恢复通常比微小的测试差异更重要，这也是选型应先确认兼容、再比较性能的原因。

按使用场景选协议与内核

选型应从约束出发，而不是从协议排名出发。先确认设备平台、服务端实际提供的组合、需要代理的应用类型，以及是否依赖 UDP。然后选择能完整表达这些参数的客户端与内核，最后再比较管理成本和运行表现。没有服务端配合时，用户通常不能自由更换协议，只能在已提供的配置中选择。客户端界面的协议下拉框是配置入口，不是把远端服务自动转换成另一种协议的工具。

桌面端与 Android 的起点

桌面端首推 v2rayN。先在安装包页按操作系统与处理器架构选择，再核对协议需要的内核。Windows 桌面版与经典 WPF 版属于界面与运行环境选择，不代表远端协议不同；macOS 和 Linux 同样需要核对架构与系统条件。若普通浏览器访问已经由系统代理覆盖，可以先不启用 TUN，用较少变量建立基线，再决定是否扩大接入范围。

Android 端优先按服务端能力选择 v2rayNG，特别是需要 Xray 相关功能时。若部署明确要求 V2Fly 路径，且配置在支持范围内，可以考虑 v2flyNG。首次启动要完成系统 VPN 授权，并确认是否有其他 VPN 连接占用同一接入位置。随后检查后台限制与网络切换表现。应用退到后台后断开，不应立即归因于协议；系统电量管理、后台权限与信号变化都需要单独排查。

既有服务、新建部署与实时应用

接入既有服务时，最稳妥的是保持原协议与传输，先验证完整导入。现有 VMess + WebSocket + TLS 正常运行，就不必仅为更换名称迁移；已有 Trojan 则重点维护证书、名称和密码；已有 Shadowsocks 则精确匹配方法与密钥格式。需要 VLESS + REALITY 时，选择支持完整组合的 Xray 路径，并按服务端提供值填写流控与握手参数，不借用其他记录的字段。

新建部署更适合从维护能力反推选择：是否能够管理证书和名称，是否需要反向代理承载，目标设备是否都支持相同安全方案，订阅工具能否完整输出参数。将这些问题写成清单，比追求某种理论开销更有用。若需要实时语音或其他 UDP 应用，应优先验证端到端 UDP 和路由，不要仅凭网页成功就结束测试；应用本身的区域、目标线路与服务器位置也会影响体验。

用最小配置建立可回退的基线

第一次验证时，使用单一服务器、清楚的路由方案和默认兼容设置。先确认内核启动，再确认请求进入本地端口，然后判断服务端握手与目标访问。以下 JSON 仅展示原生配置中 routing 对象的最小规则结构：私有地址交给名为 direct 的出站。它不是完整连接配置，使用前必须已有对应标签的直连出站，并检查现有规则顺序；图形客户端用户优先通过路由设置完成同类操作。

{
  "routing": {
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

这类规则说明了协议之外的另一个边界：即使节点没有变化，路由也能改变请求是否经过它。规则按实现的匹配机制处理，前面的宽泛条件可能先命中，后面的细规则便没有机会生效。实际使用还要考虑地理数据文件是否可用。不要为了套用示例覆盖整份 routing 对象，应该先理解现有规则，再新增明确的条件，并分别验证局域网与目标网络访问。

出现问题时按证据回退

内核无法启动，检查配置生成与端口占用；握手失败，检查身份、安全层与时间；连接建立但应用无响应，检查本地接入、DNS 和路由。本地监听冲突可查阅端口占用与监听端口修改笔记。每次只改一项并保留上一份可用状态，恢复时先关闭新加的高级功能，而不是把所有协议字段重新填一遍。

最终可把选型结果记为一行完整组合：客户端、内核、代理协议、传输、安全层、接入方式与路由方案。这样换设备时能逐项复核，出现问题也能准确描述差异。协议选择的目标不是让名称尽量复杂，而是让服务端能力、客户端实现和实际应用需求一致。完成这条基线后，再依据性能章节的方法做受控比较；日常操作返回快速上手文档，具体疑问则从常见问题继续查阅。