V2Ray 协议与内核参考

配置分层：协议名不等于完整连接方案

先拆开代理协议、传输和安全层

客户端中一条服务器配置至少涉及三个问题：通过什么协议表达目标地址和身份，使用什么传输承载数据，以及怎样建立安全连接。VMess、VLESS、Trojan、Shadowsocks 主要回答第一个问题；TCP、WebSocket、gRPC 等回答第二个问题；TLS 与 REALITY 属于安全连接相关的选择。界面可能把这些字段放在同一张编辑表单里，但它们不是可以互相替换的同类选项。只知道服务器使用 VLESS，还不足以重建连接。

例如，两条配置都标注 VLESS，其中一条使用 TCP 与 REALITY，另一条使用 WebSocket 与 TLS，握手流程、必填字段和服务端接入方式都不同。把第一条的公钥复制到第二条，或者把第二条的路径填进第一条，通常不能解决问题。更可靠的记录方式是写出协议、传输、安全层三项，再单独记录地址、端口和认证信息。这样即使客户端界面名称变化，也能对照字段含义完成检查。

区分服务器地址与握手名称

服务器地址决定连接首先发往哪里，可以是域名，也可以是 IP 地址。TLS 中的服务器名称通常由 SNI 字段表达，用于握手和证书身份验证；它不必与地址栏的字符串完全相同，但必须符合服务端部署。WebSocket 的 Host 则属于 HTTP 请求头，路径用于选择接入端点。这几个字段有时填写相同域名，因此容易被误认为重复项。实际排查时应分别核对，不能只改地址栏就假定其他名称会自动同步。

本地入口、系统代理和路由又属于另一组设置。本地入口负责接收应用连接，系统代理只是让部分应用把请求交给该入口，路由才决定进入内核后的流量走哪个出站。应用没有采用系统代理时，修改协议加密方式不会让它自动进入内核；路由命中直连时，换服务器也不会改变这条连接的出站。安卓的 VPN 接管与桌面的系统代理机制不同，因此两端应对照作用范围，而不是照抄所有开关。

用最小变更保留诊断依据

导入后先保留原始配置，再逐项调整本地行为。地址、认证、传输和安全参数应以服务端提供的信息为准；本地端口、分应用范围和日志级别则可以按设备需要设置。一次同时更换协议、DNS 和路由，会让成功或失败都难以解释。建议复制配置做对照，只改变一个变量，并记录错误发生在启动、握手还是访问阶段。有关字段短释可查术语表，初次导入的完整操作仍以入门指南为主。

VMess：认证、时间与加密方式

设计背景与连接成本

VMess 是 Project V 生态早期的重要代理协议，将身份认证、请求描述和数据保护纳入协议设计。它并不是给普通 TCP 连接加一个名称，而是要求客户端和服务端按一致格式处理请求。对选型而言，价值在于成熟的生态支持，以及多种传输组合的可用性；代价是需要理解协议自身加密与外层安全连接的关系。遇到旧配置时，还要区分历史认证形式与当前实现，不能把所有 VMess 链接视作同一种格式。

VMess 的速度不能只用是否加密判断。一次访问包含本地解析、传输连接、认证和远端转发，外层若叠加 TLS，还会增加相应握手工作。现代处理器对常见加密算法有不同程度的硬件支持，小请求可能主要受往返时间影响，长时间下载才更容易暴露持续吞吐限制。因此，看到 VMess 比另一条连接慢，首先应确认两者线路、服务端负载和传输方式一致，再讨论协议处理成本。

UUID、加密与 alterId 的边界

编辑 VMess 时，UUID 是身份信息，不是节点备注，也不是可以由客户端自行生成后直接使用的随机字符串。加密方式需要双方实现支持；客户端提供的自动选择通常用于按运行环境选择适合的算法，而不是自动修复认证错误。不要为了减少开销随意选择不提供数据加密的模式。外层 TLS 与协议自身保护的职责不同，是否采用特定组合，应由明确的部署设计决定，而不是把“少一层”当成普遍优化规则。

旧教程常出现 alterId。它与历史兼容机制有关，现代 VMess AEAD 配置通常使用零值，客户端也可能隐藏该字段。若订阅里仍带有非零值，不应只把数字改成零便认定迁移完成，因为服务端必须支持对应认证方式。正确顺序是确认提供方的配置要求，再检查当前内核能否处理该形式。长期保留旧参数可能造成导入成功但连接失败，界面没有报语法错误并不能证明双方认证一致。

