V2Ray从零到精通：订阅、分流与TUN

核心概念：先分清客户端、内核、协议与订阅

客户端负责操作，内核负责连接

V2Ray使用过程中最容易混淆的四个对象是客户端、内核、协议和订阅。客户端是用户直接操作的图形界面，负责保存订阅、选择节点、切换代理模式、生成运行配置并展示日志。v2rayN、v2rayNG和v2flyNG都属于客户端。内核则在后台读取配置，完成连接建立、流量转发、域名解析和路由匹配。常见内核家族包括V2Fly与Xray，两者继承了相近的配置思路，但支持的协议能力和字段细节可能不同。

因此，“客户端能导入某条链接”不等于“当前内核一定能正确运行这条链接”。客户端需要先识别分享链接或订阅内容，再把参数转换为内核配置；内核还要支持相应协议、传输方式与安全参数。排错时应先判断问题发生在导入阶段、配置生成阶段还是实际连接阶段，而不是反复重装客户端。导入后看不到节点，通常与订阅内容或解析有关；节点存在但启动报错，通常与字段兼容性有关；启动正常但目标地址无法访问，则应继续检查代理、路由和网络链路。

协议描述通信方式，传输参数必须成组匹配

VMess、VLESS和Trojan等名称描述客户端与服务端之间如何认证和组织数据。它们并不是速度等级，也不能单独决定连接质量。同一种协议还会组合TCP、WebSocket、gRPC等传输方式，并可能使用TLS或REALITY等安全配置。地址、端口、用户标识、传输方式、主机名、路径和安全选项必须与服务端设置逐项匹配。只修改其中一个字段，通常不会得到“相近但可用”的结果，而是直接导致握手失败。

分享链接将这些参数编码成便于传递的文本，订阅则把多条分享链接或结构化节点信息集中在一个可更新的地址中。订阅地址不是网络节点本身，它更像一份远程配置清单。客户端执行订阅更新时，先请求清单，再解析节点，最后写入本地分组。更新成功只代表清单被读取和解析，不代表其中每个节点都能连接。反过来，订阅暂时无法更新时，本地已有节点仍可能继续使用，因为客户端保存的是上一次成功同步的配置。

系统代理、路由与DNS处在不同层次

系统代理决定支持代理设置的应用是否把请求交给客户端；路由规则决定客户端收到请求后选择代理出口、直连出口还是阻断；DNS负责把域名转换为地址，并可能参与域名规则匹配。三者需要分别观察。浏览器可用而某个程序不可用，可能是后者没有读取系统代理；全部应用都进入客户端但部分地址走错出口，通常是路由规则问题；域名失败而直接访问地址有响应，则应检查DNS链路。

选择客户端：平台、内核与管理方式

桌面端优先使用v2rayN

v2rayN覆盖Windows、macOS与Linux，适合作为桌面端主客户端。它把订阅分组、节点选择、系统代理、路由规则、TUN和日志集中在同一个界面中，便于长期维护。Windows用户可以在新一代跨平台桌面界面与经典WPF界面之间选择；两者承担的核心任务相同，主要区别在界面技术和操作习惯。macOS需要按处理器架构选择对应安装包，Linux则按发行版的软件包格式选择。

如果需要管理多个订阅、为工作与日常使用保留不同分组，或准备学习自定义路由，v2rayN的桌面管理方式更合适。它允许先按订阅来源分组，再在组内选择节点。这样更新某个来源时，不会把所有节点混成一个难以追踪的列表。使用前应先明确“分组是配置来源，节点是连接目标”，不要用频繁重命名节点替代分组管理。

Android端在v2rayNG与v2flyNG之间选择

v2rayNG采用Xray内核路线，通常作为Android端的首选；v2flyNG采用V2Fly内核，可用于需要对应内核能力或配置兼容性的场景。两者都能完成订阅导入、节点切换和基于VPN接口的流量接管，但菜单名称、路由选项和内核支持范围并不完全相同。桌面端导出的全部高级规则也不一定可以原样迁移到移动端，应以客户端实际可识别的字段为准。

