V2Ray 协议与内核
选型参考手册

配置分层：协议不是整条连接

先把一条配置拆成四层

客户端里常见的协议名称，只描述连接链条的一部分。应用先把请求交给本地代理入口，内核根据路由决定出站，再用代理协议封装目标地址和认证信息，最后通过选定的传输方式连接远端。安全层负责保护这段传输。于是，VLESS、TCP、TLS 可以同时出现在一条配置中，它们并不冲突，也不能放在同一列里互相替代。判断配置是否兼容，必须把这几层一起看，而不是只看列表里的协议标签。

本地入口和远端协议也要分开。浏览器连接本机的 HTTP 或 SOCKS 端口，不代表远端服务器也使用相同协议。系统代理通常只是告诉遵循系统设置的应用，把请求送到本地入口；它并不自动接管所有程序。虚拟网卡模式则在更靠近网络层的位置接收流量，覆盖范围、权限要求与 DNS 处理都不同。遇到某个应用不能访问，先确认请求是否进入内核，再判断远端协议，能少走很多弯路。

传输方式与安全层各管什么

TCP 提供可靠的字节流；WebSocket 在连接建立时增加 HTTP 升级过程；gRPC 基于 HTTP/2 的机制组织传输。它们改变连接的建立方式和中间设施的适配条件，但不会自动替换用户认证协议。路径、服务名和请求头通常属于传输设置，不是密码。客户端选择了 WebSocket，服务器却按普通 TCP 接收，即使地址、端口和用户标识都正确，也不能靠反复重试修好。应当先把两端的传输类型对齐。

TLS 负责认证服务端并保护传输，证书名称、服务器名称指示与证书信任链都参与其中。REALITY 则是另一种安全层机制，具体支持范围依赖内核。二者不是在所有字段上都能直接互换。看到服务名称里带有 TLS，也不能推断配置已经启用了正确的安全层；界面中的开关、实际导出的字段和运行日志才是依据。代理地址可以是 IP，而验证使用域名，这两个字段承担不同职责，不应为了看起来一致而强行改成同一个值。

用分层方法定位问题

拿到一份配置，建议按固定顺序记录：连接地址与端口、协议与认证、传输类型、安全层、额外流控设置。随后再看路由、DNS 和本地代理模式。前一组决定能否正确建立远端连接，后一组决定哪些请求使用这条连接，以及域名在哪里解析。把所有选项同时修改，可能偶然恢复访问，却无法知道是哪一步生效；下一次更新订阅，问题还会回来。一次只调整一层，并保存原始配置，结果更容易复现。

日志也可以按层阅读。连接被拒绝通常先看地址、端口与服务端监听；握手失败先看安全层和传输；认证失败再核对用户信息。这里的“先看”不是绝对归因，服务端主动关闭也可能表现为连接中断。应把同一时间的错误与当前配置对应起来，避免把后台其他请求的报错当成这条连接的结论。更完整的关键词解释见Xray 内核运行日志定位笔记。

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

VMess 为什么把更多能力放进协议

VMess 是 Project V 早期的重要协议，把用户认证与数据保护等能力纳入协议设计，便于在不同传输环境中建立代理连接。它不是简单地给原始请求添加一个密码字段，握手和数据封装都有自己的规则。因此，客户端与服务端必须理解同一套协议机制。VMess 的实际开销取决于加密实现、处理器能力、外层传输及连接复用，不能只凭“协议较早出现”就判定它一定更慢，更不能从协议名称推导一条线路的可用带宽。

现代 VMess 配置通常使用 AEAD 认证机制。旧教程里反复出现的额外标识参数，属于历史兼容背景，不适合拿来作为今天的调优旋钮。导入旧链接后，如果客户端提示格式过时或认证失败，应先向配置提供方确认当前格式，而不是随机尝试额外标识。VMess 对时间同步也有要求；设备日期、时区显示与实际系统时间需要区分，真正影响认证的是时间本身是否准确。先修正系统时间，再观察日志，比更换加密选项更有意义。

