V2Ray 协议与内核选型参考

// 01 · DECISION MODEL

先拆分协议、传输、安全与路由

客户端配置不是单一协议

V2Ray 图形客户端把复杂配置压缩成若干表单项，容易让人误以为选中 VMess 或 VLESS 就完成了全部技术选择。实际上，一条连接至少可以拆成五层：应用访问产生原始 TCP 或 UDP 流量；客户端本地入口接收流量；代理协议负责认证和封装；传输方式负责把代理数据放进 TCP、WebSocket、gRPC 等载体；TLS 或 REALITY 负责外层握手与加密。数据到达远端后，还要经过出站与路由规则决定直连、代理或阻断。任何一层参数不匹配，都可能表现为“配置可导入但无法连接”。

协议层主要决定认证字段、请求头结构和内核实现。例如 VMess 使用用户标识并带有自己的协议结构，VLESS 更轻量，把加密与传输安全交给外层。传输层决定数据如何分帧、是否需要 HTTP 语义以及中间链路能否正确转发。安全层则处理证书验证、服务器名称、密钥交换与目标身份确认。路由层不改变协议本身，却直接影响哪些请求会进入代理连接。排查问题时必须先定位层级，再修改参数，连续替换多个选项只会掩盖真正原因。

用约束条件代替“最强协议”

协议没有脱离环境的统一排名。选型需要同时确认服务端已提供什么、当前客户端内核能解析什么、操作系统需要哪些功能，以及链路中是否存在反向代理或只接受特定传输方式的基础设施。服务端已经固定为 VMess 时，客户端不能单方面改成 VLESS；订阅只提供 WebSocket 时，也不能仅在本地把传输切换为 gRPC。客户端表单中的协议、地址、端口、用户标识、传输方式和安全参数必须与服务端逐项一致。

判断优先级可以按“可用性、兼容性、资源成本、维护成本”排列。第一步确认服务端与内核支持，第二步确认订阅字段能完整传递，第三步才比较连接建立速度、吞吐和耗电。对于多设备使用，还要考虑桌面端与 Android 端能否复用同一订阅。如果某个组合只有一端能完整识别，日常维护成本往往高于它带来的微小性能收益。

建立可回退的基线配置

准备比较协议时，应保留一条已经验证可用的基线配置，不要直接覆盖。基线用于排除本地端口、系统代理、DNS 和路由规则造成的干扰。测试新配置前可临时使用全局代理或最简单的路由模式，确认基础连接后再恢复分流。若基础连接正常而恢复规则后异常，问题就在路由或 DNS，不应继续修改协议参数。图形客户端通常支持复制配置或按订阅分组管理，合理利用分组能显著减少反复导入带来的字段混乱。

// 02 · PROTOCOL FAMILIES

VMess、VLESS、Trojan、Shadowsocks 与 REALITY

VMess：完整协议结构与成熟兼容面

VMess 是 Project V 生态早期形成的核心代理协议，设计目标是把用户认证、时间校验和数据封装放在统一协议中。客户端常见字段包括服务器地址、端口、用户 ID、alterId、加密方式和传输设置。现代配置中的 alterId 通常为零；如果旧订阅仍提供非零值，必须按服务端实际设置保留，不能依据新配置习惯擅自改动。VMess 对系统时间较敏感，设备时间偏差明显时可能无法完成认证，因此“相同配置在一台设备可用、另一台不可用”时应检查自动校时。

VMess 的优势是长期积累形成的工具兼容性和大量现有部署，许多订阅格式都能稳定表达它的基础字段。代价是协议自身结构比 VLESS 更复杂，认证和封装存在额外处理。对现代桌面与手机硬件而言，这部分成本通常不是瓶颈；真正影响体验的更多是网络往返、传输方式、TLS 握手和服务端负载。如果现有 VMess 配置稳定，单纯为了追求理论上的少量开销差异而迁移，收益未必覆盖重新配置和跨设备验证的成本。

