V2Ray 协议与内核参考

客户端、内核与服务器不是一回事

v2rayN、v2rayNG、v2flyNG 是图形客户端，负责保存订阅、展示配置、生成运行参数，并协调系统代理或虚拟网络接口。内核负责建立连接、处理协议、解析域名与执行路由。服务器是连接另一端的服务进程。界面里能够选择某个名称，只表示客户端知道如何描述它；是否真正可用，还取决于正在运行的内核和服务端配置，不能把界面支持直接理解成端到端支持。

选型时可以把一条出站连接看成几层：代理协议说明如何认证用户和携带目标地址，传输层安排字节如何到达对端，安全层负责连接保护与身份验证，路由决定哪些请求使用这条出站，入口负责从本机应用接收流量。它们互相配合，但不能相互替代。切换路由模式不会修复错误的密码，开启系统代理也不会自动补上缺失的服务器证书名称。

协议名称只描述连接的一部分

例如，VLESS 可以搭配不同传输与安全设置。同为 VLESS 的两条配置，可能一条使用普通 TLS，另一条使用 REALITY；连接所需字段和服务端能力就不同。WebSocket 是一种传输承载方式，并不是与 VLESS 并列的代理协议。TLS 也不是节点认证密码的另一种叫法。阅读订阅详情时，应分别记录协议、地址、端口、传输、安全方式和认证信息，而不是只记一个协议标签。

客户端中的“地址”通常是连接服务器所用的域名或 IP；“服务器名称”常对应 TLS 的 serverName，也经常显示为 SNI；WebSocket 的 Host 与路径属于应用层请求。三者可以相同，也可能由服务端要求填写不同内容。将它们全部改成地址栏里的域名，看起来整齐，却可能破坏证书验证或反向代理分流。最可靠的依据是配置提供方给出的字段映射，而不是字段之间是否长得相似。

把“能导入”和“能连接”分别验证

导入成功只说明客户端接受了输入格式，并创建了一条记录。某些高级字段可能没有被识别，某些默认值也可能与原始配置不同。真正建立连接还需要地址可达、端口开放、认证匹配、安全层参数正确，以及目标请求符合路由规则。一个名称完整、图标正常的节点，仍然可能在握手前就失败。因此，应先检查详细参数，再做单连接验证，最后才比较使用体验。

这套分层也能缩小排错范围：完全没有请求日志，先查入口与路由；已经连接服务器但认证失败，查协议凭据；证书或握手错误，查安全层与时间；只有特定网站失败，再查 DNS、目标站点和分流。按层定位比同时切换协议、内核和路由更容易复现问题。常见字段的简短定义可配合术语手册阅读，本页后续章节则展开各层的取舍和边界。

VMess：协议内的认证与数据保护

VMess 随 Project V 生态发展，采用用户标识进行认证，并在协议自身处理数据保护。与只在外层建立安全通道的方案相比，它在代理协议中承担了更多工作。实际配置不仅要识别 UUID，还要留意实现采用的认证机制和加密选项。旧配置中的额外标识字段具有历史背景，不应照着早期文章随意增加数值。连接现代服务端时，应以双方实现所支持的认证方式为准。

VMess 的认证对时间有要求。设备时间明显偏离可能导致认证失败，而表现出来的现象未必直接写着“时间错误”。排查时先启用系统自动校时，再看认证日志，往往比反复刷新订阅有效。它适合已有稳定部署、客户端与服务端配置明确的环境；不需要为了追随另一种协议而迁移一条工作正常的连接。协议的历史长短不能单独说明性能，也不能代替具体实现的维护情况。

VLESS：把职责交给合适的层

VLESS 采用较精简的代理协议设计，负责认证和请求表达，不像 VMess 那样在协议本体提供同样的数据加密职责。因此，VLESS 配置中的 encryption 为 none，并不等于整条连接必然明文；实际保护可能来自 TLS 或 REALITY。反过来，看到 VLESS 名称也不能自动推断连接已经得到保护。判断时必须同时阅读安全层，不能孤立解释一个下拉框中的 none。

