V2Ray 进阶配置
订阅、路由与 DNS

配置层级与回退基线

先区分界面、内核与系统

一次访问能否成功，并不只取决于服务器参数。图形客户端保存订阅、当前服务器与界面选项，随后生成内核能够读取的配置；内核负责入站监听、路由匹配、名称解析和出站连接；操作系统则决定应用流量是否进入客户端。排查时要先确认错误发生在哪一层。例如，浏览器未遵循系统代理属于流量入口问题，内核提示出站标签不存在属于配置引用问题，两者不应通过同一种开关处理。

v2rayN 的“参数设置”“路由设置”和主窗口的系统代理选项分别影响不同环节。“自动配置系统代理”通常只改变系统提供给应用的代理入口，并不等于启用虚拟网卡；“启用 Tun”会引入另一条流量接管路径。Android 端的 v2rayNG 使用系统 VPN 接口承接流量，“路由设置”负责进入内核后的分流。界面中的“绕过大陆”还可能涉及不同规则模板，不能仅凭相同名称判断最终生成内容完全一致。

建立可以重复验证的基线

开始前先保留当前可用配置：记录客户端名称、所选内核、当前服务器、路由模式、系统代理状态以及 DNS 相关开关。通过客户端提供的备份或导出功能保存设置时，注意文件可能包含订阅地址、连接标识和认证信息，应放在受控目录。若需要截图求助，先遮盖这些内容。不要把包含凭据的整份配置直接贴到公开讨论中，也不要只截最后一行错误而丢掉发生问题前的操作背景。

验证基线宜选三个有代表性的动作：通过明确使用代理的应用打开普通网页，访问局域网中的自有服务，再测试日常使用的业务应用。记录的是成功与失败、错误类型和出现条件，而非单个延迟数值。浏览器打开网页成功，不能证明其他应用已被接管；局域网访问正常，也不能证明 DNS 查询经过了预期路径。同一动作在改动前后重复执行，才有比较意义。

一次只改变一个变量

建议依次调整订阅组织、路由、DNS，最后再启用 TUN 和 FakeDNS。每完成一项，重新连接并重复基线测试。如果客户端要求重启内核，应确认日志确实出现新的启动过程，而不是只关闭了设置窗口。更换内核之前先核对协议与安全参数支持范围，尤其是 REALITY 等设置；具体差异可参考Xray 与 V2Fly 内核差异，不以名称相近推断兼容。

遇到故障时，按修改顺序逆向撤销：先关掉新加的接管或解析功能，再恢复路由模板，最后恢复原有服务器。撤销后仍失败，才继续检查系统代理残留、网络切换和其他 VPN。更新客户端前可到安装包页面选择对应平台，但不要在排查同一问题时同时换客户端、换内核、换订阅。这样会失去因果线索，也让原本能解释的错误变成无法复现的偶发现象。

订阅分组与服务器过滤

分组先表达来源，再表达用途

订阅分组的首要作用是保留来源边界。v2rayN 中可从“订阅分组”进入分组管理，为一个订阅地址建立独立条目，并填写可辨认的备注。备注宜描述来源或用途，不写密码与完整链接。同一来源的订阅如果需要不同筛选条件，可以拆成不同分组，但应确认更新后不会产生难以区分的重复条目。手动导入的连接也最好放入独立分组，避免与订阅重新生成的服务器混在一起。

v2rayNG 通常在侧栏“订阅分组设置”中维护地址，再回主界面执行订阅更新；v2flyNG 的入口与可用字段应以实际界面为准。保存订阅地址不等于已经下载到服务器列表，更新成功也不等于已经选中可用服务器。操作完成后应核对当前分组、列表内容和当前活动项。若更新后列表为空，先判断是远端未返回内容、格式无法解析，还是客户端筛选阶段排除了全部条目。

过滤只处理列表，不替代访问控制