安装包架构需要与设备匹配。多数较新的Android设备使用arm64，通用版则面向无法确认架构或需要兼容其他架构的情况。架构只影响安装包能否运行，不会改变订阅内容和协议参数。若arm64版本能够正常安装，就没有必要因为连接问题改用通用版；连接异常应回到日志、节点参数和网络条件排查。

不要用客户端切换掩盖配置问题

同一条配置在不同客户端中的表现可能不同，但更换客户端不应成为第一排错动作。先记录协议、传输、安全参数和错误日志，再判断是否属于内核能力差异。如果配置在某一客户端中无法导入，应检查分享格式是否完整；如果能导入但启动失败，应查看生成配置或核心日志；如果只有特定网络环境失败，应比较网络链路与DNS，而不是直接得出客户端不兼容的结论。

客户端选择完成后，建议固定一个主工具并熟悉其日志入口、配置目录和恢复方法。频繁在多个客户端之间来回导入，会产生重复节点、过期分组和不同的路由默认值，使后续判断更困难。桌面端以v2rayN为管理中心，移动端根据内核需要选择v2rayNG或v2flyNG，是较清晰的组合。具体安装入口和系统架构说明可在客户端下载页按平台查看。

安装与初始设置：先建立可恢复的基线

下载前确认系统与处理器架构

Windows需要先决定使用桌面版还是经典WPF版。希望在不同桌面系统间保持相近界面时可选桌面版，习惯传统Windows操作方式时可选WPF版。macOS设备要区分Apple Silicon与Intel处理器，安装包架构选错通常会表现为无法启动或需要额外兼容处理。Linux用户应按发行版使用deb或rpm包，并继续区分x64与arm64。Android端优先确认设备是否为arm64，无法确认时再考虑通用版。

安装目录应保证当前用户具备读写权限。客户端运行时通常需要保存订阅、日志、路由配置和界面设置，放在受严格限制的目录可能造成更新后配置无法写入。Windows便携式使用场景还应避免把程序长期放在临时解压目录；macOS首次启动后应确认应用能够保存设置；Linux安装完成后要从应用菜单或终端确认程序可以正常启动，而不是只根据软件包安装成功判断。

首次启动只配置必要项目

初次打开v2rayN时，先确认界面语言、配置存储位置和日志入口，不要立即开启全部高级选项。建议保留默认路由，关闭TUN，暂不设置开机自动连接，只完成一次最小连接测试。最小基线包含四项：客户端能正常启动、订阅能够导入、选定节点后内核能够运行、浏览器在系统代理开启后能够通过客户端访问目标地址。只有这四项稳定后，再添加自动更新、开机启动和自定义分流。

系统时间是容易忽略的基础条件。某些安全连接对时间偏差较敏感，设备时间或时区明显错误时，可能出现证书验证和握手问题。先开启系统自动校时，再排查协议参数。代理端口也应避免与本机其他程序冲突。若日志提示监听地址已被占用，先退出旧客户端或查明占用程序，不要连续修改多个端口，因为浏览器或其他应用可能仍引用旧端口。

认识配置目录与退出方式

图形窗口关闭不一定代表客户端进程退出。桌面客户端常驻系统托盘时，窗口关闭后内核和系统代理可能继续运行。修改安装目录、替换程序文件或恢复备份前，应从托盘菜单执行退出，并确认相关进程结束。如果只关闭窗口后直接移动目录，可能出现文件占用、设置写入中断或系统代理仍指向旧端口的问题。

配置目录通常包含客户端设置、节点数据库、订阅信息、路由规则和日志。备份时应在客户端完全退出后复制整个配置目录，而不是只导出当前节点。只保存分享链接无法保留分组、自定义路由和界面设置；只复制程序目录又可能遗漏由系统存放的用户数据。具体位置会随平台和客户端形态变化，因此应优先使用客户端提供的打开配置目录或备份功能，再记录实际路径。

