V2Ray 进阶配置手册

订阅分组与服务器过滤

先区分订阅来源与服务器选择

订阅是远端提供的服务器配置集合；分组是客户端用于整理这些配置的本地边界；当前选中的服务器则是一次连接实际使用的出口。三者不能互相替代。把不同来源的地址分别放入订阅分组，更新失败时才能定位是哪一个来源出现问题，也能避免名称相似的服务器混在同一列表。添加订阅时，先为分组填写可辨认的名称，再录入地址并手动更新一次。更新完成后检查该分组内的服务器数量和协议类型，而不是只看界面是否出现成功提示。

v2rayN 的订阅设置和服务器列表提供分组选择；不同界面版本可能把分组放在侧栏、顶部选项或订阅设置内。操作顺序保持一致：选择分组、执行更新、限定当前列表、再挑选服务器。若更新后仍显示旧条目，先确认正在查看的确实是刚更新的分组。切换分组通常只改变列表范围，不一定自动更换当前活动服务器；活动项仍需单独确认。不要把列表中可见的第一项当作正在运行的连接。

过滤只影响视图，不修改订阅

服务器过滤适合处理名称较多的订阅。例如先按名称中的地区标识缩小范围，再按协议或备注识别目标。名称由订阅来源维护，命名方式不统一，因此过滤词只是一种本地检索条件，不能证明服务器所在地、可用性或安全属性。过滤后看不到原有条目时，应先清空搜索词并取消分组范围，再判断是否真的在更新过程中被删除。筛选结果也不应直接作为批量删除依据，尤其在多个订阅都使用相同服务器名称时。

需要比较服务器时，保持同一组选定的测试方法与网络环境。TCP 连接测试只覆盖连接建立的一部分；网页加载还受 TLS 握手、域名解析、路由和目标服务影响。把单次延迟排序当成稳定性结论，会掩盖这些差异。可以先查看延迟测试方法对比，再在候选项之间做实际访问验证。测速结果属于选项参考，不应写进订阅备注当作长期不变的指标。

给本地修改留出边界

订阅服务器的地址、端口和凭据由来源提供。直接改动受订阅管理的条目，下一次更新可能覆盖这些更改。若需要临时调整一个服务器，先复制为独立的本地条目，并在备注中写明改动目的；确认连通后再决定是否保留。复制条目不会让远端订阅一并更新，因此要区分原始项和实验项。尤其在排查传输设置时，一次只改一个参数，避免把订阅变化与本地实验混为一谈。

当订阅更新后出现大量同名项，先检查是否重复添加了相同来源，而不是立即删除列表。两个分组可能指向同一订阅地址，但采用不同更新设置；也可能只是来源方重复使用了名称。对照分组来源与条目所属关系后再处理。清理分组之前，记录当前活动服务器属于哪个分组，并准备一个可回退的选择。删除列表展示项与移除订阅来源的影响不同，执行前要读清客户端的确认文字。

若更新请求本身失败，先确认订阅地址仍可访问，再查看当前系统代理是否让更新流量走了不可用的出口。部分客户端允许为订阅更新设置独立的访问方式，选择应与当前网络条件一致。失败信息如果指向解析或连接超时，先解决网络路径；如果更新成功却没有服务器，再核对返回内容是否符合客户端识别的订阅格式。不要用反复点击更新代替检查错误信息。订阅来源恢复之后，重新更新并核对条目变化，才算完成这一轮排查。

多订阅管理与更新边界

以用途建立分组，而不是合并所有来源

管理多个订阅时，最容易发生的问题不是条目太多，而是无法判断配置从何而来。可按工作场景、使用设备或来源维护方式划分分组，每个分组保留独立名称与更新设置。命名要能表达来源差异，避免全部写成“默认”或“常用”。如果两份订阅含有同名服务器，分组仍能提供识别依据。桌面端以 v2rayN 为主；Android 端的 v2rayNG 和 v2flyNG 分别维护自己的订阅记录，不能假设桌面端分组会自动同步到移动设备。

录入新来源后，先只更新这一组。检查是否出现预期数量的条目、服务器协议是否被识别、原有活动服务器是否仍能使用，然后再考虑自动更新。这样可以把初次导入错误与日后来源变化分开。自动更新周期并非越短越好：频繁请求会增加失败记录的噪声，也可能在使用过程中替换列表。若来源变化不频繁，手动更新并在配置调整前后核对结果，通常更容易追踪。

理解更新后的覆盖范围