VLESS 的 flow 是另一类需要留意的字段。它描述特定流处理方式，例如与 Vision 相关的取值，但并非所有传输都能任意搭配。客户端允许输入不代表服务端接受，订阅缺少该字段也不表示应手动补上。若服务端指定了 flow，应原样保留并确认内核支持。把精简理解成“参数少就可以随便组合”，是常见误区；减少协议本体职责，实际上更要求各层边界清楚。

Trojan：基于 TLS 的代理连接

Trojan 的典型设计以 TLS 为外层保护，再在其中完成密码认证和代理请求。用户最常接触的是服务器地址、端口、密码和服务器名称。密码认证与证书验证承担不同职责：前者判断是否有使用权限，后者帮助确认连接的是预期对端。因为两者不同，修正密码不能解决证书名称不匹配，关闭证书验证也不能修复错误的密码。排错必须先看失败发生在哪个阶段。

选择 Trojan 时，要检查证书链、服务器名称以及部署中是否存在反向代理。使用域名连接通常更容易维持明确的证书对应关系；若地址填 IP，仍可能需要单独指定合法的服务器名称。是否支持某种额外传输或复用方式，要查所用内核和服务端实现，不能把某个客户端提供的扩展当成所有 Trojan 部署的共同能力。原始协议与实现扩展应分开理解。

Shadowsocks：紧凑的数据封装与方法兼容

Shadowsocks 通常直接围绕代理数据流进行加密封装，配置中最关键的是地址、端口、加密方法和密码。它没有必须采用证书握手的统一前提，因而常被用于希望减少外层组件的部署。不过，“Shadowsocks”并不表示所有方法彼此兼容。传统方法、现代 AEAD 方法与 Shadowsocks 2022 系列具有不同要求，密码的表示和长度约束也可能变化，不能只复制密码而遗漏方法名称。

具体选择仍应回到部署条件：已有哪一种服务端、是否需要 UDP、设备内核支持哪些方法，以及订阅能否完整表达参数。不要仅凭“轻量”就断言 Shadowsocks 在所有手机上更省电，也不要只看 VLESS 字段少就判断它一定更快。更完整的横向阅读见四种协议的场景对比；这里只保留一个原则：先满足兼容与功能，再在同等条件下比较开销。

REALITY 是安全机制，不是独立的代理协议

REALITY 常与 VLESS 一起出现，但两者并非同一层的替代选项。VLESS 处理代理请求，REALITY 处理外层连接的安全握手及相关验证。典型客户端字段包括服务器名称、服务端公钥相关参数、短标识和客户端指纹。服务端持有的私钥不应出现在客户端订阅中。公钥参数在不同界面可能采用不同标签，应按当前客户端与内核文档对应，不能只凭字段名称的新旧判断配置正确与否。

REALITY 的握手涉及客户端参数与服务端设置共同匹配。服务器名称通常必须落在服务端允许的范围内，公钥相关参数必须与服务端密钥配对，短标识也必须符合服务端接受的值。某些部署允许空短标识，另一些则明确要求指定值，不能一概而论。客户端指纹用于相关握手特征的构造，不是随便填一个浏览器名称就会改善连接；有效取值与行为依赖内核实现。

TLS：名称验证比“能打开端口”更进一步

普通 TLS 连接需要验证证书链与证书名称。服务器端口能建立 TCP 连接，只代表网络层走到了那里，不代表对端证书可信，也不代表代理认证成功。常见问题包括设备时间不准、服务器未发送完整中间证书、服务器名称与证书不一致，或反向代理把请求转到了错误入口。这些问题应在证书和部署层修正，而不是将跳过验证当作固定配置保留下来。

ALPN 用于协商应用层协议，它不是任意加速选项。某些传输依赖特定的协商结果，某些服务端则会根据协商结果选择处理路径。手动删改可能让握手完成之后的请求仍然失败。若订阅已经给出 ALPN，先保持原值；若订阅没有提供，也不要根据另一条节点的配置盲目复制。握手中每个看似可选的字段，都可能在具体部署里承担明确作用。