VLESS 把哪些工作交给外层

VLESS 的设计强调较轻的协议结构，不在协议内部承担与 VMess 相同的数据加密职责，而是配合外部安全层使用。用户标识用于认证，但它本身不是保护传输内容的完整方案。这解释了为什么常见配置会把 VLESS 与 TLS 或 REALITY 一起列出。选择 VLESS 不意味着可以省略安全设置；当客户端里出现“不加密”一类协议字段时，要理解它说的是这一层，不代表整条连接应该以明文穿过不可信网络。

UUID 是常见的用户标识表示方式，导入时应完整保留，不要混入空格、换行或全角符号。客户端可以生成新的标识，但本地重新生成并不会同步修改服务器。用户认证必须与服务器记录一致。另一个容易混淆的字段是流控：它不是全局加速开关，也不是所有 VLESS 组合都需要填写。只有服务器明确提供了对应配置，且当前内核与传输组合支持时，才应照原值使用；不清楚时保留导入结果，不自行拼接流控名称。

两者之间如何做实际选择

已有稳定 VMess 配置时，迁移的理由应当是明确的兼容需求、服务端维护方案或实际测得的问题，而不是看到另一个协议更常被讨论。客户端支持某种协议，只说明它能处理这类配置，并不说明配置提供方已经部署了对应服务。反过来，拿到 VLESS 配置时也不必寻找 VMess 中的每个字段：不同协议的认证和封装结构不同，参数缺少并不一定是导入失败。应对照同一协议的字段说明，而不是逐项补齐另一套界面。

在 v2rayN 中核对时，先打开服务器编辑窗口，确认协议类型，再看传输、安全层和流控；在 v2rayNG 中同样按这个顺序检查。界面标签可能随客户端更新调整，判断依据应是字段含义。若更换内核后突然不能连接，要记录切换前后的内核名称和错误，而不是把 UUID 删除重建。需要回退时恢复整条已知可用配置，保留一个清晰对照，比在同一条记录上连续修改更容易判断差异。

安全层和传输设置正确之后，才值得比较资源占用。短网页请求可能主要花时间在域名解析和握手，持续下载则更受带宽、拥塞与加密吞吐影响。两种负载得出的结论可以不同。对普通用户，优先选择提供方持续维护、客户端完整识别且不需要手工补字段的组合。协议选型的目标是减少配置歧义，而不是为每条记录追求一个看起来最简短或最新的名称。

Trojan 与 SS：密码之外还有哪些条件

Trojan 依赖完整的 TLS 配置

Trojan 的典型设计把认证和代理请求放在 TLS 连接之内，让成熟的 TLS 实现承担传输保护。客户端通常需要服务器地址、端口、密码和服务器名称，但“字段少”不代表验证链条简单。证书是否覆盖对应名称、是否在有效期内、服务端是否提供了完整证书链，都会影响连接。密码正确但证书验证失败时，问题并不在密码层。应先区分安全连接没有建成，还是连接建成后认证未通过，再决定该检查哪一项。

服务器地址与服务器名称指示可以不同。前者决定连接到哪里，后者参与 TLS 握手和证书名称验证。配置提供方给出 IP 地址和一个域名时，不能因为浏览器里访问该 IP 没有熟悉的页面，就认定代理配置有误。代理监听服务的响应方式和普通网站并不完全一致。正确做法是保留原始字段，通过客户端日志观察握手结果，并向提供方确认服务端要求的名称，而不是随便填一个常见域名。

不建议把跳过证书验证当成常规修复手段。这样会削弱对服务端身份的确认，也可能掩盖系统时间错误、名称填错或服务端证书部署不完整。若只在某一台设备上失败，先比较系统时间和信任环境；若所有设备同样失败，则优先确认服务端设置。握手过程中还可能涉及应用层协议协商，客户端与服务器对其有明确要求时，应照配置填写，不能为了“选项越多越兼容”而把所有值都加入。