VLESS：认证与安全层分离

VLESS 延续用户 ID 认证方式，但不在协议内部重复承担数据加密，安全能力交给 TLS、REALITY 等外层机制。这样做减少了协议层冗余，也让传输安全的职责更清晰。VLESS 配置除了地址、端口和用户 ID，还常见 flow 字段。flow 不是所有 VLESS 配置都需要；只有服务端启用了对应流控方式时客户端才应填写。最常见的相关值是 xtls-rprx-vision，留空与填写错误值都会导致客户端和服务端行为不一致。

VLESS 本身并不等于 REALITY，也不自动代表某种传输。它可以与 TCP、WebSocket、gRPC 等方式组合，并可使用 TLS 或 REALITY。选中 VLESS 后仍需继续检查 network、security、serverName、flow 等字段。现代 Xray 配置中，VLESS 与 REALITY、Vision 的组合较常见，因为这些能力在同一内核家族内协同实现。若需要把配置交给只支持 V2Fly 特性的客户端，应先确认该组合是否在目标内核中存在等价实现。

Trojan：以 TLS 为基础的密码认证

Trojan 的核心字段相对直接：服务器地址、端口、密码、TLS 服务器名称和可选传输参数。它依赖正确的 TLS 部署，客户端会按服务器名称验证证书。地址使用 IP、服务器名称填写域名是正常组合，因为连接目标与证书身份可以分开；但若服务器名称为空、拼写错误或证书链异常，连接会在进入代理数据阶段前失败。关闭证书验证虽然可能暂时绕过错误，却会失去身份校验，不适合作为长期处理方式。

Trojan 的协议认知成本较低，适合服务端已经稳定提供标准 TLS 的环境。它与 VLESS TLS 的性能差距通常小于线路质量和传输选择带来的差距。比较时应保持服务器位置、端口、传输方式和并发量一致。若一个配置走直接 TCP，另一个叠加 WebSocket 与中间转发，仅根据下载速度判断协议优劣没有意义。

Shadowsocks：轻量加密代理

Shadowsocks 常缩写为 SS，配置主要由地址、端口、密码和加密方法组成。它结构简洁，资源占用通常较低，对 TCP 与 UDP 都有成熟实现。加密方法必须与服务端完全一致，方法名称相近也不能互换。现代部署应使用客户端与服务端共同支持的 AEAD 类方法；旧式方法可能仍能被部分内核解析，但兼容性、安全属性和维护状态不能与现代方法等同。

SS 适合字段简单、跨客户端复用要求高的场景。它的订阅链接表达也相对紧凑，但不同生成器对用户信息编码、插件参数和备注字段可能采用不同写法。基础 SS 配置通常容易迁移，带额外插件参数的配置则必须确认目标客户端是否实现同一能力。v2rayN、v2rayNG 与 v2flyNG 能处理常见基础配置，但复杂扩展仍受各自内核和导入器限制。

REALITY：传输安全方案，不是独立代理协议

REALITY 经常与 VLESS 同时出现，因而容易被误称为独立协议。更准确的理解是：VLESS 负责代理协议与用户认证，REALITY 负责外层握手和服务端身份确认。客户端常见字段包括服务器名称、公钥、短标识、浏览器指纹模拟值，以及可选的 SpiderX。公钥来自服务端密钥对，短标识由服务端允许值决定，两者都不能在客户端自行生成后直接替换。服务器名称同样必须符合服务端配置。

REALITY 主要由 Xray 内核提供完整支持。导入配置时，即使界面识别出 VLESS，如果 REALITY 的 publicKey、shortId 或 fingerprint 被订阅转换器丢失，最终仍无法连接。排查时应展开配置详情逐项查看，不能只看列表中的协议标签。对于需要 V2Fly 内核的设备，应准备另外的兼容配置，而不是期待 V2Fly 自动忽略 REALITY 字段后继续工作。

// 03 · PERFORMANCE & RESOURCE