服务器过滤通常按备注文本、协议类型或客户端提供的条件保留条目。它改变的是导入或显示结果，并不会限制应用能访问哪些目标，也不会自动建立分流策略。名称中包含某个地区词，并不证明连接实际出口或能力符合预期；过滤适合减少列表干扰，不适合作为安全边界。首次设置时先不启用过滤，确认完整订阅能够解析，再加入一个容易验证的条件观察结果。

不同客户端的过滤字段可能采用普通关键词、正则表达式，或单独的包含与排除规则。先阅读字段旁的提示，不要把正则写进只接受字面文本的输入框。若字段明确支持正则，竖线表示“或”，括号用于分组，点号默认匹配任意字符；需要匹配字面点号时应转义。大小写是否敏感、包含与排除谁先执行，应按当前客户端实际结果确认，不要凭另一款软件的习惯套用。

(?i)(实验|备用)

上例仅用于支持相应正则语法的字段，表示不区分大小写地匹配“实验”或“备用”。它没有固定的保留或删除含义，具体取决于输入位置是包含条件还是排除条件。先用测试分组验证，不要直接应用到唯一可用的生产分组。服务器备注来自订阅提供方，后续可能改名，依赖备注的过滤也会随之改变；重要条目消失时，应先暂时清空条件重新更新，而不是立即重新购买或更换来源。

区分更新路径和业务路径

订阅更新本身也是一次网络请求。客户端如果提供“通过代理更新”与普通更新两种操作，应按订阅地址的可达性选择。当前代理已经失效时，继续通过该代理获取修复后的列表，容易形成依赖循环；反之，订阅地址只能通过当前连接访问，直连更新也可能失败。排查时分别验证更新请求和业务连接，不把“网页能打开”当作订阅接口一定可用的证据。

更新完成后，观察活动服务器是否仍属于原订阅。有些更新过程会重建条目，旧的选中记录不一定还能对应新列表。确认协议字段、传输方式与安全选项仍存在后，再设置为活动项。若客户端报告不支持某类连接格式，不应通过改文件扩展名或只保留部分字段强行导入；应核对所选客户端与内核是否支持该格式，再向订阅提供方确认输出类型。

当列表为空、导入提示格式错误或更新时出现网络异常，可按订阅解析失败自查清单逐项定位。先禁用过滤、核对来源和更新路径，再检查编码与响应内容。分组管理解决的是配置来源的可追溯性，连接质量与协议兼容性仍需在选中服务器后独立验证。

路由规则实战

规则顺序先于规则数量

路由的输入是内核已经收到的连接信息，输出是选中的出站。v2rayN 中从“路由设置”查看当前方案，先确认主窗口选中的是该方案，再编辑规则。Xray 与 V2Fly 常见路由行为是按顺序查找首条匹配规则；同一条规则内部，不同字段通常共同约束，某一域名或 IP 列表内部则可以匹配其中之一。把域名与端口同时写进一条规则，意味着同时满足，而不是任意满足。

实用的顺序通常是：确有需要的局域网直连规则、业务专用规则、通用分类规则，最后由默认出站承接未命中流量。不要把匹配范围过宽的规则放在最前面，否则后面的精细条件不会获得机会。“绕过大陆”等预设适合作为起点，但具体包含哪些域名集合、IP 集合和解析策略，要查看当前方案或生成结果。界面名字只是方案入口，不是完整规则说明。

域名规则与 IP 规则分别覆盖什么

full: 用于完整域名匹配，domain: 用于域名及其子域匹配，geosite: 引用域名分类资源，geoip: 引用 IP 分类资源。以下片段展示显式域名和私有地址直连的写法，前提是完整配置中存在名为 direct 的出站。使用客户端规则编辑器时，应把条件填入对应字段，不要将整个路由对象粘进单个域名输入框。

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

这里的示例域名仅用于说明匹配语法，应换成实际要管理的业务域名。IP 规则不能天然覆盖域名规则：域名可能解析到多个地址，也可能在不同网络下返回不同结果。相反，只写域名规则也不一定能识别直接访问 IP 的应用。对于局域网服务，应同时考虑访问方式、DNS 返回地址与虚拟网卡路由；某些服务名还依赖本地发现协议，并非添加一条域名规则就能解决。

