V2Ray 进阶配置手册

订阅分组与服务器过滤

先把订阅地址、订阅分组和服务器条目分开理解。订阅地址是获取配置的入口；订阅分组是客户端保存入口及更新策略的容器；服务器条目则是更新后得到的连接参数。三个对象并不等价。删除某个服务器通常不代表删除订阅，下一次更新仍可能把它重新加入。需要永久停用一批配置时，应先停用相应分组的更新，再决定是否删除分组及其条目。

建立可追溯的分组

在 v2rayN 中打开“订阅分组”相关设置，新建分组，填写便于识别的备注与完整订阅地址，然后保存。备注建议记录来源和用途，例如“工作设备”或“临时测试”，不要把访问口令写进备注。订阅地址可能带有访问令牌，复制时应包含整个查询部分，但不要把完整地址贴进截图或公开日志。若输入框前后混入空格，先清理再保存，避免把输入错误误判为网络故障。

保存后先只更新这个分组。更新成功的判断依据不是弹出提示消失，而是日志中请求完成、条目数量发生合理变化，并且列表能显示来自该组的服务器。随后选择一条已知可用的配置，设置为活动服务器，再按快速上手流程验证。如果同时更新多个来源，某组失败可能被其他组成功的信息掩盖，因此初次建立分组时不宜直接执行全部更新。

自动更新间隔应按来源的变更频率设置。很短的间隔会增加重复请求，也可能触发来源端的访问限制。电脑休眠、网络切换和应用未运行都会影响定时任务，不应把间隔理解为服务端推送。更新前还要判断订阅地址能否直连；若只能经当前代理获取，应使用客户端提供的代理更新方式，并保留一条能工作的活动配置，避免更新入口与活动连接同时失效。

过滤列表与删除配置的区别

服务器过滤通常只改变列表展示范围，不修改服务器本身。先选定分组，再输入名称关键词，可以减少误操作。检查是否启用了名称筛选、协议筛选或只显示特定分组，再判断条目是否真的丢失。部分界面支持正则表达式，部分只做普通文本匹配；应以输入框说明为准。普通关键词不能直接当作正则使用，反过来也一样。

如果过滤器明确支持正则，可用 工作|备用 匹配任一关键词，用 ^测试 限定名称开头。输入后先观察结果，不要立即批量删除。括号、加号和方括号在正则中有特殊含义，来源名称恰好含有这些字符时，应按该界面的正则规则转义。不确定匹配模式时，退回单个普通关键词比堆叠复杂表达式更容易确认结果。

更新失败时保留现场

遇到空列表，先清空过滤器并切回对应分组，再查看更新日志。连接超时侧重检查网络路径；解析错误侧重检查响应内容。订阅接口返回登录页、过期提示或普通网页时，网络请求可能成功，但客户端不能把页面识别为服务器配置。此时反复切换协议没有帮助，应检查地址是否失效，以及来源是否要求重新获取订阅入口。

手工编辑订阅生成的条目前，先复制到独立的本地分组。来源更新可能重建条目，覆盖本地改动。原始分组负责同步，复制分组负责实验，二者职责清晰后，排错时就能回到来源参数。安卓端 v2rayNG 与 v2flyNG 的菜单位置可能不同，但同样应区分订阅更新和当前服务器选择。常见连接问题可继续查阅帮助中心，不要在订阅尚未导入成功时同时修改 DNS 和路由。

路由规则实战与匹配顺序

路由的任务是把进入内核的请求分配给出站，而不是替应用创建连接。先确认请求确实到达本地代理，再讨论分流结果。若程序不读取系统代理，路由规则写得再完整也不会改变它的连接路径。排查顺序应是应用入口、请求携带的信息、规则匹配、出站连接。把这四步混在一起，容易把入口问题当成规则错误。

先确定规则使用的配置层

v2rayN 的路由编辑界面可能使用简写形式，例如 domain:example.com、geosite:private，也可能将域名和 IP 分成不同输入框。这是客户端的录入方式，不等于内核 JSON 的所有字段。内核中域名应放进 domain 数组，网段应放进 ip 数组；不要把界面里的整行文本直接粘贴到任意字段。尤其是 ip:192.168.0.0/16 这类界面简写，不能原样作为内核的 IP 数组元素。