首次安装检查顺序
1. 确认系统与处理器架构
2. 安装或解压到可长期使用的位置
3. 启动客户端并找到日志入口
4. 保持默认路由，暂不启用TUN
5. 导入一个订阅并选择一个节点
6. 开启系统代理，完成浏览器测试
7. 退出客户端，确认系统代理已恢复

退出测试非常重要。正常退出后，如果系统仍保留指向本地代理端口的设置，普通网络请求可能受到影响。再次启动客户端时，应检查系统代理状态与界面显示是否一致。若不一致，先使用客户端的清理系统代理功能，再到系统网络设置中确认。不要把“重启设备后恢复”作为常规操作，理解代理开关和进程状态后，绝大多数情况可以直接修复。

订阅与节点：导入、更新、分组和筛选

订阅导入不是一次性复制节点

订阅地址用于持续获取节点清单。手动粘贴单条分享链接适合临时测试，长期使用则应把订阅保存到独立分组。导入前先检查地址是否完整，尤其注意复制过程中是否带入前后空格、换行或聊天工具附加的标点。订阅名称应表达来源或用途，例如“日常订阅”与“测试配置”，不要用当前节点名称作为订阅名，因为节点会更新，而来源关系需要保持稳定。

在v2rayN中添加订阅后，应先保存订阅设置，再执行更新。部分用户把“添加订阅”和“更新订阅”视为同一步，结果只保存了地址却没有生成节点。更新完成后核对三个结果：目标分组是否出现、组内是否有节点、原有手动节点是否仍在独立分组。若更新后整个列表为空，不要立即再次覆盖更新，应先查看订阅日志，判断响应为空、格式无法解析，还是分组筛选隐藏了结果。

更新策略要兼顾变化与可追踪性

自动更新间隔不宜设置得过短。订阅内容通常不需要分钟级刷新，频繁请求不仅难以带来实际收益，还会让节点列表在排错过程中不断变化。可根据配置来源的更新频率设置数小时到一天的间隔，并保留手动更新入口。准备排查某个节点时，先暂停自动更新或记录节点关键参数，避免测试过程中名称、地址或排序被远程清单改变。

更新订阅与测试节点是两个独立动作。更新只确认配置清单可获取，连通性测试才会调用具体节点。测试结果也要区分TCP连通、真实连接延迟和下载测速。TCP连通只能说明目标地址与端口有响应；真实连接延迟还包括协议握手；下载测速则受到带宽、服务器负载和目标资源影响。可继续阅读延迟测试的区别与使用顺序，避免仅按一个数字排序。

分组、去重与失效配置处理

多个订阅应分别建立分组，不建议把节点全部复制到默认组。分组能回答“这个节点来自哪里”“更新哪个订阅会改变它”“删除某个来源时是否会误删手动配置”等问题。手动添加的节点也应放在专门分组，避免订阅刷新时被同名项目覆盖。客户端如果提供按别名、地址或完整参数去重，应先了解规则；两个名称相同的节点可能参数不同，而两个名称不同的节点也可能指向同一配置。

失效节点不必立即逐个删除。先执行一次订阅更新，确认它是否已从远程清单移除；再通过日志判断是持续失效还是当前网络临时不可达。若某节点需要保留用于对照，可复制到手动分组并标明日期或用途。长期积累大量失效配置会增加误选概率，也会让批量测试耗时，因此维护时应定期清理不再属于有效订阅的孤立节点。

代理模式：系统代理、应用代理与连接验证

系统代理只影响愿意读取它的应用

v2rayN开启系统代理后，会把操作系统中的HTTP或SOCKS代理指向客户端监听端口。浏览器和多数遵循系统网络设置的应用会把请求交给客户端，但部分程序使用自己的网络栈，可能忽略系统代理。于是会出现浏览器正常、命令行工具或特定应用仍直连的情况。这不是路由规则失效，而是流量根本没有进入客户端。