Shadowsocks 的方法和密钥必须配套

Shadowsocks 常在界面中缩写为 SS，设计上以较紧凑的加密代理机制处理流量。实际兼容性不仅取决于密码，还取决于加密方法与协议代际。传统 AEAD 方法和较新的方法可能在密钥格式、身份处理及内核支持上存在差异。选择一个同名方法并填入任意文本，不一定能得到有效配置。应把提供方给出的加密方法和密钥视为一组完整参数，不能只复制密码后再按个人偏好修改方法。

一些较新的方法要求特定长度和编码的密钥，而不是普通口令；客户端显示的“密码”只是统一界面标签，不保证底层接受任意字符串。导入失败时先看是否被聊天工具截断、特殊字符是否被转义，以及当前内核是否实现该方法。自行删掉末尾符号、替换字符或重新编码，都可能把原本正确的密钥改坏。客户端能保存一条记录，也不等于内核一定接受它，启动时的配置检查结果更有参考价值。

插件、传输与协议能力不能混算

看到 SS 分享链接附带插件参数时，要额外确认当前客户端能否识别和执行这套插件机制。内核原生支持某种加密方法，与客户端能够调用某个外部插件，是两回事。本手册不建议通过不断更换插件来试错。先问清提供方需要的是原生协议连接，还是带特定封装的组合；如果客户端不具备对应能力，应选择双方共同支持的配置，而不是把插件名称塞进传输路径字段。字段名称相似，并不意味着作用相同。

两者的实际使用边界也不相同。TCP 网页访问正常，不能顺带证明 UDP 应用同样可用；UDP 转发还受服务端能力、路由和本地入口影响。选型时可先用常见网页验证基础连接，再针对需要的应用单独测试。若需求只是稳定访问日常服务，优先保留一套参数来源清晰的配置。若必须兼顾特定应用的网络行为，则把 UDP、域名解析和系统接管范围列为检查项，不要把所有差异都归结为协议速度。

REALITY：安全层与参数的对应关系

REALITY 不是另一个代理协议按钮

REALITY 常与 VLESS 一起出现，但两者解决的问题不同。VLESS 组织代理认证与请求，REALITY 处理其外层安全握手机制。它基于 TLS 相关机制进行设计，并引入自己的认证与握手处理，不等同于普通网站的证书部署方式。理解这一点后，就不会把“服务器类型 VLESS”和“安全层 REALITY”当成重复设置。也不能在其他协议配置里直接把安全选项切成 REALITY，期待服务端自动接受；具体组合必须由两端实现共同支持。

常见的 REALITY 客户端配置包含连接地址、服务器名称、公钥参数、短标识和客户端指纹等信息，此外还可能带有流控要求。每项都与服务端设置有对应关系。公钥参数用于客户端侧的认证计算，不是让用户填写服务器私钥的地方；服务端私钥不应被放进订阅或分享链接。不同版本界面的命名可能调整，核对时应看字段用途和提供方说明，不能只凭“密钥”两个字就把一段内容粘贴到所有相关输入框。

服务器名称、公钥与短标识

服务器名称参与握手，必须符合服务端允许的配置。它既不是随意填写的备注，也不一定等于实际连接地址。服务端还会配置握手目标等内容，这些服务器侧细节不能由客户端单方面更改。用户拿到一份完整配置后，只需确认客户端正确保留了必要字段；不要根据名称猜测目标网站，再自行替换为另一个域名。即使替换后的域名可以正常打开，也不能说明它与当前 REALITY 服务端的配置匹配。

短标识通常以十六进制文本表示，需要满足服务端与实现的格式要求。空值是否允许，也取决于服务端配置，不能一概认为为空就是缺失。手动输入时要注意字符是否合法以及长度是否符合要求，避免混入空格和全角字符。公钥也应原样导入，不应被编辑器自动折行后连同换行一起保存。若订阅更新前能用、更新后失效，先比较这类认证字段是否变化，再看本地是否仍保留了旧的手动覆盖设置。

