V2Ray 协议选型
与内核兼容参考

01 / 连接模型

协议、传输与安全层的区别

一条连接由多组参数共同决定

在 v2rayN 中打开服务器编辑窗口，协议类型只是连接定义的一部分。地址与端口决定连接到哪里，用户标识或密码负责认证，传输设置规定数据怎样承载，TLS 或 REALITY 再处理相应的安全握手。路由规则决定哪些请求使用这条连接。把这些层次分开，才能解释为什么两个条目都写着 VLESS，却不能交换其余字段后直接使用。

应用请求通常先进入客户端的本地入站，再由内核依据路由选择出站。出站连接远端服务，远端继续访问目标地址。图形界面负责组织参数，实际建立连接的是内核；系统代理或虚拟网络接口则负责把应用请求送进入站。因此，“客户端已启动”“本地代理端口已监听”“远端握手成功”和“目标页面可访问”是不同阶段，不能用一个连接图标代替全部验证。

地址、服务器名称与请求主机名

服务器地址可以是域名，也可以是提供者指定的地址。TLS 的服务器名称通常用于证书名称验证，并参与服务器名称指示；HTTP 相关传输还可能另有 Host 或请求主机字段。三者有时相同，有时因服务端部署方式而不同。正确做法是逐项采用服务端配置，而不是把编辑窗口里的所有域名字段统一替换成服务器地址，更不要从别人的截图复制一组不相关的名称。

传输类型也不是随意的速度档位。原始 TCP 承载、WebSocket、gRPC 等需要服务端提供对应入口；路径、服务名称以及中间反向代理的转发规则必须互相匹配。WebSocket 的路径不等于网站任意目录，gRPC 的服务名称也不是备注。若远端只接受一种传输，切换本地选项通常只会造成握手失败，不会自动协商出另一种可用连接。

先保存原始参数，再做单项修改

导入一个完整连接后，建议先保留原始条目，复制一份用于实验，并在备注中标明改动项目。每次只调整一类设置，例如仅改变路由规则，或者仅检查服务器名称。若同时修改内核、传输和 DNS，即使连接恢复，也难以确定真正原因；下次遇到问题时又会重新猜测。订阅更新可能覆盖编辑结果，长期需要保留的本地调整应放入独立管理的条目或配置。

阅读日志也应遵循同样的分层方法。名称解析失败先查地址解析；连接被拒绝先查远端端口与服务状态；证书名称不匹配先查时间和服务器名称；握手完成后访问失败再看目标解析与路由。相似的界面提示可能来自完全不同的阶段。把日志中的第一个有效错误与当前操作时间对应起来，比反复切换所有开关更容易缩小范围。

02 / 认证与加密边界

VMess 与 VLESS 的设计取舍

VMess：协议自身包含认证与加密机制

VMess 是 Project V 生态中较早形成的代理协议，设计上把用户认证与数据保护纳入协议本身。客户端不仅要知道远端地址，还要持有匹配的用户标识，并按双方接受的方式组织请求。现代部署通常使用 AEAD 认证机制；旧式条目中仍可能保留额外标识数量等历史字段。遇到这些字段，不应仅凭名称猜测其用途，更不应为了“兼容”而随意填入数值。

VMess 的认证过程与时间条件有关，因此系统时间明显偏差可能导致握手失败。排查时应在操作系统中启用自动时间同步，确认时区显示与实际时间来源一致，再重新发起连接。只修改客户端备注、重启浏览器或切换路由并不能修复认证时间问题。旧订阅如果持续要求过时参数，优先向提供者确认当前可用格式，而不是长期依赖旧客户端继续解析。

VMess 的安全选项需要与内核能力以及服务端要求相符。自动选择通常比手工强制一种算法更适合作为起点；处理器是否具备硬件加速，也会影响不同算法的实际开销。协议自身具备数据保护，不意味着外层 TLS 永远没有用途：某些部署依靠 TLS 入口和反向代理组织服务。是否需要外层安全层，仍由完整部署方式决定。

VLESS：精简协议层，把安全职责交给外层