订阅更新可能新增、修改或移除属于该来源的服务器。它不等于恢复客户端全部设置：本地路由、DNS、系统代理状态和其他分组应分别检查。反过来，修改本地路由也不会写回订阅。遇到更新后无法访问的情况，先区分是服务器配置变化，还是恰好同时更改了路由或 DNS。使用一个之前可用的本地条目作为对照，再检查更新日志与活动项，往往比直接重装客户端更快找到原因。

有些来源会复用条目名称，但实际地址或传输参数已经变化。因此，“名称没变”不能作为配置没变的证据。更新前若正在进行复杂路由实验，可以先导出客户端设置或保存一份不含敏感信息的变更记录；更新后重点检查活动服务器所依赖的字段。导出的完整配置可能含订阅地址或服务器凭据，应保存在受控位置，不要直接贴入公开讨论。要分享排错材料时，只截取与问题相关的字段并去除凭据。

处理失效来源与重复条目

一个来源长期更新失败时，不要让它阻塞其他来源的排查。先单独确认其地址是否可访问、返回内容是否为空，再决定暂停更新或移除分组。暂停与删除是两种不同操作：暂停保留现有服务器以便比较，删除可能连同该分组的本地列表一起清理。执行删除前，先切到其他可用服务器，并确认使用该分组的自动选择或路由规则没有留下依赖。不要因为某一次网络超时就认定订阅已永久失效。

重复服务器也不总是错误。相同名称可能对应不同协议、端口或传输方式；相同地址也可能在不同来源中采用不同参数。清理时逐项比较，而不是只凭显示名称批量删除。若确属重复来源，保留更新稳定、说明清楚的一份，把另一份从更新计划中移除。完成后再清空列表过滤条件，确认当前活动项仍属于保留的分组，并进行一次实际访问。这个顺序可以避免“清理成功但当前连接失效”的结果。

为每次调整记下一行最小变更记录即可：改动的分组、执行的动作、活动服务器以及验证结果。记录不必包含服务器凭据。多订阅环境中，这种记录能回答两个关键问题：失败从哪次更新开始，以及回退时应选哪一个分组。若问题只在某台设备复现，还要分别核对两台设备的订阅更新时间与本地路由；同一来源地址不保证各客户端此刻拥有完全相同的条目状态。

路由规则实战：匹配与出站顺序

先确定流量能否进入路由器

路由规则决定已经进入内核的连接交给哪个出站。它不能让尚未进入客户端的应用自动接入代理。浏览器使用系统代理时，通常由本地 HTTP 或 SOCKS 入口接收请求；不遵循系统代理的程序则需要单独设置，或由 TUN 接管。编写规则前，先确认目标应用的流量入口。否则即使规则正确，也不会出现预期效果。规则匹配还受域名是否可见影响：仅有目标 IP 的连接，不能凭空匹配一个域名分类。

常见路由模式可概括为按规则、全部代理或全部直连，但实际行为还取决于客户端生成的配置。按规则模式通常从上至下检查规则，命中后使用对应出站；未命中的连接落到默认出站。检查规则时要同时看匹配条件、顺序、出站标识和默认路径。把宽泛规则放在前面，会使后面的精细规则没有机会生效。实验时先写少量可解释的规则，再逐条增加，不要一次导入多套来源不同的规则集。

从明确的匹配条件开始

下面的片段展示域名分类、指定域名和局域网地址的不同用途。它属于配置结构示意；在客户端中使用时，还须确保 proxy 与 direct 两个出站标识已经存在，并确认内核具有规则使用的域名分类数据。geosite: 匹配的是分类数据，不等同于按字符串包含关系搜索。domain: 和 full: 的匹配范围不同，精确目标适合先用 full: 验证。

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

AsIs 倾向于保留域名用于域名规则判断；需要按解析后的地址判断时，应理解所选域名策略何时触发解析，以及解析结果会不会进入 IP 规则。改变这一项可能同时影响 DNS 请求量和路由命中情况，不能只根据某个网站的访问结果推断全部流量行为。geoip:private 面向私有地址范围；局域网设备无法访问时，除了检查这条规则，还要确认 DNS 返回的地址及系统是否把局域网流量送入了客户端。

用对照法定位规则冲突

新规则未生效时，先看更靠前的规则是否已经匹配，再核对规则中引用的出站标识。域名规则不命中时，检查请求是否以域名进入、应用是否提前自行解析、所需分类数据是否可用。IP 规则不命中时，确认连接目的地址和域名策略的处理结果。日志中的路由目标比“网页打不开”更有定位价值。要避免把不同层的问题混在一起：DNS 失败发生在发起目标连接之前；代理服务器连接失败则可能与目标域名规则无关。

