协议与内核手册

一、配置分层与字段对应

先识别客户端、内核和服务器

客户端是管理配置的图形界面，负责导入分享链接、维护订阅分组、选择服务器以及修改系统代理。内核读取客户端生成的配置，实际执行监听、域名解析、路由判断和远端连接。服务器则运行与客户端相匹配的接入配置。三个环节各自有职责，因此界面能保存一条记录，只能说明输入通过了界面检查，不能说明内核支持全部参数，更不能说明服务器已按相同方式部署。

一条连接可以按四层阅读：代理协议确定身份验证与代理请求的表达方式；传输方式确定这些内容如何承载；安全层处理外部连接的加密与身份认证；路由规则决定哪些请求使用这条连接。订阅链接是配置的分发入口，不属于上述连接层。把订阅地址填进服务器地址栏，或者把传输名称当成代理协议，都会让后续检查失去对应关系。应先确认正在编辑的是订阅分组还是单条服务器记录。

不要凭显示名称推断配置

服务器别名仅用于列表辨认，可以由订阅提供方任意命名。别名包含某个协议名称，不等于实际协议字段就是该类型。判断应以编辑窗口中的类型、地址、端口、身份字段、传输和安全设置为准。地址可能是域名，也可能是网络地址；端口是远端服务监听端口，不是本地代理端口。浏览器连接本机代理时使用的监听端口，与远端端口分属两段连接，修改其中一个不会自动修复另一个。

传输路径和服务器名称也不能相互替换。使用基于网页连接的传输时，路径通常用于服务端分发请求；服务器名称则参与安全握手或证书验证。部分配置还包含请求头中的主机名，三者可以相同，也可以不同，取决于部署方式。客户端把这些字段放在邻近位置，是为了编辑方便，不表示它们语义相同。排错时应逐项核对原始配置，而不是把所有域名字段改成服务器地址。

用最小变更建立可复现条件

订阅配置通常已经给定完整组合，不适合凭偏好更换其中一层。例如，把已有记录的安全层改成另一种类型，并不会让服务器自动获得对应能力；更换传输方式也需要服务端同步支持。若需要比较两种方案，应取得服务端明确提供的两条完整配置，并保持本地路由、测试目标和接入网络一致。只改一条记录的类型字段，得到的往往是连接失败，而不是有意义的协议对比。

建议在第一次排错前记下客户端名称、正在运行的内核、协议类型、传输方式和安全层，再记录问题发生在导入、启动、握手还是访问阶段。这样可以把“无法使用”拆成具体环节。日志若显示配置字段不被识别，应先检查内核与配置格式；若内核已启动而远端握手失败，再检查地址、身份和安全参数。跨层反复修改会让前一次有效配置也难以恢复。

二、四类代理协议的取舍

VMess 与 VLESS：不同的职责边界

VMess 是 Project V 生态较早采用的代理协议，设计中包含用户身份验证与消息保护机制，常见配置以用户标识作为认证信息。其历史实现存在不同认证方式，较新的配置通常围绕 AEAD 机制使用。旧教程中的额外身份参数不能直接当作新配置的推荐值。对客户端用户来说，重点是按服务端给出的字段导入，并保持系统时间准确；部分认证失败与时间偏差有关，不应立即归因于线路不可用。

VLESS 从职责拆分出发，简化协议本身，把常见部署中的传输安全交给外部安全层。常见的空加密字段不表示整条连接必然是明文，也不表示可以忽略安全设置：实际保护取决于外层是否正确启用了 TLS、REALITY 或其他明确设计的安全通道。它通常同样使用用户标识认证，但不能与 VMess 的身份、加密或传输字段随意互换。选择 VLESS 时，应把安全层和相关流控要求一起视为配置的一部分。

部分 VLESS 组合使用特定流控方式，例如 XTLS Vision。流控字段不是对所有传输都有效的通用加速按钮，需要内核、传输与服务端共同满足条件。已有订阅未设置流控时，不应自行补入一个名称；已有配置包含流控时，也不能为了适配另一个内核直接删掉。两种操作都可能改变连接行为。实际选择优先考虑完整组合能否被双方支持，而不是只比较协议名称是否更新。

