v2rayN 进阶配置手册

订阅分组与服务器过滤

订阅分组先解决来源归属，再解决服务器筛选。一个订阅通常包含多条服务器记录，分组负责保存订阅地址、备注和更新选项；服务器记录则保存协议、地址、端口与连接参数。两者不是同一层数据。修改分组备注不会改变远端服务器，删除本地记录也不一定阻止下次更新重新导入。需要长期排除某类记录时，应使用分组过滤，而不是反复手动删除。

建立可辨认的分组

在 v2rayN 的订阅分组设置中新增分组，先填写能说明来源或用途的备注，再粘贴完整地址。教学地址为 https://example.com/sub?token=xxxx，实际使用时替换为自己的授权地址。不要删掉问号后的查询参数，也不要把网页展示地址误当成订阅地址。复制后检查首尾空格、换行和中文标点；地址里带有的访问参数应视为敏感信息。

建议先只建立一个分组并手动更新。导入后检查服务器备注、协议和数量变化是否符合来源说明，再添加其他来源。分组命名可以采用“来源简称／用途”形式，避免用当前速度或某次测试结果命名。线路表现会变化，但来源归属应保持稳定。截图、日志分享和配置备份都要遮住订阅参数，不能因为它只是一个链接就公开传播。

启用自动更新前，确认该分组确实需要持续同步。更新会重新读取远端内容，可能增删记录，也可能改变已有条目的连接参数。手工修改订阅导入的服务器后，不应假定修改会永久保留。需要特殊参数的记录可以另存为独立配置，并注明来源及修改理由；原订阅分组继续承担同步职责，避免同一记录既依赖远端更新又依赖本地覆盖。

过滤关键词与正则边界

过滤通常针对服务器备注，但具体匹配范围、包含或排除语义由客户端界面决定。先用一个明确的普通关键词验证结果，再启用正则表达式。不要把路由里的 geosite: 写进备注过滤框，两者处理的对象不同。过滤后的列表只表示哪些记录被导入或显示，不代表这些服务器已通过连接测试，也不代表其地区标签经过独立确认。

需要匹配多个备注片段时，正则中的竖线表示“或”，例如 (实验|备用)；匹配字面圆括号时，应写成 \(备用\)。不要直接粘贴包含斜杠分隔符的程序代码式正则，除非界面明确要求。大小写处理和正则引擎可能不同。测试时保留一条应匹配、一条不应匹配的样本，观察两者结果比凭列表长度猜测更可靠。

更新失败与空列表分开处理

更新失败说明获取或解析阶段出现问题；更新成功但列表为空，则要检查过滤与订阅内容。排错时先临时清空过滤条件，仅更新当前分组。若记录恢复，逐条恢复关键词；若仍为空，检查来源是否返回有效订阅、授权是否失效、响应是否变成登录页面。不要通过频繁更新掩盖错误，连续请求也可能触发来源侧的访问限制。

如果网络只能通过已建立的代理访问订阅来源，可以在客户端支持时选择经代理更新。但这会依赖当前服务器和代理入口，不能用一个尚未成功导入的分组来建立它自己的更新通道。先保留可用配置，区分直连更新与代理更新各自的失败日志。更多分支见订阅更新失败排查，不要在公开求助内容中附上完整地址。

路由规则实战

路由的核心是按顺序匹配请求，并把请求交给已有出站。规则不会创建服务器，也不会自动修复一个不可用的连接。先确认当前代理出站可用，再添加分流。阅读规则时依次看匹配对象、条件和出站标签：域名条件处理域名，地址条件处理 IP，端口和网络类型进一步限制范围。把这些层次分开，才能判断一条规则为什么命中或为什么被跳过。

先确定规则顺序

常规字段规则自上而下评估，首先匹配的规则决定出站。更具体的例外应位于更宽泛的集合之前。例如某个域名需要代理，即使它属于一个直连域名集合，也应把单域名代理规则放在集合规则前面。不要单纯按“直连、代理、阻断”分类排列所有规则；实际优先级应由例外关系决定。一个规则内部的不同条件通常需要同时满足，同类列表则可包含多个候选项。