对特定站点做临时测试，可以把精确域名规则放在宽泛分类规则之前，并先记录原有顺序。测试完成后恢复顺序，再分别验证直连目标、代理目标和局域网地址。若只有其中一类失败，检查该类出站或规则；若三类都失败，优先回到入口和系统代理状态。关于连接测试与实际访问的区别，可参照延迟测试说明。测速通过只表明测试对应的链路环节可用，不能证明所有路由分支都正确。

规则集更新时，应关注分类含义和条目范围，而不只关注文件是否载入。宽泛分类可能覆盖原本要单独处理的域名。遇到访问结果突然变化，先检查最近更新的规则和匹配顺序，再考虑修改服务器。为关键目标保留一条精确规则作为诊断工具，往往比长期堆叠大量例外更容易维护。路由设计的目标是让每条规则都能解释其匹配对象及出口，而不是追求规则数量。

DNS 配置优化与解析路径

把解析、路由与连接分开观察

DNS 把域名转换为地址，但代理客户端还需要决定由谁查询、查询请求从哪个出口发送，以及结果是否参与路由判断。浏览器能打开某个站点，并不能证明全部应用使用相同 DNS。应用可能内置解析机制，也可能缓存旧结果。排查时先记录目标应用的接入方式，再检查客户端日志中的域名、解析错误和出站选择。不要在未确认流量入口时一次更换系统 DNS、客户端 DNS 和路由模式，否则很难知道是哪一步改变了结果。

在 v2rayN 中，图形设置与最终生成的内核配置之间可能存在转换。保存 DNS 设置后，应确认内核已重新加载，并查看生成配置中的 dns 与 routing。系统代理模式主要处理遵循代理设置的应用；系统自身的 DNS 查询不一定经由代理入口。TUN 模式接管范围更广，但也可能受到应用自身解析机制影响。因此“已开启系统代理”不等于“所有 DNS 都由客户端处理”。要判断实际路径，应看请求是否进入内核以及内核将其交给哪个出口。

给查询指定明确的服务器

以下是 Xray 内核配置中 DNS 字段的简化写法，展示备用查询地址和特定域名规则的结构。示例地址只用于说明字段关系；正式使用时，应按所处网络选择可达且符合需求的 DNS 服务。局域网名称、企业内部域名和公共域名可能需要不同的查询路径。domains 决定服务器适用范围，而不是为这些域名设置最终代理出口。

{
  "dns": {
    "servers": [
      {
        "address": "localhost",
        "domains": ["geosite:private"]
      },
      "1.1.1.1"
    ]
  }
}

如果局域网设备依赖本地解析服务，直接把所有查询交给公共解析器，可能导致内部名称查不到。相反，把所有公共域名交给只识别内部名称的解析器，也会带来超时。处理这类问题时，先用目标域名和局域网名称各做一次测试，确认故障只发生在哪一组。还要检查路由规则是否允许 DNS 服务器地址从预期出口访问。解析器本身无法连接时，修改域名匹配表并不会修复网络路径。

控制缓存与重复解析造成的误判

更换 DNS 后，旧连接和应用缓存可能继续使用原地址。验证时关闭相关应用连接并重新发起请求；必要时分别检查系统缓存和浏览器行为，而不是只刷新页面。若域名可以解析但访问仍失败，记录解析出的目标地址，并看路由最终选用了直连还是代理。若只有浏览器失败而其他应用正常，先检查浏览器是否使用了独立的代理或安全 DNS 设置。若只有某个命令行工具失败，核对其环境变量和本地 SOCKS/HTTP 端口。

DNS 与路由之间还有一个常见交叉点：按 IP 分类的规则需要地址，按域名分类的规则需要保留可识别的域名。过早把域名转换为 IP，可能使原本期望命中的域名规则失去条件；完全不解析，则无法使用依赖地址的判断。选择域名策略时，应先明确哪些目标依赖域名分类、哪些目标依赖 IP 分类，再观察生成配置的实际行为。不要把某种策略称为适合所有网络的固定答案。

完成调整后，保留一组稳定的测试目标：一个局域网名称、一个明确直连的域名、一个明确代理的域名。分别记录解析是否成功以及连接选中的出站。之后更新订阅或规则集，也用同一组目标复测。这样可以看出变化发生在解析、规则匹配还是远端连接阶段。若查询响应正常却得到不符合预期的地址，检查本地网络提供的解析结果、应用缓存和域名适用规则，不要仅凭一次页面加载失败更换整个 DNS 方案。