系统时间与传输字段的检查顺序

VMess 认证涉及时间，因此系统时间明显偏移可能导致请求被拒绝。排查时先开启系统自动校时，确认日期和实际时刻，而不只是检查界面显示的时区；时区显示不同并不必然代表系统时钟错误。接着核对 UUID、端口及服务端是否仍接受当前配置。只有认证基础信息正确后，才继续检查 WebSocket 路径、Host 或其他传输字段。这样可以避免把认证问题误判为线路不通。

通过 VMess 链接导入时，还要留意链接内部字段与客户端编辑页的映射。某些历史链接把传输名称、TLS 开关和主机名使用旧字段表达，导入器可能按自身规则补默认值。建议查看导入后的具体设置，尤其是地址、SNI、路径和加密方式，不要只看列表里的协议标签。若同一配置在另一设备可用，应比较字段和内核日志，而不是反复删除后重新粘贴同一条链接。

VLESS 与 REALITY：轻量协议和安全握手分开看

VLESS 减少协议内职责

VLESS 的设计取舍是简化协议自身的认证和请求处理，不像 VMess 那样在基础协议内提供同类的数据加密机制。常见配置中的 encryption 为 none，表示这一层的处理方式，不代表整条连接必然以明文传输。是否具备安全保护，要继续看外层使用 TLS 还是 REALITY，以及相关验证是否正确启用。这个分层方式便于组合，但也要求使用者避免把一个字段的含义扩大到整条链路。

因此，不能把 VLESS 简化为“去掉加密所以一定更快”。减少某些协议处理只是成本的一部分，TLS 或 REALITY 仍有握手和数据保护工作，传输封装也可能成为主要开销。VLESS 是否适合当前设备，取决于服务端提供的组合、内核实现和网络条件。桌面选择时先确认 v2rayN 使用的内核支持完整参数；安卓则确认客户端内核和配置类型一致，不能仅凭能识别 UUID 就推断全部功能可用。

REALITY 不是独立代理协议

REALITY 是 Xray 生态中的安全连接方案，常与 VLESS 配合使用。客户端通常需要服务器公钥、服务器名称、shortId 及相应指纹设置；这些信息共同参与握手，不能从普通 TLS 配置直接推导。它与证书域名验证的配置方式不同，但并不意味着可以忽略身份校验。客户端只应持有连接所需的公开参数，服务端私钥不应出现在订阅、截图或客户端输入框中。

公钥看起来像一串可复制文本，但其内容必须与服务端密钥对应；shortId 则需要符合服务端允许的值及格式。服务器名称也必须符合部署要求，不能随意填写一个可访问域名。指纹选项用于相关握手行为，属于兼容参数，不是地区选择或速度档位。若导入器漏掉其中一项，配置可能仍出现在列表中，但会在握手阶段失败。应逐项与原始参数核对，而不是关闭验证来绕过错误。

flow 与传输不能自由拼接

VLESS 中的 flow 描述特定流控方案，例如 XTLS Vision 相关值。它不是通用加速按钮，也不适用于所有传输组合。服务端要求 Vision 时，客户端需要支持该方案，并使用相容的传输和安全层；服务端没有配置相应 flow 时，自行添加反而可能导致失败。网页教程截取的一段参数只适用于它所在的完整组合，不能脱离上下文复制到 WebSocket 或其他不同接入方式中。

实际检查可按“协议与 UUID—传输—安全层—公钥及名称—shortId—flow”的顺序进行。先在编辑页确认字段没有被默认值替换，再查看内核日志区分参数解析失败和远端握手失败。前者通常提示实现不支持或字段格式错误，后者需要继续核对服务端要求与网络可达性。若订阅更新后突然失败，应保留旧记录做字段差异比较，避免把所有失败都归因于公钥变化。

Trojan 与 Shadowsocks：TLS 依赖和加密方法

Trojan 把安全连接放在 TLS 上

Trojan 的典型连接先建立 TLS，再进行协议认证和数据转发。对客户端使用者而言，重要字段包括服务器地址、端口、密码和服务器名称。它的配置表面上比某些组合简短，但 TLS 仍有明确的身份验证要求。证书名称不匹配、证书链异常或系统时间错误，都可能在密码被检查之前终止连接。因此，Trojan 连接失败时，不应从反复更换密码开始，而要先看日志停在哪一个阶段。