以下是可合并进 V2Fly 或兼容 Xray 配置的路由片段。它假定已经存在名为 direct 和 proxy 的出站。第一条让本地地址直连，第二条让示例域名走代理，最后一条接住其他 TCP 与 UDP 请求。示例只说明匹配关系，不提供远端服务器参数，也不会单独构成一份完整连接配置。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": ["127.0.0.0/8", "10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16", "::1/128", "fc00::/7"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["domain:example.com"],
        "outboundTag": "proxy"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

把例外放在兜底规则之前

规则通常按顺序匹配，首个满足条件的规则决定出站。覆盖全部连接的兜底规则必须放在后面，否则后续例外永远无法生效。单条规则内同时填写域名、端口和网络类型时，一般要求这些条件共同满足；同一个数组中的多个域名则用于表达多个候选项。不要用一条规则同时描述彼此无关的需求，拆成两条更容易检查。

domain:example.com 用于匹配该域名及其子域名；full:example.com 用于完整域名匹配。正则适合确有结构规律的名称，但不适合作为默认选择。域名规则不会自动匹配用户直接输入的 IP 地址。若希望目标网段也采用相同路径，应增加独立的 IP 条件，并留意域名解析策略是否允许在路由阶段查询地址。

AsIs 不会为了 IP 规则主动解析域名；IPIfNonMatch 会在域名阶段未匹配时尝试解析并继续匹配 IP；IPOnDemand 则可能在需要 IP 条件时更早触发解析。这些选项影响查询次数和规则命中，不是单纯的速度档位。选择前先确认是否真的依赖目标 IP 分流，以及 DNS 查询本身是否能通过正确出站完成。

用单个请求验证命中

验证时先选一个确定的域名，关闭旧页面或重启目标应用，再发起新连接。已有长连接不会因为规则保存就自动改道。临时提高日志详细程度，观察请求的目标、入站标记与出站标记是否符合预期；完成后恢复常用日志级别。若只能看到 IP，看不到域名，应回查应用是否传递主机名，以及流量嗅探是否适用于该协议。

规则引用的地理数据必须由当前客户端及内核提供。出现找不到数据文件或分类名称的错误时，应先修复数据来源，不要靠调整顺序掩盖加载失败。图形界面的路由方案可能在内核重启时重新生成配置，因此应在客户端保存规则，而不是长期修改临时生成文件。字段之间的关系可对照配置文件 JSON 结构详解，将格式错误与匹配逻辑错误分开处理。

DNS 配置优化与解析路径

DNS 排查先区分三个位置：应用或操作系统的解析器、代理内核的解析器，以及通过代理访问的远端服务。浏览器启用安全 DNS 后，可能绕过系统解析器；应用把域名交给 SOCKS 入口时，则可能由代理侧继续处理。仅在客户端中更换一个 DNS 地址，不代表设备上所有程序都改用该地址。应先画清请求在哪一层变成 IP，再决定修改哪个设置。

分别处理服务器域名与目标域名

代理服务器自身使用域名时，建立代理连接前就需要解析它。这个过程如果被安排到尚未建立的代理通道中，会形成循环依赖。目标网站的域名则可以按分流需求选择直连解析或经代理查询。两类域名职责不同，不宜用一条模糊的“全部远程 DNS”设置覆盖。遇到启动后完全无法连接，应优先检查服务器域名能否通过独立路径解析。

在 v2rayN 的 DNS 设置中，先确认当前编辑的是哪一种内核的配置。不同内核后端的字段、默认行为和可用传输方式可能不同，不能把某个后端的 JSON 粘贴到另一个后端。以下片段用于说明 V2Fly 风格的内置 DNS 设置：为保留示例域名指定静态地址，并向指定解析器请求 IPv4 地址。它只影响使用该内置解析器的请求，不会自动接管系统 DNS。

{
  "dns": {
    "hosts": {
      "example.com": "192.0.2.10"
    },
    "servers": ["1.1.1.1"],
    "queryStrategy": "UseIPv4"
  }
}

示例中的静态地址属于文档用途，不能作为真实网站连通性的测试目标。实际配置应删除这条示例映射，或填写自己管理的域名与正确地址。静态映射适合明确且稳定的内部服务，不适合长期固定内容分发服务的地址。后者可能因地区、网络和时间返回不同结果，强行固定后反而会造成连接错误。

优化前先建立对照

