V2Ray 协议与内核参考

一、先把配置拆成四层

客户端中看到的一条服务器配置，通常同时包含代理协议、底层传输、安全层和本地接入方式。它们解决不同的问题，不能只凭列表里显示的协议名称推断全部能力。代理协议负责客户端与服务端之间如何认证、表达目标地址和转发数据；传输负责这些数据通过怎样的连接承载；安全层负责连接的加密与身份验证；本地接入决定哪些应用的请求能够进入客户端。排查时先分层，才能知道应该修改哪一处。

协议类型不是连接方案的全部

以 VLESS 为例，名称只说明代理协议，并没有说明是否使用 TLS、是否使用 REALITY、采用哪种传输，也没有说明服务端是否要求特定流控。同样写着 VLESS 的两条配置，可能需要不同内核功能。VMess 也可能搭配不同传输，Shadowsocks 则需要进一步核对加密方法。编辑服务器时，应先确认协议类型，再对照地址、端口与认证字段，最后检查传输和安全设置。不要在协议下拉框里随意改名，客户端不会据此把远端服务转换成另一种协议。

地址和服务器名称也不是同一字段。服务器地址决定连接到哪里，通常是域名或地址；TLS 的服务器名称用于握手时的名称声明，并参与证书身份核对。二者可以相同，也可能按部署要求分别填写。把服务器地址换成数字地址后，直接清空服务器名称，容易造成原来正常的证书验证失败。端口则是远端监听入口，不应与本地监听端口混淆。客户端里的本地端口供本机应用连接，修改它不会改变远端服务的监听位置。

本地接入与远端协议分别检查

v2rayN 的系统代理用于告诉遵循系统代理设置的应用，把请求交给本地客户端。它不等于远端协议，也不保证所有程序都按这一设置运行。TUN 模式属于另一种接入路径，通常涉及虚拟网络接口、权限和路由处理。Android 客户端通过系统 VPN 授权建立接入路径，但界面中的 VPN 图标只说明本地服务已建立，不能单独证明远端认证成功。应再查看日志，并用实际应用验证连接。

路由分流位于请求进入客户端之后。规则可以决定某个域名、地址或端口使用代理、直连或阻断出站，却不能修复服务器密码错误。DNS 则可能在应用、系统、本地客户端或远端链路中的不同位置发生，具体取决于接入和解析设置。出现部分域名打不开时，应先分清是解析失败、分流到了错误出站，还是远端连接失败。直接把所有协议都换一遍，只会让原始条件难以复现。

建立一份可复查的参数记录

实际核对时，可记录协议、地址、端口、传输、安全层、服务器名称和内核这几类非敏感信息，再注明当前使用系统代理还是其他接入方式。UUID、密码与订阅地址另行保管，不要放进公开截图。先保存原配置副本，再一次只改一个字段。如果日志显示本地端口无法绑定，先解决端口占用；如果显示证书名称不匹配，回到服务器名称与证书；如果显示认证被拒绝，再检查凭据与协议。按错误所属层处理，比按客户端名称猜原因更可靠。

二、VMess、VLESS、Trojan 与 SS 的取舍

协议选型的前提是服务端确实提供相应入口。客户端支持某种协议，不代表任意服务器都能接受它。以下比较关注协议职责与配置边界，不给出脱离设备和网络条件的速度排名。协议本身的开销只占完整连接的一部分，线路质量、传输组合和服务端实现都可能改变最终体验。对于已有稳定订阅的用户，先正确导入并验证，比主动把所有配置迁移到某个名称更新的协议更有价值。

VMess：认证与加密结合的协议

VMess 来自 Project V 的早期协议设计，承担认证与数据保护等职责。现在使用时，应关注客户端与服务端对现代认证机制的支持，而不是照搬旧教程里的历史参数。部分旧配置包含额外身份编号等字段，这些字段在不同实现和年代的含义存在差异。导入后若认证失败，应首先核对服务端说明、UUID 和双方时间，不能把旧文章中的数值当成通用修复方法。系统时钟明显不准，也可能影响认证或安全握手。