TUN 模式与系统代理的边界

选择接入方式

系统代理向支持该设置的应用公布本地代理入口。浏览器和部分桌面程序会主动连接此入口，但并非所有程序都读取系统代理。TUN 模式则建立虚拟网络接口，让符合接管范围的 IP 流量经过客户端处理。它适合需要覆盖更多应用的场景，却同时引入路由表、虚拟接口、DNS 接管和权限等额外变量。先用系统代理验证服务器、订阅及基础路由；只有确认应用未走系统代理或确实需要更广的接管范围，再启用 TUN。

v2rayN 桌面端的 TUN 设置可能依赖系统权限和附加网络组件，实际入口随系统与客户端界面变化。启用前保存当前工作状态：活动服务器、系统代理模式、DNS 配置及路由模式。启动时观察客户端是否报告虚拟接口创建成功，而不要只看开关是否处于开启位置。部分系统会要求授予网络扩展或管理权限；拒绝权限后反复切换开关，通常不会解决接口创建失败。应先处理日志指向的权限或组件问题。

按平台检查网络环境

表格列的是排查方向，不表示不同系统可以套用同一条命令。已经运行其他虚拟网络工具时，两个程序可能都尝试修改默认路由或 DNS。此时先逐个退出，再单独启动 v2rayN 验证。若目标应用在系统代理模式下可用、切换 TUN 后不可用，优先比较两种模式下的流量入口与 DNS 路径，不要马上更换服务器。服务器没有变化而接入方式变了，故障更可能发生在本地网络接管环节。

用最小范围验证接管

启用 TUN 后，先测试普通网页、局域网设备和一个此前不遵循系统代理的应用。三类目标对应不同的失败线索：网页失败可能涉及解析或默认出口；局域网失败可能是私有地址被误送到代理；特定应用失败可能与其自带网络栈或协议有关。测试过程中保持活动服务器不变。若只改变 TUN 开关就能稳定复现问题，检查接口启动日志、路由表与 DNS 状态，而不是重新导入订阅。

本地代理入口在 TUN 开启后仍可能被其他程序使用，但不应因此让同一应用重复设置多个接入方式。某个应用既配置了手动 SOCKS，又被 TUN 接管时，流量路径会变得难以判断。排错时暂时只留一种明确入口；确认工作后再决定是否恢复应用级设置。对终端程序也一样：检查环境变量中是否仍指向本地 HTTP 或 SOCKS 端口。停止 TUN 后，确认虚拟接口及其路由已撤销，再判断系统网络是否恢复正常。

若关闭 TUN 后仍无法访问网络，依次检查系统代理是否仍指向已停止的本地端口、DNS 是否仍采用不可达地址、默认路由是否恢复。不要同时重置所有网络设置；先找到仍残留的改动。对于经常切换办公与家庭网络的设备，应在两种网络下分别测试局域网访问，因为私有地址与内部 DNS 的布局可能不同。TUN 配置的完成标准不是开关保持开启，而是接管范围、局域网例外和关闭后的恢复行为都可预期。

FakeDNS 的用途与限制

理解合成地址的作用

FakeDNS 在适用的流量路径中，为域名请求返回一个临时的合成地址，并保存该地址与原域名的映射。应用随后连接合成地址时，内核可从映射中恢复原域名，继续执行域名路由。它解决的是部分网络路径中域名信息提前丢失的问题，不是一个可替代全部 DNS 服务器的公共解析服务。合成地址也不是目标站点的真实地址；把它复制到独立于客户端的网络工具中，通常无法得到相同的访问结果。

在启用 FakeDNS 前，先确认当前问题是否确实是域名规则无法看到域名。如果日志已经能记录目标域名，且规则命中正常，增加 FakeDNS 只会扩大配置复杂度。典型检查顺序是：确定应用流量进入内核，确认 DNS 请求也由相关路径处理，再看应用连接是否回到内核。只接管查询而不接管后续连接，或者只接管连接而由系统其他解析器返回真实地址，都无法形成完整的映射链。

核对地址池与路由

以下片段展示 Xray 的 FakeDNS 地址池结构。它仅是 fakedns 字段示例，不构成完整客户端配置；是否使用 IPv6 地址池，应与当前接管方式及网络环境一致。示例地址池必须避免与正在使用的实际网络相冲突。还需要让相应 DNS 请求进入 FakeDNS，并确保合成地址产生的后续连接仍由客户端接管。只添加这一段而不处理流量入口，不会让功能自动生效。