判断应用是否进入代理，最直接的方法是查看客户端访问日志。操作目标应用时，如果日志中完全没有相关连接，应检查该应用的代理设置，或在需要接管更多流量时评估TUN模式。如果日志中出现连接，但出口与预期不同，再检查路由规则。不要仅根据网页能否打开判断系统代理状态，因为缓存、已有连接和应用自带代理都可能干扰结论。

PAC、自动配置与全局代理的差别

客户端界面中的“自动配置”“PAC”或“全局”描述的是系统层如何把请求交给本地代理，不应与内核路由模式混为一谈。PAC通过规则脚本决定哪些域名使用系统代理；全局系统代理则让支持系统代理的请求全部进入客户端。请求进入客户端后，仍可能被内核路由判定为直连。因此，“系统代理全局”与“路由全局代理”是两个不同开关。

首次测试建议使用明确且容易观察的组合：系统代理开启，内核路由暂用默认规则，选择一个已确认参数完整的节点。若要验证某个应用是否支持系统代理，可先临时使用全局系统代理，再查看日志。验证完成后再切回日常模式。频繁同时切换PAC、路由规则和节点，会导致无法确认究竟是哪一项改变了结果。

旧连接、缓存与验证方法

切换节点或路由模式后，已经建立的长连接不会总是立即迁移。浏览器可能继续复用旧连接，DNS也可能保留旧解析结果。测试时应关闭目标页面的现有连接，必要时重新启动应用，再发起新的请求。仅刷新页面有时仍会复用连接，因此比较两个节点时应使用相同目标、相同应用状态和相近时间段。

Windows需要清理本地DNS缓存时，可以使用系统命令，但这不是每次切换节点的必需步骤。只有出现域名解析结果明显陈旧、修改DNS设置后仍使用旧地址等情况才需要执行：

ipconfig /flushdns

macOS与Linux的DNS缓存由系统服务管理，具体命令随系统版本和发行版变化。相比盲目执行命令，更可靠的做法是先确认问题确实发生在解析层：同一域名在客户端日志中是否被解析、是否命中预期规则、直接使用已知地址时现象是否变化。若域名与地址访问结果不同，再针对系统所用解析服务处理缓存。

退出客户端前应恢复系统代理，尤其是在程序异常结束或强制终止之后。若客户端未运行而系统代理仍指向本地端口，应用会表现为普遍无法联网。此时先在系统网络设置中关闭代理，再重新启动客户端检查退出行为。确认基础代理流程稳定后，再进入路由和TUN配置，能够显著减少变量数量。

路由分流：规则顺序、匹配条件与验证

路由规则从上到下匹配

路由分流的目标是让不同请求进入不同出口。常见出口包括代理、直连与阻断。规则通常按顺序匹配，前面的规则命中后，后面的规则不再参与。因此，规则内容正确但位置错误，也会产生不符合预期的结果。例如先放置一个覆盖范围很大的域名规则，后面针对单个域名的例外规则就可能永远无法执行。

设计规则时应把明确、范围小的例外放在前面，把范围大的默认规则放在后面。域名、IP、端口、网络类型和进程名属于不同匹配维度，不要在不理解逻辑关系时一次叠加过多条件。部分配置中同一条规则里的多个字段需要同时满足，另一些客户端界面会把条件展开为独立规则。导入外部规则后，应检查客户端最终生成的配置，而不是只看界面上的规则名称。

域名规则与IP规则的边界

域名规则依赖客户端能够看到原始域名。如果应用直接连接IP，或域名在进入客户端前已被解析，规则只能根据IP判断。反过来，IP规则受解析结果和地址变化影响，同一域名可能在不同时间返回不同地址。较稳妥的策略是：对明确服务使用域名规则，对局域网和保留地址使用IP规则，最后用默认出口接住没有匹配的流量。

常见域名匹配包括完整域名、子域后缀和规则集合。完整域名只匹配指定主机；后缀规则会覆盖其全部子域，范围更大；规则集合便于维护一类域名，但应了解它的更新来源与包含范围。不要仅凭名称推测规则集合内容。修改规则后，通过日志查看实际命中项，才能确认请求是按域名、IP还是默认规则离开。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": [
          "geoip:private"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": [
          "domain:example.com",
          "full:service.example.net"
        ],
        "outboundTag": "proxy"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