VMess 的优势是已有部署和订阅工具覆盖较广，适合继续使用现成且维护正常的配置。它并不要求用户为了名称更换内核，但具体传输仍需双方支持。编辑时应区分协议内部加密设置与外层 TLS：两处名称相近，却不是同一控制项。若配置来源规定了加密方法，应原样核对，不要因为外层已经开启 TLS 就任意修改内部字段。历史兼容字段越多，越应保留原始导入结果作为对照。

VLESS：精简代理层，依赖外层保护

VLESS 减少代理层自身的复杂度，基础设计不提供 VMess 那样的数据加密职责，通常与 TLS 或 REALITY 等安全层配合使用。它的轻量定位不等于可以忽略身份验证，也不意味着明文传输适合直接暴露在不可信链路上。客户端中看到加密字段为 none 时，需要结合外层安全配置理解；这可能是协议要求，而不是要求关闭整条连接的保护。选择它之前，先确认服务端提供的完整组合。

VLESS 配置经常出现 flow 字段。流控不是随意勾选的性能开关，而是与特定实现及传输组合相关的协议行为。服务端未要求时不要自行增加，服务端要求时也不能漏掉。若订阅成功生成服务器条目，但启动后提示不支持某个流控，通常要检查所选内核及其功能，而不是先换 UUID。对于现成订阅，完整保留服务端指定字段比追求统一配置更重要。

Trojan 与 Shadowsocks：认证字段不同

Trojan 的常见部署使用密码认证，并依托 TLS 保护连接。需要同时检查密码和证书验证相关设置；密码正确但服务器名称错误，仍可能在认证之前就握手失败。它的配置表面上较短，却不意味着安全层可以省略。若服务端使用额外传输封装，客户端也要提供对应字段。把 Trojan 密码粘贴到 UUID 输入框，或者把另一种协议的分享链接仅改前缀，都不能生成有效配置。

Shadowsocks 常缩写为 SS，核心参数包括服务器地址、端口、密码与加密方法。不同加密方法并不是可互换的选项，尤其涉及较新的方法族时，需要明确双方实现支持。某些配置还依赖额外封装参数，不能只留下地址和密码。其设计通常较简洁，但资源占用取决于加密算法、处理器支持和转发路径。旧方法不应仅因某篇教程写着“兼容最好”就继续优先选用，应按当前服务端与内核的明确支持范围配置。

归纳到操作上，已有 VMess 配置先检查现代实现兼容与时间；已有 VLESS 配置重点核对安全层和流控；Trojan 同时关注密码与 TLS 身份；SS 则必须确认加密方法的精确名称。只有服务端提供多个可比较入口时，才进入性能比较。比较时尽量保持相同地区、相同接入方式和相近时段，避免把不同服务器的差别误当成协议差别。

三、传输、TLS 与 REALITY 的参数边界

代理协议之外，传输与安全层经常决定一条配置能否正确建立。传输字段描述数据如何组织和承载，安全字段描述连接如何验证身份并保护内容。它们可以组合，却不能任意拼接。服务端选择了某种传输与安全方案，客户端必须匹配；客户端下拉框提供更多选项，只表示具备配置能力。阅读订阅说明时，应把协议、传输、安全层作为一个组合记录，不要单独抽出其中一个名称当成完整答案。

TCP、WebSocket 与 gRPC

直接使用 TCP 承载时，链路层次相对直观，但新建连接仍可能需要 TCP 建连、安全握手与代理认证。WebSocket 在 HTTP 握手之后承载双向数据，经常需要核对路径和请求头中的主机信息。路径中的大小写、前导斜杠和服务端反向代理规则都可能影响匹配。看到握手被拒绝时，除了检查协议密码，还应确认请求是否到达了正确入口；返回普通网页内容也不表示代理认证已经成功。

gRPC 基于 HTTP/2，配置中常有服务名称等字段，不能把 WebSocket 的路径直接复制进去。前置服务需要正确支持相应连接方式，中间环节的空闲超时也会影响长连接。某种传输在另一条线路表现稳定，不代表在当前部署同样合适。对已有服务，先使用明确提供的传输；自行维护服务时，再根据中间代理能力、连接管理和应用类型评估。额外封装一般会增加处理环节，但是否形成可感知开销，需要实际观察。