VLESS 的设计重点是精简代理协议层，保留用户识别等必要信息，并让传输安全由外层方案承担。常见配置中的加密字段为 none，它表达的是 VLESS 协议层不提供相应的数据加密，不能据此推断整条连接没有保护。判断连接安全性时，必须继续查看外层是否启用 TLS 或 REALITY，以及认证和证书相关参数是否正确。

反过来，看到用户标识也不能把它当成加密层的替代品。若部署原本要求 TLS，而本地为了排错关闭安全层，服务端通常不会接受；即使另有能够接受明文的入口，也不能认为两种连接具备相同安全属性。选用 VLESS 的前提是理解服务端给出的完整组合，不是单独追求“字段少”或把它视作 VMess 的任意替换项。

VLESS 配置里的 flow 表示特定流控方式，与普通路由分流不是同一概念。某些 flow 需要配合特定内核、传输和安全层使用，不能把一条连接的值复制到所有 VLESS 条目。客户端存在该输入框，只说明界面能够收集这个字段；最终是否支持、是否接受该组合，仍需由当前内核和服务端共同决定。

协议选择应以远端支持为先

已有可用 VMess 服务时，不必为了名称更新而直接改成 VLESS。两者的服务端认证过程不同，仅在本地修改协议类型不会完成迁移。正确迁移需要服务端提供对应入口，再导入新的连接资料，验证目标访问及所需的 UDP 应用，最后决定是否替换旧条目。保留一份已知可用配置，也有助于区分服务变化与本地环境变化。

如果服务端同时提供两种完整配置，可以在同一设备、同一网络和相近时间内比较连接表现。先保持路由、目标地址与测试任务一致，再观察建立连接是否稳定、持续传输是否正常、休眠恢复后是否重连。不要只凭一次测速就归因于协议；出口线路、服务负载、传输封装以及本地 DNS 都可能比协议层差异更显著。

03 / 不同安全模型

Trojan、Shadowsocks 与 REALITY

Trojan：围绕 TLS 组织代理连接

Trojan 的常见部署以 TLS 连接为基础，在受保护的通道内完成密码认证与代理请求。它的配置入口通常比多层封装的组合直观，但这不意味着只填写密码就足够。服务器地址、端口、服务器名称和证书验证仍是关键参数。若证书对应的域名与填写名称不一致，客户端应当拒绝连接，而不是把验证失败理解为可以忽略的普通警告。

Trojan 的握手表现受 TLS 协商、远端响应和链路质量影响，不能仅因其采用 TLS 就认定建立连接必然更慢。某些条件下会话恢复可以减少重复握手成本，但效果取决于实现与连接生命周期。实际选择时应关注远端证书维护、密码轮换和客户端支持情况。证书错误的具体分支可查阅TLS 握手与证书报错排查。

Shadowsocks：方法名称决定兼容边界

Shadowsocks 常缩写为 SS，核心思路是以预共享密钥建立加密代理通道。经过演进，不同方法的认证、密钥处理和数据组织存在差别。旧方法、AEAD 方法与较新的方法族不能只凭“都是 SS”就认定互通。导入时必须保留准确的方法名称和密码格式；尤其不要把需要特定长度密钥的配置当成任意口令字段处理。

SS 的字段相对集中，适合作为理解加密方法与客户端兼容性的例子。但若服务资料另含插件参数，便多出一个独立兼容条件。某个内核支持基础 SS 协议，不等于图形客户端会启动全部插件，也不等于订阅转换能够保存插件选项。遇到导入成功却握手失败，应先查看原始资料是否包含未被保留的附加要求，再确认当前客户端能否承载它。

REALITY：安全层方案，不是独立代理类型

REALITY 常与 VLESS 一起出现，但它不负责替代 VLESS 的全部代理功能。可以把 VLESS 理解为定义代理请求的一层，把 REALITY 理解为特定安全握手方案。客户端通常需要服务器名称、公钥、短标识等资料，部分实现还提供指纹相关选项。这些值由服务端配置约束，不能从目标网站证书或另一条连接中推导出来。

客户端保存服务端提供的公钥，服务端持有相应私钥；两者职责不能混淆。订阅中已经给出公钥时，应原样保留，不能在本地重新生成一个后期待远端接受。短标识同样需要与服务端允许的值匹配，留空是否有效取决于具体配置。服务器名称也应采用提供者指定的值，而不是看到地址栏里的域名就自行替换。