Trojan：依赖正确的 TLS 部署

Trojan 的常见设计把代理认证和请求放入 TLS 通道，以密码作为主要身份凭据。这里的密码属于代理认证，证书验证则用于确认外部安全连接的对端，两者不是替代关系。密码正确而证书名称不匹配，连接仍可能失败；证书验证成功而密码错误，同样无法完成代理请求。编辑时应分别核对服务器地址、服务器名称、端口和密码，不要把“允许不安全连接”当作处理所有握手错误的常规操作。

从使用角度看，Trojan 的字段相对直观，但部署简单与否取决于证书、域名和服务端维护方式。不同内核对扩展传输及附加选项的支持范围也可能不同。只看到一条以该协议命名的分享链接，无法推断它采用哪种传输组合。若订阅导入后出现空路径、丢失安全选项或不认识的扩展字段，应回到原配置确认，而不是默认所有客户端都会补上相同设置。

Shadowsocks：精简结构与方法兼容

Shadowsocks 采用较精简的代理结构，常见配置的核心是服务器地址、端口、密码和加密方法。不同方法代表不同的数据处理与密钥要求，不能只保留密码而随意更换方法。较早的方法、常见的 AEAD 方法以及后续的新协议系列并不天然互通。部分方法要求特定长度或编码的密钥，客户端接受普通文字输入，也不代表服务端会把它解释为同一个有效密钥。

该协议经常用于希望减少配置层次的场景，但是否适合仍取决于客户端实现、服务端方法以及是否附加外部传输组件。分享链接如果引用额外组件，而当前客户端并未提供对应支持，只导入基础字段通常不够。比较资源开销时，也必须把附加组件算进完整连接成本。结构精简可以减少某些处理步骤，却不能改变远端带宽、链路拥塞或应用请求模式。

三、TLS 与 REALITY 参数

证书验证、服务器名称与时间

TLS 为上层连接提供传输保护，并通过证书验证等机制确认对端身份。客户端连接的服务器地址用于建立网络连接，服务器名称通常参与握手中的名称表达和证书匹配。两者不必完全相同，但必须符合服务端配置。使用网络地址连接而证书签发给域名时，直接把服务器名称也改成网络地址，可能导致名称验证失败。正确做法是取得服务端要求的名称，而不是尝试关闭验证绕过错误。

证书验证还依赖设备时间与信任链。设备日期明显偏差，证书可能被判断为尚未生效或已经过期；服务端没有提供适当的证书链，部分环境也可能无法建立信任。若多个不同服务器在同一设备上同时出现证书错误，应先检查本机时间和网络环境。若只有一条配置失败，则优先核对该服务器的证书与名称。错误来源不同，对应处理也不同，反复更换密码通常没有帮助。

REALITY 的额外匹配关系

REALITY 在客户端侧通常涉及服务器名称、服务端公钥和短标识等参数，其认证方式与常规公开证书部署不同。服务端公钥需要来自对应服务配置，不能由客户端任意生成来替代；短标识的取值与格式也需要符合服务端允许范围。它不是把安全层选项切换一下就能启用的模式。客户端与内核必须支持该方案，并且连接到已经按对应方式配置的服务端。

这里的公钥与用户标识分工不同：用户标识用于代理层身份，公钥用于相关安全认证，短标识又承担另一项匹配要求。把某个字段复制到另一个输入框，即使字符形式看起来相近，也不能得到等价配置。界面还可能提供客户端指纹选项，用于影响握手表现。指纹不是随意填写的品牌标签，应使用当前内核明确支持的值，并按提供方要求保持组合一致。

部分教程会把 REALITY、VLESS 与 Vision 连写，因此容易让用户认为三者必须始终同时出现。实际应分别理解代理层、安全层与流控层，再依据具体实现判断哪些组合有效。不能从一种组合的成功经验推导出所有传输都支持相同流控，也不能把某个内核专用字段转写到另一个内核中期待等价执行。判断依据应是所用内核的实际功能，而非界面中是否出现了一个近似名称。

传输路径和协商参数