TCP、WebSocket 与 gRPC 的实际代价

直接使用 TCP 承载，路径通常比较直观，额外封装较少；WebSocket 需要先完成 HTTP 升级，之后再承载数据，部署时还要匹配路径与 Host；gRPC 通常依赖 HTTP/2，需要匹配服务名称并得到中间代理支持。这些传输主要解决承载与部署适配问题，不是“越复杂越先进”的等级表。选择已有服务端真正支持的组合，比只挑名称更新的传输更重要。

经过反向代理时，还要考虑代理的空闲超时、请求大小限制、长连接处理和上游协议。浏览网页正常、长时间会话却定期断开，可能是某一层超时，并不是代理协议认证突然失效。WebSocket 路径差一个字符、gRPC 服务名称被转换器丢失，都可能造成服务端返回普通 HTTP 错误。此时应核对路径与代理日志，而不是继续调整本地监听端口。

复用和 UDP 不能独立于全链路讨论

复用尝试让多个逻辑连接共享底层连接，可减少重复建连，但共享连接也会产生共同的拥塞与故障影响。已有传输本身具备多路能力时，额外叠加复用未必有收益。是否启用要看内核、协议、服务端和应用特征，不宜作为全局必开的开关。尤其在排错阶段，先用简单组合建立基线，之后再比较复用开启前后的短请求和持续传输表现。

UDP 是否可用也取决于入口、代理协议、内核封装、服务端和目标网络共同支持。本地 SOCKS 入口能接收 UDP，不代表普通 HTTP 代理入口也具有相同行为；应用不使用该入口时，协议支持再完整也不会生效。语音、游戏或其他 UDP 应用出现问题，应逐段确认数据如何进入客户端、如何被出站承载，再查服务端策略，不能只靠“节点支持 UDP”的标签作结论。

区分探测延迟、首个响应与持续吞吐

客户端里的 TCP 延迟通常侧重到服务器端口的建连耗时；真实请求测试还可能包含安全握手、代理认证和目标站点响应。两者测量对象不同，结果自然不能直接互换。一个 TCP 探测很快的入口，可能因为目标路由、DNS 或服务端负载而打开网页缓慢。反过来，某种探测失败，也可能只是测试目标或探测方式不适用，不足以证明全部业务连接都失败。

首个响应关注一次新请求从发起到收到数据的时间，持续吞吐关注连接建立后能够传输多少数据。安全握手和传输升级更容易影响前者，链路带宽、拥塞控制和服务器出口更容易影响后者。网页还会并发请求许多小资源，因此单个大文件传输顺畅，不代表页面渲染一定快。比较协议之前，先确定正在优化的是新建连接、日常网页还是长时间传输，避免指标与目标错位。

协议成本要放在同等条件下看

协议封装、认证与加密确实消耗计算资源，但通常不是影响体验的唯一因素。远端距离、丢包、网络切换、服务端拥塞和目标网站差异，常常比协议头部多几个字节更明显。严谨比较应尽量使用同一设备、同一网络、同一服务器地区和相同测试目标。若两条订阅本来就连接不同服务端，得到的结果只能说明这两条完整路径的差异，不能归因于协议名称。

硬件能力也会改变结果。不同处理器对加密算法的加速支持不同，内核实现、系统调度和温度限制都会影响耗时。笔记本在接电与节能模式下的表现未必相同，手机长时间运行后也可能因温控降低频率。没有固定的设备与测试条件，就不适合给出普遍有效的资源占用排名。对普通用户而言，持续稳定、满足应用需求，通常比追逐很小的瞬时差距更有价值。

内存与电量往往由运行方式决定