地址使用 IP 而证书签发给域名时，通常需要根据服务端说明填写正确的服务器名称。SNI 用于握手中的名称表达，证书验证用于确认对方身份，两者相关但并非同一个开关。启用跳过证书验证会削弱身份确认，不能作为常规修复。若服务端采用专门的信任方案，应按明确的信任配置处理；对于普通公开证书部署，优先修复时间、名称或证书链，保留正常验证路径。

Shadowsocks 的方法名属于协议条件

Shadowsocks 常简写为 SS，设计上强调较简洁的代理转发与加密处理。客户端需要服务器地址、端口、密码和加密方法。方法名不是客户端可独立选择的性能设置，而是双方必须一致的协议条件。即使密码正确，方法不匹配仍会失败。历史配置和较新的协议变体可能使用不同的密钥要求，因此不能把所有标注 SS 的配置当成只需交换密码就能互通的同一形式。

传统 AEAD 方法与 Shadowsocks 2022 系列在密钥处理等方面存在差异。后者使用的方法名和编码密钥要求，应由服务端或订阅提供，不适合把任意短口令直接填入。是否支持某个方法，取决于正在运行的内核，而不只是客户端界面是否列出 Shadowsocks。若导入时提示方法未知，应先核对拼写和内核能力；把方法改成另一个熟悉名称，不会让服务端自动采用新的算法。

传输组合与 UDP 需求

Trojan 或 SS 在不同部署中可能伴随额外传输参数，但不能假定一个通用分享链接能完整表达所有扩展。特别是 SS 链接中的附加参数，导入器未必都支持。确认提供方所需的组合能被当前三款客户端及其内核表达，再决定是否使用。若扩展参数在导入后消失，应把它视为兼容性问题，而不是继续用缺少字段的配置测试线路速度。

有语音、游戏或其他数据报需求时，还应单独验证 UDP 路径。协议具备 UDP 能力，并不代表本地入口、客户端接管方式、服务端转发和目标网络都已经允许数据报通过。TCP 网页访问成功，只能证明相应请求链路可用。测试时使用确实依赖 UDP 的应用并观察日志，区分应用没有进入内核、服务端没有转发和目标没有响应。不要因为某个网页能打开，就把 UDP 问题归结为应用本身。

速度、资源与电量：区分握手和持续传输

连接快与下载快是两种结果

打开短页面主要受解析、连接建立、握手与首字节等待影响；持续下载则更多受线路容量、拥塞控制、服务端出口和设备处理能力影响。某种协议减少握手工作，可能改善短连接体验，却不一定提高长连接吞吐。反过来，一条下载表现良好的线路，也可能因解析或握手等待让网页起步缓慢。因此，比较协议时至少分开记录连接成功率、首个响应和稳定传输表现，不能用一个延迟数字概括全部体验。

TCP、WebSocket 和 gRPC 带来不同封装与连接管理行为，但真实影响取决于实现和部署。WebSocket 增加 HTTP 升级及帧处理，gRPC 依赖相应 HTTP/2 行为与服务端支持；它们的存在往往服务于接入架构，而不是为了在所有线路上减少延迟。丢包、拥塞和中间设备处理也会改变结果。没有控制线路和服务端条件的横向测试，只能评价那组连接，不能据此给协议排出固定速度名次。

CPU、内存与复用的边界

加密算法是否能利用处理器指令、内核缓冲策略、活动连接数和日志输出量，都会影响资源占用。桌面低负载时，协议之间的差异可能被浏览器和系统任务掩盖；小型设备在长时间高吞吐下，则更容易遇到温度限制。观察资源时应同时看实际吞吐和持续时间：同样的 CPU 百分比，可能对应完全不同的数据量。不要把客户端界面进程占用当成内核全部消耗，两者有时是独立进程。

连接复用尝试让多个逻辑请求共享较少的底层连接，可能减少重复建连，也可能在拥塞、长短请求混合或实现不匹配时增加等待。它不是对所有协议都有效的全局优化。先保留默认设置，在确有大量短连接且服务端支持的情况下再做对照；如果启用后出现间歇停顿，应回到独立连接基线。路由、DNS 和传输方式同时变化时，不能把结果全部归功于复用开关。

安卓电量主要看唤醒与重连

移动端电量除了加密工作，还受到无线网络保持活跃、后台唤醒、保活频率和失败重连影响。看似节省计算的协议，如果频繁断线并重建安全连接，最终可能更耗电。切换移动网络与无线网络时，连接重建也会带来额外成本。评估 v2rayNG 或 v2flyNG 时，应在相近信号、亮屏时间和应用负载下观察，不宜把一次后台耗电排名直接解释为某个协议的固定电量特征。