WebSocket 常见路径与请求头配置，gRPC 常见服务名称与相关模式配置。它们通常需要与服务端及中间代理对应。安全握手通过后，传输层仍可能因为路径或服务名称错误而失败；这类错误不能仅靠检查证书排除。ALPN 表达应用层协议协商偏好，其取值也应符合部署要求。添加更多候选值并不必然提高兼容性，反而可能使连接进入服务端未准备处理的路径。

保存安全层配置前，最好按原始分享记录逐项对照，尤其留意复制时的空格、编码和大小写要求。遇到新字段不认识时，先确认客户端是否支持，再确认内核是否支持。不要把所有空白字段填满当作完整配置，许多选项应保持默认或不设置。若必须临时修改用于定位，应保留原记录副本，并在测试后恢复；安全验证的长期设置不应由一次偶然连接成功来决定。

四、速度、资源与连接成本

把首次连接与持续传输分开

用户所说的“快”可能指首次打开网页、持续下载速度、视频开始播放时间，也可能指交互请求响应。首次连接包含域名解析、网络连接、可能的安全握手和代理请求；持续传输更受带宽、拥塞控制、链路丢包以及服务端负载影响。某种组合减少了握手步骤，不代表大文件下载一定更快。相反，持续传输表现较好的线路，也可能因为域名解析耗时而让首次打开显得迟缓。

代理协议的加密与封装会产生处理成本，但现代设备上的瓶颈经常不在这一步。只有在处理器明显受限、持续高吞吐或并发连接较多时，协议实现和硬件加速差异才更容易显现。对普通浏览而言，远端线路和目标站点的响应可能占据主要时间。不能仅凭一次下载结果，把服务器负载的变化归因于协议，也不能给所有设备套用固定的速度或占用排行榜。

多路复用与传输封装的边界

多路复用尝试在较少的底层连接中承载多个逻辑请求，可能减少重复建立连接的成本，但也会改变并发请求共享链路的方式。底层连接丢包或阻塞时，多个请求可能一起受影响。部分传输或流控组合不适用通用复用设置，强行开启可能没有收益甚至出错。应先使用客户端与服务端默认兼容的组合，确认问题确实来自频繁建连后，再考虑受支持的复用方式。

增加网页传输等封装层，可能有利于特定部署中的接入与分发，却也可能引入额外头部、缓冲和中间代理限制。原生连接路径较短，不代表在所有网络中都更稳定；经过中间代理的连接更复杂，也不代表必然更慢。比较时要确认两条记录是否连接同一地区、同一服务资源，否则协议差异与线路差异混在一起，结果只能描述这两条完整线路，不能代表协议本身。

正确理解延迟测试

基础网络探测只能反映某一层是否可达，无法完整验证代理认证和目标访问。真连接延迟测试通常会经过实际代理链路访问指定目标，但其结果仍受测试地址、路由规则、域名解析与超时设置影响。测试通过说明该测试请求成功，不表示所有应用都已使用代理；测试失败也需要查看错误阶段。首次验证的操作顺序可参考v2rayN 首次连接与代理生效验证。

进行对照时，保持同一接入网络、相近时间段和相同目标，先逐条测试，再进行有限重复。不要同时启动多个大流量任务，也不要一边自动更新订阅一边比较连接。记录是否能完成请求、首次响应是否稳定、持续传输是否中断，比只保留一个最好看的数值更有参考意义。如果差异在不同轮次中反复倒转，应把结论限制为“当前条件下没有稳定差异”，而不是强行选出胜者。

资源观察也要区分客户端界面与内核进程。长时间保留大量日志、频繁刷新列表或后台测试可能增加界面负载，持续连接与规则处理则更多发生在内核。查看系统任务管理工具时，应同时观察两者，避免把窗口占用当作协议开销。内存增长还可能来自连接缓存、域名缓存或规则集合，不应只因某次峰值就更换协议。先停止测试和后台任务，再观察稳定状态。

五、V2Fly 与 Xray 内核

共同来源不等于功能相同

Project V 形成了以配置驱动代理连接、路由和多种传输的技术生态。V2Fly 延续 V2Ray 相关项目的发展，Xray 则从这一技术基础分支演进，围绕自身目标扩展协议与传输能力。两者共享一部分概念和历史配置结构，因此许多字段看起来相近；但各自演进后，支持范围、默认行为与扩展字段并不完全一致。选择内核首先是功能匹配问题，不宜用简单的新旧关系概括。

