代理协议与内核选型

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

把节点拆成四组参数

客户端里的一个节点不是单独的协议名称，而是一组共同工作的连接参数。第一组是服务器地址与端口，决定流量发往哪里；第二组是代理协议与认证信息，决定双方怎样识别请求；第三组是传输方式，决定代理数据如何承载；第四组是安全层，决定连接如何加密并验证对端。订阅将这些内容打包导入，只是省去手工填写，并没有消除各层之间的依赖。

例如，VLESS 可以与不同传输方式搭配，也可以配合 TLS 或 REALITY。看到“VLESS”并不能推断它一定使用哪一种安全层；看到“TCP”也不能判断里面运行的代理协议。客户端可能把传输字段称为“传输协议”“网络”或“传输方式”，名称随界面变化，但它们都不应与顶部的协议类型混为一谈。排查时先保留原配置，再按层核对，比随意切换下拉框更容易得到明确结论。

从界面设置追溯到实际连接

传输方式会引入自己的参数。WebSocket 常见路径与 Host，gRPC 常见服务名称；这些字段不是备注，也不能凭域名外观推测。服务器地址用于建立底层连接，Host 可能用于上层请求分发，SNI 则用于 TLS 握手中的服务器名称指示。三者有时相同，有时按部署要求不同。订阅原本提供了哪些值，就应完整保留哪些值，不能用“统一填服务器地址”的方式代替核对。

系统代理与路由规则位于另一层。系统代理决定愿意读取系统设置的应用是否把请求交给客户端；路由规则决定已进入客户端的请求选择直连还是代理。节点参数正确，不代表所有应用都已经使用它；系统代理已开启，也不代表路由规则一定把目标交给当前节点。因此，连接问题应先确认请求是否进入客户端，再判断协议握手是否成功，避免把应用入口问题误判成协议不兼容。

怎样阅读错误而不误改配置

日志中的“连接被拒绝”通常要求先检查入口和监听状态；名称解析失败应先看 DNS；证书相关报错应进入安全层核对；认证失败再检查协议字段。它们不是绝对的一一对应关系，但足以确定第一轮检查方向。不要只截取最后一行重试提示，应保留同一次连接前后的上下文，并把电脑与手机上的结果分开记录。不同设备使用了不同内核时，相同节点名称也可能对应不同的实际处理路径。

求助时可提供客户端名称、内核名称、协议类型、传输方式、安全层和脱敏后的错误信息，不应公开用户标识、密码、完整订阅地址或分享二维码。节点备注可以自由命名，却不能证明底层配置是什么。真正有用的是编辑窗口里的字段，以及内核接受配置之后的运行结果。后续章节都沿用这一分层方式：先解释协议本身，再讨论承载、安全和客户端实现。

VMess 与 VLESS：认证与加密的取舍

VMess 的设计背景与现有配置

VMess 是 Project V 生态早期的重要代理协议，将用户认证、请求信息封装和数据保护放进自己的协议设计中。它让客户端与服务端通过约定的用户标识识别连接，也支持搭配不同传输方式。长期使用留下了较多配置资料和订阅样本，但这些资料跨越了不同实现阶段。阅读旧教程时，不能只看字段名称相同，就假定其中的认证参数和当前客户端完全适用。

现代 VMess 配置应关注 AEAD 认证方式。旧式配置中出现的额外标识字段属于历史兼容问题，不应为了照搬旧文章而随意填写非零值。用户标识需要与服务端一致，系统时间也应保持准确。遇到认证失败时，先确认订阅是否过期、标识是否完整，再检查时间同步和客户端兼容范围。把传输方式改成另一个选项，通常不能解决认证参数本身不匹配的问题。

VMess 的数据加密选项与 TLS 不是同一个开关。前者属于代理协议内部，后者属于连接外部的安全层。界面里看到“自动”时，通常表示由实现根据设备能力选择支持的处理方式，不代表服务端可以接受任意参数组合。已有订阅工作正常时，不必为了减少一个加密层就直接关闭现有设置；需要优化资源开销，应先取得服务端支持的完整方案，再做同条件比较。

VLESS 为什么强调外部安全层