下面是 Xray 的 routing 局部示例。它要求已有 block、direct 和默认代理出站，同时依赖相应 geo 资源。广告集合首先阻断，私有地址随后直连，中国域名集合再直连。此片段没有声明默认代理；未命中的请求如何处理，还要查看完整配置中的出站顺序或客户端补充的兜底规则。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["geosite:category-ads-all"],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      }
    ]
  }
}

私有地址规则适合保护局域网访问，但它不是万能豁免。应用若提交的是域名，且路由采用 AsIs，不会为了这条 IP 规则主动查询地址。内部服务最好补充明确的内部域名规则，并让内部域名由正确的本地解析器处理。共享目录、打印服务和管理页面还可能依赖广播或其他流量，不应仅凭一个网页能打开就认定局域网功能全部正常。

域名、IP 与解析策略

domain:example.com 可用于匹配该域名及其子域名；full:example.com 用于精确匹配。正则适合存在明确结构的域名集合，但应避免过宽表达式把无关域名纳入同一出站。示例域名只是说明语法，实际规则应采用自己的访问需求。域名规则不能直接看到网址路径，因此不能用它区分同一个域名下面的不同网页。

AsIs 尽量按请求现有信息匹配；IPIfNonMatch 在域名规则未匹配时尝试解析，以继续进行 IP 规则匹配；IPOnDemand 在匹配需要 IP 信息的规则时进行解析。后两者会引入 DNS 依赖和额外等待，也可能让结果受解析位置影响。不要为了“更完整”就选择更积极的解析策略，先判断规则是否真的需要目标 IP。

如果入口只交给内核一个 IP，域名规则可能无法命中。嗅探有时可以从应用握手恢复域名信息，但它受到协议、加密方式和客户端设置限制。不要把嗅探当成所有流量都能恢复域名的保证。TUN 与 FakeDNS 可以提供不同的域名关联路径，仍需确认流量实际经过对应入口，否则规则写得正确也缺少匹配依据。

命中验证与资源问题

验证规则时选择明确的测试目标，并对照日志中的目标地址、入口标签和出站标签。每次仅修改一条规则，重新发起连接，避免旧连接沿用之前的出站。浏览器连接池和应用后台连接会影响观察结果。必要时关闭对应应用后再测试，而不是只刷新页面；规则修改是否需要重启内核，也应按客户端实际保存行为确认。

若内核报告 geo 文件或集合不存在，先核对资源路径和集合名称，不要把所有 geosite 规则改成正则来绕过错误。资源内容会随来源变化，某个标签存在并不等于其分类符合所有使用场景。更详细的日志定位可参考内核启动失败与配置错误分析。恢复连接后再逐步调整集合规则。

DNS 配置优化

DNS 配置应先回答三个问题：谁发起查询、向哪个解析器查询、查询连接走哪个出站。系统解析、内核内置 DNS 和代理服务器侧解析可能同时存在。客户端界面里的“远程 DNS”也不等于所有应用查询都会自动交给它。先画清请求路径，再修改解析地址，可以避免出现网页连接经代理、域名查询却仍走另一条路径的误判。

区分路由解析与连接解析

路由解析用于获取 IP 并判断规则，连接解析用于找到实际目标地址，两者可能在不同位置完成。域名通过代理出站交给远端时，客户端不一定需要提前解析它；直连出站则通常需要在本地获取地址。路由的 domainStrategy 与直连出站自身的解析策略不是同一个设置。调整其中一个，不应推断另一个也发生了相同变化。

下面示例展示 Xray 内置 DNS 的域名分配思路：中国域名集合优先使用本地系统解析，其他查询可以使用加密 DNS。skipFallback 表示该服务器不参与普通回退选择，不等于阻止所有回退。示例依赖 geo 资源，且加密 DNS 请求能否通过代理发送，需要另配路由及可用出站，不能只凭地址使用 HTTPS 就认定路径正确。

{
  "dns": {
    "tag": "dns-query",
    "servers": [
      {
        "address": "localhost",
        "domains": ["geosite:cn"],
        "skipFallback": true
      },
      "https://1.1.1.1/dns-query"
    ],
    "queryStrategy": "UseIP"
  }
}

示例中的 localhost 表示使用系统解析行为，并非固定连接到某个本机监听端口。它适合需要跟随当前网络或内部解析的情况，也意味着结果会受到系统和网络配置影响。若系统 DNS 又被 TUN 劫持回内核，就必须检查是否形成循环。直接把“本地”和“直连”视为同义词，往往会漏掉这一层依赖。