连接速度、吞吐与资源占用怎么比较

先区分握手速度和持续吞吐

“速度”至少包含连接建立时间、首字节时间、持续下载吞吐、上传吞吐和高并发稳定性。协议层较轻不代表所有指标都更快。一个新连接需要经历 DNS 查询、TCP 建连、TLS 或 REALITY 握手、代理协议认证以及目标站连接。跨地区链路中，网络往返时间往往远大于本地协议编码时间。短连接较多的网页访问更容易受到握手轮次影响，长时间文件传输则主要受线路带宽、丢包、拥塞控制和服务端处理能力影响。

比较 VMess、VLESS、Trojan 与 SS 时，应尽量使用同一服务器、同一路线、相近端口和相同传输层。测试前先关闭会改变路径的自定义路由，确认 DNS 解析结果一致。每种配置至少进行多轮交替测试，而不是先测完一种再测另一种，因为网络负载会随时间变化。结果应记录中位表现和异常次数，不要只保留最快的一次。若差异只有很小幅度，通常不足以证明协议本身更优。

传输封装经常比协议差异更明显

直接 TCP 的额外分帧较少，适合链路允许端到端稳定连接的场景。WebSocket 在数据外层加入 HTTP 升级与帧结构，便于接入理解 HTTP 的基础设施，但会增加头部与分帧成本。gRPC 基于 HTTP/2，具有流与连接管理能力，适合服务端和中间链路均正确支持 HTTP/2 的部署。HTTPUpgrade 与 WebSocket 的入口形式相近，但具体支持取决于内核和服务端。选型不能只看理论开销，还要确认整条链路是否会缓冲、限时或重置长连接。

多路复用试图让多个逻辑请求共享较少的底层连接。它可能减少频繁建连成本，也可能在丢包时让多个逻辑流同时等待，形成队头阻塞。网页小请求、即时通信和大文件传输对复用的反应不同。启用复用后若出现下载稳定但网页偶发卡顿，或者单个连接丢包时全部请求同时停顿，应关闭复用做对照，不要把现象直接归因于 VLESS 或 VMess。

CPU、内存与加密实现

资源占用由协议解析、加密算法、TLS 实现、传输分帧、日志级别和连接数量共同决定。VLESS 将数据加密交给外层，协议处理相对直接；Trojan 依赖 TLS；SS 使用配置指定的加密方法；VMess 有自己的协议结构。现代设备通常具备高效的加密实现，在普通浏览场景下，几种协议的 CPU 差异可能很难感知。低性能设备、高速传输或大量并发连接时，算法实现与内存复制次数才更容易成为瓶颈。

日志同样会影响资源。排错时使用详细日志有助于定位握手和路由，但长期保持调试级别会增加磁盘写入、内存缓冲和界面刷新。稳定后应恢复常规日志等级。路由规则数量也不是越少越快的简单关系：结构合理的域名集合和 IP 集合由内核高效匹配，真正应避免的是大量重复、冲突和顺序不清的自定义规则。

可复现的测试顺序

建议先用单个浏览器完成冷启动测试，记录首次打开与连续打开的差异；再进行持续传输，观察吞吐是否稳定；随后测试多个并发请求和 UDP 应用；最后恢复日常路由与 DNS 设置。每一步只改变一个变量。若从 VMess WebSocket TLS 一次改成 VLESS TCP REALITY，出现改善也无法确认来自协议、传输还是安全层。更可靠的方法是先保持传输与 TLS 不变比较 VMess 和 VLESS，再单独更换传输方式，最后比较安全层。

客户端界面的连接测试通常只验证远端是否能响应，不等于完整业务路径稳定。真实应用可能使用不同域名、IPv4 或 IPv6、UDP、长连接和并发请求。判断一个配置能否作为主配置，至少要覆盖网页访问、持续传输、休眠恢复和网络切换。测试结果若只在特定应用异常，应转向 DNS、路由或该应用的代理接入方式，而不是继续随机更换协议。