这个示例先让局域网与保留地址直连，再让指定域名走代理，最后把尚未匹配的TCP与UDP流量交给代理出口。实际客户端生成配置时，出口标签可能使用不同名称，不能直接复制示例中的标签覆盖现有配置。应先查看客户端当前出站项的tag，再让路由规则引用已经存在的值。若标签拼写不一致，内核可能拒绝加载配置或把请求交给默认出口。

从默认规则逐步增加例外

稳定的分流配置应从简单结构开始。先使用客户端默认的“绕过局域网与大陆”或同类预设完成基础验证，再新增少量明确规则。每新增一组规则，就用对应目标地址测试并记录命中结果。一次导入大量规则后再排错，往往无法判断冲突来自顺序、数据集、域名解析还是出口标签。

进程分流适合处理不遵循系统代理、但能够被客户端识别进程信息的桌面应用。它与域名分流解决的问题不同：进程规则按应用来源决定出口，域名规则按访问目标决定出口。如果同一应用访问不同目标需要不同策略，应以域名或IP规则为主；如果某个应用的全部流量都要使用固定出口，进程规则更直接。使用TUN时，进程识别能力还会受平台权限和客户端实现影响。

规则验证应查看日志中的目标、入站、命中规则和出站。只观察最终页面结果无法确认流量路径。修改后应新建连接，并分别测试一个应直连的目标、一个应代理的目标和一个局域网目标。三类测试都符合预期，才说明规则整体没有被宽泛项覆盖。有关配置文件各部分的结构，可继续阅读inbounds、outbounds与routing逐段解析。

TUN模式：接管范围、DNS与兼容性

TUN解决系统代理覆盖不到的流量

TUN模式通过虚拟网络接口接收更广范围的系统流量，适合不读取系统代理的应用、需要处理UDP的程序，或希望统一执行路由规则的场景。它不是“更快模式”，也不会自动修复失效节点。TUN增加了网络栈、DNS和路由表三个变量，因此应在普通系统代理已经验证可用后再开启。如果基础节点连接本身失败，启用TUN通常只会让现象更复杂。

开启TUN时，客户端可能需要提升权限以创建虚拟接口和修改系统路由。权限不足会表现为虚拟接口创建失败、路由写入失败或启动后没有流量。应从客户端日志确认具体阶段，不要仅根据开关状态判断。Windows、macOS和Linux对虚拟接口与系统权限的处理方式不同，升级系统或安全策略变化后，也可能需要重新授权。

严格路由与绕过局域网

TUN接管范围扩大后，必须明确局域网流量如何处理。打印机、网络存储、路由器管理地址和本地开发服务通常需要直连。路由配置应优先放行局域网与保留地址，避免它们进入远程代理。若开启TUN后本地设备无法访问，先检查私有地址规则是否存在并位于宽泛代理规则之前，再检查虚拟接口是否改变了到局域网网段的路由。

严格路由用于减少流量绕过TUN的可能，但可能与虚拟化软件、企业网络客户端、容器网络或其他网络过滤程序发生冲突。出现冲突时不要立即关闭全部安全选项，应先确认哪一条路由或哪一个虚拟适配器重叠。记录开启TUN前后的路由表差异，再逐项调整绕过网段或接口优先级。多个虚拟网络工具同时运行时，最后启动的程序可能重写默认路由，导致结果随启动顺序变化。

TUN中的DNS路径

TUN模式下，DNS请求也可能被客户端接管。域名解析结果既影响连接目标，也影响IP路由匹配。若配置使用FakeDNS，客户端会先向应用返回保留地址，再在内部恢复原始域名并选择真实出口。这种方式有利于保留域名信息，但某些依赖真实IP的应用可能不适应。出现域名可解析但应用连接异常时，应检查是否与FakeDNS行为有关，而不是直接更换节点。