内存不仅用于协议处理，还用于连接缓冲、DNS 缓存、路由资源和界面列表。导入大量节点、长期保留详细日志或加载较大规则集合，可能比更换一种代理协议更影响占用。比较时要区分图形客户端与核心进程，观察稳定运行后的状态，而不是只看启动瞬间。删除重复分组、缩短不必要的日志保留，比为了降低一个数字反复切换内核更容易理解结果。

移动设备的电量消耗常与无线模块唤醒有关。频繁探测、过短的保活间隔、网络不稳时持续重连，以及后台应用不断产生请求，都可能延长活跃时间。一次握手略少的协议，如果在实际网络里不断断线，最终反而可能耗费更多电量。应同时观察空闲状态、正常浏览和网络切换后的表现，不能用一次短跑测试替代全天使用判断。

建立可以重复的对照记录

建议先保留一条已知可用配置，固定测试网站和应用，分别记录首次请求、持续传输、空闲保持和切换网络后的恢复情况。每轮只改一个变量，测试结束恢复基线，再试下一项。不要同时换协议、服务端和 DNS，否则即使体验改善也难以解释原因。节点测速是辅助工具，不是最终裁判；最终应以实际任务能否连续完成、错误是否能够复现为判断依据。

Project V、V2Fly 与 Xray 的关系

Project V 是理解这套工具生态的背景，V2Ray 曾是其中广为使用的核心实现。V2Fly 社区延续了 V2Ray 核心的开发与维护；Xray 从相关代码基础发展为独立项目，围绕自己的功能路线继续演进。两者存在历史联系，也共享不少概念，但不是同一程序的两个显示名称。阅读文档时应确认描述针对哪种内核，避免把一方的新增能力当成另一方自然具备的共同特性。

两者都可以承担代理连接、路由与域名解析等工作，但支持的协议扩展、传输细节、DNS 行为和配置字段会逐渐形成差异。REALITY 与 XTLS Vision 是理解 Xray 功能路线时经常遇到的内容；不能据此推断 V2Fly 的同名配置位置接受相同参数。反过来，V2Fly 文档中的某种传输或特定选项，也应在 Xray 当前实现中单独确认，而不是按共同历史推断完全兼容。

三个客户端分别如何选择

桌面端首推 v2rayN，它覆盖 Windows、macOS、Linux，适合在图形界面里管理订阅和检查出站参数。不同发行包的界面及所带组件可能不同，选择前应阅读客户端下载页的系统与架构说明。Windows 的桌面版采用跨平台界面，经典 WPF 版保留另一套界面习惯；这属于客户端界面与分发形式的选择，不能直接等同于某个协议更快或内核功能更多。

Android 端优先考虑使用 Xray 内核的 v2rayNG；需要围绕 V2Fly 兼容性验证配置时，再考虑 v2flyNG。二者的界面概念可能相近，但对协议扩展的支持边界并不因此相同。已有订阅如果包含明确依赖 Xray 的参数，应先确认选用的客户端与内核匹配，而不是导入之后再逐项删除不认识的字段。删除字段可能让配置变得能启动，却已经偏离服务端要求。

配置语法相似，不代表可以直接搬运

内核 JSON 中常见的入站、出站与路由结构具有相似概念，但字段集合、默认值和合法组合不一定一致。某段配置被解析器接受，也不证明它具有预期行为：未知字段可能被忽略，默认路由可能不同，DNS 的查询路径也可能变化。迁移时应先核对协议和安全层，再核对传输，最后处理路由与 DNS。不要一次搬入完整复杂配置，否则失败时很难判断是哪一层产生差异。

客户端通常会把自己的节点模型转换成内核配置。用户在界面里修改某项，下一次启动时生成文件可能被重新覆盖。因此，直接修改临时运行文件往往不是持久方案。需要高级自定义时，应使用客户端明确支持的自定义配置入口，并理解它是否替代默认路由、是否仍接受订阅更新。查看运行日志可以帮助确认实际启动了哪个内核，但日志中的文件路径和配置内容应避免公开泄露。

更新与迁移应保留可回退路径