{
  "fakedns": [
    {
      "ipPool": "198.18.0.0/15",
      "poolSize": 65535
    }
  ]
}

规划地址池时，先检查当前网络和其他虚拟网络工具的路由范围。若合成地址落入已有的业务路由范围，应用可能把连接送往错误接口。实验阶段保留一份原有 DNS 与 TUN 配置，并一次只开启一个与 FakeDNS 相关的设置。启用后分别测试域名目标和直接使用 IP 的目标：FakeDNS 主要针对域名映射，不应把所有 IP 连接异常都归因于它。还要测试一个局域网名称，避免内部服务因错误的解析路径而不可达。

排查映射丢失与应用行为

应用若长期缓存了旧的合成地址，而客户端已经重启或映射已变化，访问可能暂时失败。此时先让应用重新解析，再观察新请求是否经过预期入口。某些应用自行实现解析或直接连接固定 IP，FakeDNS 对它们的影响可能有限。遇到只有一个应用失败，检查其网络设置与 DNS 行为；遇到所有域名都失败，检查 DNS 接管和内核日志。不要凭浏览器页面上显示的地址判断映射是否正确，应该看内核是否还原了目标域名。

按域名分类的路由与 FakeDNS 配合时，要留意规则顺序。若合成地址被一条宽泛的 IP 规则先行处理，原本期望的域名分流可能无法按计划执行。检查日志时，分别寻找查询、映射恢复、路由命中和出站连接四个阶段。哪个阶段缺失，就优先检查那个阶段的入口和配置。DNS 返回了合成地址只能证明查询环节工作；最终目标是否正确连接，还取决于后续连接是否进入内核以及出站能否访问目标。

如果使用场景已能通过普通 DNS 与现有路由稳定工作，可以维持较简单的配置。FakeDNS 是解决特定域名可见性问题的工具，不是默认应开启的性能选项。决定保留它时，记录地址池、接管模式、测试应用和回退方法；以后修改 TUN 或 DNS 时重新验证完整链路。决定关闭它时，也要让应用重新解析，避免继续使用缓存中的合成地址，从而把旧缓存误判为关闭后的新故障。

自定义出站与规则引用

出站是路由的目的地

一个出站描述流量离开内核的方式。常见的 freedom 出站用于直连，blackhole 出站用于阻断；代理服务器出站则由服务器参数决定连接方式。路由规则通过 outboundTag 引用出站的 tag。因此添加自定义出站时，至少要同时核对标识是否唯一、规则是否引用正确，以及默认出站是否仍符合预期。为不同目的采用可读名称，比使用含糊的数字编号更方便排查日志。

v2rayN 通常会根据所选服务器生成代理出站。直接改动生成文件可能在切换服务器、更新订阅或重启内核后消失。需要长期保留的自定义行为，应使用客户端提供的自定义配置或合并机制，并在保存后检查最终生成结果。不同配置入口对字段的合并方式可能不同：有的替换整个数组，有的只调整特定部分。操作前备份原配置，修改后先确认 JSON 结构可被内核接受，再验证实际流量。

建立可检查的直连与阻断出口

以下片段展示两个出站及一条精确域名规则之间的引用关系。它没有包含代理服务器参数，也没有包含入站，因此不能单独作为完整运行配置。示例域名仅用于解释规则结构。阻断规则应谨慎使用，特别是在诊断期间；如果过宽的规则先匹配了 DNS 服务或业务接口，后续规则就无法挽回该连接。

{
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom"
    },
    {
      "tag": "blocked",
      "protocol": "blackhole"
    }
  ],
  "routing": {
    "rules": [
      {
        "type": "field",
        "domain": ["full:example.com"],
        "outboundTag": "blocked"
      }
    ]
  }
}

测试自定义出站时，先从一条精确规则入手，确认日志显示预期的出站标识。之后再扩大匹配范围。阻断规则命中时，应用可能表现为超时或连接失败；这种结果不能反过来证明代理服务器故障。直连规则命中时，目标仍可能因为本地 DNS 或网络条件不可用。路由选择正确只说明流量交给了对应出站，出站到目标的连接还需要单独验证。

避免服务器与出站标识相互覆盖