// 04 · MOBILE POWER

Android 连接的电量、后台与网络切换

耗电不只由协议名称决定

Android 上的代理客户端通常通过系统 VPN 服务接管流量，耗电来源包括持续运行的本地入口、加密与解密、DNS 处理、路由匹配、连接保活、日志写入以及网络频繁重连。屏幕关闭后，系统调度和后台限制会改变连接状态；从无线网络切换到移动网络时，原有 TCP 连接通常需要重建。因此，单看 VMess、VLESS 或 SS 的理论封装成本，无法准确预测整机电量表现。

v2rayNG 使用 Xray 内核，适合需要 VLESS、REALITY 和 Xray 路由能力的配置；v2flyNG 使用 v2fly 内核，可作为 V2Fly 生态配置的 Android 选择。两者的电量差异需要在相同配置、相同路由模式和相近日常行为下比较。若一边启用了全量日志、复杂 DNS 分流和持续探测，另一边只运行简单代理，结果不能归因于内核家族。

连接保活与频繁唤醒

保活用于维持连接和及时发现失效，但过短的保活间隔会频繁唤醒网络与处理器。即时通信需要稳定长连接，普通网页访问则可以容忍按需重连。客户端或服务端的空闲超时、中间网络设备的连接回收策略都会影响合适间隔。出现待机耗电明显时，应先检查是否有持续传输、详细日志或异常重连，再考虑调整保活，不建议把间隔盲目设为极短。

多路复用有时能减少底层连接数量，但单一长连接也可能被系统或网络回收。关闭复用后连接数量增加，握手次数可能上升；开启后若主连接频繁失效，又会造成成组重连。实际选择应观察一段完整的前台使用与待机周期。系统电量页面能显示应用活动趋势，但无法直接分辨协议开销，需要结合客户端日志中的重复连接、DNS 超时和网络切换记录判断。

路由范围和 DNS 对电量的影响

全局接管意味着更多应用流量进入内核，后台同步、媒体传输和系统服务都会增加处理量。分应用代理或合理的域名与 IP 分流可以减少不必要的转发，但规则过于复杂、频繁触发远程 DNS 查询也会增加开销。电量优化的重点不是追求最少规则，而是让本地流量、局域网访问和明确的直连目标不绕行，同时保证域名解析路径与最终出站一致。

DNS 配置不当会造成重复查询、超时后回退和连接重试，这类耗电常被误判为协议问题。若日志连续出现解析超时，应先确认当前网络能否访问所配置的 DNS、查询是否被路由到正确出站、IPv6 结果是否与实际网络能力匹配。只关闭 IPv6 并不是通用答案：具备稳定 IPv6 的网络可能因此多走一次回退，不具备完整 IPv6 路径的网络则可能因优先尝试无效地址而延迟。应依据当前网络实测。

协议与传输的实际选择

如果服务端同时提供多种方案，移动端可先选择字段完整、内核原生支持且连接恢复稳定的组合。VLESS REALITY 需要 v2rayNG 所用的 Xray 能力；基础 VMess、Trojan 或 SS 则有更宽的配置选择。传输方面，直接 TCP 通常结构较简单，WebSocket 与 gRPC 是否合适取决于服务端部署。某种传输在桌面宽带稳定，不代表移动网络切换时同样稳定，尤其要观察从后台恢复后是否需要手动重连。

出现高耗电时不要立即删除订阅。先复制配置并建立对照：关闭详细日志，减少非必要探测，保持协议与服务器不变，仅切换复用；再保持复用不变，仅比较传输；最后比较不同协议。每轮测试保持相似的屏幕时间和流量类型。若耗电伴随大量业务流量，它可能只是正常的数据处理成本；若几乎没有流量却持续活跃，才应重点排查循环重连、DNS 重试和后台应用不断发起请求。

// 05 · CORE FAMILIES

V2Fly 与 Xray 内核家族关系

共同基础与不同演进方向