如果不使用FakeDNS，则需要明确DNS服务器请求走直连还是代理，并防止形成循环：DNS请求被送入代理，而代理连接建立前又必须依赖同一个DNS结果。客户端默认配置通常会避免基本循环，自定义时则要保留一个可用于解析节点服务器地址的引导DNS。节点地址本身如果是域名，这一点尤其重要。

安全开启与恢复步骤

开启前先保存当前配置，退出其他会修改路由的网络工具，记录普通系统代理下的可用节点。随后启用TUN并确认虚拟接口创建成功，再测试局域网、域名解析、TCP与UDP应用。若失败，先关闭TUN并确认基础网络恢复；如果关闭后仍异常，应退出客户端并检查残留虚拟接口、系统代理和默认路由。不要在网络尚未恢复时连续重装客户端，因为残留路由通常不由重新安装解决。

日常维护：更新、备份、日志与速度排查

把客户端更新与订阅更新分开

客户端更新改变程序界面、配置转换逻辑和内核管理方式；订阅更新只改变节点清单。两者应分别安排并保留恢复路径。更新客户端前先退出程序、备份配置目录并记录当前可用模式。更新完成后先使用原节点和原路由测试，不要同时刷新订阅。这样如果出现异常，可以判断变化来自程序更新，而不是远程配置变化。

订阅更新则应保留分组结构，并关注更新后的新增、移除与重命名。某个常用节点消失时，应先确认订阅来源是否调整了清单，不要从旧缓存反复复制回主分组。若必须保留旧配置用于短期对照，可复制到手动分组并标记用途。对照结束后及时清理，避免后续误选过期参数。

备份内容与恢复演练

有效备份至少包括订阅设置、手动节点、路由规则、客户端偏好和必要的本地配置。日志通常不需要长期全部保存，但发生稳定复现的问题时，应保留包含启动阶段与错误时刻的片段。备份文件应放在与程序目录不同的位置，并在客户端退出后制作，减少数据仍在写入造成的不一致。

只制作备份而从未测试恢复，无法确认它是否完整。可以在更新前记录配置目录位置，并检查备份中是否存在最近修改的分组和路由文件。恢复时先安装可运行的客户端，再在程序退出状态下放回配置，随后从默认路由开始验证。不要把新旧配置目录混合覆盖多次，否则难以判断客户端最终读取了哪一份文件。

日志要从第一条错误开始读

核心日志常会在一个基础错误后产生多条连锁信息。例如配置字段无效会导致内核退出，随后客户端继续报告连接本地端口失败。真正需要处理的是最早出现的配置错误，而不是最后一条“连接被拒绝”。阅读时从内核启动位置开始，依次关注配置加载、监听端口、DNS初始化、出站连接和协议握手。

分享日志前应删除订阅地址、用户标识、服务器地址等配置内容，只保留错误类型、时间顺序和必要上下文。排查时不需要公开完整配置。对于重复错误，可以记录触发动作，例如“更新订阅后出现”“开启TUN后出现”或“仅某个节点出现”。触发条件比单独截取最后一行更有判断价值。

速度慢按本地、节点与线路分层

速度问题不应先通过反复测速解决。第一层检查本地设置：是否误用全局代理、路由是否让大流量任务进入不合适的出口、TUN是否与其他虚拟网卡冲突、设备是否存在后台下载。第二层比较节点：在相同时间、相同目标和相同代理模式下测试两个节点。第三层观察线路：比较不同时段以及不同网络接入方式，判断波动是否与拥塞相关。

延迟低不代表下载速度高。延迟反映一次连接或请求的等待时间，吞吐则受带宽、拥塞控制、丢包和服务器负载共同影响。视频卡顿还可能与DNS、分片和持续连接稳定性有关。完整的分层方法可参考V2Ray速度慢分层排查。测试时一次改变一个条件，并记录节点、模式、目标和时间，才能得到可比较结果。

进阶路线：从会用客户端到读懂配置