为解析流量安排出站

需要让内核 DNS 查询走指定出站时，可利用 DNS 标签匹配，但要核对当前内核如何处理该类请求。以下规则是前面示例的配套片段，应放在可能抢先匹配的宽泛规则之前。它要求已存在 proxy 出站。系统解析调用和带有本地语义的解析地址可能不遵循同样的代理路径，应分别验证，不能仅看标签便下结论。

{
  "type": "field",
  "inboundTag": ["dns-query"],
  "outboundTag": "proxy"
}

解析器地址若本身是域名，还需要解决这个域名的初始解析。使用明确的地址可以减少引导依赖，但 HTTPS 的证书验证和服务支持仍必须正确。不要关闭证书验证来处理路径错误。代理服务器的地址若也需要内置 DNS 解析，而解析又依赖该代理连接，就可能形成启动循环；应为服务器地址安排独立可达的解析路径或由系统完成引导。

双栈、缓存与排错

UseIP 允许按配置获取地址族；选择仅 IPv4 或仅 IPv6 应有明确依据。网络存在 IPv6 地址并不代表其出口和路由都可用。遇到部分网站等待很久时，可临时做单地址族对照测试，比较错误和连接行为，而不是永久删除所有 IPv6 支持。还要确认所用内核支持对应字段及取值，不能照搬另一个内核的扩展选项。

更换解析器后，系统、浏览器和内核的缓存可能继续使用旧结果。排错应分别观察查询结果和连接目标，按需要重启内核或应用，不必每次都重置整台设备的网络。应用自带的加密 DNS 也可能绕开系统设置。先在应用内确认是否启用，再决定让它保持独立还是改用系统解析，避免两套策略相互抵消。

域名能解析但网页打不开时，继续检查路由、连接和服务器能力；域名完全没有结果时，再检查解析器可达性、查询出站、内部域名和地址族限制。记录一次失败的查询与相邻连接日志，通常比同时替换多个解析地址更有价值。DNS 优化的目标是路径可解释、结果符合访问位置，而不是简单选择某个看起来更快的地址。

TUN 模式

TUN 通过虚拟网络接口承接流量，适合不遵循系统代理设置的应用。它改变的是流量入口，不是服务器协议，也不是独立的连接服务。v2rayN 的系统代理主要影响愿意读取系统代理的应用；TUN 则依赖接口、路由和相关网络栈。启用后仍需一个可用的代理出站及正确的 DNS 路径，不能用 TUN 开关替代前面的连接验证。

启用前记录网络基线

先在普通代理模式下验证服务器连接，然后记录当前默认网关、DNS 设置、已有虚拟接口和常用内部地址。使用单位网络、远程桌面或虚拟机时，尤其要确认哪些流量不能被接管。已有隧道、容器和虚拟机软件也可能安装路由。若这些基础状态不清楚，启用 TUN 后的异常很难区分是新规则造成，还是原有网络路径一直存在问题。

在 Windows 上，创建接口或修改系统路由通常需要管理员权限；macOS 和 Linux 则需要对应的系统授权或权限配置。v2rayN 的界面名称、辅助组件与启动方式会变化，应按当前设置说明操作。Android 的 v2rayNG 和 v2flyNG 通常通过系统提供的隧道授权承接流量，其授权方式不等同于桌面管理员运行，不应照搬桌面权限处理方法。

首次切换可先停用系统代理，再启用 TUN，减少两个入口同时生效的变量。这里的“清除系统代理”只表示调整应用访问入口，并不关闭代理内核。确认虚拟接口成功创建后，再检查默认路由和 DNS 是否按预期改变。若当前连接用于远程维护设备，应先准备本地回退方式，避免接管路径变化后失去操作通道。

堆栈、路由与排除项

堆栈决定如何处理虚拟接口收到的数据，常见选项包含系统栈及 gvisor，实际可选项由所用实现决定。不同选项在协议兼容、资源开销和平台支持上有取舍。不要仅凭名称判断快慢。先使用客户端建议的默认选项，遇到特定应用兼容问题时再做对照，测试相同目标和相同出站，避免把服务器波动误认成堆栈差异。