V2Fly 与 Xray 都延续了 Project V 配置体系中的许多核心概念，包括入站、出站、路由、DNS、传输与策略对象。两者在 VMess、基础 VLESS、Shadowsocks、SOCKS、HTTP 等常见能力上存在较多交集，因此不少基础配置看起来相似。但它们是独立演进的内核家族，新功能、字段名称、默认行为和发布节奏并不要求完全同步。配置结构相似不代表任意配置都能直接互换。

Xray 在 VLESS、XTLS Vision、REALITY 等能力上形成了明确的组合路径。V2Fly 则围绕自身内核持续维护协议、传输、路由与平台能力。选择内核时不应只问哪个“更新”，而应问订阅中使用的功能属于哪一方、客户端是否暴露对应设置、服务端是否采用同一实现。协议越基础，跨内核兼容越容易；使用专属安全层、流控或实验字段时，兼容范围越窄。

三款图形客户端如何对应

桌面平台首推 v2rayN，它覆盖 Windows、macOS 与 Linux，并提供订阅管理、系统代理、路由规则和多种内核配置入口。Android 上，v2rayNG 以 Xray 内核为主，适合需要 VLESS、REALITY、Vision 等 Xray 能力的配置；v2flyNG 对应 V2Fly 内核，可用于服务端和订阅明确采用 V2Fly 兼容能力的场景。具体安装入口与平台要求可在获取客户端页面按系统选择。

客户端名称与内核名称不能混为一谈。v2rayN 是图形管理层，负责订阅、配置编辑、启动内核和系统代理；真正执行协议、传输和路由的是所选内核。相同 v2rayN 界面中，切换内核后可用字段和运行结果可能变化。排错时除客户端名称外，还应记录当前内核类型。只说“v2rayN 无法连接”信息不足，同一配置在不同内核下可能得出不同结果。

配置兼容的三个层次

第一层是语法兼容：JSON 能否被解析，字段类型和对象位置是否符合内核要求。第二层是功能兼容：字段虽然可读取，对应协议或传输是否真正实现。第三层是行为兼容：两边都实现同名功能，但默认值、回退规则或边界处理是否一致。订阅导入成功只证明图形客户端接受了输入，不代表内核一定能运行，更不代表服务端参数匹配。

例如一条 VLESS REALITY 配置可能以通用链接形式导入 v2flyNG，列表也显示地址和用户 ID，但如果目标内核不支持 REALITY，连接不会因此降级为普通 TLS。安全层不能静默替换，因为服务端期待的握手完全不同。正确处理方式是使用服务端另外提供的兼容配置，或在支持对应功能的 v2rayNG、v2rayN 与 Xray 内核中使用。

迁移内核前的验证方法

迁移前先导出或记录原配置的协议、传输、安全、路由和 DNS，不要只保存分享链接。然后查看目标内核是否支持每个关键字段，尤其是 flow、REALITY 公钥、短标识、传输服务名和自定义出站。迁移后先禁用复杂路由，用单一配置验证基础连接；再恢复 DNS；最后恢复分流。这样能区分是协议不兼容、DNS 行为差异还是规则标签发生变化。

内核切换后还应检查本地监听端口和系统代理。图形客户端可能为不同配置模式使用不同入口，旧的浏览器或应用代理设置仍指向原端口时，会表现为“内核启动成功但没有流量”。如果日志显示入站没有连接记录，应先检查应用是否进入本地入口；如果有入站但远端握手失败，再检查协议与安全字段。关于端口冲突可参考本地监听端口排查。

// 06 · TRANSPORT & SECURITY

传输方式、TLS、REALITY 与关键参数

TCP、WebSocket、gRPC 与 HTTPUpgrade

TCP 在客户端配置中通常表示直接以 TCP 承载协议数据，并不意味着没有 TLS。network 决定传输，security 决定外层安全，两者是独立字段。WebSocket 需要路径，部分部署还需要 Host；路径通常以斜杠开头，并且必须与服务端及中间转发规则一致。gRPC 使用 serviceName 标识服务，不应把 WebSocket 的 path 原样填入。HTTPUpgrade 同样涉及路径与 Host，但它和 WebSocket 是不同传输类型，服务端必须明确支持。