REALITY 的支持范围应按内核实现判断，不能因为 v2rayN 和 v2flyNG 都属于相近生态，就认为它们拥有完全一致的选项。涉及 REALITY、特定 flow 与相应传输组合时，优先核对 Xray 侧的实现要求，再确认图形客户端是否完整生成这些字段。若界面缺少必要参数，反复导入同一链接并不能补齐底层能力。

这三种名称不构成可以直接排名的同类清单。比较时应写出完整连接组合，再考察维护成本、设备负担与远端可用性。若参数来源不完整，先取得明确资料，比寻找所谓通用最佳值更重要；客户端不会根据缺失字段自动还原服务端意图。

04 / 实现与配置

V2Fly、Xray 与客户端的关系

内核执行连接，客户端组织设置

Project V 是理解这一生态的背景。V2Fly 延续 V2Ray 相关内核的维护与发展，Xray 则沿相关技术基础形成自己的功能演进路线。它们有共同概念，也存在独立实现与字段差异。内核不是图形界面的另一个名字：同一个客户端可能能够调用不同内核，而某个内核支持的底层选项，也未必全部显示为界面中的开关。

v2rayN 是桌面端优先推荐的客户端，覆盖 Windows、macOS 和 Linux；具体安装入口见客户端页面。它负责服务器列表、订阅分组、系统代理和配置生成等操作。可选内核及其功能入口取决于客户端实际提供的构建和设置，不应假定任意安装包都包含相同组件，更不应通过改文件名把不兼容程序伪装成另一种内核。

Android 端以 v2rayNG 为首选，它使用 Xray 内核；v2flyNG 使用 V2Fly 内核，适合作为相关配置的备选。两款应用可能拥有相似的操作概念，但配置字段和默认行为仍可能不同。选择应用时，应先看现有服务要求，再考虑界面习惯。涉及 REALITY 等特定能力的配置，应优先沿对应实现核对，不能只根据应用名称相近作判断。

配置结构相似，不等于字段可以照搬

两类内核常见配置都使用入站、出站、路由和 DNS 等概念，部分基础结构看起来非常接近。但传输名称、字段接受范围、流控方式及新功能支持并不保证一致。某段 JSON 能通过语法检查，只能证明括号与字符串等格式成立，不能证明当前内核理解全部字段；有些错误要到启动或建立连接时才出现。

图形客户端往往先读取订阅，再保存内部服务器模型，最后生成给内核使用的配置。兼容问题可能发生在其中任何一步：链接解析器没有识别参数、内部模型没有保存扩展项，或者内核拒绝生成结果。排查时先确认编辑窗口中的值，再查看启动错误；不要把所有问题都归结为远端服务。配置分段可配合JSON 结构解析文章阅读。

内核切换前后的验证顺序

切换前记录当前协议、传输、安全层、flow、DNS 和路由配置，保留已知可用的条目。切换后先执行客户端提供的配置检查或尝试启动，确认没有未知字段、缺少组件和端口占用，再验证远端连接。若直接拿浏览器访问结果作唯一依据，本地接管失败与远端协议不兼容很容易被混为一谈。

对于普通连接，迁移时也应检查默认值变化。例如域名匹配策略、嗅探行为、UDP 转发以及连接复用可能没有出现在服务器编辑页，却影响实际请求。不要为了模仿旧环境把所有高级选项全部打开；先保持最小必要配置，确认基础连接，再逐项恢复确有用途的规则。迁移后的稳定性通常来自边界清晰，而不是开关数量更多。

更新内核与更新订阅解决的是不同问题。前者改变本地实现能力，后者改变远端连接资料；某次更新后连接恢复，不代表两者可以互相替代。出现回归时应注明最后改变的是客户端、内核还是订阅，并保留错误发生时间。提交排查资料前，移除配置中的认证材料与订阅地址，只留下必要字段名称和错误类型。

05 / 性能观察

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

把建立连接与持续传输分开观察

“速度”至少包含建立连接等待、首次响应、持续吞吐和长时间稳定性。域名解析、到远端的网络往返、安全握手、远端到目标的连接都会参与首次响应；持续传输则更受链路带宽、拥塞控制、服务端负载和设备处理能力影响。一个方案打开短页面较快，不代表大型文件传输必然更快，也不代表后台保持连接时更省电。