TLS：证书名称比“已开启”更重要

TLS 设置不只是一枚开关。客户端需要验证证书信任链、有效期和目标名称，部分配置还指定应用层协议协商参数。服务器名称通常用于握手中的名称指示，并与证书身份验证相关；传输请求头中的主机名则服务于另一层请求处理。即使部署恰好使用相同文字，也不能认为两处字段始终等价。修改地址、迁移域名或调整反向代理后，应分别复核，不要把所有名称字段统一清空。

遇到证书错误，先检查系统时间，再确认订阅中的服务器名称是否保留，以及服务端证书是否有效。跳过证书验证会改变连接的信任条件，不应作为日常排错的默认动作。若服务使用私有信任体系，应由服务管理者说明正确的信任配置，而不是让每台设备长期忽略验证。应用层协议协商同样需要双方一致；看到相关握手错误时，应核对服务端要求，而不是从另一条配置抄一组看似常见的值。

REALITY：按服务端公开参数对应填写

REALITY 是 Xray 生态中的安全层方案，常见客户端字段包括服务器名称、服务端提供的公钥、短标识以及客户端指纹。客户端使用的是公开参数，服务端私钥不应被分发给客户端。服务器名称也不是可以任意替换的网站名称，需要符合服务端部署允许的值。短标识是否可空以及应填什么，取决于服务端实际配置。导入时只保留了协议和 UUID，却丢失这些参数，条目仍可能出现在列表中，但无法正常连接。

客户端指纹用于选择相应的握手行为，不代表浏览器身份、账号身份或连接速度等级。不同内核对可选值与相关功能的支持可能不同，应使用配置来源指定且当前内核支持的值。流控与 REALITY 也不是同一个设置：前者属于协议行为，后者属于安全层；二者常一起出现，但应分别核对。日志若提示不支持安全类型，先确认内核；若已经进入握手但失败，再检查名称、公钥、短标识和网络可达性。

最终可以把核对顺序固定为：先确认服务器地址与端口，再确认代理协议及凭据，接着检查传输字段，最后对照安全层参数。每完成一层，就保留日志中的具体错误。这样能区分入口不可达、传输不匹配与身份验证失败。若同时改路径、服务器名称和流控，即便恢复连接，也很难知道哪一项才是原因，后续更新订阅时同类问题仍会重复出现。

四、Project V、V2Fly 与 Xray 内核家族

Project V 是理解这套工具生态的起点，V2Ray 是其中广为使用的核心项目。V2Fly 社区延续相关开发与维护，Xray 则从相近的代码与设计背景发展出独立演进的内核分支。两者拥有共同概念，也各自增加功能和调整实现。它们不是简单的新旧替代关系，不能仅凭名称判断某一方适用于所有配置。选择时应查看实际协议、传输、安全层和扩展字段是否得到支持。

图形客户端与内核分别承担什么

v2rayN、v2rayNG、v2flyNG 是用户操作的图形客户端，负责保存配置、导入订阅、组织路由并启动内核。真正处理代理连接的工作主要由内核完成。图形界面能显示某个字段，并不保证当前启动的内核接受该字段；界面能够导入链接，也不等于底层已经验证完整兼容。遇到启动错误，应同时记录客户端名称、实际内核类型和错误文本，避免只报告“导入成功但不能用”而缺少判断依据。

桌面平台优先使用 v2rayN，可在其支持的配置和设置中核对实际使用的内核。Android 的 v2rayNG 以 Xray 内核为主要基础，v2flyNG 则作为 v2fly 内核方向的备选。具体可用能力仍受安装包所带内核和客户端实现影响。准备更换客户端之前，先确认问题是协议功能缺失，还是本地权限、订阅转换或服务器参数错误。换界面无法自动修正同一份错误凭据。

共同结构不代表扩展字段通用