VLESS 将重点放在较简洁的认证和请求表达上，不提供与 VMess 相同的内置数据加密机制。因此，讨论 VLESS 的安全性时必须同时说明它与什么安全层组合。通过互联网使用时，通常应采用服务端明确支持的 TLS 或 REALITY 方案。仅看到协议名更简洁，就推断它天然更安全或天然更快，都忽略了外部安全层、传输方式与服务端实现的作用。

VLESS 配置中的用户标识、加密字段和流控字段各有职责。常见加密字段为 none，它描述的是 VLESS 协议内部的加密选择，并不表示整条连接没有 TLS 保护。流控则是特定实现的附加机制，例如服务端要求的 Vision 流控需要客户端和内核共同支持。不能把流控看成通用加速按钮，更不能给所有传输方式批量套用同一个值。

两者之间怎样做实际选择

如果现有 VMess 配置稳定，业务也没有暴露出兼容或性能问题，保留它是合理选择。新配置若明确提供 VLESS 与现代安全层组合，则优先检查当前内核能否完整支持，再考虑采用。比较时应尽量控制服务器、传输路径和测试任务一致，否则测到的差异很可能来自不同出口，而不是协议。不能用两个来源不同的节点，得出某种协议一定更快的结论。

迁移还涉及订阅和设备的一致性。电脑端能够导入某个 VLESS 组合，不意味着手机端的旧解析器能够识别全部字段。先在一台设备保留原节点并导入新配置，确认认证、域名访问和所需应用都正常，再扩展到其他设备。若只有某个客户端失败，应对比流控、安全层和指纹字段，而不是立刻重新生成用户标识。协议选型最终要落在完整配置是否可被两端正确执行。

Trojan 与 SS：不同的安全封装路径

Trojan 对 TLS 的依赖

Trojan 的基础思路是让代理请求运行在 TLS 保护的连接中，通过密码完成代理身份认证。与把加密机制放在协议内部的设计相比，它更直接地依赖成熟的 TLS 实现。因此，检查 Trojan 节点时，证书名称、信任链与系统时间不是外围细节，而是连接能否建立的核心条件。密码正确只说明认证材料可能正确，并不代表 TLS 握手已经通过。

服务器地址和证书对应名称可能不同。服务端如果要求指定 SNI，客户端就必须按提供的名称填写；如果使用受信任证书，还需要系统能够建立正常的证书信任关系。遇到证书错误时，把“跳过证书验证”打开虽然可能改变报错现象，却同时取消了重要的身份检查，不能当作常规修复。应先核对名称、系统时间、证书链以及订阅是否仍指向正确的服务端。

Trojan 也可能与不同传输方式组合，因此“Trojan 节点”并不总是只有地址、端口和密码三项。订阅包含路径、Host 或服务名时，这些内容仍需要保留。客户端显示了协议名但遗漏附加参数，可能造成导入成功、连接失败的情况。判断兼容性应看具体组合，而不是只看支持列表里是否有 Trojan。需要排查握手问题时，可结合TLS 与证书报错排查逐项检查。

SS 的加密方法决定兼容边界

SS 是 Shadowsocks 的常用简称，其设计强调较直接的加密代理转发。使用时通常需要服务器地址、端口、密码和加密方法。加密方法是协议解释的一部分，不是可以任意调节的本地偏好；服务端使用哪一种，客户端就需要提供相应实现。密码相同但方法不同，仍然无法正常通信。订阅中的方法字符串应完整保留，包括连字符和数字，不能凭印象选择一个相似名称。

常见配置涉及 AEAD 系列方法，另外还有具有独立密钥与会话设计的较新方案。不同系列对密码或密钥材料的要求可能不同，不能把一个方案的普通口令直接当成另一个方案要求的编码密钥。旧式方法也可能被当前实现移除或限制。客户端界面能打开 SS 编辑窗口，只能证明它支持某些 SS 配置，不能证明它接受所有历史方法及所有扩展。

传输扩展同样需要留意。部分 SS 分享链接附带额外扩展参数，但本站列出的客户端与所选内核不一定实现这些扩展。此时应向配置提供方索取直接兼容的连接方案，而不是删掉附加参数后假定功能等价。删除参数可能让界面不再报错，却改变了连接所需的实际封装。导入结果应与来源配置逐项对照，尤其检查加密方法和任何额外传输说明。