涉及 REALITY、XTLS Vision 等组合时，应重点确认 Xray 的支持与相应配置要求，不能默认 V2Fly 会按相同语义执行。对于双方都支持的协议，仍需核对具体传输、加密方法和附加选项。一个协议名称出现在支持列表中，不代表该协议下所有历史与新增扩展都可用。遇到字段无法识别或启动失败，应先缩小到具体能力，而不是仅凭协议大类判断配置应该兼容。

三款客户端的选择关系

v2rayN 是桌面端配置管理入口，适合需要查看服务器列表、订阅分组、日志和路由状态的用户。它能管理的核心能力取决于实际使用的内核与客户端适配情况，不能仅由窗口名称推断。v2rayNG 面向安卓，常用于 Xray 相关配置；v2flyNG 则作为 V2Fly 路线的安卓备选。两款移动客户端的界面可能相似，但迁移配置前仍要逐项确认支持范围，不能把它们当成只换名称的同一程序。

客户端更新、内核更新和订阅更新是三个独立动作。客户端更新影响界面和配置生成逻辑；内核更新影响运行时能力；订阅更新则替换或补充远端提供的服务器记录。订阅更新成功不会自动增加内核不支持的功能，内核更新也不会修正错误的订阅地址。操作前先明确需要改变哪一层，更新后检查日志中实际运行的内核标识，再验证原有连接是否仍按预期工作。

配置兼容要看语义而不只看格式

两份文件都能解析为 JSON，只能说明语法成立。字段层级、允许值、默认值和行为才决定是否兼容。有的字段会在解析阶段被拒绝，有的可能被忽略，后者更容易造成误判。若从一种内核迁移到另一种，优先由目标客户端根据受支持的分享链接重新生成配置，而不是直接替换完整配置文件。涉及自定义路由、域名解析和特殊传输时，再逐段核对对应写法。

迁移测试应保留可恢复的原配置，并先验证一条已知可用的服务器。不要同时更换内核、导入新订阅和修改路由，否则失败后难以确定责任环节。先确认启动日志没有未知字段，再确认安全握手与目标访问，最后迁移复杂规则。对于只有原内核明确支持的能力，应保留原方案或取得服务端提供的另一种完整组合，而不是通过删除报错字段来强求启动成功。

开源属性意味着相关实现可以被研究和持续维护，但不能代替具体环境中的功能检查。不同项目可能采用不同开源许可证，许可证约束的是代码使用与分发，不直接决定连接速度或服务端兼容性。本站提供下载与说明入口，不替代项目自身技术定义。若只需要确认安装包平台和处理器架构，返回安装包页面即可；协议能力则继续按本章的内核与字段关系判断。

六、订阅格式与导入兼容

订阅获取与配置解析是两步

订阅链接通常指向一个返回配置内容的地址，内容可能是分享链接集合、经过编码的文本，或某种结构化配置。客户端需要先取得响应，再识别格式，最后把字段转换成自己的服务器记录。因此“订阅更新失败”至少包含网络请求失败、响应格式不符和单条记录解析失败几种情况。浏览器能打开一个地址，只说明取得了某种响应，不表示返回内容适合当前客户端，也不表示每条配置都受支持。

有些地址在认证失效后会返回网页说明，另一些会发生跳转或返回空内容。客户端若把网页当作订阅文本解析，可能显示格式错误或导入为空。这时应核对订阅分组中的完整地址、访问权限和服务端提供的格式说明，不要重复把同一地址添加为多个分组。订阅地址常包含访问凭据，应当像密码一样保管；交流错误时遮盖查询参数和个人标识，保留错误类型即可。

分享链接会发生字段转换

不同协议的分享链接并非同一种内部结构。有的把配置对象编码后放入链接，有的使用用户信息、主机、端口和查询参数表达字段。百分号编码用于表达保留字符，编码层数错误或复制时丢失分隔符，都可能改变解析结果。不要仅因一段文本看起来像乱码就自行解码后保存，也不要手工把所有加号或斜杠替换掉。应先使用客户端的标准导入入口，并查看失败记录具体缺少什么字段。