一次只比较一个变化：保留同一活动服务器、同一路由方案和同一个测试域名，仅更换解析路径，再建立新连接。若同时更换服务器与 DNS，结果变好也无法确定原因。系统查询工具只能证明它自己使用的解析路径，不能直接证明内核 DNS 工作正常。应结合内核日志和实际应用请求，观察查询目标、返回类型及后续连接使用的地址。

IPv4 与 IPv6 要和实际出口能力对应。查询得到 IPv6 地址但出口缺少可用 IPv6 路径时，应用可能等待失败后才回退，看起来像 DNS 很慢。临时限定 IPv4 可以用于定位，但不宜把它当作所有网络的固定答案。若业务需要 IPv6，应同时检查本地网络、代理服务器、内核出站和路由网段，不能只保留 AAAA 响应而忽略后续连通性。

理解加密查询与缓存边界

使用加密 DNS 时，还要考虑解析服务本身的连接路径、证书名称及引导解析。解析器写成域名后，该域名仍需要首次解析；某些特殊形式可能在本地直接发起查询，而不是遵循常规出站路由。具体行为应以当前内核支持的 DNS 类型为准。不要仅凭地址以加密协议开头，就推断查询一定经过活动代理。

配置保存后，客户端缓存、操作系统缓存、浏览器缓存和应用长连接可能同时保留旧状态。先重新建立测试连接，再按需要清理相应层的缓存，不必每次重置整个网络。若内核日志已经得到正确地址而应用仍访问旧目标，应检查应用缓存。TUN 下还需核对 DNS 接管是否真正覆盖目标请求；未被接管的查询不会因为内置 DNS 字段变化而自动改变路径。

TUN 模式与虚拟网卡接管

系统代理是向应用公布本地代理入口，应用是否使用它取决于自身实现。TUN 则通过虚拟网卡及系统路由，把符合条件的 IP 流量送入处理链。两者入口不同，不能简单理解为同一个开关的强弱档位。只有在常规系统代理已经工作、而某些程序不读取代理设置时，才有必要继续评估 TUN，避免把基础配置错误带进更复杂的接管环境。

开启前检查权限与原有路由

先记录当前路由方案、活动服务器和 DNS 设置，确认关闭 TUN 后仍能恢复常规连接。然后检查是否已经运行其他虚拟专用网络、虚拟网卡工具或流量接管程序。多个工具同时争夺默认路由时，表面上都显示已启用，实际流量却可能进入另一条链。测试阶段只保留一套接管机制，确定各自的工作范围后再考虑共存。

在 Windows 上，创建虚拟网卡和修改路由通常需要管理员权限；在 macOS 与 Linux 上，可能需要系统授权或相应服务组件。应按当前 v2rayN 界面的权限提示操作，不要反复使用普通权限启动后只看开关颜色。权限失败、组件缺失和配置语法错误属于不同问题，需要分别从启动日志中确认。安装包选择可回到客户端下载页，按系统与处理器架构核对。

v2rayN 的 TUN 功能可能交由独立的接管后端处理，而不是直接在 V2Fly 或 Xray JSON 中增加一个通用字段。因此不能把网络上的任意 TUN 配置片段当作所有内核通用语法。优先用客户端提供的开关和设置项，让客户端负责生成对应后端配置；只有确认后端类型及配置入口之后，才继续编辑高级参数。

分阶段启用并观察连接

开启后依次检查虚拟网卡是否创建、路由是否加入、DNS 是否按预期接管、目标应用是否出现新的连接日志。开关点亮只代表用户请求了启用，不一定代表每一步完成。先测试一个普通网页，再测试原本不读取系统代理的应用。如果网页也失败，先恢复关闭状态确认基础连接，不要同时修改 MTU、路由表和服务器参数。

代理服务器自身的连接必须有正确的出口，不能再次被接管回同一条代理链。客户端通常会生成排除或保护机制，但多网卡、移动热点和网络切换仍可能影响出口选择。若日志持续出现重复连接、连接数异常增长或服务器地址反复进入接管链，应先停用 TUN，检查服务器地址的排除方式以及默认出口网卡，而不是继续提高重试次数。

局域网排除规则应覆盖实际网络，而不是只复制常见私有网段。公司网络、虚拟机和容器网络可能使用其他地址段，也可能依赖特定接口。若只在连接办公网络后失败，先对比接入前后的路由变化。允许局域网设备连接本机代理是另一项功能，涉及监听地址和防火墙，不能用 TUN 开关代替；相关步骤见局域网代理共享设置。