简洁并不自动等于低开销

从配置体验看，基础 SS 方案字段较少，适合已经明确服务端方法、只需完成标准代理转发的场景；Trojan 则适合已有正常 TLS 配置并能正确管理证书的服务端。两者都可能承担日常网页访问，但是否适合特定应用，还要看 UDP 支持、客户端接入方式和路由设置。不要把“字段少”直接等同于“手机更省电”，后者往往受连接数量和后台行为影响更大。

选型时先确认需求是否包含实时通话、游戏或其他依赖 UDP 的任务，再确认客户端、内核、服务端和承载链路是否都支持相应流量。仅测试网页能打开，无法证明 UDP 已经通过。若已有 SS 配置能满足任务，没有必要仅因另一种协议的名称较新就迁移；若目标组合依赖当前内核不支持的功能，换一个兼容配置通常比反复修改本地字段更有效。

TLS 与 REALITY：安全层参数核对

TLS 验证的是连接对端

TLS 不只是把内容变成不可直接阅读的数据，还承担对端身份认证。正常验证会涉及证书是否在有效期内、证书名称是否匹配、签发链是否受信任等条件。系统时间不准确可能让正常证书看起来尚未生效或已经过期；服务器名称填写错误则会触发名称不匹配。排查这些问题时，应先修正时间和配置来源，而不是用一个忽略错误的选项覆盖所有检查。

SNI 用来在握手时指示请求的服务器名称，证书验证也需要正确的名称依据。在图形客户端中，它可能显示为“服务器名称”“SNI”或相关安全设置。连接地址可以是域名或 IP，但这不意味着 SNI 必须跟着改成同一个值。服务端通过同一个入口承载不同服务时，名称甚至会影响请求分发。应按订阅提供的值填写，不要把地址栏与安全层名称栏机械同步。

ALPN 用于协商上层协议，指纹设置则影响客户端握手的具体表现。它们都不是通用提速参数。服务端要求特定组合时应保持一致，未要求时不宜从其他节点复制。部分客户端会以预设名称表示握手指纹，支持范围由实现决定；文字名称能够保存，不保证当前内核能够执行。遇到启动失败应查看配置加载错误，遇到握手失败再检查与服务端的协商关系。

REALITY 不是另一种代理协议

REALITY 是安全层方案，不能与 VMess、VLESS、Trojan 这些代理协议简单放在同一层级互相替换。常见配置会将它与 VLESS 组合，但最终支持哪些搭配，要看所用内核的具体实现。用户选节点时，应把“代理协议、传输、流控、安全层”作为一套整体读取。只看到备注里写着 REALITY，并不足以知道配置所需的全部字段，也不能据此判断其他客户端一定兼容。

REALITY 客户端参数通常涉及服务器名称、服务端提供的公钥材料或对应认证字段、短标识以及握手指纹。字段标签可能随客户端与内核演进有所不同，必须按当前配置说明映射。短标识并非节点备注，公钥材料也不能用普通密码替代；缺失时应从配置提供方重新获取。服务端私钥不应出现在面向普通用户的客户端订阅中，更不应作为排错截图公开。

最小改动的安全层排查

先重新更新订阅，再打开失败节点的编辑窗口核对安全层类型。如果本应是 REALITY 却导入成普通 TLS，应优先怀疑解析兼容，而不是手工补一个服务器名称就结束。随后核对指纹、认证材料、短标识与流控。每次只改变一个有明确依据的字段，并保留原配置；同时改动多个参数，即使偶尔连通，也难以确定真正的原因，更不利于在其他设备复现。

如果同一份订阅在电脑上可用、手机上不可用，重点比较内核支持和字段保留情况。只有所有参数一致且实现支持明确后，才进一步分析接入网络差异。REALITY 不是解决所有连接错误的通用选项，TLS 也不天然意味着配置落后；可维护、可验证、与实际部署匹配，才是安全层选择的基本标准。

性能与电量：区分首包、吞吐和后台开销

连接速度不是单一指标