先读懂入站、出站与路由关系

进阶学习不需要从记忆全部JSON字段开始。先建立三段式模型：入站接收应用流量，出站决定流量如何离开，路由在两者之间做选择。系统代理通常连接本地HTTP或SOCKS入站；TUN对应虚拟网卡入站；代理节点、直连和阻断分别对应不同出站。路由规则根据域名、IP、端口、网络或进程信息，把请求交给某个出站。

理解这个模型后，界面选项就能映射到配置结构。修改本地监听端口是在调整入站；切换节点是在更换代理出站参数；选择绕过局域网是在调整路由规则；启用TUN则是新增或启用另一类入站。遇到错误时，可以根据日志判断是哪一段没有建立，而不是把所有问题归为“节点不可用”。

{
  "inbounds": [
    {
      "tag": "local-socks",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "udp": true
      }
    }
  ],
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom"
    },
    {
      "tag": "block",
      "protocol": "blackhole"
    }
  ]
}

这段示例展示一个仅监听本机的SOCKS入站，以及直连和阻断两个基础出站。它不是完整代理配置，不能替代订阅生成的节点出站，但适合观察字段关系。监听地址使用127.0.0.1表示只接受本机连接；若改为其他地址，可能扩大可访问范围，需要同时考虑本机防火墙和网络边界。手动修改客户端生成文件前，应确认该文件是否会在下次启动或切换节点时被覆盖。

学会做最小复现

复杂故障最有效的处理方式是缩减配置。先保留一个节点、一个本地入站、最简单的默认路由和明确的DNS设置，确认问题是否仍然存在。若最小配置可用，再逐项恢复订阅分组、自定义规则、TUN、进程分流和自动更新。恢复到哪一步重新出现问题，就集中检查该层。最小复现并不是删除原配置，应先备份后在副本中操作。

协议问题也应按字段分组验证。先核对地址、端口和用户标识，再核对传输方式，最后检查TLS、REALITY、主机名、路径等组合参数。不要在不确定时用随机值尝试，因为这些字段由服务端配置决定。日志若提示握手、证书名称或传输路径错误，应回到对应参数组，而不是调整路由规则。

建立自己的变更记录

当配置从默认预设逐步发展为自定义规则时，应保留简单的变更记录。记录日期、修改目的、涉及规则、验证目标和回退方式即可。例如“为本地开发域名增加直连规则，验证本地服务与普通网站”“为特定应用增加进程规则，失败时删除该规则”。这样的记录能解释为什么某条例外存在，也能防止数月后把必要规则当作冗余项删除。

对配置文件进行人工调整时，先使用格式校验工具确认JSON语法，再检查标签引用。JSON不允许注释，最后一个数组项后也不能保留多余逗号。语法正确仍不代表语义有效：路由引用不存在的出站标签、端口被占用、协议字段放错层级，都会导致内核无法启动。客户端日志中的配置路径和错误位置是主要依据。

完整排错树

1. 客户端无法启动：检查系统架构、目录权限、依赖与旧进程占用。
2. 订阅无法更新：检查地址完整性、订阅响应、解析格式和目标分组。
3. 内核无法运行：从第一条配置错误开始，检查端口、字段和内核支持。
4. 应用没有日志：检查系统代理、应用代理能力，必要时再评估TUN。
5. 有日志但出口错误：检查规则顺序、域名与IP条件、出站标签。
6. 仅域名失败：检查DNS接管、缓存、引导解析和FakeDNS兼容性。
7. 连接可用但速度慢：按本地设置、节点负载和线路波动分层对照。

完成这条进阶路线后，应能独立回答四个问题：流量从哪个入口进入、命中了哪条规则、使用哪个出口离开、失败发生在哪个阶段。客户端界面仍是日常操作中心，配置文件与日志用于解释行为，不需要为了进阶而放弃图形客户端。需要重新核对首次安装项目时，可参考v2rayN首次安装设置清单；需要重走最短操作路径时，回到快速上手文档。