路由解析策略不等于 DNS 出站策略

AsIs 尽量使用已有目标信息匹配，IPIfNonMatch 在域名规则未匹配时尝试解析后继续匹配 IP 条件，IPOnDemand 则可能在匹配需要 IP 的规则时触发解析。它们决定路由阶段何时需要地址信息，不直接规定 DNS 请求走哪条出站。若同时调整了解析策略与 DNS 服务器，故障来源会混在一起；应先固定解析服务，再比较策略变化带来的命中差异。

嗅探可以在支持的流量中辅助获取域名信息，但不是所有协议都能可靠识别。加密封装、应用直接使用 IP、连接复用或元数据不足，都可能影响判断。启用嗅探后还要了解目标地址是否被重写；只想补充路由信息时，应查看当前内核是否提供相应的仅路由选项。不要把嗅探当作域名规则一定命中的保证，更不要依赖它弥补所有 DNS 配置缺失。

用日志验证实际命中

保存规则后重新加载内核，发起一个新连接，并在日志中确认使用的出站标签。已有长连接可能继续沿用旧路径，浏览器缓存与后台连接也会干扰观察，必要时关闭测试应用后再打开。发现规则不生效时，先检查活动方案，再检查排在前面的规则，随后确认内核拿到的是域名还是 IP，最后检查分类资源是否存在。缺少资源文件通常会在启动阶段报错，不应通过反复重连掩盖。

默认行为也必须明确。对于这类内核，未命中规则的连接通常交给完整配置中的首个出站；图形客户端可能据此安排默认代理或直连。不要只读规则列表就推断兜底方向。需要固定行为时，应使用客户端提供的默认规则设置，或在自定义配置中明确设计末尾匹配，同时确认没有覆盖管理流量的特殊要求。术语可查术语表，常见连接异常见疑难解答。

DNS 配置优化

分别画出业务连接与查询路径

DNS 配置首先要回答三个问题：谁发起查询、谁返回结果、查询通过哪条网络路径到达解析服务。应用可能直接使用系统解析，也可能自带加密 DNS；内核还可能为路由匹配、连接目标或解析服务器地址发起查询。因此，客户端中填入一个远程 DNS 地址，并不表示系统中的所有查询都经过它。先确认应用流量是否进入客户端，再讨论解析请求是否被内核处理。

v2rayN 可在“参数设置”中查找 DNS 相关配置，v2rayNG 可在“设置”中检查“启用本地 DNS”、远程 DNS 与域名策略等选项。界面所称“本地”往往指客户端侧的 DNS 处理模块，不必然代表请求只发往局域网。不同客户端生成配置的方式也不同，开启开关后应查看日志或生成内容，确认所用服务器和策略，而不是仅以开关颜色判断配置已经完整生效。

先分清三个容易混淆的策略

下面是内核 DNS 对象的局部示例，表达限定查询 IPv4 地址并指定解析服务器。它不包含 DNS 流量的路由设计，也不意味着该请求天然经过代理。配置加密 DNS 时还需核对当前内核支持的地址语法、证书验证及域名解析入口。若解析服务器地址本身是域名，要确认首次解析依赖哪个可用解析器，避免“必须先解析才能连接，而解析又依赖该连接”的循环。

{
  "dns": {
    "queryStrategy": "UseIPv4",
    "servers": [
      "1.1.1.1"
    ]
  }
}

按业务边界选择解析方式

局域网内部域名通常依赖路由器、企业 DNS 或搜索域，应保留对应的本地解析路径。将所有查询强行交给公共解析器，可能导致内部服务无法找到地址。外部业务则需要让解析结果与所选出站具有合理的一致性：如果目标使用地域化分发，解析所在网络与实际出口不同，可能获得不合适的地址。优化重点不是堆叠更多服务器，而是为每类域名安排可解释的解析与连接路径。