客户端切换活动服务器后，自动生成的代理出站可能改变内容，但规则里引用的标识应保持可解析。添加自己的出站前，先查看最终配置已有的标识，避免重复定义。重复标识可能让日志难以解释，也可能造成规则落到非预期出口。若使用多个自定义代理出口，要明确哪个出口用于普通目标、哪个只服务于精确规则，并检查所依赖的服务器配置是否仍存在。不要在公开示例中复制真实服务器地址与凭据。

连接链路中的本地 SOCKS 入口也需要与出站分开理解。入口负责接收应用流量，不是远端服务器。下面的片段仅展示监听范围与端口的字段位置；将监听地址限制在本机，可以避免在未计划的情况下向局域网提供代理入口。实际端口应与客户端界面及使用该端口的应用设置一致。如果端口已被其他进程占用，内核可能无法启动，对应的排查方法见本地端口冲突说明。

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

回退自定义配置时，先停用新增规则，再移除只供这些规则使用的出站，最后重新加载内核。反过来先删除出站，会让仍在生效的规则指向不存在的目标。回退后分别测试一个直连目标和一个代理目标，确认默认路径没有受到残留规则影响。若客户端启动失败，查看报错指向的字段或标识；不要在错误状态下继续叠加新片段。配置规模越大，越应让每项新增规则都有明确用途和独立验证结果。

配置验证、回退与日常维护

按链路顺序查错

进阶配置涉及多个层次，排错顺序应沿着连接链路展开：应用是否把流量交给客户端，本地入口是否启动，DNS 是否得到预期结果，路由是否选择正确出站，出站能否连接目标。跳过前面的环节直接更换服务器，可能暂时改变现象，却不能说明原问题是什么。每次只改一个可观察的变量，记录改动前后同一目标的结果。如果所有应用都无法访问，优先检查客户端启动状态与系统代理；如果只有某个域名失败，再检查 DNS 与规则。

日志能提供比网页报错更具体的线索，但必须结合操作时间阅读。先清楚地重现一次问题，再查看这一时间段的入口、解析、路由和连接记录。启动时闪退或内核未加载时，不会产生完整的目标连接日志；此类问题先检查运行环境与系统权限，可参照启动崩溃排查。日志中没有目标请求时，回到应用代理设置或 TUN 接管范围，不要先修改域名规则。

准备可复现的测试矩阵

建议固定四类目标：一个普通网页、一个按规则应直连的目标、一个按规则应代理的目标，以及一个局域网服务。对每个目标记录“应用入口、DNS 结果、命中规则、出站、最终结果”，而不是只记“能打开”或“打不开”。更改 DNS 时，重点比较解析和后续连接；更改路由时，重点比较命中规则与出站；更改 TUN 时，重点比较请求是否进入客户端。测试目标保持不变，结果才有可比性。

表格是排查起点，不是根据现象直接得出原因。比如域名解析成功，仍可能在路由阶段交给错误出口；出口正确，也可能由目标网络或服务器连接问题导致失败。单次延迟数值不能替代实际访问测试，三种常见测量方法的覆盖范围见连接测试与下载测速对比。做出判断之前，应确认测试使用的活动服务器与当前浏览器访问使用的是同一个出口。

建立最小回退方案

每轮修改开始前，保存当前能工作的状态：活动服务器所属分组、路由模式、DNS 设置、TUN 状态，以及新增的自定义片段。记录配置项即可；包含凭据的完整导出文件要妥善存放。修改后若出现异常，按与变更相反的顺序回退。先停用新增规则或功能，再恢复 DNS 与接入方式，最后检查系统代理状态。一次回退一项并重复同组测试，才能知道哪一项与故障有关。

客户端更新、订阅更新和规则数据更新应作为三类独立事件记录。它们影响的对象不同：客户端更新可能改变界面和生成逻辑，订阅更新改变服务器列表，规则数据更新改变分类匹配。若同一天连续执行三种更新，再遇到路由异常，就难以确定触发点。先完成一种更新，运行固定测试矩阵，确认无异常后再执行下一种。需要安装桌面端或 Android 客户端时，通过安装包页面选择对应平台，不要把下载操作混进规则排查。

需要向他人描述问题时，给出操作系统、客户端名称、接入方式、出现故障的环节、相关错误文字和已做的对照测试。v2rayN、v2rayNG 与 v2flyNG 的界面和内核选择并不完全一致，应写清具体客户端。分享日志前遮盖订阅地址、服务器凭据及个人网络信息。问题若只发生在首次导入与连接阶段，回到快速上手教程按主线复核；问题若出现在订阅、路由或 TUN 的组合设置中，则依照本手册逐层缩小范围。