导入成功后仍需检查转换是否完整，尤其是安全层、公钥、短标识、流控、路径与服务名称等容易被不同实现区别处理的字段。别名和分组存在，不表示关键设置没有丢失。部分客户端能识别基础协议，却不支持链接中的扩展参数，此时服务器列表看起来正常，但实际生成配置可能不符合服务端要求。可打开编辑窗口与提供方说明对照，再通过启动日志确认运行时是否接受。

区分整份配置和单条服务器

包含规则、域名解析、入站与多个出站的整份配置，不等于一条服务器分享链接。把整份配置粘贴到单条导入窗口，可能无法导入，也可能只提取部分内容。反过来，单条链接通常也不会携带完整的本地路由策略。更换订阅后本地应用走向没有变化，可能正是路由独立于服务器记录的结果。不要期待一条分享链接自动修复本地监听、系统代理或分应用选择。

订阅分组适合保留来源关系。更新后，远端可能更换字段、删除记录或修改显示名称，本地手工编辑的内容是否保留则取决于客户端行为。需要长期保留的实验配置，宜先复制成独立记录，明确标记用途，再进行测试。复制后不会自动跟随原订阅变化，因此也要承担后续核对责任。不能一边希望完全手动控制参数，一边又假设订阅更新始终会替手工记录修正全部变更。

同一订阅在两个客户端表现不同，应先比较实际导入数量与关键字段，而不是立即判断其中一个内核不稳定。可能是一方支持该格式，另一方只支持其中部分链接；也可能是一方能通过现有代理取得订阅，而另一方尝试直接访问。先分开检查“拿到什么内容”和“如何执行配置”，再确认联网方式。必要时使用提供方明确为目标客户端准备的格式，避免经过不受信任的在线转换服务暴露凭据。

七、路由、本地接入与电量

系统代理和路由解决不同问题

系统代理设置负责告诉遵循该设置的应用，应向本机哪个地址和端口提交请求；内核路由则在请求进入后，决定直连、代理或拒绝。选择“自动配置系统代理”不会让所有程序必然接入，选择某条路由规则也不会自动让未接入的程序开始使用代理。排查网页没有变化时，先确认浏览器是否读取系统代理以及本地端口是否正确，再确认请求进入内核后匹配了什么规则。

本地监听通常应限制在实际需要的接口。仅供本机应用使用时，没有必要为了排错随意扩大到所有网络接口；需要局域网共享时，则要同时考虑访问控制与设备防火墙。监听地址改变后，系统代理仍可能指向旧地址。端口被其他进程占用时，内核可能启动失败或无法创建入站，此时远端协议没有机会执行。具体定位可阅读本地端口占用处理。

规则顺序与域名解析

路由通常按规则顺序匹配，请求命中后进入指定出站。域名规则依赖请求是否保留域名信息，地址规则则可能依赖解析结果以及域名处理策略。提前放置覆盖范围很大的规则，可能让后续细分规则没有机会生效。下面是 Xray 风格配置中的局部片段，只展示两个本地域名的直连匹配；它不是可单独启动的完整文件，整合前必须已定义名为 direct 的出站，并核对所用内核语法。

{
  "routing": {
    "rules": [
      {
        "type": "field",
        "domain": [
          "full:localhost",
          "domain:local"
        ],
        "outboundTag": "direct"
      }
    ]
  }
}

规则命中与域名解析位置并非同一个开关。应用可能先自行解析，再把地址交给代理；也可能把域名交给本机代理处理。内核中的域名解析策略、系统解析设置和浏览器自身解析设置又可能分别起作用。出现只有部分域名失败时，应检查实际请求使用的是域名还是地址，以及解析结果是否可达。不要只改一处解析地址就认定整个请求路径已经统一，也不要在不了解规则顺序时堆叠大量例外。

安卓接入与分应用代理

安卓客户端通常通过系统提供的虚拟网络接口接收应用流量，这与桌面应用读取系统代理的方式不同。启用连接时需要系统授权，其他占用相同接入机制的应用也可能产生冲突。分应用代理决定哪些应用进入这条接入路径，而进入后的流量仍可能被内核路由设为直连。因此，一个应用被选中，不代表它的每次请求都经过远端服务器；一个应用未被选中，也不代表内核能够再用规则把它补接进来。