配置多个 DNS 服务器时，不应假定它们一定按列表顺序逐一尝试。内核可能根据域名条件并行查询或合并结果，回退字段的支持也随实现变化。先用单个稳定的解析路径确认可用，再引入按域名选择的服务器，并检查默认回退能否覆盖剩余目标。对于不能向外部解析器发送的内部域名，应明确排除公共回退，而不是只在列表前面加一个内网地址。

缓存、双栈与日志的排查顺序

更改 DNS 后，应用缓存、系统缓存和内核缓存可能仍保留旧结果。关闭并重新启动测试应用，再按系统提供的方式刷新解析缓存，必要时重启客户端内核。不要在每次失败后立即切换解析器，否则缓存会让前后结果难以比较。日志里若出现超时，先核对查询路径是否可达；出现地址后连接仍失败，则继续检查目标地址族、路由与远端连接，不再只围绕 DNS 开关尝试。

IPv6 问题应区分“能查到地址”和“能完成连接”。网络可能返回 IPv6 地址，却没有可靠的 IPv6 出口或正确的虚拟网卡路由。临时限制地址族可以帮助定位，但不应被当作所有环境的固定优化。反过来，在依赖 IPv6 的网络中只查询 IPv4 也可能破坏可达性。完成诊断后应恢复与当前网络能力一致的策略，并用新连接验证，不根据单次网页加载速度判断整个解析方案。

TUN 模式

接管范围改变，不代表规则失效

TUN 通过虚拟网卡与系统路由把符合条件的 IP 流量送入客户端，适合不遵循系统代理的应用。它改变的是流量进入方式，不会自动决定所有目标都走远端代理。进入客户端后，业务仍需按照路由规则选择直连、代理或阻断。因此，“启用 Tun”与“全局代理”不是同一个概念；即使接管范围扩大，局域网直连、内部 DNS 和业务例外仍需按实际需求保留。

桌面端使用 v2rayN 时，先关闭其他可能接管系统路由的 VPN 或虚拟网卡工具，再按平台提示授予创建接口、修改路由所需的权限。权限不足可能导致界面显示已切换，但网卡或路由并未建立。不要通过长期关闭防火墙解决启动问题，应先查看客户端与系统日志，确认失败的是权限申请、接口创建还是规则安装，再按最小范围调整系统设置。

从系统代理逐步切换到 TUN

启用前先在普通代理入口验证当前服务器可用，并记录原有路由模式。随后在 v2rayN 主窗口切换“启用 Tun”，观察内核启动和虚拟网卡状态。首次测试可让系统代理保持一个明确且可回退的状态，避免应用手动代理、系统代理和 TUN 同时叠加造成判断困难。若需要同时使用，应了解各入口使用的监听地址和流量走向，而不是简单认为入口越多越完整。

测试按三个方向进行：明确不使用系统代理的应用是否能访问预期目标，局域网设备是否仍可达，DNS 是否按照设计解析。浏览器本身遵循系统代理时，即使 TUN 接管失败也可能表现正常，因此不能只用它验证。访问内部业务时，同时测试域名与已知内部地址；前者失败而后者成功，通常应回到 DNS 与搜索域检查，而不是继续修改远端服务器。

路由循环与虚拟网卡冲突

TUN 需要避免把客户端发往远端服务器的连接再次送回自身，否则会产生循环。客户端通常会通过接口绑定、路由排除或进程处理避免这种情况，但自定义规则、多个 VPN 同时运行和网络接口变化都可能破坏条件。出现启用后所有连接超时、日志重复连接相同目标时，先关闭新启用的接管功能，再确认当前默认网卡与服务器出口路径。不要直接增加更宽泛的代理规则。

网络从有线切换到无线、休眠后恢复或连接企业 VPN，都可能改变接口顺序和路由优先级。若 TUN 只在切网后失败，可先重新连接客户端，让它按新网络重建状态；若每次都失败，应检查是否固定绑定了已失效的接口。Linux 与 macOS 的系统授权方式、网卡名称和路由管理不同，不能照搬 Windows 的处理步骤。具体操作以当前客户端的权限提示和系统网络管理方式为准。