指纹、流控与排错顺序

客户端指纹通常通过内核提供的握手实现选项生效。某个界面能显示一长串名称，不代表正在调用的内核全部支持。遇到“不支持的指纹”或相关初始化错误，先检查实际内核和配置来源。流控同样需要单独看待，它不是 REALITY 的别名，也不能只要启用 REALITY 就随意填写。常见组合有自己的适用范围，尤其在更换传输类型时，应重新确认流控是否仍然成立，不要把上一条配置的高级选项整体复制过去。

排查时可以分成三个阶段。第一阶段确认网络能连接到给定地址和端口；第二阶段看安全握手能否完成，核对名称、公钥、短标识和指纹；第三阶段再看用户认证、流控以及实际代理请求。日志里同一个握手错误可能对应多个原因，不应仅凭一句报错就断言公钥错误。先确认本地没有使用另一个订阅分组中的同名记录，再确认修改后内核确实重新加载了配置，最后把错误时间与连接尝试对应起来。

选用 REALITY 的前提是提供方维护这套配置，当前客户端也能完整导入。它不需要用户把普通 TLS 的每项证书选项照搬过来，更不意味着可以跳过对参数来源的确认。使用 v2rayN 或 v2rayNG 时，优先保留正常解析后的原值；如果导入工具不认识安全层，不要退回普通 TLS 来凑齐界面。应先处理客户端与内核兼容性，再讨论是否切换到双方都支持的另一套配置。

V2Fly 与 Xray：客户端背后的执行边界

图形界面和代理内核不是同一个项目

Project V 是理解这套生态的起点，V2Fly 社区延续了 V2Ray 核心的开发与维护，Xray 则由相关代码基础分支演进，逐步形成自己的能力与配置细节。共同来源让两者在基础概念和不少配置结构上相似，但并不保证新增功能始终同步。不能把它们理解成两个下载地址不同、功能完全相同的文件，也不能仅凭某个界面写着“V2Ray”就判断实际运行的是哪一个内核。运行状态与日志里的内核标识更可靠。

v2rayN 是桌面端首推的图形客户端，负责服务器记录、订阅管理、代理模式和内核调度等工作；具体协议连接由被调用的内核执行。v2rayNG 是 Android 上常用的 Xray 内核客户端，v2flyNG 则面向 V2Fly 内核使用需求。三款客户端并不是三种代理协议。移动端通常也不能像桌面上切换程序路径那样，任意把另一套内核文件塞进应用后就得到相同功能，仍应按客户端自身的构建与支持范围选择。

共同结构不代表配置可以任意互换

两套内核都能见到入站、出站、路由和 DNS 等概念，部分基础字段也接近，因此简单配置可能具有一定迁移空间。但涉及 REALITY、特定流控、新传输实现或扩展参数时，必须查当前内核的支持情况。尤其不能把“可以读取 JSON”理解成“理解 JSON 里的每个选项”。有的差异会在启动时直接报错，有的会被客户端转换，还有的可能直到发起连接才暴露。保存成功只是第一步，不是兼容结论。

同样需要注意客户端层的转换。图形客户端经常保存自己的内部记录，再在启动时生成内核配置；用户看到的订阅字段不一定原封不动地进入最终文件。自定义配置模式又可能绕过部分图形界面的路由和 DNS 生成逻辑。因此，修改了界面选项却发现行为没变，应先确认这条记录是否使用自定义配置，以及该模式是否采纳全局设置。不要继续叠加同类开关，否则只会增加无法生效的设置。

迁移时保留可以比较的基线

切换内核之前，先保存已知可用的客户端设置，记录协议、传输、安全层、DNS 和路由模式。第一次启动新内核时，优先使用简单且双方明确支持的配置，确认基础连接后再恢复自定义路由。若一开始就同时迁移复杂规则、实验性传输和多个高级字段，失败时很难分清原因。也不要把内核启动失败误判成远端服务异常：配置语法或不支持的参数可能让内核根本没有进入监听状态。