两个内核家族都使用入站、出站、路由和 DNS 等概念，部分配置结构相近，因此基础配置存在迁移空间。但扩展协议、安全层、流控选项、DNS 行为与个别字段名称可能不同。REALITY 和常见 Vision 流控组合应按 Xray 的明确支持范围核对，不应直接假定可以交给 v2fly 内核运行。反过来，面向某个内核生成的专用配置，也不能仅修改文件名便交给另一个内核。

配置迁移要区分分享链接与原生配置。分享链接只表达单条服务器的连接参数，客户端还能据此重新生成本地接入、路由与 DNS；原生 JSON 配置则可能已经包含这些内容，甚至依赖自定义标签和文件路径。下面只是两个内核常见的路由规则结构示意，需要合并到已有配置，并确保对应出站标签已经定义。它不是可单独启动的完整配置，也不改变服务器认证参数。

{
  "routing": {
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "port": "0-65535",
        "outboundTag": "proxy"
      }
    ]
  }
}

这段规则先让私有地址使用直连，再让其余端口走代理出站。使用地址库匹配时，运行环境需要提供相应资源；若现有配置没有名为 direct 或 proxy 的出站，应改成实际标签，而不是增加一条不存在的引用。规则按顺序匹配，因此把广泛匹配项放到前面，会遮住后面的具体条件。图形客户端自动生成配置时，也要确认自定义规则是否会被重新生成过程覆盖。

内核切换前保留可回退状态

在 v2rayN 中调整内核相关设置前，先备份当前配置，记录系统代理、路由模式和 DNS 的原状态。切换后先看内核能否正常启动，再验证同一条服务器配置。若日志明确提示未知字段或不支持的安全类型，应恢复原设置并核对支持范围，不要连续删除字段直到程序能启动。配置能加载只是第一步；认证、域名解析和应用访问仍需逐项验证。

客户端更新与内核更新也不必然同步。界面变化可能只影响配置管理，内核变化则可能改变协议支持或默认行为。阅读更新说明时，应关注与当前配置相关的功能，而不是只追逐版本数字。本页不把任何固定版本当成通用门槛；下载时在平台对应入口选择正确安装包，迁移前保留原配置，迁移后再以实际功能验证兼容性。

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

订阅地址是获取配置集合的入口，不是一种代理协议。服务器返回的内容可能是分享链接列表、编码后的文本，或某种结构化配置。客户端首先需要识别返回格式，再把每条记录转换成自身可以编辑和运行的配置。因此“订阅更新成功”“服务器条目出现”和“能够建立连接”是三个不同阶段。检查兼容时应分别确认，不能把下载到一段内容就视为全部字段已经正确解析。

链接外观相似，字段编码可能不同

VMess 分享链接常见形式是编码后的结构化内容；VLESS 和 Trojan 常使用类似地址的写法，在用户名位置放置认证信息，并通过查询参数补充传输与安全字段；SS 分享链接还涉及加密方法与密码的编码方式。以上都是常见约定，不代表所有生成器完全一致。备注名里的中文、空格和特殊符号可能需要正确编码，认证信息中的特殊字符更不能通过手工删改来“整理”链接。

同一字段还可能在不同格式中使用不同名字。例如某种分享格式用短参数表示服务器名称，另一种原生配置则放在独立的安全设置对象中。导入器负责映射，但不一定支持每一种新扩展。导入后应打开编辑界面，对照协议、传输、服务器名称、流控和 REALITY 相关参数，而不是只看备注名。出现同名条目时，还要确认选中的确实是刚更新的那条配置，避免拿旧记录验证新订阅。

订阅更新不一定保留本地修改

许多客户端把订阅管理与手工服务器分开，更新时可能重建订阅所属记录。直接在订阅条目里修改路径、流控或备注，下次更新后有可能被覆盖。需要临时对照时，可复制为独立的手工配置，并注明用途；确认问题后再回到订阅来源修正，避免长期维护多份彼此不同的记录。不要为了保留一次修改而一直停止更新，否则服务器地址和认证信息发生变化时，本地记录可能已经失效。