协议层精简能够减少某些处理工作，但不能消除链路距离和丢包。WebSocket、gRPC 等承载方式增加了相应封装，也可能适应已有服务基础设施；额外封装是否构成瓶颈，需要在目标环境中观察。不能仅凭层数宣布某个组合性能差，更不能把服务端部署在不同线路上的结果当成协议之间的严格对照。

加密算法的资源开销依赖处理器、系统库和内核实现。具备相应硬件加速的设备可能以较低负担完成某种加密，而另一台设备的结果不同。高速持续传输时处理器负载可能更明显，普通网页访问时则可能主要等待网络响应。比较时同时观察设备发热与任务完成情况，避免把正常的短时负载误判为客户端异常。

复用连接不等于所有任务都更快

连接复用尝试让多个逻辑请求共享底层连接，可能减少重复建立连接的成本，也可能让多个请求共同受到某条连接拥塞或中断的影响。其价值与任务形态、传输方式和实现有关。面对少量短请求与持续大流量，最佳设置可能不同。启用后若出现部分应用卡住，应先关闭复用做对照，而不是继续叠加更多高级开关。

UDP 任务需要单独验证。网页可用只证明相关 TCP 或 HTTP 请求能够完成，不代表语音、实时交互或其他 UDP 应用已经获得正确转发。客户端、协议实现、服务端和路由都可能参与限制。某些网络对 UDP 的处理也不同于 TCP，因此应使用实际需要的应用检查，而不是用一次网页测速代替全部兼容性测试。

移动耗电更常受接管方式和重连影响

Android 电量表现不仅由协议名称决定。虚拟网络接口接管的数据范围、后台应用活动、无线网络信号、心跳和重连频率都会影响耗电。设备在移动网络与无线局域网之间切换时，旧连接可能需要重新建立；若后台有持续请求，重试会放大无线模块的活跃时间。把所有额外耗电都归因于 TLS 或 REALITY，通常缺少足够证据。

系统电池优化也存在取舍。过度限制后台可能使客户端被暂停，恢复前台后不断重连；完全放开后台则可能让其他应用的持续流量照常通过。应先查看应用电池使用记录，再检查断线时间是否与熄屏、网络切换对应。仅为解决一次断线就关闭全部系统优化，不利于判断真正原因，也可能影响其他应用的电量表现。

可复现的比较方法是保留两份配置，在同一设备、同一接入网络与相同任务下交替测试，避免边充电边比较发热。分别记录首次访问是否成功、持续任务有无停顿、熄屏后能否恢复以及系统电池记录。多次观察一致的趋势才值得采用；不同出口、不同时间的单次峰值，不适合用来形成协议排行榜。

06 / 资料交换

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

订阅是配置交付方式，不是协议本身

订阅地址通常返回一组连接资料，客户端负责识别内容、解析条目并放入分组。返回内容可能是分享链接集合、编码后的文本，或某种结构化配置。相同地址也可能依据请求条件返回不同内容。因此，“浏览器能打开订阅”只说明取得了一个响应，不能证明响应格式正好适合当前客户端，更不能证明里面每种协议都受当前内核支持。

分享链接也有各自约定。VMess 链接常见编码后的结构化内容，VLESS、Trojan 和 SS 则常以 URI 形式携带认证信息及查询参数；不同提供者可能使用扩展字段。链接中某些字符需要百分号编码，备注与查询参数还可能包含非拉丁文字。复制时丢掉尾部、把换行混入地址或被消息软件截断，都可能造成导入失败。

Base64 是数据编码方式，不是加密保护。订阅或分享内容即使肉眼看不懂，仍可能包含可直接使用的认证材料。不要把完整订阅地址粘贴到公开讨论区，也不要随意交给不明确的数据转换服务。排查格式时可以先在本地确认内容类型，并对认证字段做删除处理；只隐藏备注而保留整段连接资料，并不能降低泄露风险。

导入成功后，继续核对字段完整性

导入后应打开条目，逐项对照协议、地址、端口、用户认证、传输类型、路径和安全设置。REALITY 等组合还应核对相关公钥与短标识，VLESS 应检查需要的 flow。列表出现一行仅表示解析器创建了条目，不表示所有扩展参数都已保留。若备注正确而关键字段为空，连接仍然不完整。