导入订阅后若地址、端口和用户 ID 正确，但日志出现 HTTP 状态错误、服务不存在或连接被立即关闭，应优先核对传输。常见问题包括路径末尾多出斜杠、serviceName 被转换器当作 path、Host 与服务器名称混用，以及中间转发只启用了 HTTP/1.1 或 HTTP/2 中的一种。客户端不能通过自动尝试猜出服务端实际部署，表单值必须准确。

TLS 的服务器名称与证书验证

TLS 配置中的 serverName 用于握手身份验证，常与证书中的域名对应。连接地址可以是域名或 IP，serverName 则应按服务端要求填写。allowInsecure 一类选项用于控制证书验证，正常配置应保持严格验证。遇到证书错误时，应检查设备时间、服务器名称、证书有效范围和证书链，而不是长期关闭验证。证书错误发生在代理认证之前，修改用户 ID 或密码不会解决。

ALPN 用于协商上层协议，常见值与 HTTP/2 或 HTTP/1.1 相关。只有服务端或中间基础设施有明确要求时才需要手动指定。随意添加 ALPN 可能让客户端协商出服务端未正确处理的协议。指纹模拟字段则影响 TLS 客户端握手特征，具体可选值由内核实现决定。订阅已提供该字段时通常应保留；手动编辑前先确认当前内核接受的名称。

REALITY 的四个关键字段

REALITY 配置最需要核对的是 serverName、publicKey、shortId 和 fingerprint。serverName 是握手中使用的服务器名称；publicKey 对应服务端密钥对中的公钥；shortId 必须是服务端允许的值；fingerprint 指定客户端握手指纹。任何一项缺失或字符错误都可能导致连接在早期失败。分享链接中这些字段常以 sni、pbk、sid、fp 等参数出现，导入后应在配置详情中确认它们没有被截断。

VLESS REALITY 常与 Vision 流控组合。此时客户端的 flow 与服务端必须一致，不能因为其他 VLESS 配置留空就删除。反过来，服务端未启用 Vision 时也不应擅自添加。REALITY 参数看似都属于“高级设置”，实际是连接必需信息。订阅转换、二维码识别或手工复制后出现问题时，先逐字符对照这些字段，比反复切换路由模式更有效。

路由配置示例与协议配置的边界

路由规则不负责建立远端协议连接，它只把已进入内核的请求分配到不同出站。下面示例展示常见的优先顺序：先阻断广告分类，再让私有地址和本地区域域名直连，其他请求落入默认代理出站。示例是可解析的 Xray/V2Ray 路由对象片段，实际使用时需要确保完整配置中存在名为 block、direct 和 proxy 的出站标签。

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "domain": ["geosite:category-ads-all"],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      }
    ]
  }
}

规则按内核配置语义匹配，冲突规则的顺序会影响结果。自定义规则前应确认客户端是否在生成最终配置时追加预设规则，因为界面中的顺序不一定等于最终 JSON 顺序。domainStrategy 决定何时把域名解析为 IP 以继续匹配 IP 规则，它会影响 DNS 查询数量和分流结果。关于 domain、ip、geosite 的具体写法与优先级，可继续阅读自定义路由规则语法详解。

// 07 · SUBSCRIPTION COMPATIBILITY

订阅格式、分享链接与字段兼容

订阅是一组配置的运输方式

订阅本身不是代理协议。它负责把服务器配置从提供端传递给客户端，内容可能是 Base64 编码的多行分享链接，也可能是客户端能够识别的结构化配置。常见分享链接以 vmess://、vless://、trojan:// 或 ss:// 开头。链接方案表示协议类型，查询参数继续表达传输、安全、服务器名称、路径、公钥等字段。客户端导入时需要完成解码、字段映射和内部配置生成。