用户感受到的“快”至少包括三个方面：建立连接到收到首个有效响应的时间、持续传输时的吞吐能力，以及长时间使用是否频繁中断。前者受域名解析、网络往返和握手影响；后者受到线路带宽、拥塞、服务端负载和本地处理能力共同限制。某个节点的简易测试结果较好，不代表大文件传输更快，也不代表实时通话的波动更小。

协议设计会改变认证、封装和加密开销，但这些开销在总耗时中的比例并不固定。网络往返较长时，多一次连接交互可能比一次本地加密更明显；设备处理能力较弱时，大吞吐任务又可能受加密和内存复制限制。因此不能给所有设备排列一个永久有效的协议速度榜。更可靠的办法是先排除线路与服务端差异，再针对自己的任务比较完整配置。

传输方式也会改变表现。WebSocket 增加相应封装和请求处理，gRPC 依赖自己的承载与协商过程，直接的 TCP 组合则通常结构更直接。然而，中间接入设施可能只支持某种传输，这时额外封装是部署条件的一部分，并不是可以随意删掉的浪费。优化应先确认部署约束；如果服务端要求路径与上层转发，客户端改为直接 TCP 通常只会导致连接失败。

资源占用要看完整工作负载

处理器占用可能来自加密，也可能来自日志、流量统计、规则匹配和大量短连接。硬件对不同加密算法的支持不同，同一种算法在两台设备上不一定有相同成本。内存占用则受到连接缓冲、DNS 缓存、规则数据和图形界面影响。比较客户端时应区分界面进程与内核进程，不能把某一刻任务管理器里的总量直接当作代理协议的固定开销。

连接复用可减少部分重复建连成本，但也可能让多个请求共享同一承载连接，在某些丢包场景下相互影响。某些协议或流控组合对复用有特定限制，因此不能把“开启复用”当作统一的性能建议。应先查看配置提供方要求和内核支持，再用多标签网页、持续下载和实际应用分别验证。只改善一种测试任务，却让日常连接更容易卡住，不算有效优化。

移动端电量与网络行为密切相关

手机耗电不仅取决于每个数据包的加密成本。无线网络唤醒、频繁重连、过密的保活、持续测速以及大量后台域名请求，都可能扩大消耗。接入信号较弱时，网络本身的成本也会上升。因此，为省电优先减少不必要的自动测试和重试，确认订阅更新间隔合理，再考虑协议选择。不要为了追求更积极的保活，把所有连接都设置成持续活跃。

Android 上的系统电池管理可能在后台限制客户端，表面看起来像节点掉线，实际却是进程或网络活动被暂停。应按设备系统提供的电池设置检查 v2rayNG 或 v2flyNG 的后台运行权限，再观察是否还会中断。反过来，也不必对所有应用解除限制。先保证承担代理连接的客户端可以按需求运行，再通过一天内相近使用量的对比判断电量变化。

实际比较时，选取相近网络环境，固定目标任务，分别记录首次打开、连续使用和待机后的恢复情况。一次只更换一个主要变量，保留原配置以便回退。测试前关闭批量测速，减少其他下载，避免把路由或 DNS 同时修改。若两组配置使用不同服务器，就把结果写成“这两条配置在当前环境的表现”，不要上升为某个协议永远更省电或更稳定。

V2Fly 与 Xray：内核家族及配置边界

客户端界面与代理内核各做什么

Project V 是理解这类工具的生态背景，V2Fly 与 Xray 则属于相关的代理内核项目。内核负责解析配置、建立代理连接、执行路由并处理流量；图形客户端负责订阅管理、编辑设置、启动内核和展示运行状态。二者不是同一个层级。界面上能够显示某种协议名称，不代表当前正在运行的内核具备全部相关功能，也不代表生成的配置已经被内核接受。

v2rayN 是本站优先推荐的桌面客户端，覆盖 Windows、macOS 和 Linux；其内核选择应以实际安装包和界面提供的能力为准。Android 上，v2rayNG 以 Xray 内核为主要使用路径，v2flyNG 是 V2Fly 内核方向的备选。三款客户端的菜单和可编辑字段不完全相同，不能将电脑端的某个字段位置直接当成手机端的操作路径。安装入口见四平台客户端安装包。

共同来源不等于配置完全互换