在客户端之间迁移时，推荐使用双方明确支持的分享格式，先导入少量条目验证，再转移其余分组。直接复制应用数据目录可能夹带平台路径、本地端口和专属设置，不能视为通用迁移方法。桌面系统代理配置也不会自然转化为 Android 的网络接管设置；连接资料可迁移，本地接管与权限仍需重新检查。

订阅更新通常围绕远端资料重新生成或合并条目，手工修改是否保留取决于客户端管理方式。若要长期调整备注、路由关联或某个连接字段，应先弄清更新后的覆盖规则。把实验配置保存在独立分组，并给原始订阅保留清晰名称，可以避免下一次更新后误以为服务端突然改变了所有设置。

列表为空时按响应与解析两层排查

更新失败先确认地址是否完整、是否失效以及当前网络能否取得响应。若请求已经返回，再检查返回的是连接资料、登录页面还是普通错误文本。请求成功与解析成功是两件事；把一段网页内容反复编码，不会变成有效订阅。需要更详细顺序时，可参照订阅更新失败与空列表自查清单。

部分服务会依照 User-Agent 或请求参数选择订阅格式。只在提供者明确说明时调整这些设置，避免为了尝试而随意伪装成另一种客户端。更新是否经由现有代理也需要核对：依赖尚未建立的连接去更新同一组资料，可能形成循环。先确保至少有一种可用的更新路径，再验证返回格式，最后处理具体条目的兼容问题。

07 / 请求去向

路由规则与 DNS 的协作边界

路由决定出站，不负责修复握手

路由分流的作用是根据域名、地址、端口或其他条件选择出站。它发生在内核处理请求的过程中，不能替代远端认证，也不会修复证书名称错误。若所有访问都无法完成，先确认本地接管和代理出站是否可用；若只有一部分域名异常，再查看匹配规则及解析结果。把连接故障和分流故障分开，可以避免无效修改。

常见规则按顺序匹配，前面已经命中的宽泛条件可能让后面的精细条件没有机会生效。默认出站同样重要：在常见配置模型中，没有命中规则的请求可能落到默认路径，其具体选择应以生成配置为准。不能只查看规则列表中的名称，还应核对规则引用的出站标签是否真实存在，大小写及拼写是否一致。

下面是配置中的路由片段，用于说明私有地址直连的结构。它不是独立可运行的完整客户端配置，需要与其他段落合并，并确保已有一个标记为 direct 的直连出站，同时具备相应地址规则数据。图形客户端已经生成这些内容时，不应把片段重复附加进去；优先通过路由设置界面表达相同意图。

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

解析发生在哪里，影响规则能看到什么

应用可能把域名交给代理，也可能先在本机解析后仅提交地址。前者让内核有机会直接按域名匹配，后者则可能只剩地址信息。系统代理、应用自带代理与虚拟网络接口接管，在请求信息保留方式上并不完全相同。因此，同一条域名规则在一种接管方式下生效，在另一种方式下没有命中，不一定是规则文本写错。

AsIs 通常表示不为了路由匹配主动把域名转换成地址，但不代表整个连接过程从此不需要 DNS。其他域名策略可能在特定条件下引入解析，以尝试匹配地址规则。改变策略会同时影响规则结果和解析成本，不能简单理解为越积极解析越准确。应先明确想按域名还是地址做决定，再选择与该目标一致的行为。

内核 DNS、操作系统 DNS、浏览器的加密 DNS 与远端目标解析可能处在不同路径。修改一个设置不一定覆盖全部请求。若浏览器与其他应用结果不同，应先查看浏览器是否自行解析，以及应用是否真的经过客户端。DNS 服务器能够响应也不代表访问路径正确；解析成功后，请求仍可能被路由到不符合预期的出站。

系统代理、嗅探与本地网络访问

自动配置系统代理主要影响遵循系统设置的应用，不等同于全部流量接管。全局代理、绕过局域网和直连等模式名称还可能是客户端预设入口，应检查其实际生成规则。使用局域网打印机、共享目录或本地管理页面时，先确认私有地址的处理方式，再考虑是否需要为内部域名补充明确规则。