代理服务器本身的连接必须避开回送进 TUN 的循环。客户端通常会通过接口绑定、路由排除或其他机制保护这条出站路径，但自定义配置可能破坏保护条件。表现可能是启动后普通网络和代理同时失效、日志反复连接同一地址。应检查服务器地址的实际出口，而不是继续添加默认路由。使用域名服务器时，也要考虑地址变化后的排除是否仍有效。

局域网排除需要结合实际地址范围。家庭常见网段并不能覆盖所有单位、虚拟机或专用网络。只排除一段私有地址，可能遗漏其他内部范围；排除过大的范围，又可能让应代理的请求直接发送。先确定必须访问的网段与内部域名，再选择客户端支持的路由排除或直连规则。DNS 也要同步处理，否则路由可达但内部名称仍无法解析。

接管效果与退出恢复

验证时选择一个不读取系统代理的应用，确认请求进入 TUN，再分别测试网页、局域网和需要 UDP 的功能。UDP 失败可能来自出站能力、防火墙、远端限制或栈实现，不能一律归因于 TUN。浏览器能打开页面只说明其中一类请求成功，不能证明所有系统流量已接管。也不要用虚拟接口的存在代替实际连接测试。

若启用后断网，先关闭 TUN，观察普通网络是否恢复，再停止内核并检查残留接口、路由和 DNS。优先使用客户端正常关闭流程，不要立即删除所有虚拟网卡或重置整套网络。能够恢复基线后，按权限、入口、服务器出站和 DNS 四层逐项复测。相关设置概念可先查名词解释，再回到当前平台的设置窗口。

FakeDNS 与域名关联

FakeDNS 返回用于内部映射的地址，而不是目标服务器的真实地址。内核保存“域名与合成地址”的关系，后续请求进入支持映射恢复的入口时，再找回域名并选择出站。它主要用于保留域名信息，帮助域名路由，不是普通 DNS 加速选项。启用前必须确认 DNS 查询、后续连接和映射恢复位于同一条处理链路，否则合成地址会变成无法访问的目标。

理解完整处理链路

完整过程包括应用查询域名、查询到达 FakeDNS、返回合成地址、应用向该地址发起连接、入口恢复域名、出站连接真实目标。任何一个环节绕开内核，都可能导致失败。例如应用自行使用另一套加密 DNS，可能不获得合成地址；应用拿到了合成地址但连接绕过 TUN，也不会发生恢复。只把 DNS 服务器改成 fakedns 并不足以完成整个配置。

下面展示 Xray 的 FakeDNS 池和内置 DNS 片段。所选网段属于基准测试用途地址范围，仍需检查本地是否已经使用相同范围。poolSize 控制映射池规模，并非预留给公网服务器的地址数量。示例只是结构说明，实际入口还需要配套嗅探与路由；v2rayN 使用其他网络组件承接 TUN 时，应按该组件的配置方式处理，不能跨实现混用字段。

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

入口还需具备识别 FakeDNS 地址并恢复域名的能力。以下是对应 Xray 入口可使用的 sniffing 局部对象，不是独立入口定义。metadataOnly 限制为元数据嗅探，适合说明映射恢复路径；若还需要 HTTP 或 TLS 嗅探，应重新核对目标列表和选项。不要把不同来源的嗅探片段叠加后假定它们会自动协同。

{
  "sniffing": {
    "enabled": true,
    "destOverride": ["fakedns"],
    "metadataOnly": true
  }
}

地址池、例外与兼容性

地址池应足够容纳实际使用中的映射，又不能和现有网络发生重叠。映射空间与池规模不是同一个概念，调大数值也不能解决入口没有接管的问题。频繁重启可能使映射状态丢失，而应用缓存仍持有旧地址。此时应用继续连接旧合成地址，内核可能无法还原域名，表现为刚启动的一段时间正常、切换配置后部分应用失败。

内部域名通常需要真实解析结果，因为其访问可能被排除在 TUN 外，或者依赖本地网络地址。对这类域名应设置明确的真实 DNS 路径，并验证后续连接也按内部网络处理。不要仅把内部 IP 设为直连，却让内部域名仍返回合成地址。某些应用会自行检查 DNS 结果或把解析地址用于连接之外的逻辑，也可能需要例外处理。