v2rayN 可从“订阅分组设置”检查地址与分组，再执行订阅更新；Android 客户端则在订阅管理及更新入口核对相同信息。不同界面的菜单文字可能略有变化，判断重点不变：分组是否保存、请求是否成功、返回内容是否能识别、目标条目是否属于当前分组。遇到更新后数量异常减少，先看更新日志和格式，不要立刻清空全部配置。先备份再操作，能够保留有效的对照样本。

订阅转换不能补出缺失能力

格式转换可以把一个字段映射成另一个格式的等价字段，却不能让不支持 REALITY 的内核获得相应实现，也不能为缺失的密码推导出正确值。遇到导入后丢字段，应先确认源内容是否真的包含该字段，再判断导入器是否识别。不要把完整订阅地址提交到不明转换页面；订阅地址常带有访问凭据，泄露后可能让其他人获得同一配置集合。分享排错信息时，只提供遮挡后的字段和错误文本。

多设备同步时，共用订阅可以保持服务器参数一致，但本地系统代理、VPN 授权、应用筛选和 DNS 设置通常仍要分别配置。备份文件也可能保存设备特有路径或本地端口，不能假设跨平台直接恢复后就能运行。具体迁移方法见多设备配置同步方案。首次导入的主流程仍以快速上手教程为准，本节用于处理格式与字段层面的差异。

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

“速度快”至少包含首次打开响应快、持续传输吞吐稳定，以及空闲后恢复快几种体验。它们受不同因素影响。首次访问要经历解析、建连、安全握手和代理认证；持续传输更多受链路带宽、拥塞、丢包、服务器负载与设备处理能力影响；空闲后恢复还可能涉及连接被回收和移动设备休眠。把其中一种测试结果当成整个协议的性能结论，容易得出相互矛盾的判断。

先固定条件，再比较协议

若服务端提供多个协议入口，尽量在同一台设备、相同接入方式和相近时段比较。使用同一应用与相同任务，保持路由模式和 DNS 设置不变。若不同协议分别连接不同地区服务器，比较结果主要反映线路，而不是协议。测试时也应区分首次连接与已经复用连接的访问：浏览器第二次打开很快，可能来自缓存或连接复用，并非更换协议产生的效果。

协议开销可以从握手次数、封装层次、认证处理、加密运算和连接管理几方面理解。精简的协议层可能减少部分工作，但如果外层还有复杂传输、设备缺少相关加速，实际差距未必符合直觉。TLS 连接恢复也可能减少后续建立成本，是否生效取决于具体实现与连接条件。没有受控测试时，不应写出某协议必然更快或某加密方法必然更省资源的排序。

CPU 与内存反映的是整条处理路径

处理器占用除了加密，还包含数据复制、域名解析、规则匹配、日志输出与本地接入。TUN 模式与系统代理模式的处理路径不同，用它们分别测试两种协议，会混入接入方式差异。内存占用则可能来自规则数据库、活动连接、DNS 缓存及图形界面。任务管理器看到客户端整体内存较高，不一定代表协议本身消耗大；应同时观察空闲状态与相同负载下的变化。

多路复用用于在既有连接中承载多个逻辑流，可能减少重复建连，但也改变拥塞和故障的影响范围。某条承载连接发生丢包时，多个逻辑请求可能一起受到影响。某些传输自身已有流管理，再叠加复用未必收益更大；对依赖特定流控的组合，还应遵守内核说明。不要为了“优化”统一打开全部复用开关，应先保留默认行为，再针对短连接密集或特定应用场景验证。

UDP、DNS 与连接恢复分别测

网页能打开，不代表应用所需的 UDP 已被正确转发。实时音视频、部分交互应用和某些传输路径可能使用 UDP，其支持受本地接入、代理协议、内核与服务端共同影响。选择配置时要明确应用实际需要的流量类型，不能仅凭协议名称判断全链路能力。若只有一类应用异常，应查看该应用是否进入代理、UDP 是否被路由到正确出站，以及服务端是否允许相关转发。

DNS 体验也不能只按一次查询结果判断。缓存命中、并发查询、解析位置与路由策略都会影响后续连接。浏览器启用独立解析功能时，客户端 DNS 设置未必控制全部查询。排查时先确认请求到底在哪解析，再检查所得地址与出站路径是否一致。若换协议后恰好清空缓存，短时间的改善也可能只是解析状态变化。记录前后条件，才能把原因与现象分开。