更新客户端与更新内核解决的问题不同。前者可能改变界面、订阅解析和参数生成，后者可能改变协议实现或运行行为。升级后若出现问题，应记录究竟变更了哪一部分，而不是统一归结为“新版本不好用”。先用少量配置验证基本连接、常用应用和网络切换，再恢复完整规则。没有明确需要时，不必为了试验扩展功能而同时替换全部组件。

保留可回退路径不意味着长期停留在旧实现，而是为定位变化提供参照。可以在更新前导出必要配置并记录重要界面选项，随后对照启动日志与实际请求。若界面显示的内核类型与预期不符，先纠正客户端设置；若只有特定扩展失败，再核对该扩展的文档。把生态关系、客户端能力和实际运行内核分开，通常就能避免多数“同样配置为什么不同”的误判。

订阅地址、分享链接和运行配置

订阅地址用于获取一批配置，单节点分享链接用于表达一条连接，内核运行配置则描述进程如何工作。三者不是同一种文件。订阅响应可能是多行链接，也可能经过 Base64 编码，或者采用客户端特定结构。能在浏览器中打开地址，只说明服务端返回了内容；如果返回登录页面、提示文本或错误页，客户端仍会报告格式错误。因此，更新失败时应把连接问题与响应格式问题分开看。

常见分享形式包括 vmess、vless、trojan 和 ss 等 URI 方案。VMess 分享历史上常见编码后的 JSON 载荷；VLESS 和 Trojan 分享常把连接参数放在查询部分；Shadowsocks 又存在凭据编码等不同写法。分享链接中的参数是约定的一部分，不是任意备注。相同协议经过不同分享格式传递时，可能发生字段名称变化或表达能力受限，不能只看开头几个字母判断完整兼容。

哪些内容容易在导入时丢失

高级安全参数、flow、ALPN、客户端指纹、WebSocket Host 与路径、gRPC 服务名称，以及某些 UDP 封装选项，都是需要重点检查的部分。有些订阅格式只能表达基础连接，无法完整携带内核所有功能。转换器若不认识字段，可能直接省略；客户端若不支持，也可能只保留备注和基本地址。看似成功导入的记录，实际已经不再等价于原始配置。

编码处理同样影响结果。查询参数中的特殊字符通常需要正确进行百分号编码，链接备注与认证信息也可能采用不同编码规则。复制过程中丢掉结尾、换行插入到链接中间，或者把编码内容重复解码，都可能让解析结果改变。不要为使链接“看起来好读”而手工替换符号。若必须调整，先在客户端详情页核对每个字段，而不是仅比较分享文本的外观。

订阅更新失败的检查顺序

先确认地址完整，尤其是带查询参数的链接是否被截断；再检查是否需要登录、是否已失效，以及设备是否能够访问订阅服务。若日志显示网络超时，重点检查获取订阅时采用直连还是通过当前代理。某些客户端提供不同的更新路径，当前代理不可用时，依赖它更新订阅就会形成循环。应选择环境允许的可达路径，而不是反复点击相同按钮等待不同结果。

如果请求成功却解析失败，应确认响应确实是目标客户端支持的订阅内容，而不是网页。不要随意把完整订阅上传到陌生转换服务，因为地址和返回数据可能包含账户凭据。向配置提供方询问正确格式通常更直接。需要说明问题时，可以提供错误类型、客户端名称、所选内核和脱敏后的字段结构，不必公开整条订阅链接，也不应把认证信息贴到公开讨论中。

分组管理与更新覆盖的边界

订阅节点通常会在更新时重新生成，手工修改可能被覆盖。需要长期保留的试验配置，宜复制到独立的本地分组，并明确标记用途。与此同时，分组备注并不是安全隔离机制，只是帮助整理记录。删除一个分组前，应确认其中是否混有手工维护的节点，避免把订阅数据与个人测试配置一起清除。定期整理重复记录，也有助于减少误选旧入口的机会。