FakeDNS 返回地址属于内部映射，因此传统“先解析再按真实 IP 分类”的判断不一定仍成立。应优先确认域名恢复发生在路由匹配之前，以及当前实现对合成地址、域名和 IP 规则的处理顺序。特别是直接连接、内部地址和需要真实地址的规则，不能靠同一套 IP 集合推断结果。若配置目标主要是域名分流，先用明确域名验证，再逐步扩展。

分阶段启用与关闭

测试时先保留普通 DNS 和 TUN 的可用基线，再启用 FakeDNS。检查一次域名查询是否返回池内地址，随后查看同一应用的连接能否恢复为域名。只有两步都成立，才继续验证分流和局域网。若查询没有进入 FakeDNS，优先检查 DNS 入口；若拿到合成地址却连接失败，检查连接接管和入口映射，而不是反复更换上游解析器。

关闭 FakeDNS 时也要处理缓存。先恢复真实 DNS 路径，再重启持有合成地址的应用，必要时按系统方式清理解析缓存。直接关闭接管入口但保留旧 DNS 结果，可能造成短时访问失败。排错期间不要把合成地址写进静态域名映射、服务器地址或长期规则，它只在对应映射上下文里有意义。确认恢复真实解析后，才能判断回退是否完成。

多订阅管理与更新隔离

多订阅管理的目标不是把所有记录合并成一个长列表，而是保持来源、更新和使用状态可追溯。不同来源可能采用相似备注，也可能返回同一服务器的不同参数。分组应成为更新边界，当前活动服务器应成为连接边界，路由则成为流量边界。三者分别管理，才能在某个来源失效时保留其他分组和当前可用连接，而不是整体重建配置。

按来源拆分更新责任

建议每个独立来源建立一个分组，不把多个地址拼接进同一地址框。备注注明用途，但不要写入访问参数或身份信息。先逐组手动更新，检查导入格式、过滤条件和服务器变化，再决定自动更新安排。如果两个分组确实来自同一个来源，只是过滤范围不同，要认识到它们会重复请求同一服务；不必要的重复更新应适当合并。

更新频率应跟随来源变化和实际使用需求，而不是越频繁越好。频繁更新增加请求次数，也可能让服务器记录在测试期间变化。需要比较连接表现时，可先暂停相关分组的自动更新，固定配置后再测。更新完成应检查是否仍选中预期服务器，尤其是原记录被删除或参数重建的情况；客户端保留选择的方式不能代替人工确认。

某个分组更新异常时，只排查该分组。先确认地址与授权，再比较直连和经代理获取的结果，最后检查返回格式。其他分组能正常更新，只能证明相应来源可达，不能证明失败来源的地址没有问题。若所有分组同时失败，则更可能是共享网络、解析或代理入口出现变化。采用这样的范围判断，可以减少无效地重新导入全部来源。

重复记录与测量结果

重复记录不能只按备注去重。备注相同的服务器可能有不同端口、协议、传输或加密参数；备注不同的记录也可能指向同一连接。删除前比较关键连接字段，并保留来源关系。教学和求助时可以描述差异，但不要公开导出完整连接参数。需要保留一个长期使用的条目时，应记录其来源及用途，避免下次更新后无法识别。

延迟测试、真实请求和带宽测试衡量的内容不同，不能把一次排序当成固定选型结论。测试还会受到本地网络、测试地址、并发数量和服务器负载影响。多分组比较时使用相同测试方式、相同目标和接近的时间窗口；同时保留一条已知可用记录作为对照。具体原理见Tcping、真连接延迟与下载测速区别。

不要仅按地区名称选择服务器。地区标签通常是来源提供的备注，未必能完整说明入口位置、出口位置和实际线路。倍率、协议兼容和用途限制也会影响选择。某个记录测试延迟低，却不一定适合持续传输或特定应用。建立“日常、特定用途、备用”的少量候选，比保留一份不断变化的全量排名更便于维护。

备份与退出来源

配置备份可能同时包含订阅地址、服务器身份参数、自定义出站和路由。备份应保存在受控位置，不作为普通截图附件分享。恢复时先确认客户端与内核兼容，再逐组导入。旧备份里已经失效的地址不应自动成为新的更新来源；恢复成功也只代表配置被读取，仍需重新验证连接、DNS 和当前网络下的路由效果。