Base64 只是编码，不代表内容经过加密，也不决定协议能力。同一个订阅地址可能随更新返回不同节点、备注或参数。客户端更新订阅时，通常会按分组替换或合并旧配置，因此手工修改订阅生成的条目可能在下次更新时被覆盖。需要长期保留本地调整时，应复制为独立配置，或使用客户端提供的订阅前置、后置处理能力，并记录修改原因。

分享链接字段为什么会丢失

字段丢失常发生在生成端、转换环节和客户端导入器对同一参数采用不同名称时。以 VLESS REALITY 为例，公钥可能写作 pbk，短标识可能写作 sid，服务器名称可能写作 sni，指纹可能写作 fp。导入器若只识别其中一套命名，列表仍能生成地址和用户 ID，但关键安全字段为空。VMess 的 JSON 分享内容也可能因旧字段、字符编码或备注中的特殊字符解析失败。

判断订阅问题时，可把“订阅获取”和“单条配置运行”分开。订阅地址无法更新，先检查地址是否完整、是否需要认证、系统时间和网络是否能访问提供端；订阅更新成功但某条配置不能运行，再检查该条目的协议字段。若手工导入原始分享链接可用，而通过订阅导入后不可用，说明问题更可能出在订阅内容或转换过程，而不是内核。

三款客户端的兼容判断

v2rayN 适合在桌面端集中管理 VMess、VLESS、Trojan、SS 等常见类型，并根据所选内核运行。v2rayNG 面向 Android 和 Xray 配置，对 VLESS REALITY 等 Xray 能力更合适。v2flyNG 使用 V2Fly 内核，适合订阅明确提供 V2Fly 可运行配置的情况。三款客户端都可能识别基础分享链接，但“识别链接”与“支持链接中的全部功能”必须分开判断。

跨设备共用订阅时，最稳妥的做法是让订阅同时提供基础兼容配置与需要专用内核的配置，并用清晰备注区分。若所有条目都依赖 REALITY，v2flyNG 端不会自动获得可用替代项。反之，只使用基础 VMess 或 SS 时，跨内核迁移通常更简单，但仍要核对传输扩展、UDP 和加密方法。完整导入步骤见v2rayN 与 v2rayNG 订阅链接导入教程。

更新订阅的安全操作顺序

更新前记录当前正在使用的条目和路由模式，重要的手工配置先复制到非订阅分组。更新后不要立刻删除旧分组，先检查条目数量是否合理、备注是否变化、当前配置是否仍被选中，再进行连接测试。若更新后全部条目异常，可回到旧配置判断是订阅内容变化还是本地网络问题。只在单条异常时，应对比更新前后的地址、端口、协议、安全和传输字段。

二维码导入也属于分享链接解析。二维码画面清晰并不保证内容完整，截图裁切、缩放和长链接容量都可能影响识别。识别后应查看配置详情，不要以弹出“导入成功”作为最终验证。若订阅或分享链接包含敏感连接信息，应按访问凭据管理，不在公开页面或日志截图中展示完整内容。提交问题时可保留协议类型和字段名称，但应遮盖地址、用户 ID、密码与密钥参数。

// 08 · SCENARIO CHOICE

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

已有服务端：保持匹配优先

如果配置来自现有服务端或订阅，选择空间由服务端决定。客户端应原样使用协议、传输和安全参数，不要把 VLESS 改成 VMess，也不要把 WebSocket 改成 TCP。桌面端优先使用 v2rayN，根据配置选择能够完整支持字段的内核；Android 端遇到 VLESS REALITY、Vision 等 Xray 能力时使用 v2rayNG，明确采用 V2Fly 兼容配置时可使用 v2flyNG。稳定运行比追求协议名称更新更重要。