版本能力需要结合实际安装环境确认，但不必为了比较而编造一张永久有效的支持表。客户端更新、内核更新和订阅格式更新是三条不同的时间线。某个选项在新版内核里存在，不代表当前客户端已经提供导入支持；反过来，客户端提前展示某个字段，也不保证当前执行文件已经实现它。遇到边界差异时，给出客户端名称、实际内核名称、协议组合与错误摘要，比只说“最新版不能用”更容易定位。

日常选型可以保持简单：桌面先用 v2rayN，Android 按配置要求选 v2rayNG 或 v2flyNG；不要为了名字相近就跨内核搬运高级配置。开源意味着代码与维护过程具有可研究性，但不意味着任何分支都会保持所有行为相同。需要进一步理解项目关系，可以读Project V、V2Fly 与 Xray 生态梳理；需要比较平台操作差异，则查看三款客户端对比。

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

把“快”拆成不同阶段

连接速度至少包含几件事：域名解析花多久、到服务器的连接建立多久、安全握手多久、首个响应何时回来，以及持续传输能够达到什么吞吐。协议主要影响其中一部分，线路和服务器往往影响更大。打开一个网页很快，不代表持续下载一定快；下载吞吐较高，也不代表每次短连接都响应迅速。比较两种协议时，先说明测的是哪个阶段，避免把不同指标揉成一个“延迟”数字，然后得出过于简单的结论。

想得到可解释的结果，应尽量固定设备、网络、服务端位置、访问目标和测试时段。测试前暂停订阅自动更新、后台大文件传输和频繁健康检查，保留相同路由模式与 DNS 策略。随后交替测试两套配置，而不是上午测一条、晚上测另一条。每次观察首个请求和后续请求的差别，因为连接复用、域名缓存和 TLS 会话恢复都可能改变后续表现。这里只需要记录趋势，不必追求看起来精确却无法复现的小数。

CPU、内存和复用并非越低越好

加密计算、数据复制、传输封装和连接数量都会消耗资源。处理器是否具备相应硬件加速，可能比某个协议的头部大小更重要。外层已经使用 TLS 时，内层是否还有额外加密也会影响工作量，但不能因此随意关闭协议要求的保护。内存则可能随活动连接、缓冲区、DNS 缓存与规则集增长。看到进程占用短时上升，应先观察连接结束后是否回落，不要把正常缓存直接当作泄漏，更不能只看空闲截图比较内核优劣。

连接复用可以减少重复建立连接的开销，但也可能让多个请求共享同一连接的拥塞和故障影响。开启后是否更快，取决于实现、传输方式与应用负载，不存在对所有配置都成立的最佳开关。某些流控或传输组合还可能限制复用的使用方式。对于原本稳定的配置，建议先保留默认值；只有在可重复的短连接问题上做单项对照。不能把复用、并发、缓冲区同时调大，再把短时变化归功于其中某一项。

安卓耗电通常不只由协议决定

移动网络的电量消耗与无线电活跃时间关系很大。频繁保活、反复重连、持续探测和后台应用的小请求，可能不断唤醒网络，即使每次传输内容很少也会耗电。屏幕关闭后，系统后台限制又可能让进程休眠，恢复时产生重连。因而，某协议在一次长下载中占用较低，不保证待机整夜也更省电。判断时应分别观察屏幕开启使用和屏幕关闭待机，保持应用使用习惯与网络类型接近，避免把场景差异算到协议头上。

虚拟网卡接管范围、应用分流和 DNS 查询也会改变移动端负载。全量接管时，更多后台流量可能经过内核；按应用或规则分流后，路径和查询数量都会变化。路由规则太宽或 DNS 反复失败，可能带来额外请求和重试。电量异常时，先看是否存在连续错误、频繁切网和过密的连通性检查，再检查协议。不要仅为降低后台耗电就禁止客户端所有后台运行，否则可能造成系统保留代理入口、实际连接却已停止的状态。