区分传输能力与网卡接管

TUN 能接收到某类数据包，不代表远端出站就能正确转发它。UDP 应用还取决于服务器配置、传输方式和网络环境。某些探测工具使用的控制报文，也不适合直接作为代理业务可用性的标准。验证应使用目标应用真实需要的协议，并在日志中确认转发链路，而不是把单一探测结果当成全部网络状态。

遇到部分页面加载停滞时，可以在确认 DNS、路由和 UDP 路径之后再检查 MTU。较大的数据包在某些链路上可能遇到分片或路径探测问题，但盲目缩小 MTU 会掩盖真正原因。每次记录原值、调整一项并复测同一业务；无改善就恢复。更细的开启与回退顺序可参照v2rayN TUN 模式设置，保持可回退比一次开启所有高级项更重要。

FakeDNS 映射与域名恢复

FakeDNS 返回的不是目标服务的真实地址，而是一个由代理维护映射关系的合成地址。应用连接该地址后，处理链通过映射找回原始域名，再进行路由或远端连接。它解决的是某些入口只能看到 IP、难以继续按域名处理的问题，不是给普通 DNS 查询增加缓存的另一个名称。理解这一点后，才能判断当前入口是否需要它。

启用条件是完整的映射链

可用链路至少包括四个环节：查询进入 FakeDNS、应用收到合成地址、连接回到维护映射的处理器、处理器恢复域名并选出站。缺少任意一环，合成地址都可能被当成普通地址发往网络。只在配置中写一个地址池，而没有接管查询及后续连接，不会自动形成完整功能。先确认客户端当前后端确实提供对应能力，再考虑启用。

V2Fly 风格的 FakeDNS 配置与某些 TUN 后端的合成地址功能不是同一套语法。即使名称相近，它们也可能有不同的地址池、缓存、持久化及域名排除方式。不能把一套后端的开关与另一套后端的地址池拼成配置。以下片段仅展示支持该语法的 V2Fly 配置中，地址池、DNS 与入站嗅探的关联；合并时仍需保留完整出站和现有路由。

{
  "fakedns": [
    {
      "ipPool": "198.18.0.0/15",
      "poolSize": 65535
    }
  ],
  "dns": {
    "servers": ["fakedns"]
  },
  "inbounds": [
    {
      "tag": "local-socks",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "udp": true
      },
      "sniffing": {
        "enabled": true,
        "destOverride": ["fakedns"]
      }
    }
  ]
}

这个片段不负责把操作系统的 DNS 自动送入内核。若应用从其他解析器获得真实地址，FakeDNS 池就不会参与那次请求；若应用获得合成地址却绕开代理直连，同样会失败。测试时应确认查询和连接都经过同一处理链。当前 Xray 或其他后端是否支持相同字段，应查看客户端实际提供的配置选项，不能以本段示例代替兼容性确认。

地址池不是可访问的目标网段

合成地址池必须与正在使用的网络规划分开检查。示例地址段常用于此类映射，但某些测试环境或内部网络也可能实际使用它。若网段重叠，系统无法仅凭目标 IP 判断连接究竟属于真实服务还是合成映射。应先核对路由表和内部网络用途，再使用后端允许的地址池；不要随意改成一个公网网段来回避冲突。

池容量限制的是可维护的映射规模，不等于同时在线的连接数量。大量域名、频繁网络切换或应用长期缓存，都可能让旧地址与当前映射关系失配。重启内核后，应用仍可能持有旧的合成地址，此时需要让应用重新查询，而不是一直重试旧连接。只清理浏览器页面并不一定清理系统缓存，应根据实际缓存所在层处理。

有些应用会检查目标地址是否属于特殊网段，或把查询结果写入长期存储。此类程序可能不适合使用合成地址。需要排除时，应在支持该功能的 DNS 规则中让特定域名返回真实结果，同时保证其真实连接仍按所需路径处理。排除 DNS 合成和选择直连不是一回事：返回真实地址之后，连接仍然可以走代理出站。

与域名路由共同验证