UDP、MTU 与恢复路径

TUN 能接收某类流量，不代表远端协议、传输与服务端都支持同样的转发能力。遇到 UDP 业务失败时，先确认当前连接的完整链路是否支持 UDP，再检查规则是否把该业务送到正确出站。只有大响应、文件传输或特定应用卡住，而普通短请求正常时，才考虑 MTU、路径发现或分片问题。不要无依据地不断降低 MTU；应保留原值，每次调整后用同一业务验证。

退出客户端前，优先在界面关闭 TUN 并正常退出，让程序撤销路由和接口状态。异常终止后若网络没有恢复，先查看系统代理是否仍指向已停止的本地端口，再检查其他 VPN 与残留网卡状态。必要时通过系统网络设置恢复连接，但应避免在不了解用途时删除正在使用的企业网络配置。恢复普通联网后，重新建立本章的最小测试，而不是立即重新叠加全部功能。

FakeDNS

合成地址保存域名映射

FakeDNS 并不是返回目标真实地址的普通解析器。它从专用地址池分配一个合成地址，将域名与地址的对应关系保存在内核中；应用随后连接该地址时，内核再根据映射恢复目标域名，继续执行路由与出站处理。这样可以在部分接管场景中保留域名信息，减少先解析真实地址才能决定分流的需求。但它依赖完整的 DNS、流量接管与域名恢复链路，单独打开开关并不构成完整方案。

v2rayNG 中可在“设置”查看“Fake DNS”相关选项，同时核对“启用本地 DNS”和当前路由设置。不同内核与客户端对所需配置的自动生成程度不同，应以实际生成结果和启动日志为准。v2flyNG 不应仅因界面相似就沿用同一组参数。建议先完成普通 DNS 和路由基线，再测试 FakeDNS；若仍处在无法正常联网的阶段，额外引入合成地址只会增加排错层次。

地址池、查询入口与恢复能力

以下是常见内核语法中的局部示例，包含合成地址池、DNS 服务入口和入站嗅探相关字段。它们需要合并到相应位置，不是把整个对象随意粘入客户端某个开关旁的输入框。示例中的嗅探对象属于入站配置内容；完整配置中还应存在可处理该流量的入站、路由和出站。地址池不能与实际使用的业务网段冲突，也不应配置成任意公共地址段。

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

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

上例地址段用于测试网络用途，出现在此处是合成地址池示意，不是实际服务器地址。地址池大小决定可保存映射的容量，不能把扩大容量当作通用性能优化。更重要的是让应用拿到的合成地址始终回到掌握映射的同一内核。若查询由一个客户端应答，连接却被另一个 VPN 接管，或者应用把地址保留到内核重启后再用，恢复关系就可能丢失。

按应用行为判断是否适用

适合测试的场景是：应用主要通过域名访问，查询与后续连接都被同一客户端接管，并且希望路由阶段更稳定地获得域名。可能不适合的场景包括依赖真实地址做业务判断的应用、需要把解析结果交给其他设备的服务，以及内网业务与测试地址段发生冲突的环境。某些应用会检查解析地址属性、缓存结果或绕过系统 DNS，这些行为都会让 FakeDNS 的效果与普通浏览器测试不同。

应用如果使用自己的加密 DNS，查询可能不会进入 FakeDNS 处理模块。此时开关已启用，但目标仍获得真实地址，并不一定是内核故障。反过来，应用拿到合成地址后若绕过客户端直连，连接就会失败。排查时应分别确认查询是否命中合成解析、连接是否被接管，以及内核是否完成域名恢复，不要只根据“看到了特殊地址”判断整个链路已经正确。

开启与关闭都需要处理缓存

开启后，先重新启动测试应用，让它发起新的解析请求，再测试普通网页、局域网服务和一个日常业务。若局域网域名被错误合成，可按当前客户端能力为内部域名保留真实解析，并确认对应连接直连。需要注意，DNS 规则中的排除、路由规则中的直连和系统路由中的绕过分别作用于不同阶段，只完成其中一项不一定足够。