如果所有协议在同一时段都慢，优先检查本地网络与共同服务端条件；如果只有首次访问慢，重点看解析与握手；如果持续传输中断，观察丢包、空闲超时和资源负载；如果只有某个应用受影响，回到接入和分流。完整分层方法见连接速度慢的逐级排查。协议选型应放在问题定位之后，而不是作为替代诊断的第一步。

七、Android 电量与后台连接

Android 上的耗电不能只归因于 VMess、VLESS 或某个内核名称。客户端通过系统 VPN 接入后，持续处理选定应用的网络请求，处理器唤醒、无线网络活跃、DNS 查询、重连和日志都会消耗电量。相同配置在无线局域网与移动数据下的表现可能不同，弱信号时的能耗也可能显著变化。因此比较前应固定网络环境、屏幕状态和前台应用，避免把整台设备的使用差别算到代理协议上。

VpnService 授权与后台限制

v2rayNG 或 v2flyNG 首次建立本地 VPN 服务时，需要 Android 的系统授权。授权成功后应查看应用状态与日志，再验证目标应用能否联网。系统 VPN 标识不是远端可用性的证明。若设备已经运行另一个占用同类接入通道的应用，可能无法同时建立当前连接；应先确认系统实际保留的是哪个服务，而不是重复更换协议。部分厂商系统还会对后台服务施加额外限制。

锁屏后断开、重新进入客户端又恢复，常需要检查电池优化、后台活动权限与自启动管理。设置路径随设备厂商变化，应在系统应用信息中查找电池或后台相关选项，只对确有需要的客户端调整。放宽后台限制可能提高持续可用性，也可能增加后台活动时间，不应当作统一的节电方案。操作后用相同锁屏时长验证，确认问题是否确实来自进程被系统暂停或结束。

减少无效重连，而非盲目减少加密

连接反复失败会触发重复解析、握手与认证，在移动网络中还可能反复唤醒无线模块。若日志不断出现同一种握手错误，应先修正服务器名称、安全参数或时间问题，而不是长期保持重试。网络在无线局域网与移动数据之间切换时，原有连接可能失效，需要建立新路径；这类恢复行为不能直接解释为协议不稳定。记录故障是否只发生于切网，有助于与持续连接中的中断区分。

为了省电而关闭安全层，会改变连接保护条件，并不构成合理的常规优化。更值得先检查的是不必要的后台应用请求、重复的连接测试、长期详细日志和过于频繁的订阅更新。日志应在排错时启用适当级别，收集到足够信息后恢复日常设置。若设备发热而网络流量很少，应观察是否存在失败循环或异常应用，而不是仅根据当前选中协议推断加密计算过重。

分应用代理改变哪些请求进入客户端

分应用代理可以用于只让指定应用进入代理，或让指定应用绕过代理，具体选项名称以客户端界面为准。两种模式含义相反，不能只检查勾选了哪些应用。配置后需要重新验证目标应用；某些应用还通过独立组件完成登录、下载或系统服务请求，单独选择主应用未必覆盖整个流程。若分应用设置导致登录页与主界面走不同路径，可能出现部分功能正常、部分功能失败的现象。

分应用代理并不等于按域名分流。前者决定哪些应用的流量进入本地通道，后者决定进入客户端后的请求使用哪个出站。一个应用被排除后，修改客户端里的域名规则通常不会影响它。反过来，应用已经进入通道，也可能被路由规则指定为直连。排查时先确认应用筛选，再看路由；不要同时调整两处，否则难以判断改变发生在哪一层。

评估电量应比较一段正常使用过程，而不是刚连接后的瞬间百分比。查看系统电池记录时，结合应用活动时间与实际任务，不把短时波动写成固定结论。操作细节可参阅v2rayNG 授权、省电与分应用设置。选型时优先确保协议兼容和连接稳定，再减少无效工作；对于移动设备，避免反复失败往往比争论协议名称更有实际意义。