开启后先验证一个域名：日志中应能看到合成地址被还原到域名，随后命中预期规则。如果看到合成地址直接落入通用 IP 规则，应检查恢复环节，而不是给整个地址池强行指定某个出站。把地址池全部转发可能暂时改变现象，却不能补回丢失的域名，也可能让远端收到没有意义的目标地址。

如果原先的 SOCKS 域名入口已经能够稳定按域名分流，增加 FakeDNS 未必带来收益。它更适合确实需要从 IP 入口恢复域名、且查询与连接能一起受控的场景。完成测试后记录启用原因、适用入口、排除域名和回退方法；后续换内核或换接管后端时重新验证，不要仅复制原地址池就认为迁移完成。

多订阅管理与更新边界

多订阅管理首先解决来源和用途的可追踪性，而不是把所有服务器堆进一个列表。建议一个来源对应一个基础分组，再用独立的本地分组保存手工实验。若同一来源确实有不同业务入口，应在备注中说明用途，避免几个名称近似的分组重复更新。分组结构清楚后，才能解释条目来自哪里、为什么变化，以及哪个配置应该承担日常连接。

把同步数据与本地修改分开

订阅返回的服务器参数属于来源维护的数据，本地备注、排序和手工调整则属于客户端状态。更新是否保留这些状态取决于客户端的条目识别方式，不能假定名称相同就必然视为同一个对象。来源调整名称、端口或标识后，客户端可能重建条目。因此重要的本地改动应复制到手工分组，并写清修改目的，原始分组保持同步职责。

重复配置不宜只按显示名称删除。两个同名条目可能使用不同端口、协议、传输或安全设置；两个异名条目也可能指向相同端点。整理时先看来源，再对比连接参数和实际用途。若客户端提供去重功能，应先了解它依据哪些字段判断重复，并在导出设置后操作。对不确定的条目先移到测试范围观察，比直接批量清空更容易恢复。

本地分组与订阅分组还应采用不同的更新策略。手工分组不需要填写订阅地址，避免误以为保存一个来源链接就能自动维护其中所有修改。若订阅更新后协议参数发生变化，应先在原始分组验证新的服务器，再决定如何迁移本地实验项。不要把旧参数重新覆盖到来源条目上，否则下次更新还会再次冲突。

设计更新顺序与故障替代

先确定至少一个来源能在当前网络直连更新，还是所有来源都依赖代理。如果需要代理更新，活动服务器的选择会影响更新成功率。日常更新可以逐组进行：先更新非活动来源，确认可连接后，再更新当前来源。这样能减少活动连接与配置同步同时变化的情况，也能在某组响应异常时保留可工作的对照。

多个订阅并不等于自动故障切换。普通分组只是组织配置，切换活动服务器往往仍需用户操作。只有明确配置了客户端支持的选择或调度机制，才应预期自动改用其他出站；调度所需的探测条件也要另外验证。不要因为列表里存在多条服务器，就假定连接失败时内核会自动寻找下一条。

测速结果也不能直接决定长期优先级。连接建立、网页访问和持续传输测试关注不同指标，测试目标自身还会影响结果。先按业务需求选择测试类型，再比较同一条件下的结果。测试期间保留相同网络、路由和 DNS，避免把网络切换引起的差异归因于订阅来源。某条配置测试失败时，还应确认它是否需要当前尚未启用的协议或传输能力。

迁移设置与保护订阅入口

迁移电脑前，分别确认客户端设置、订阅地址和本地手工服务器是否都在导出范围。某些导出只包含服务器，不包含路由、DNS 或接管选项。导入后应逐项检查，不要看到条目齐全就直接启用 TUN。先验证普通代理，再恢复分流，最后恢复高级接管，能把迁移错误限制在明确层级。

订阅地址通常具有访问能力，应按敏感配置保存。分享排错信息时保留错误类型和状态，遮去完整地址、身份参数及服务器认证信息。遇到疑似入口泄露，应在来源端重新生成地址并更新客户端；只改分组备注没有作用。删除停用来源后，也要检查是否仍有复制到本地分组的旧条目，避免后续误选。

当多个来源同时更新失败，优先检查共同依赖：系统时间、DNS、当前网络、代理更新路径和本地防火墙。只有单一来源失败时，才重点检查该来源的地址与响应。按这个顺序能避免把全局故障逐个归咎于不同订阅。若浏览器能访问而客户端更新失败，应继续比较两者的代理和解析路径，不能只凭浏览器正常就排除本机设置问题。