可操作的顺序是：先稳定配置，再停掉不必要的高频测试，检查后台运行权限，最后比较不同协议组合。每次至少覆盖一段正常使用与一段待机，并观察是否伴随断连重试。若只有某个应用耗电明显，继续检查该应用本身的后台行为，而不是立刻更换内核。若连接正常但网页打不开，先按已连接却无法浏览的逐项清单检查；不可达导致的持续重试，本身就可能让耗电判断失真。

订阅格式：导入成功之后还要核对什么

分享链接、订阅列表与完整配置

单条分享链接主要描述一条服务器记录，订阅地址则通常返回一组记录或客户端可识别的内容。完整内核配置又是另一种形态，可能同时定义本地入站、多个出站、DNS 和路由。三者不是同一种文件改个后缀就能互换。客户端的“从剪贴板导入”和“添加订阅地址”处理的对象也不同：把订阅网址当成单条服务器链接，可能只得到无法识别的提示；把整段内核 JSON 放进订阅地址栏，也不会自动变成在线订阅。

不同协议的分享链接对字段编码方式不完全相同，部分还存在历史格式差异。备注中的中文、特殊符号和空格通常需要正确编码；一些内容会使用 Base64 表示，但这种编码不是对订阅内容的保密保护。链接能被复制粘贴，不代表经过聊天工具转发后仍然完整。发现导入数量异常时，先从原始来源重新复制，确认没有混入解释文字、换行或尾部标点，再看客户端的解析提示，不要急着把内容交给陌生转换工具。

记录数量相同不代表字段完整

较新的安全层、流控或传输参数，可能在旧的导入逻辑中被忽略。结果是客户端显示了服务器名称、地址和端口，列表看起来正常，但关键字段没有保存。对 REALITY 等组合，导入后至少抽查一条：协议类型、安全层、服务器名称、公钥参数、短标识和流控是否符合原始说明。对 WebSocket 或 gRPC，则重点看路径、请求头或服务名。不能只看列表里出现了多少条，就认定整个订阅格式已经兼容。

不同客户端对订阅更新、重复记录和手动修改的处理也可能不同。某些手动更改会在下次更新时被覆盖，某些覆盖设置又可能持续作用于新记录。维护时最好把订阅来源分组与本地试验配置分开，试验先复制记录，再做单项修改。不要把同一条订阅记录当成长期手写配置编辑，否则提供方更新服务器参数后，本地覆盖与新数据混在一起，很难看出究竟哪一个字段来自哪里。

路由配置不会自动跟着服务器记录走

从一个客户端迁移到另一个客户端时，服务器记录可以导入，不代表原来的 DNS、路由、应用分流和代理模式也会一起迁移。基础连接成功后，还要重新核对默认出站与域名处理方式。下面的片段是常见内核配置中的路由结构示意，只把环回地址交给名为 direct 的出站；它不是完整配置，不能单独启动，完整文件中必须已经定义对应出站标签。这样的短片段适合说明字段关系，不适合直接覆盖客户端生成的整个配置文件。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": ["127.0.0.0/8", "::1/128"],
        "outboundTag": "direct"
      }
    ]
  }
}

AsIs 表示路由判断不因该策略主动把域名转换成 IP；它并不等于整个客户端停止 DNS 查询，也不等于请求永远不会解析。其他域名策略会在不同条件下参与解析和 IP 规则判断，具体行为应结合内核与 DNS 配置理解。迁移时如果路由结果变化，先确认请求进入内核时携带的是域名还是 IP，再检查域名规则、IP 规则和最终默认出站，避免仅凭选项名称推断实际路径。