V2Fly 与 Xray 存在共同的技术来源，基础配置中也能看到相似概念，例如入站、出站、路由和 DNS。但项目分别演进后，协议扩展、传输实现、参数默认值与字段语义可能出现差异。尤其涉及 REALITY、特定 VLESS 流控或其他扩展时，应以目标内核的明确支持范围为准。不能因为两份文件都是 JSON，就直接认为它们可以原样互换。

JSON 语法正确只表示括号、逗号和字符串满足格式要求，内核还需要检查字段是否合法、组合是否允许以及所需实现是否存在。以下是 Xray 配置中的一个完整 outbound 对象，用于说明协议层的位置；它是直连出站，不是代理节点，也不是可单独启动的完整客户端配置。将它放进 outbounds 数组时，仍需配合其余设置。

{
  "tag": "direct",
  "protocol": "freedom",
  "settings": {}
}

这个对象中的 protocol 描述出站行为，tag 是供路由引用的标记。仅修改标记不会改变协议，路由引用旧标记却可能导致配置失效。类似地，代理出站中的传输与安全字段必须遵循对应内核的结构。图形客户端通常会代为生成这些内容，因此普通订阅用户应优先通过客户端管理，而不是混合复制不同内核的配置片段。

更换内核前先划定迁移范围

准备切换内核时，先备份订阅分组和自定义设置，再选择一个已知可用的节点做小范围验证。核对协议、安全层、传输、流控、DNS、路由以及 UDP 需求，确认目标内核都能表达。切换成功之后，不仅要看主界面是否显示运行中，还要检查日志是否有字段不支持、规则加载失败或出站初始化错误。内核进程存在，并不能证明所有功能已经正常。

不同内核对 DNS 与路由的表达尤其容易出现细微差异。某些域名解析策略、规则顺序或数据文件要求不是一一映射；客户端可能替你转换部分设置，也可能要求重新选择预设。迁移后应分别验证应走代理的目标与应直连的目标，再检查域名解析和所需 UDP 应用。只打开一个网页，就宣布迁移完成，容易遗漏分流错误和后台应用异常。

不要因为单个功能需要就频繁在多套内核间来回切换。先确定主要使用场景，选择能够完整覆盖的稳定配置，再保留一份可回退的设置。若节点依赖 Xray 的特定扩展，优先使用明确支持该扩展的客户端路径；若现有 V2Fly 配置长期满足需求，也可以继续使用。内核选择的依据是功能与配置一致，而不是项目名称听起来更新。

订阅格式：导入成功不等于字段完整

区分订阅地址、分享链接和配置文件

订阅地址是一个用于获取配置集合的入口；分享链接通常描述单个节点；配置文件则可能包含节点以外的入站、路由与 DNS 设置。三者都能帮助迁移信息，但不是同一种数据。把订阅地址当成单节点链接导入，或者把完整配置文件粘进分享链接输入框，可能得到空结果或解析错误。先确认手里材料属于哪一类，再选择客户端对应的导入菜单。

常见分享链接具有 vmess://、vless://、trojan:// 或 ss:// 等前缀。前缀告诉解析器使用哪一类规则，但不保证所有扩展参数都已标准化。VMess 链接常见编码后的结构化内容，VLESS 和 Trojan 常通过查询参数表达传输及安全设置，SS 也存在不同的编码表达。链接能被某个工具识别，不意味着所有客户端的解析行为完全相同。

订阅服务可能返回编码后的多条链接，也可能返回客户端专用格式。浏览器打开后看到一大段文字，不足以判断内容是否适配当前客户端；返回的是登录页面、错误说明或过期提示时，下载动作本身甚至仍可能显示成功。应以客户端解析出的条目和日志为准。若更新后节点为空，先保留原有分组，不要立即删除全部旧配置，避免同时失去可用的回退路径。

导入后最值得核对的字段

基础地址、端口和用户标识通常比较醒目，容易遗漏的则是流控、指纹、安全层名称、WebSocket 路径、Host、gRPC 服务名以及 REALITY 认证参数。尤其在新格式进入旧解析器时，解析器可能忽略它不认识的字段，而不是立即拒绝整条链接。此时主界面里能看到节点，也能打开编辑窗口，但实际连接所需的信息已经不完整。