自定义出站与配置闭环验证

出站描述内核如何把请求送往下一跳，路由则负责选择出站。自定义出站适合需要特殊上游、固定本地转发链或明确链式连接的情况，不是导入普通订阅的必要步骤。开始前先在 v2rayN 中保留一套已验证的普通配置，确认当前使用的是客户端管理的服务器、完整自定义配置，还是可合并的配置片段。这三种入口对字段覆盖和保存行为的要求不同。

用标记连接入站、规则和出站

tag 是配置内部的名称。路由中的 outboundTag 必须与已有出站的标记逐字对应，大小写和拼写都不能随意变化。建议使用能说明职责的短名称，不要把服务器密码或完整地址塞进标记。标记缺失、重复或指向不存在的对象，都可能导致启动失败或实际选路偏离预期。

下面是一份可独立启动的本地转发示例，采用 V2Fly 与兼容 Xray 的常见结构：在回环地址开放 SOCKS 入站，把所有业务转交给本机另一个 SOCKS 服务。它要求本机端口 20808 已有独立上游运行；若没有，该示例仍可用于检查配置结构，但实际连接会失败。它不包含远端服务器凭据，不能代替订阅提供的真实配置。

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "tag": "local-in",
      "listen": "127.0.0.1",
      "port": 10818,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": false
      }
    }
  ],
  "outbounds": [
    {
      "tag": "upstream-socks",
      "protocol": "socks",
      "settings": {
        "servers": [
          {
            "address": "127.0.0.1",
            "port": 20808
          }
        ]
      }
    },
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    }
  ],
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "network": "tcp",
        "outboundTag": "upstream-socks"
      }
    ]
  }
}

示例把 UDP 关闭，是为了让验证范围保持为 TCP，不对上游的 UDP 能力作出假设。监听地址限定在回环接口，因此只供本机使用。不要为了方便测试就把它改为所有网卡监听；若确需共享，应另外处理来源限制、身份认证和防火墙。端口也不能与现有客户端监听冲突，否则启动失败与远端连通性无关。

避免链式连接产生回环

转发链最常见的错误是入口又指向自己，或者上游通过系统代理再次回到当前入口。配置前把链画成明确顺序：应用、本地入站、选中的出站、独立上游、最终目标。每一跳记录监听地址和端口，不能仅写“走代理”。若上游也启用了 TUN，还要确认连接到上游服务器的流量不会重新被下游接管。

域名在哪一跳解析也需要明确。应用传递域名时，上游 SOCKS 服务可能继续处理该域名；应用预先传入 IP 时，后续链路通常只能使用这个地址，除非存在可靠的恢复机制。出站链不会自动修正错误解析，也不会让不支持某种传输的上游突然具备相应能力。测试链式连接时应先验证上游独立可用，再增加下游转发。

自定义完整配置可能绕过客户端自动生成的部分路由和 DNS。保存前应查看界面说明，确认系统代理入口仍指向实际监听端口。不要在图形界面改了路由后，假定自定义配置也会同步变化。相反，临时生成文件可能在下次启动时被覆盖，长期维护应放在客户端正式支持的配置入口，并保留原始文件作为回退依据。

按结构、入口、选路、出口验收

先检查 JSON 语法，再检查内核是否支持各字段。合法 JSON 只代表括号、逗号和字符串结构正确，不代表配置语义成立。启动日志中若出现未知协议、找不到标记或端口占用，应先解决这些本地错误。内核稳定启动后，再从单个应用发起请求，观察入站是否收到连接、路由是否选择预期出站、上游是否接受连接。

若浏览器成功而终端失败，先检查终端是否真正使用本地入口，而不是继续修改出站。部分终端程序需要单独设置代理环境或参数，系统代理不会统一覆盖它们。具体排查可参照系统代理不生效：浏览器与终端分别排查。每次验收都应使用新连接，旧会话仍可能保留原来的出口。

最后记录四项结果：配置能否加载、目标请求走哪条规则、使用哪个出站、关闭高级功能后能否恢复。再分别验证订阅更新、局域网访问和必要的 UDP 业务，避免只测试一个网页。完成后恢复日常日志级别，移除临时规则与多余入口。后续更换客户端或内核时按同一顺序复测，配置文件能够导入不等于全部行为已经保持一致。