同一订阅有多条不同协议时，可先排除字段不完整和内核不匹配的条目，再比较实际链路。VMess 适合延续成熟部署；VLESS 适合与现代 TLS 或 REALITY 组合；Trojan 适合标准 TLS 参数清晰的部署；SS 适合基础字段简洁、需要良好 UDP 支持的情况。最终选择应依据稳定性、恢复速度和日常应用表现，而不是列表排序或名称印象。

多平台共用：兼容面优先

需要在 Windows、macOS、Android 与 Linux 之间共用配置时，应先确认各端客户端都能完整导入。基础 VMess、Trojan 和 SS 通常更容易跨环境表达，基础 VLESS TLS 也有较广支持；加入 REALITY、Vision 或特定传输扩展后，要逐端确认内核。多平台方案可以保留一条功能较新的主配置，再准备一条字段简单的兼容配置，避免某台设备因内核差异完全无法连接。

订阅备注应包含可读的协议和用途信息，例如区分 Xray 专用与基础兼容，而不是依赖客户端自动识别后再猜测。更新订阅时先在一台设备验证，确认字段和分组正常后再更新其他设备。这样能降低订阅生成端字段变化同时影响全部设备的风险。设备之间不必强求使用同一客户端，但应记录各端内核和配置对应关系。

低资源与移动使用：减少额外工作

低性能设备或重视待机电量时，优先选择内核原生支持、传输层简单且无需复杂转换的配置。SS 结构简洁，VLESS 协议层开销较低，但最终资源使用仍取决于外层安全、连接数量、DNS 和路由。直接 TCP 往往比叠加多层 HTTP 语义更简单，不过服务端部署条件必须允许。不要为节省少量协议处理而关闭必要的身份验证或证书检查。

Android 上先减少调试日志、无效 DNS 重试和过短保活，再比较协议。若待机后频繁断线，应检查后台限制和网络切换，而不是只换加密方法。需要 UDP 的应用还要确认服务端、协议、传输和客户端入口都支持 UDP，任何一层缺失都会导致部分功能异常。TCP 网页正常不能证明 UDP 路径正常。

复杂路由：内核与规则能力优先

需要按域名、IP、应用或协议类型精细分流时，客户端的规则生成方式与内核能力比代理协议更重要。v2rayN 适合桌面端维护较复杂的路由；v2rayNG 可在 Android 上配合 Xray 规则。设计规则时先确定 direct、proxy、block 三类出站，再按高优先级例外、私有网络、区域集合和默认路径组织。规则越多越需要明确顺序和 DNS 策略。

路由异常的典型表现是只有部分域名无法访问、局域网设备不可达、解析结果与连接出站不一致。此时切换 VMess 与 VLESS通常不会解决。应临时使用简单路由验证基础协议，再逐组恢复规则。DNS 泄漏、远程解析和本地解析属于 DNS 与路由设计问题，可参考DNS 检测与客户端配置实操继续排查。

最终决策清单

1. 确认服务端：记录协议、地址、端口、传输、安全层和全部认证字段，客户端不得单方面改型。
2. 确认内核：REALITY 与 Vision 优先核对 Xray 支持；V2Fly 配置在 v2flyNG 或对应桌面内核中验证。
3. 确认订阅：检查导入后的 flow、sni、publicKey、shortId、fingerprint、path 与 serviceName 是否完整。
4. 建立基线：先用简单路由和常规 DNS 验证连接，再恢复分流、复用与高级选项。
5. 按场景测试：分别观察短连接、持续传输、UDP、休眠恢复、网络切换和多设备导入。
6. 保留回退：复制已验证配置，协议迁移、内核切换和订阅更新不要同时进行。

如果仍无法判断，桌面端可从 v2rayN 与服务端原始配置开始，Android 端按内核能力在 v2rayNG 和 v2flyNG 之间选择。出现错误后先定位层级：本地入口无流量查系统代理与端口；远端握手失败查协议和安全字段；仅部分域名异常查路由与 DNS；订阅更新后异常则对比更新前后的字段。按这个顺序处理，通常比连续更换协议更快找到原因。