跨客户端迁移时，先用单条配置做往返核对，再导入整个订阅。重点不是节点数量是否相同，而是关键参数是否保真。若基础参数一致而功能不同，再回到内核兼容章节检查扩展支持；若连接正常但分流不同，则检查客户端本地路由，因为订阅通常不等于完整的路由策略。订阅负责提供连接资料，本地客户端仍然决定这些资料如何被使用。

桌面办公：先保证应用入口一致

桌面环境建议先用 v2rayN 建立一套简单、可验证的配置。浏览器、终端和办公软件未必遵循同一代理入口：部分应用读取系统代理，部分使用自己的设置，部分需要单独配置。某个浏览器能够访问，不代表所有程序都已进入内核。应先确认应用实际走向，再讨论协议差异。系统代理适合处理遵循系统设置的应用，不能自动等同于接管设备全部流量。

日常办公通常包含大量短请求、持续会议连接和后台同步。与只追求单次测速相比，更应重视长连接稳定性、DNS 一致性和规则可解释性。已有工作正常的 TLS 或 REALITY 配置，可以先保持默认参数；需要 UDP 的应用则逐段确认支持。不要为了让所有请求看起来都“走同一路”而贸然启用复杂模式，应先知道应用需要什么，再决定入口与路由范围。

手机通勤：关注网络切换与空闲恢复

Android 端优先使用 v2rayNG，围绕 Xray 支持的协议组合核对参数。手机在无线局域网与移动网络之间切换时，源地址和底层连接可能改变，已有连接通常需要恢复或重建。恢复速度不仅与协议有关，也受客户端网络监听、系统后台限制、服务端超时和应用重试机制影响。测试时应实际切换网络并打开常用应用，不要只在固定网络下观察一次连接成功。

省电设置需要结合症状调整。若客户端被系统停止，前台界面退出后连接可能中断；若完全放开所有后台活动，又可能增加不必要的运行时间。可以先检查系统是否对客户端施加过强的后台限制，再观察空闲时是否持续重连或频繁探测。只保留必要的后台运行条件，不把高频测速当作维持连接的方法。真正需要的是任务期间可靠，空闲期间尽量减少额外唤醒。

弱网：先减少变量，再谈换协议

弱网下常见的限制是丢包、抖动和间歇断连。换一种代理协议不会自动修复底层链路。可以先选路径较稳定、传输层次较清晰的配置，避免在排错时同时叠加多种复用和额外转发。若新建请求经常失败而已建立的连接相对稳定，重点看握手与重连；若持续传输出现停顿，重点看拥塞与丢包。两类现象需要不同的观察方法，不能统一解释成“协议不适合弱网”。

多路复用在短请求较多时可能减少重复建立连接，但在共享底层连接受阻时，多个逻辑请求也可能一起受影响。先关闭可选复用做基线，再根据任务逐项比较，比直接套用“弱网必开”的建议稳妥。若使用依赖 HTTP/2 的传输，还要确认沿途代理能够稳定维护长连接。复杂部署有其适用位置，却不应成为排查不稳定网络时的额外未知数。

持续传输与实时应用应分别验证

文件传输更看重持续吞吐、稳定连接和服务器出口，实时语音更关注抖动、丢包及 UDP 链路。下载速度较快，并不能证明通话质量一定好；网页延迟较低，也不能保证大型传输不会触发温控或带宽限制。对长期运行的任务，应观察一段实际业务过程，并留意设备温度、错误日志和断线恢复。测试目标越接近日常应用，结论越有参考意义。

需要 V2Fly 特定兼容路径时，可用 v2flyNG 在独立配置中验证，但不应把它当作修复所有连接故障的通用替代。若服务端参数明确依赖 Xray，切换到另一内核反而会引入新问题。客户端选择、协议选择与服务端选择应彼此匹配：先确定服务端能够提供什么，再选支持完整参数的客户端，最后比较日常任务表现，而不是先凭偏好选名称。

把选型结论写成条件，而不是排行榜