不再使用某个来源时，先切换活动服务器，停用它的更新，再检查是否有路由或自定义出站引用相关记录。确认没有依赖后删除分组。删除本地分组不会取消来源侧授权或服务，需要按来源自身的管理方式处理。若只是暂时不用，保留分组但明确停用，比把地址复制到多个临时记录里更容易恢复，也更容易控制敏感数据的保存范围。

自定义出站与内核边界

自定义出站用于定义请求离开内核的方式。常见职责包括直接连接、阻断，以及通过已有代理服务转发。路由以标签引用出站，标签是内部标识，不是服务器备注或订阅分组名。先设计清晰的出站职责，再写匹配规则，可以避免标签拼写不一致、默认路径变化和客户端生成配置覆盖本地编辑等问题。普通使用仍优先通过 v2rayN 的图形配置完成。

定义标签与默认路径

以下是 Xray 的直连与阻断出站片段，没有提供代理服务器。它可用于理解 freedom 和 blackhole 的结构，不应整体覆盖当前出站列表。如果只保留这两个出站，未命中的连接通常会落到第一个直连出站。需要默认代理时，应保留客户端生成的代理出站，并检查出站顺序和兜底路由，不能只把标签改成 proxy。

{
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {}
    }
  ]
}

标签应短且职责稳定，例如直连、阻断和某个固定代理入口各用不同标识。避免重复标签，也不要把同一标签在不同文件里赋予不同含义。路由引用必须与出站标签完全一致。修改出站时，搜索所有相关规则及其他引用，尤其是 DNS 查询和特殊应用规则。一个未被引用的出站存在，并不代表任何请求会自动使用它。

阻断出站适合处理明确不需要发送的请求，但不要用它替代所有连接失败处理。把未知域名全部阻断可能导致应用依赖的认证、资源和更新请求一起失败。直连出站则依赖当前设备的网络与解析能力，并不意味着可以访问所有目标。为每个出站规定范围和验证目标，比给它起一个“快速”或“安全”的名字更有实际意义。

本地转发与代理链

下面展示转发到本机 SOCKS 服务的出站片段。它假定已有一个独立服务监听 127.0.0.1:10808，示例不会创建该服务。若端口实际是同一内核的入口，且该入口又回到这个出站，就可能形成循环。必须确认监听者、入口去向和最终出口；本机端口能建立连接，不等于转发路径已经正确完成。

{
  "tag": "local-socks",
  "protocol": "socks",
  "settings": {
    "servers": [
      {
        "address": "127.0.0.1",
        "port": 10808
      }
    ]
  }
}

代理链把多个处理环节串起来，会增加连接、解析与故障依赖。设计时先画出每一跳的入口和出口，再确认目标域名在哪一跳解析、UDP 是否可转发，以及任一环节停止后的表现。不是每种出站都支持相同链式配置字段。需要链式转发时，应按当前内核的配置结构处理，不要把另一个实现中的字段直接粘贴进现有对象。

监听地址也属于边界。仅供本机使用的入口通常限制在回环地址；监听所有接口会扩大可访问范围，需要认证与防火墙配合。不要为了让另一台设备接入，就直接开放一个未授权的代理入口。与本机 SOCKS 片段配套的服务还应明确端口冲突、启动顺序和关闭行为，避免开机后仅有下游内核启动而上游服务缺失。

客户端生成与内核兼容

v2rayN 会根据界面选项生成运行配置。直接修改临时生成文件可能在切换服务器、保存设置或重启时被覆盖。优先使用客户端提供的自定义配置或扩展入口，并确认它采用“合并片段”还是“完整替换”。两种方式的责任不同：完整替换通常需要自行提供入口、出站、路由和 DNS；合并则必须理解标签冲突及覆盖顺序。

Xray 与 V2Fly 共享一些基础概念，但协议能力和扩展字段不能视为完全相同。v2rayNG 以 Xray 生态配置为主要参考，v2flyNG 则应按 V2Fly 的支持情况核对。某个协议名称被界面识别，也不说明所有传输组合都可用。内核差异可查客户端与内核对照及Xray 与 V2Fly 差异说明。