VpnService 负责安卓流量接管，不等于内核已经成功连接。省电限制可能在锁屏后中断后台处理，表现为唤醒屏幕后恢复；分应用设置也可能让部分应用完全不经过内核。先检查系统后台限制与接管范围，再讨论换协议。相关操作见v2rayNG 授权、省电与分应用设置。测速对象的区别可查延迟测试原理，不要用 ICMP 结果代替真实代理请求。

V2Fly 与 Xray：家族关系和配置兼容性

图形客户端与内核分工

Project V 是理解这组工具的生态背景，V2Fly 延续 V2Ray 相关开发，Xray 则从相关代码基础分支发展，形成自己的功能路径。两者共享部分概念和配置习惯，但已经不能简单理解为改名关系。图形客户端负责管理配置、订阅、本地接管和日志展示，内核负责实际连接、路由与协议处理。界面能创建某类服务器，只能说明客户端提供了相应编辑能力，最终仍要由运行中的内核执行。

桌面首推 v2rayN，是因为其配置管理和多平台使用方式适合统一查阅与维护；具体协议能力仍需对照所选内核。安卓的 v2rayNG 主要围绕 Xray 能力使用，v2flyNG 作为 V2Fly 路线的备选。选择二者时，应先确认服务端需要的协议和扩展，再考虑界面习惯。不要把同一份订阅能在两款软件中显示，等同于其中每一条配置都具备相同执行结果。

共同字段不代表完整互换

两类内核都可能出现入站、出站、路由和 DNS 等顶层概念，也可能支持同名协议，但扩展字段、默认行为和具体传输支持存在差异。Xray 体系中的 REALITY、XTLS Vision 相关能力，不能因为 JSON 外观相近就推断 V2Fly 可以原样运行。反方向迁移也需要检查 V2Fly 特有配置和客户端生成方式。最稳妥的迁移单位是字段含义，而不是整份文件的文本复制。

自定义配置与图形编辑页还可能采用不同生命周期。客户端通常把界面保存的信息生成运行配置，启动时可能覆盖临时文件；直接修改生成文件，下次连接未必保留。需要长期自定义时，应使用客户端明确提供的自定义配置入口，并确认哪些系统代理、路由或 DNS 功能仍由界面控制。否则可能出现文件里写了一组规则，运行时却加载另一组规则的情况，排查方向随之偏离。

读取最小配置片段

下面是 Xray 风格的路由对象片段，只展示字段层级，不是完整可启动配置。domainStrategy 表示路由判断过程中处理域名的策略；规则按照顺序匹配，outboundTag 必须对应已经定义的出站标签。它不能创建服务器，也不会自动设置系统代理。将片段用于已有配置前，先确认当前内核的字段支持，以及客户端是否会再次生成路由内容，避免把有效规则粘贴到错误位置。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["domain:example.com"],
        "outboundTag": "direct"
      }
    ]
  }
}

内核更新需要和客户端配置生成能力一起看。更新可能新增协议字段或改变兼容处理，但不会替服务端补齐缺少的参数。遇到启动错误时，先读取最早出现的解析错误，确认运行的是预期内核，再检查生成配置中的字段。若此前可用而更新后失败，保留可回退的设置副本，并用最小配置复现。开源属性提供代码审阅与维护基础，不意味着不同实现天然兼容；相关客户端差异见横向评测。

订阅与分享链接：导入成功不等于字段完整

地址、内容格式和连接配置是三件事

订阅地址通常用于拉取一组服务器配置，单条分享链接则直接表达某一条配置。两者用途不同：订阅可以后续更新，分享链接一般是当时参数的快照。订阅使用普通网页地址并不意味着内容就是网页，也不保证返回格式可被任意客户端解析。服务器可能返回链接列表、编码后的文本或特定配置格式；客户端必须具备对应导入能力，才能把这些内容转换为可编辑的服务器记录。

订阅下载成功，只证明取到了响应。若返回登录页、错误提示或不兼容内容，列表仍可能为空。应先分辨请求失败与解析失败，再决定是否更改网络路径。部分客户端允许选择订阅更新经直连还是经已有代理，当当前配置已失效时，强制经代理更新可能形成依赖循环。调整前先确认更新设置和可用连接，不要一边切换路由一边重复请求同一地址而不查看错误。

不同链接格式的损失点