电量消耗与协议有关，但不能只看协议名称。持续上传下载、弱信号下重传、频繁重连、过密的后台检测和应用周期唤醒，都可能让设备无线通信与处理器保持活跃。两种配置若承担的应用流量不同，其电池占用没有直接可比性。观察时应保持相同应用任务和屏幕状态，减少额外测试，再查看系统电池统计及连接日志。若连接反复断开，优先找出重连原因，而不是先降低全部安全设置。

把客户端加入电池优化例外，可能改善后台存活，也可能增加后台活动机会；限制后台则可能节电，但会影响待机后的连接恢复。应按是否需要持续接收消息来取舍。分应用代理可以减少不必要的接入范围，却不保证电量按固定比例下降。更完整的处理路径见v2rayNG 后台与省电设置。测试完成后关闭不再需要的后台探测，避免把诊断负载当作正常运行开销。

八、按场景选择与分层排错

先列约束，再比较方案

已有可用订阅时，第一约束是服务端实际提供什么配置，第二约束是客户端和内核是否完整支持。桌面端可以先使用 v2rayN 管理与验证，安卓端根据配置所需能力选择 v2rayNG 或 v2flyNG。若订阅只提供一种受支持且稳定的组合，没有必要为了追逐协议名称重新拆改。若服务端提供多种组合，再按首次响应、持续传输、后台稳定性和维护复杂度进行对照，而不是先设定一个普遍最优答案。

对于维护成本敏感的使用方式，字段清晰、来源可靠且能够稳定更新，比堆叠更多可选特性更重要。需要新安全层或特殊流控时，选用明确支持的内核，并让服务端提供完整记录。对于处理能力较弱的设备，应实际观察持续任务下的占用，避免重复封装、无必要的检测和过多后台并发。对移动设备则把网络切换与待机恢复纳入测试，不能只在屏幕常亮时完成一次连接就结束评估。

从导入到访问逐层缩小范围

第一层检查输入与解析。订阅没有生成记录时，确认请求是否成功、返回格式是否正确以及链接是否完整。记录已出现但内核无法启动时，查看未知字段、无效参数和本地监听错误。这个阶段不应先更换远端服务器，因为连接可能尚未开始。若界面不清楚日志位置，可参考v2rayN 主窗口功能速览，先找到服务器编辑、底部状态和日志区域。

第二层检查远端连接与安全认证。内核启动正常后，区分地址无法解析、连接超时、连接被拒绝、安全握手失败和代理认证失败。超时不能直接证明密码错误，认证错误也不能靠更换本地端口解决。按日志阶段分别核对域名解析、远端端口、时间、服务器名称、身份字段及安全参数。服务端状态不在本机控制范围内时，应向提供方确认对应配置，而不是持续随机修改有效字段。

第三层检查请求是否真正接入以及如何被路由。内核中的测试请求成功，而浏览器仍无法访问时，重点检查浏览器代理来源、本地监听和规则命中。只有部分应用失败时，比较这些应用的接入方式与域名解析行为；只有部分目标失败时，再检查目标侧状态、规则与解析结果。安卓端还需核对分应用范围和系统授权。把“服务器可用”和“应用接入正常”分开验证，才能避免反复切换同样可用的服务器。

给结论保留适用边界

当连接能够完成但表现不稳定时，再进入性能和电量分析。先停止后台测速与并行下载，比较同一网络下不同记录的稳定性，再观察不同接入网络。若所有记录只在某个网络失败，优先调查该网络的解析、接入与链路条件；若只有单条失败，则回到它的服务端状态和组合参数。每次只改变一个因素，并保留修改前结果，避免把偶然恢复误判为某个设置必然有效。

一次有效选型应能回答四个问题：服务端提供的完整组合是什么，当前内核是否支持，应用是否按预期接入，以及真实任务是否稳定。无需给协议贴上永久快慢或高低等级。保留配置来源、关键字段、测试条件与错误阶段，后续更新或迁移时就有可比较的依据。需要重新建立操作主线时返回快速上手教程；针对具体报错继续查阅疑难解答，比同时重装客户端和重建全部设置更便于定位。