切换内核前保存基线，再逐项核对协议、传输、安全参数、路由和 DNS 字段。测试时先只验证单条连接，随后恢复自定义出站和复杂规则。启动失败要根据日志修正字段，不要简单删除所有不认识的选项。能够启动只是语法与部分初始化通过，仍需实际请求证明每个出站和路由都按预期工作。

配置验证与回退流程

进阶配置完成后，应把验证变成一套固定流程，而不是凭一个网页打开判断全部成功。至少分别验证启动、代理连接、域名解析、规则命中、特殊入口和退出恢复。每项使用明确目标，记录修改内容与观察结果。出现异常时，从最近修改的模块回退，保留其余可用配置。这样既能避免误删正常设置，也能为下一次调整留下可重复的测试条件。

从启动到连接逐层检查

第一层是内核能否启动。查看第一条明确错误以及它附近的字段提示，区分 JSON 语法、未知字段、资源缺失和端口占用。JSON 不能包含注释或尾随逗号；局部片段也不能直接拼成多个顶层对象。客户端界面显示“运行”时，仍要确认内核没有随即退出。若出现重复报错，先停止自动重启或反复启动，再读完整的一次错误。

第二层是入口能否接受请求。确认应用使用的代理地址和端口与当前监听一致，系统代理状态也与实际入口一致。入口能接受连接后，再检查服务器连接和协议握手。超时、拒绝连接和认证失败属于不同分支，不要用同一个“换 DNS”操作处理全部问题。服务端参数来自授权配置，应核对完整字段而不是只比较服务器地址。

第三层是解析与路由。使用一个预期直连目标和一个预期代理目标，对照日志观察目标信息及出站标签。测试新规则时重新建立连接，避免复用旧连接。日志里只出现 IP 时，先检查入口是否保留域名、嗅探是否生效或 FakeDNS 是否完成恢复。域名信息缺失和规则优先级错误都可能造成未命中，但修正方式不同。

建立有限且可复现的测试集

测试集不需要很大，但应覆盖配置目标：普通网页、明确直连的内部服务、一个需要代理的请求，以及实际使用的特殊应用。记录测试时是否开启 TUN、是否使用 FakeDNS、所选服务器和网络环境。移动网络与固定网络的结果不能直接混为一组。若问题仅在某个网络出现，就保留这项差异，优先检查网络侧解析、出口和防火墙条件。

测速可以补充观察，但不代替功能测试。握手延迟低不代表应用认证成功，下载速度高也不说明路由和 DNS 符合设计。测试失败时先让最简单配置完成一次真实请求，再恢复过滤、路由、TUN 等模块。不要同时切换服务器和内核后比较结果，因为无法判断是哪项变化导致恢复。每次改动少，反而更容易找到可以长期保留的修正。

日志级别只在排错期间提高到需要的程度，问题定位后恢复日常设置。日志可能含目标域名、服务器地址和敏感参数，分享前应逐项检查。保留错误类别、字段名、必要的上下文及复现步骤即可。不要公开完整订阅、完整配置或持续运行的全部日志。求助描述应说明“改了什么、预期是什么、实际是什么”，而不只是贴一张连接失败截图。

分层回退与维护记录

回退按改动顺序逆向进行：先恢复最后添加的规则或出站，再恢复 DNS，最后撤销 TUN 与 FakeDNS 等入口变化。若最后改动就是入口，应优先关闭该入口恢复控制路径。每次回退都重新测试，避免一下撤销多个模块后失去证据。确认基线恢复，再复制一份工作配置进行下一轮调整，不要继续在无法解释的混合状态上补规则。

维护记录可以只写日期、模块、改动原因、验证结果和回退位置，不保存凭据。订阅自动更新、网络切换和内核切换都是再次验证的触发条件。来源更新后重点检查活动服务器，换网络后重点检查内部解析与路由，换内核后重点检查字段兼容。按变化范围复测，比每次从头重建配置更省事，也更容易识别真正的故障边界。

如果当前目标只是恢复日常连接，回到订阅导入与连接主线即可，不必一次完成所有进阶功能。安装环境需要调整时使用平台下载入口；错误分支可继续查帮助中心。本手册的章节应按需要单独应用，保留少量清晰、能够验证的设置，比堆叠更多选项更适合长期维护。