八、按场景选择并完成兼容验证

最终选择可以归纳成四个问题：设备使用哪个客户端，服务端提供哪种完整组合，应用需要怎样的接入和流量类型，以及出现异常后能否稳定复现。先解决兼容，再评估性能，最后才调整可选优化项。协议没有脱离服务端和内核的独立最优解；稳定、可维护、参数清楚的配置，通常比来源不明但名称更新的组合更适合作为日常使用方案。

桌面日常使用：先选 v2rayN

Windows、macOS 与 Linux 桌面可先从 v2rayN 的对应安装包开始，按设备架构与系统选择入口。Windows 桌面版与经典 WPF 版的区别主要体现在界面技术和使用习惯，不能据此直接推断远端协议性能。安装与运行流程见Windows 安装配置说明；macOS 若遇到系统权限提示，可查阅安装与权限处理。先让客户端正常运行，再导入配置。

浏览器和遵循系统代理的桌面程序，可先用系统代理完成最小验证；确有接入需求时，再评估 TUN 等方式。不要在首次导入时同时增加自定义 DNS、复杂分流和内核切换。选择一条参数完整的配置，先验证内核启动与实际访问，再逐步恢复所需规则。若原本可用的配置在新增规则后异常，应先回退规则，不要把协议类型也一并修改。

Android：按内核需求与应用范围选择

服务端提供依赖 Xray 功能的 VLESS 与 REALITY 组合时，应优先核对 v2rayNG 的实际支持及完整参数。已有面向 v2fly 内核的配置需求时，可把 v2flyNG 作为备选，并确认所用传输与字段在其范围内。两款客户端之间迁移时，先迁移单条配置验证，不要立即覆盖全部数据。系统 VPN 授权、后台权限和分应用选择仍需在新客户端重新检查。

如果只是少数应用需要代理，可考虑分应用模式，以减少不必要的接入范围；如果多个应用互相调用，则应先弄清关联组件，避免过度拆分导致登录链路不完整。需要实时通信或其他 UDP 流量时，要验证整个链路，而不是只打开网页。对经常切换网络的设备，额外观察锁屏恢复和切网后的重连，确认日常使用条件，而不只看刚连接时的结果。

现有订阅与自管服务采用不同决策顺序

已有订阅时，协议通常由服务提供方决定。用户能做的是选对客户端、保留完整字段、选择适合的服务器入口，并核对本地接入。不要要求客户端把一种服务端协议转换成另一种。自管服务则可以先确定客户端和应用需求，再选择共同支持的协议、传输及安全层，同时安排证书或密钥维护。减少不必要的封装，有利于缩小排错范围，但不能以省略身份验证为代价。

若需要多个平台共用配置，应取所有目标客户端真实支持范围的交集，而不是以其中一台设备成功为准。可以保留不同用途的配置，但要清楚区分备注和适用设备。服务端调整协议或安全参数后，应安排各设备逐一验证，尤其注意旧记录、订阅缓存和手工副本。对于自定义原生配置，还要检查本地路径、规则资源与出站标签，不把它们误当作可以跨设备照抄的服务器参数。

用一份验收顺序结束调整

1. 确认客户端与设备架构正确，内核能够启动，本地监听没有冲突。
2. 核对协议、地址、端口、认证字段，以及传输和安全层的全部必要参数。
3. 确认系统代理或 VPN 接入已生效，再用实际应用验证，不只观察状态图标。
4. 分别检查域名解析、路由结果和所需流量类型，保留可复现的错误描述。
5. 最后验证锁屏、切网或长时间使用，确认更新订阅后设置仍符合预期。

如果仍无法判断，先恢复到一条已知可用配置，比较差异，再沿着本页的层次定位。请求错误发生在本地接入、远端建连、握手认证还是路由解析，决定下一步应该查哪里。对外描述问题时提供系统、客户端、内核类型、协议组合和经过遮挡的日志即可，不公开密码、UUID 或订阅地址。需要重新走一次操作主线时返回快速上手教程；需要更换平台安装包时前往客户端下载页，不在排错过程中引入多套未经验证的设置。