关闭 FakeDNS 后，应用或系统可能仍缓存合成地址，而内核已经不再保存映射。这会造成“关闭后反而暂时不能连接”的现象。先停止测试应用、清理相应缓存并重新建立连接，再判断回退是否成功。客户端重启同样可能改变映射状态，因此长时间运行的应用应纳入测试。详细机制与使用边界可继续阅读FakeDNS 工作原理与适用场景。

多订阅管理

建立来源、用途与更新的对应关系

管理多个订阅时，先给每个来源建立独立分组，再决定哪些条目用于日常连接，哪些仅用于兼容性测试。不要先把所有连接合并成一个大列表再靠备注猜来源。分组名称可以表达“日常”“测试”“手动配置”等用途，但还应通过本地记录保持与来源的对应关系。订阅地址可能随账号重置而变化，名称不变并不意味着它仍指向原来的配置集合。

在 v2rayN 的“订阅分组”中检查每组地址、过滤条件和更新方式，按客户端提供的选项设置更新周期。Android 端可在“订阅分组设置”中维护来源，再分别执行更新。先逐组验证，确认每个来源都能独立解析，最后再使用“更新全部订阅”一类批量操作。这样出现部分失败时，可以直接定位来源，而不是把所有网络异常都归结为客户端故障。

更新频率与活动项应分别管理

频繁更新并不等于连接更稳定。更新请求需要网络和服务端处理，也可能触发来源的访问限制。根据服务提供方的使用说明和实际变更频率安排即可，不必用极短周期反复刷新。移动设备还需考虑后台运行限制：系统省电策略可能延后任务，界面设置的间隔不等于每次都按时执行。需要使用前，可手动更新指定分组并确认结果，而不是只依赖后台状态。

更新后应复核当前活动服务器。订阅可能删除旧条目、改变备注或调整安全参数，客户端也可能重新生成内部标识。旧的收藏、排序和路由绑定是否仍然有效，需要以当前界面为准。不要只看活动名称相同就认为参数没有变化；对自定义出站或按标签引用的配置，应进一步检查引用仍指向预期对象。日常使用的条目最好保留清晰的本地用途说明，方便更新后核对。

重复条目与跨设备迁移

重复条目可能来自多个订阅包含同一连接，也可能是手动导入和订阅更新并存。判断是否重复不能只比较备注，应综合地址、端口、协议、安全参数和传输设置。仅因显示名相同就删除其中一项，可能误删了实际用途不同的配置。若客户端提供去重功能，先了解比较标准，并在备份后对测试分组执行。对于来源不同的条目，即使连接参数一致，也可能有不同的更新与撤销边界。

跨设备迁移时，把“订阅来源”和“本机环境”分开。订阅地址可以在有授权的设备之间按需要重新录入，但本地监听端口、TUN 权限、系统代理、按应用代理和内网 DNS 通常不能照搬。v2rayN 的完整配置文件也不应直接当作 v2rayNG 或 v2flyNG 的设置备份。先在目标设备完成基础导入，再逐项复现路由与 DNS 的意图，避免复制只有原设备才存在的路径和接口名称。

失效订阅与凭据撤销

某个来源更新失败时，先保留其他可用分组，不要为了重试而清空全部服务器。确认失败范围只涉及该订阅，再检查地址是否过期、是否需要登录后重新获取，以及更新是否错误地经过失效连接。若地址泄露，应通过来源提供的重置机制撤销旧链接，再更新本机分组；只修改分组备注不会让旧地址失效。同步检查其他设备，避免后台继续请求旧链接。

长期不用的来源应主动移除，同时检查相关收藏、快捷操作和自定义出站引用。导出的备份也可能保留已经撤销的链接，恢复备份后需再次检查。多订阅管理的目标是让每项配置都能追溯来源、解释用途并单独回退，而不是让列表持续变长。若列表维护已经影响日常操作，优先减少重复来源和失去用途的条目，再考虑增加更复杂的自动选择规则。