VMess 分享链接常见编码后的结构化内容；VLESS 与 Trojan 链接通常通过地址部分和查询参数表达配置；SS 则存在不同的编码形式。名称、路径和服务名中若包含特殊字符，需要遵循相应转义规则。聊天软件换行、复制时遗漏尾部或二次编码，都可能让参数改变。导入器有时会容忍部分错误，这并不代表得到的配置仍与原始含义相同，因此导入后必须检查关键字段。

VLESS 的 flow、REALITY 的公钥与 shortId、TLS 的服务器名称、WebSocket 的 Host 与路径，都属于需要重点核对的字段。一个格式转换过程如果只保留协议、地址和认证，可能丢掉决定握手的扩展信息。不要仅比较节点备注是否一致；备注只是标签，不参与连接。详细的导入分工可查分享链接与订阅地址区别，其中操作步骤与本页参数说明配合使用。

更新与本地修改应分开维护

订阅管理通常以分组为单位更新服务器记录，具体保留哪些本地修改取决于客户端行为。直接在订阅生成的记录上改端口、名称或传输参数，下一次更新可能被覆盖。需要长期对照时，可以复制为本地记录并注明用途，但也要承担手动同步服务端变化的责任。路由规则和分应用范围一般属于本地策略，不应假定订阅更新会替它们修正；每次变更都要确认修改对象属于哪一层。

跨客户端迁移时，优先重新导入原始订阅，再检查扩展字段；不要把某个客户端的完整配置文件直接当作通用订阅。桌面系统代理端口、安卓分应用列表和本地 DNS 选择都带有设备上下文，迁移后需要重新设置。测试至少覆盖一次实际网页请求与所需的 UDP 应用，再确认更新流程可重复执行。首次连接成功只能验证当前记录，不能证明下次订阅变动后仍能正确映射。

场景选型与故障检查：先匹配条件，再比较表现

按服务端和设备确定候选组合

已有可用服务时，第一选择是保持服务端明确支持且已经验证的组合，而不是为更换协议而更换。桌面使用 v2rayN，先确认系统架构和安装方式，再核对所选内核。安卓需要 REALITY 或 Vision 等 Xray 相关能力时，优先检查 v2rayNG 的对应设置；已有 V2Fly 配置且功能需求一致时，可把 v2flyNG 作为备选。安装入口统一放在下载中心，协议参考不替代系统与架构选择。

需要频繁打开短页面时，关注连接建立、解析和首字节等待；长时间传输时，关注持续吞吐、丢包与设备温度；后台消息应用则更看重接管范围、连接恢复和系统后台限制。若同时有多类需求，不必追求一个参数包办所有目标。先建立稳定的基线，再针对具体应用调整路由或分应用范围，通常比同时替换协议和传输更容易得到可以解释的结果。

把失败定位到连接阶段

内核无法启动时，先检查配置解析、端口占用和功能支持，此时测试远端速度没有意义。内核能启动但连接建立失败时，核对地址、端口、系统时间和传输参数。能够连接但安全握手失败时，继续检查服务器名称、证书、公钥、shortId 或认证信息。若日志显示请求已经转发而目标没有响应，则需要检查服务端出口、目标可达性和 DNS 结果，不能再把所有问题都归到客户端导入步骤。

网页正常但部分应用异常时，先确认这些应用是否进入代理，再看路由与 UDP 需求。桌面某些应用不采用系统代理，安卓也可能因为分应用排除而直连。进入内核之后，还可能被规则分配到 direct 或 block；规则顺序和出站标签因此需要一起检查。DNS 返回结果也可能影响基于 IP 的规则判断，调整域名策略前应理解其作用范围，避免把解析选择与协议认证混为一谈。

速度慢和连接超时采用不同检查线

连接超时优先解决“能否建立连接”，按系统时间、订阅有效性、端口、传输与内核日志逐步排查；速度慢则要在连接可用的前提下比较节点负载、线路和本地设置。对应清单分别见节点超时检查与速度慢分层排查。两种问题可能同时发生，但不宜用反复下载测速来诊断认证失败，也不宜用一次连接成功否定持续拥塞。

最后保存一份可回溯记录：客户端名称、实际内核、协议与传输组合、错误阶段及最近一次设置变更。记录中不需要包含访问凭据。恢复稳定后，把临时详细日志级别调回日常设置，并清理重复的试验记录，避免以后误选。下一次出现相似问题，先与基线比较，再做单项变更；通用疑问可转到FAQ，需要重新走导入与验证流程时回到入门指南。选型的依据始终是完整组合和实际需求，而不是协议标签本身。