流量嗅探可以尝试从请求中提取域名等信息，为路由补充线索，但不能保证识别所有协议，更不能替代应用层的完整语义。某些设置还可能影响目标地址处理，因此应按用途启用。排查单个站点时，记录应用提交的是域名还是地址、命中了哪条规则、最终走了哪个出站，比同时更换 DNS 与路由模式更有解释力。

IPv6 也应纳入路径核对。系统获得地址记录后，实际连接可能选择不同地址族；如果只为其中一种路径配置规则或支持，表面上就可能出现间歇性成功。不要把关闭某种地址族作为固定答案，应先确认本地网络、服务端和目标均支持所选路径。具体界面操作可从DNS 设置教程继续查阅。

08 / 决策与验收

按使用场景选择客户端与协议

已有服务：保持完整组合，先验证兼容

已有稳定服务时，第一选择通常是保留它提供的完整协议组合，而不是先更换协议。桌面端优先使用 v2rayN，按系统与处理器架构选择安装包；Windows 的 Desktop 与经典 WPF 界面选择可参照Windows 安装配置说明。界面形态不应成为判断远端协议安全性的依据，实际能力仍取决于调用的内核与生成配置。

Android 首先考虑 v2rayNG；若现有服务围绕 V2Fly 的具体能力部署，再评估 v2flyNG。首次验证只导入一条资料完整的连接，确认基础访问，再启用所需的分流和接管范围。若一开始就同时迁移全部订阅、规则与后台设置，失败时很难知道是资料解析、内核兼容还是系统权限问题。

可选多种入口：先列约束，再做对照

如果服务端同时提供 VMess、VLESS、Trojan 或 SS，先列出必须满足的条件：设备是否支持相应内核、是否需要 UDP、是否依赖特定传输入口、能否持续维护证书或密钥。满足约束后再比较连接稳定性和任务体验。REALITY 应作为完整安全层组合的一部分评估，而不是在协议下拉框中寻找一个可以独立替换所有连接的选项。

多设备使用尤其需要避免最低共同配置的误区。并非所有设备都必须使用相同入口；同一服务可以为不同客户端提供各自兼容的资料。强行把桌面端的新字段复制到另一套内核，可能失去兼容性；为了统一名称而删掉必要参数，也可能破坏安全条件。应统一管理目标与规则意图，而不是追求每个编辑窗口逐字相同。

移动与桌面长期运行的关注点不同

桌面长期运行时，重点观察系统休眠恢复、网络切换、端口占用以及应用是否遵循系统代理。Android 则额外检查后台限制、接管应用范围和电池记录。macOS 初次安装遇到系统拦截或权限提示，可查阅安装与网络权限处理。平台权限问题应在系统层处理，不能靠更换用户标识或协议类型修复。

为短时网页访问选择方案时，建立连接与首次响应更值得关注；为持续传输选择方案时，应观察任务完成期间的停顿、重连和设备负担。实时应用还要单独验证 UDP 路径。不同任务的侧重点不同，因此本手册不提供脱离网络条件的固定速度排序。可解释、可复现的结果，比一个没有测试条件的推荐标签更适合长期维护。

失败时按阶段返回，而不是随机改参数

完全无法启动时，先看配置检查、运行环境和本地端口；能够启动但无法握手时，再看远端地址、认证、传输与安全层；握手成功却部分应用失败时，检查接管方式、UDP、DNS 和路由。若错误只发生在订阅更新后，对照更新前后的关键字段；若只发生在熄屏后，优先观察后台限制与重连日志。

每次排查都保留一个已知条件：同一设备、同一网络、同一目标或同一条连接至少固定其中几项，再只改变一个变量。日志需要围绕一次明确操作收集，避免把很久以前的错误与当前成功连接混在一起。可以分享错误类别和经过处理的字段结构，但不要分享完整认证资料。这样得到的判断才能用于下一次复现，而不只是碰巧恢复访问。

最终保留的配置应能够说明四件事：选择了什么协议组合，为什么当前内核支持它，哪些应用会经过客户端，以及异常时从哪里查看证据。首次操作仍以快速上手主线为准；本页用于解释主线背后的边界，帮助在需要修改时作出有依据的选择。