自定义出站

标签是引用关系，不是连接名称

出站定义内核如何建立目标连接，路由则通过标签选择它。outboundTag 必须引用完整配置中已经存在的 tag，大小写与拼写都要一致。客户端列表中的服务器备注不一定就是内核标签，订阅分组名称也不自动变成可引用出站。编写规则前先确认生成配置的标签结构，尤其要避免把一个可读的界面名称直接填入路由后，误以为内核会自动查找对应服务器。

下面是直连与阻断出站的局部示例，适用于支持这些协议对象的 Xray 或 V2Fly 配置环境。它只定义两个出站，不包含代理服务器、入站与完整路由。若直接用它覆盖现有出站列表，原来的代理连接会消失。图形客户端可能已生成同类标签，合并前要检查是否重名；同名定义会让引用关系不清晰，不能靠调整显示顺序弥补。

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

阻断规则与默认出站要明确

阻断适合已经确认不需要访问的目标，不应把它当成处理所有未知连接的捷径。先使用一个确定不会影响日常业务的测试域名验证规则命中，再考虑扩展。业务应用可能依赖多个域名完成认证、内容加载和更新，只阻断其中一个也可能表现为部分页面异常。遇到问题应从日志确认具体目标，而不是通过更大范围的域名分类反复试错。

{
  "type": "field",
  "domain": ["full:example.invalid"],
  "outboundTag": "block"
}

上例是放入 routing.rules 数组的规则对象，使用专门保留的无效域名说明语法。它需要前述 block 出站存在才有意义。真实业务规则应先核对目标，再按需使用完整域名或子域匹配。与此同时，检查未命中流量的默认去向；若自定义配置把 direct 放在首位且没有兜底规则，默认行为可能与原有客户端方案不同，不能只验证显式规则就结束。

链式连接与选择器不是同一概念

多个出站并列存在，表示路由可以选择不同路径，并不自动组成链式连接。链式连接还需要内核支持的出站转接机制、正确的引用方向与可达性设计；不同内核的具体字段和限制并不完全一致。需要该能力时，应先确认客户端是否提供受支持的前置代理或链式入口，再按当前内核文档配置。不要把多个服务器依次写入数组，就认为连接会按数组顺序逐个经过。

负载选择、故障转移与手动切换也应分别理解。选择器只在一定条件下挑选候选出站，不意味着已建立的连接会自动迁移；探测目标可达也不代表所有业务可用。添加自动机制前，先让每个出站单独工作，确认协议、安全参数与 DNS 路径正确，再设计选择条件。订阅更新若重建了出站标签，还要确保选择器引用随之更新，否则配置可能启动失败或候选集合为空。

使用受支持入口，保留回退副本

v2rayN 中使用自定义配置能力时，应先确认当前配置由界面生成还是由外部文件提供。两种模式的管理边界不同：界面模式可能在重启时覆盖手工编辑的内容，自定义文件模式则可能无法继续使用某些自动生成设置。Android 端同样应从客户端提供的配置入口导入，不要在不清楚文件生命周期时修改内部目录。保存后先查看启动日志，确保不存在字段不识别、标签缺失和资源路径错误。

验证完整配置时，依次检查入站监听、DNS 查询、规则命中和出站连接。内核无法启动时先处理语法与引用；能够启动但无法访问时再检查流量入口和网络路径。日志级别可临时提高以观察问题，定位后恢复日常级别，并妥善处理可能包含目标地址的日志。不要把日志写入不可控的共享目录，也不要为了获得更多输出长期保留包含敏感连接信息的记录。

如果新增出站没有解决明确需求，应回到客户端内置路由方案，减少需要自行维护的配置。协议与内核兼容问题可继续查阅内核差异文章；基础连接恢复按入门指南重新验证。进阶配置的完成标准是每条流量路径都能解释、每项改动都能单独撤销，而不是启用了尽可能多的开关。