订阅更新失败与服务器不可用也要分开。前者发生在获取和解析配置的阶段，后者发生在实际连接阶段；旧记录仍能使用时，不应因为一次更新失败就删除整个分组。先看更新请求是否成功、响应内容是否为有效订阅，再核对格式。空列表等常见情况可到FAQ查阅；需要处理解析与分流配合时，继续阅读V2Ray DNS 分流解析设置，不要用随机换协议来绕过配置来源问题。

按使用场景选型：从需求回到配置

桌面与移动端先确认共同能力

桌面使用先选 v2rayN，再根据操作系统和处理器架构进入下载页选择对应入口。客户端安装完成后，优先使用配置提供方明确支持的协议组合，不必为了“功能齐全”启用所有高级设置。已有稳定的 VMess、Trojan 或 SS 配置，可以先沿用；拿到 VLESS 与 REALITY 组合时，先确认实际内核和导入字段。选型的第一目标是让客户端、内核和服务端处在同一能力交集里，第二目标才是优化某个场景的资源开销。

Android 上，如果配置依赖 Xray 的相应能力，优先核对 v2rayNG；如果明确使用 V2Fly 配置与维护路径，再考虑 v2flyNG。不要把两款应用同时开启后比较，因为系统 VPN 接管可能互相影响，测试结果会混入应用切换和连接恢复。对后台使用，先确保系统权限与电池管理允许预期的运行方式，再比较协议。对按应用分流的需求，要另外检查选择范围，确认浏览器测试流量与目标应用确实走了相同路径。

按负载测试，而不是按名字排名

日常网页与消息应用以短请求为主，重点观察解析、连接建立和休眠恢复；持续下载更看重稳定吞吐、设备发热与长连接保持；需要 UDP 的应用则必须单独验证对应通路。每种场景都应先用已知可用的基础配置建立基线，再比较另一种组合。如果两套配置来自不同服务器，结果只能说明这两套服务的综合表现，不能证明某协议天然更优。若服务端无法提供一致条件，就把兼容性和维护质量放在速度排名之前。

多设备使用时，所谓同步配置通常是让不同客户端订阅同一来源，而不是把整份桌面配置直接复制到手机。各端的本地端口、系统接管方式、应用分流和后台权限仍需分别设置。可以统一服务器来源和分组命名，但不要同步不适合该设备的系统代理参数。迁移完成后，应各自检查一次网页请求、必要的 UDP 应用和 DNS 行为，确保“同一个订阅”没有被误解成“所有设备的网络行为都相同”。

建立一套能回退的核对流程

实际操作可以固定为四轮。第一轮只核对来源和字段，确认链接完整、认证参数对应、传输与安全层匹配。第二轮确认客户端调用正确内核，查看启动是否成功，以及本地入口是否正常工作。第三轮验证基础访问，保持简单路由，不同时改 DNS 和代理模式。第四轮才恢复应用分流、自定义规则与可选优化。每轮保留一个已知可用状态，出现问题就回到上一轮，避免把后续优化造成的差异误认为协议本身不能用。

遇到失败时，还要判断错误发生在本地还是远端。内核启动报错、端口占用和系统代理残留，属于本地运行环境；连接超时、握手失败和认证拒绝，才继续沿网络与服务器方向检查。若网页可以打开但解析路径不符合预期，问题可能在 DNS 和路由，而非协议认证。可以结合DNS 泄漏检测与配置实操理解查询路径；检测结果需要放回当前网络和客户端模式解释，不能只凭一个页面的显示作完整结论。

最后，保留简短的维护记录即可：客户端与内核名称、协议和传输组合、特殊安全字段是否齐全、使用的路由模式，以及上一次确认可用的环境。记录问题时隐藏认证信息，只留下足够定位的结构和错误摘要。配置提供方调整参数后，先更新订阅并抽查，再处理本地覆盖。协议手册负责解释这些判断依据；需要重新走一遍导入与连接步骤时，回到快速上手教程，按单一主线操作，不必在所有高级设置之间来回试探。