订阅更新通常会重新读取来源内容。直接编辑订阅管理下的节点，下次更新时可能被覆盖；不同客户端具体行为有差异，不能把一次手工修改当作永久修复。需要比较参数时，可以在客户端允许的情况下复制为独立测试节点，并清楚命名。确认问题来自订阅源后，应修正来源或使用兼容入口，而不是每次更新后重复补齐同一个字段。

更新路径与多设备同步

更新订阅时是否经过代理，需要由当前连接条件决定。v2rayN 中可见“更新全部订阅（不通过代理）”等相关菜单；如果已有代理不可用，仍让更新依赖该代理，可能造成循环失败。反过来，某些环境下直接更新也可能失败，应比较客户端提供的更新路径。每次改变更新方式后查看具体错误，区分连接失败、认证失败与解析失败，不要只反复点击更新按钮。

多设备共用订阅并不等于共享全部本地设置。订阅通常负责节点集合，系统代理、应用接入、路由和 DNS 仍需各端配置。电脑上的自定义规则不会因为手机导入同一地址就自动出现；二维码导出也可能只包含一个节点。具体迁移方式可参考电脑与手机的订阅同步方法，更新异常可继续查看订阅更新失败自查清单。

场景选型：按需求收敛到可用组合

日常桌面与移动使用

桌面初次使用优先选择 v2rayN，再按操作系统和处理器架构选择安装包。协议方面，不必先挑一个名称再寻找配置，应先看服务端实际提供哪些完整组合，筛掉当前内核不支持的选项，再比较稳定性。对以网页、文档和常规应用为主的使用方式，稳定的域名解析、正确的路由和可靠的连接恢复，通常比更换协议带来的理论差异更重要。

Android 以 v2rayNG 作为主要选择，需要 V2Fly 配置兼容路径时再评估 v2flyNG。手机端应优先确认后台运行、电池管理和网络切换后的恢复，再测试持续传输。若设备在无线网络与移动网络之间切换后出现问题，先观察客户端是否重新建立连接，不要立即修改密码或用户标识。连接恢复属于运行行为，认证材料通常不会因为切换接入网络而改变。

按业务需求选择，而不是按名称排序

已有 VMess 或 SS 配置能够满足任务时，继续使用并保持客户端兼容更新，是成本较低的选择。需要采用 VLESS、REALITY 或特定流控时，必须取得服务端对应参数，并确认目标内核支持。Trojan 则要重视 TLS 名称和证书条件。这里不存在对所有人都正确的协议排名：同一个协议搭配不同传输、安全层和服务器，实际体验可能差别很大。

依赖 UDP 的任务需要特别谨慎。协议层宣称可以处理 UDP，并不意味着客户端入口、服务端转发以及目标网络都已经支持。系统代理也不保证所有应用流量都会进入客户端；某些应用有自己的代理设置或独立连接方式。应先依据入门指南中的接入与验证步骤确认流量入口，再用目标应用实际测试。不要用浏览器打开成功替代业务验证。

一次完整的选型与回退流程

第一步，列出必须满足的需求，包括平台、应用类型、是否需要 UDP、是否需要后台常驻。第二步，记录来源配置的协议、传输、安全层和附加参数，确认客户端与内核都支持。第三步，导入一个测试配置，先查看启动日志，再分别验证域名访问、规则分流和真实业务。第四步，在相近网络条件下观察恢复能力与资源消耗，而不是只依赖一次简易测速。

如果出现失败，按“请求是否进入客户端、地址是否能连接、安全层是否握手、代理认证是否完成、路由与 DNS 是否正确”的顺序缩小范围。每一轮只改动有依据的一项，保存修改前后的现象。域名请求异常时可参考DNS 检测与分流设置，基础概念不清楚时可阅读订阅、节点与内核的新手十问，不要让排查退化成随机组合参数。

上线使用前保留原来的订阅分组或独立配置，确认新方案覆盖主要应用后再清理重复条目。更新客户端后也应进行一次简短回归，特别检查自定义路由、DNS 和内核选择是否保持预期。若新方案仅改善一个测试结果，却增加后台中断或兼容负担，回退到原方案完全合理。可维护的配置应能说明每个关键字段的来源，也能在其他设备上重复建立。