一条有用的结论应类似“这台设备在当前网络中，使用这组参数能够稳定完成会议和同步”，而不是“某协议永远最快”。条件包括设备、内核、入口、传输、安全方式和服务端路径。记录这些条件后，未来网络变化或更新组件时才能重新验证。若几组配置都满足需求，优先保留结构清楚、参数来源可靠、容易恢复的方案，减少长期维护成本。

先建立最小可用基线

选一条参数完整的配置，使用客户端默认或明确记录的路由，先验证一个普通网页请求。不要在第一次连接时同时导入复杂自定义规则、调整 DNS、启用复用并切换内核。打开日志，确认核心成功启动，再确认实际请求到达内核。若启动就失败，网络测速没有意义，应先处理配置语法、端口占用或不受支持的选项，直到进程能够稳定运行。

本地监听地址也需要明确。下面是一个可作为 Xray 完整配置中的 inbounds 部分使用的最小入口片段，用于说明字段关系，并非包含远端服务器的完整配置。SOCKS 入口只监听本机回环地址，不对局域网开放。端口必须与应用填写的一致；若客户端已经使用这个端口，就不能另起进程重复占用。日常图形配置应优先在客户端界面修改对应项目。

{
  "inbounds": [
    {
      "tag": "local-socks",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": true
      }
    }
  ]
}

按失败阶段逐步缩小范围

没有任何请求日志，先确认应用是否使用了本地入口，以及路由是否将请求直连。出现连接超时，核对服务器地址、端口、当前网络和服务端监听状态；立即被拒绝通常说明目标端口未接受连接，但仍应结合日志判断。进入握手后失败，再查 TLS 服务器名称、证书、REALITY 参数和系统时间。认证失败则检查 UUID、密码或加密方法，不要把几类错误混在一起处理。

若服务器连接已建立，却只有某些域名失败，应区分目标站点本身、DNS 结果和路由命中。直连 DNS 与代理 DNS 的使用位置，可能使同一域名得到不同结果；而 DNS 查询是否经过代理，又与具体内核策略有关。不能只改一个公共解析地址就认为问题解决。涉及解析路径的进一步说明可阅读v2rayN DNS 检测与设置实操，再按实际请求验证。

用日志验证路径，不公开敏感内容

日志应重点看时间顺序、入站来源、命中的出站以及错误类别。单条警告未必意味着整条连接失败，有时只是某个后台请求被目标拒绝；相反，界面显示运行中也不证明业务流量成功。可以让其他应用暂时减少活动，发起一次明确的测试请求，再按时间找到相应记录。临时提高日志详细程度有助于定位，但完成后应恢复正常级别，避免长期产生大量记录。

分享日志前，应移除订阅地址、认证信息、私人域名和能够关联账户的参数。报告问题时保留客户端名称、内核类型、入口方式、协议与安全层组合，以及错误前后的必要上下文即可。不要将整份运行配置直接公开，也不要把完整订阅当成普通测试网址。脱敏不是删除所有技术信息，而是保留结构与错误原因，去掉能够直接使用连接的凭据。

复测通过后再恢复复杂设置

最小配置正常后，再逐项恢复规则、DNS、自定义入口和复用，每次变化都重复同一请求。若问题在恢复某一项后出现，就围绕该项继续检查，而不是重新从所有协议里随机选择。自定义路由尤其要留意顺序：较宽的规则提前命中，可能让后面的精确规则永远没有机会。具体语法可参阅路由匹配与优先级说明，但修改仍应保持一次一个变量。

最终验收至少覆盖正常浏览、实际业务应用、空闲后恢复和网络切换。需要 UDP 时单独验证对应应用；需要多设备使用时，分别检查各设备入口，不把一台设备的成功当成全部成功。完成验证后保存一份可恢复配置，并记录关键选择依据。日后出现异常，先比较环境和参数变化，再决定是否更新或迁移。安装与导入操作回到快速上手教程，安装包与平台选择统一在客户端下载页完成。