v2rayN 高级配置

配置基线与内核边界

进阶配置先从一套能正常工作的基线开始。桌面端首选 v2rayN，安装入口在客户端安装包页面；安卓端可按内核需求选择 v2rayNG 或 v2flyNG。客户端负责保存服务器、生成配置和控制运行状态，内核负责协议连接、路由与解析。界面中存在某个选项，并不代表当前运行的每个内核都按同一种方式处理它。排查前先确认正在使用的客户端、连接协议、内核和接管模式，避免把不同层次的问题混在一起。

保留一条已验证的连接路径

先关闭额外的流量接管功能，使用已知可用的服务器和简单路由，确认浏览器通过系统代理能够正常访问。随后记录本地监听地址、HTTP 或 SOCKS 端口、当前路由方案和 DNS 选项。如果这一步已经失败，暂时不要启用 TUN 或 FakeDNS：新增功能只会增加变量，无法修复错误的节点地址、端口或认证参数。对服务器名称加上“基线”之类的本地备注，也比依靠列表中的固定行号更可靠。

测试要覆盖实际使用场景，而不只看客户端中的一次测试结果。服务器测试成功，通常只说明测试目标经由对应配置完成了请求；它不能证明所有应用都遵循系统代理，也不能保证目标服务的每种连接方式都可用。可以分别打开一个常用网页、完成一次需要登录的正常操作，再观察日志中的出站选择。若某个应用失败而浏览器正常，应先检查应用自己的代理设置、连接协议和缓存，而不是立即更换整套配置。

区分界面设置与原始配置

v2rayN 的服务器编辑、路由编辑和 DNS 设置属于配置入口；运行时生成的文件则是这些入口的结果。直接修改生成文件，可能在切换服务器或重启内核后被覆盖。需要长期保留的调整，应优先在客户端支持的设置入口完成；确实需要自定义配置时，再使用对应的自定义配置功能并单独保存原稿。菜单文字和设置位置可能随界面变化，判断依据应是功能含义与实际生成结果，不是某张旧截图上的坐标。

本页的 JSON 示例明确以 Xray 配置片段为对象，只展示对应字段，不是一份可以独立启动的完整客户端配置。完整配置还需要入站、服务器出站和其他必要参数。使用其他内核时，不要把字段逐项照搬；即便概念都叫“路由”或“DNS”，字段结构、默认值和处理流程也可能不同。尤其是桌面 TUN 所用的执行组件，应以客户端当前实际启动的组件为准，不能仅凭选中的服务器协议推断。

一次只改变一个变量

配置前保存可恢复的设置副本，并写下本次调整的目的，例如“让测试域名走指定出站”，而不是笼统地“优化网络”。每次只改一个相关变量，重启必要的运行组件后重复相同测试，记录结果再继续。路由、DNS 和流量接管经常相互影响，同时修改三者，即使连接恢复也很难知道是哪项起作用；下一次更新或重启后，问题就可能再次出现。

日志记录以够用为原则。临时提高日志级别有助于确认配置加载与匹配过程，但日志也可能包含域名、地址和连接信息。提交求助内容时只保留错误前后的必要片段，删除订阅链接、认证字段与个人访问记录。若问题表现为超时，可先按节点超时排查顺序逐项检查；基线稳定后，再进入下面的订阅与路由章节。

订阅分组与服务器过滤

订阅是一组服务器配置的更新入口，分组则是客户端保存和展示这些配置的组织方式。两者有关联，但不是同一个概念：一个分组可以关联订阅，也可能保存手工添加的服务器。建议按配置来源建立分组，而不是把全部服务器放进一个列表。这样更新失败时能定位到具体来源，删除或停用某个订阅时也能知道影响范围。分组名称应描述用途或来源，不必复制很长的宣传式节点名称。

先组织来源，再更新服务器

在订阅分组设置中建立分组，填写自己取得的订阅地址，确认保存后只更新这个分组。更新完成后查看结果数量与报错信息，再回到服务器列表检查地址、协议和备注是否合理。第一次导入不要立即开启自动更新，也不要同时导入多个来源；先确保一个来源的拉取、解析、保存和连接都正常，后续才能区分是网络问题、订阅内容问题，还是新分组带来的配置冲突。

订阅链接往往含有用于识别账户的参数，应当像账户信息一样保管。不要把完整链接写进服务器备注、公开截图或求助日志，也不要为了缩短链接而交给不明转址服务。只要服务提供方更换了地址或账户标识，就需要在分组设置中替换旧链接。链接仍能打开但没有服务器，并不一定是客户端故障；账户状态、内容格式或服务端返回的提示页也会影响解析结果。

过滤只负责缩小范围

过滤通常依据服务器备注或客户端支持的条件减少列表中的候选项，不能改变服务器实际位置、协议能力或可用状态。还要区分界面搜索与订阅过滤：搜索只是暂时隐藏不匹配的行，清空搜索后恢复显示；订阅过滤可能在更新时就排除条目，导致它们没有进入本地分组。调整前先看清设置属于哪一种，避免把“被筛掉”误判成“提供方删除了服务器”。

不同界面的过滤输入可能接受普通关键词、多个条件或正则表达式，必须按输入框说明使用。若明确支持正则，^(测试|备用) 可以匹配以“测试”或“备用”开头的备注；它只是表达式示例，不代表所有客户端的过滤框都能解析。遇到更新后列表为空，先清空过滤条件重新更新，再逐条添加条件。大小写、空格、全角符号和服务方改名，都可能让原先有效的过滤突然失效。

保护本地修改与当前选择

由订阅导入的条目通常受后续更新管理。本地修改了地址、端口或传输字段，下一次更新可能恢复为订阅中的值；是否保留备注等字段，也取决于客户端的合并方式。确实需要维护一份不同参数的配置时，可以将它复制到独立的手工分组，并用备注写清修改原因。这样订阅条目继续跟随来源更新，手工条目则承担可控的实验用途，不会把两种维护方式混在一起。

更新后要重新确认活动服务器。列表顺序变化、条目改名或订阅删除旧记录，都会使原来的选择不再适合继续使用。不要只检查“更新成功”，还要确认实际启用的服务器仍属于预期分组，并通过一次真实请求验证。若需要批量测试，先缩小到与当前用途相关的条目；大量并发测试会占用网络和本机资源，结果也容易受到测试目标限制，不能直接当成服务器质量排名。

空列表与解析错误的处理

更新失败时先看错误发生在哪一环：请求无法完成，优先检查链接、网络和更新是否需要代理；请求完成但解析失败，检查返回内容是否确实是订阅，而不是登录页或到期提示；更新成功但列表为空，检查过滤条件和协议兼容性。不要在尚未确认来源有效前连续重置客户端。具体分支可继续查阅订阅更新失败与解析报错，保留原分组再试新配置，比直接删除全部条目更便于恢复。

路由规则与分流实战

路由负责决定一条连接使用哪个出站，并不负责生成订阅或修正服务器参数。可以把它理解为按顺序检查条件的决策表：匹配到一条规则后，流量交给该规则指定的出站。对 Xray 的常规规则路由而言，前面的匹配结果优先，所以具体例外通常应放在宽泛规则之前。客户端中选择“全局”或某个预设方案，可能会改变生成的规则；开始自定义前先确认实际启用的是哪套路由。

从一个明确目标开始

先写下需要改变的行为，例如让某个测试域名直连，或阻断一个明确不需要的目的地址。不要一开始就导入大量来源不明的规则，再凭网页是否打开推测效果。域名规则适合有稳定主机名的服务，IP 规则适合地址段明确的网络，端口规则则应结合应用用途谨慎设置。一个服务可能同时访问多个域名、内容分发地址和登录接口，只处理主页面域名不一定能覆盖完整流程。

在 Xray 规则中，full:example.com 表示完整域名匹配，domain:example.com 可覆盖该域名及其子域名。没有这些前缀的普通字符串可能按不同的匹配语义处理，因此不要把“包含关键词”和“属于某个域名”混为一谈。IP 条件支持具体地址或 CIDR 网段。维护规则时应记录每条规则的用途、影响对象与测试方法；仅写“优化规则”这样的名称，过一段时间就难以判断能否删除。

理解同一条规则里的条件关系

同一规则中的不同条件通常需要同时满足，例如域名与端口都符合才匹配；同一列表里的多个候选项则用于表达可选范围。想让某个域名和某个独立 IP 段分别走同一出站，通常应拆成两条规则，而不是把它们塞进一条规则并期待“二选一”。这种细节很容易造成规则看似存在却从未命中的情况。新增规则后要用能真正满足条件的请求测试，并检查命中的出站。

下面的片段展示简单的规则顺序：特定测试域名先直连，私有地址段随后直连，最后以 TCP 和 UDP 规则明确交给代理。示例中的 direct 与 proxy 必须对应实际出站标签；它们不是内核自动生成的保留名称。片段要合并进有效的 Xray 配置，不能单独启动。私有地址规则也应结合实际网络用途调整，不能认为所有私有地址都在当前设备的本地局域网中。

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

域名、解析与默认出站

AsIs 表示路由阶段不为了匹配 IP 规则而主动解析域名，已有 IP 目标仍能参与 IP 匹配。如果目标只有域名，某些 IP 规则就不会发挥预期作用。IPIfNonMatch 会在域名规则未命中时尝试解析，再进行匹配；这又引入了解析器和解析路径的依赖。不要只为了让一条 IP 规则生效，就忽略 DNS 请求本身是否可达。未匹配连接的默认出站行为也需确认，明确的末尾规则更便于阅读。

规则存在不代表客户端一定看得到需要匹配的域名。应用可能直接连接 IP，也可能先自行解析后再发起连接；是否启用嗅探、能识别什么协议、嗅探结果是否用于路由，都影响可见信息。嗅探不能恢复所有加密流量的域名，也不应当被当成全能补丁。先确认请求携带的是域名还是 IP，再决定调整规则、DNS 或接管方式，通常比堆叠更多匹配条件有效。

验证时分别测试规则内目标、规则外目标与本地服务，避免只证明一条路径可用。若新增规则让大量请求失败，先禁用该规则恢复基线，再检查顺序、条件关系和出站标签。阻断规则尤其应放在范围明确的位置，否则可能连解析、认证或更新请求一起拦下。路由表长期维护要定期删除过时例外，并在更新客户端或切换内核后重新检查生成结果，不能假定旧方案始终原样执行。

DNS 配置与解析路径

DNS 问题通常不只是“换一个解析地址”这么简单。应用可以使用系统解析器，客户端内核也可以为路由或直连建立自己的解析流程；代理服务器还可能在远端解析目标域名。这些请求发生在不同位置，受不同路由和网络条件影响。先确定失败发生在应用解析、内核解析，还是远端连接阶段，才能选择正确的设置入口。浏览器网页打不开而服务器测试正常，既可能是 DNS，也可能是应用没有走预期代理。

画清三条解析路径

第一条是设备到本地解析器，负责应用通常使用的域名查询；第二条是内核到所配置的解析服务，可能用于 IP 路由匹配或直连出站；第三条是代理出站把域名交给服务端后，由服务端完成的解析。并非每条连接都会经历全部路径。对照当前模式，写清查询从哪里发出、经由哪个出站、返回什么类型的地址，就能看出某个 DNS 设置为什么影响部分网站，却没有影响另一部分。

同时需要检查解析服务自身如何连接。传统 UDP 查询、加密的 HTTPS 查询等方式有不同的传输需求，不能只把地址换成一个 URL 就期待所有内核自动适配。Xray 的 DNS 服务配置对不同地址形式有特定处理语义，包括使用内核路由或本地连接的区别；其他组件又可能采用不同字段。应查看当前内核支持的形式，再确认解析请求是否确实经过希望使用的出站。

先解决引导解析循环

使用域名形式的解析服务，需要先知道解析服务自身的 IP；代理服务器地址如果也是域名，也要在建立代理前完成必要解析。若设置成“所有 DNS 都必须经过尚未建立的代理”，而代理服务器又依赖同一 DNS 才能连接，就会形成循环。表现可能是启动后全部请求超时。处理时为服务器地址或解析服务提供可达的引导解析路径，保持它独立于尚未建立的连接，而不是继续叠加超时与重试。

下面展示 Xray 内置 DNS 的简化片段：静态映射用于说明如何覆盖一个测试域名，服务器列表与查询策略则控制内置解析器的查询。示例并不会接管操作系统全部 DNS，也没有定义解析请求的出站。example.com 与文档示例地址只适合理解结构，不应作为生产服务配置；实际解析服务应根据所在网络的可达性和管理要求选择。

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

静态映射会绕过该域名正常的动态解析过程，适合短期诊断，不适合随意固定内容分发服务的地址。服务可能按地区、负载和时间返回不同地址，固定结果过期后就会造成连接失败。诊断结束后删除临时映射，并重新发起请求。解析结果正确也不等于服务可用，还需要检查目标端口、传输协议以及服务端对连接的处理，避免把后续连接错误都归到 DNS。

IPv4、IPv6 与缓存

UseIP 可查询 IPv4 与 IPv6 地址，UseIPv4 或 UseIPv6 则限制查询类型。限制为 IPv4 可以作为定位 IPv6 路径故障的对照实验，但不应被描述成普遍更快的设置。设备能够得到 IPv6 地址，并不意味着所选出站能正确连接该地址；反过来，只支持 IPv6 的目标也无法靠限制为 IPv4 解决。应结合设备网络、代理服务器和目标服务三端的能力判断。

解析缓存可能同时存在于操作系统、浏览器、应用与内核中。修改 DNS 后立即刷新一个已打开的页面，可能仍沿用旧地址或既有连接，因此测试时最好新建连接，并按需要重启受影响的应用与内核。Windows 可用系统的清理 DNS 缓存工具；macOS 与 Linux 的缓存管理方式依系统服务而异，不要照搬其他平台的命令。记录调整前后的解析结果，比反复清空所有配置更有意义。

用现象定位，而不是只看解析器名称

若域名失败而相同服务的已知 IP 路径正常，优先观察查询超时、地址类型和返回结果；若域名能解析但连接失败，转向路由、端口和服务端参数。若只有 TUN 下失败，则继续检查 DNS 接管与虚拟网卡路径。更换解析器后恢复，只证明旧路径在这次测试中存在问题，不能证明新解析器对全部应用都更合适。配置最终应与路由目标一致，并保留一个能恢复基线的解析方案。

TUN 模式与流量接管

系统代理由遵循系统设置的应用使用，TUN 则通过虚拟网络接口把选定的 IP 流量送入处理组件，两者的接管层次不同。某个应用不读取系统代理时，TUN 可能提供另一条路径，但它不等于“所有流量一定经过代理”。最终仍受系统路由、排除规则、DNS 接管、UDP 支持和出站配置影响。已经能通过系统代理工作的基线，是启用 TUN 前的重要对照，不要把 TUN 当成服务器连接失败的修复按钮。

确认执行组件与系统权限

在 v2rayN 中启用 TUN 前，检查当前客户端提供的相关设置，以及启动日志显示的执行组件。服务器使用 Xray 协议，不代表 TUN 接口就由同一内核直接创建。不同组件的配置结构、流量栈和 DNS 行为可能不同，原始 Xray 字段不能直接套到另一组件的 TUN 配置里。首次启用时保持默认或较少改动的方案，先验证接口创建、路由安装与请求路径，再讨论更细的参数。

虚拟接口和系统路由调整通常需要额外权限。Windows 要按客户端要求授予相应权限，Linux 需要具备创建接口和修改路由的权限，macOS 则应完成客户端请求的系统授权。权限错误应在日志和系统提示中确认，而不是仅凭开关状态判断成功。开关变为启用，但接口没有创建或路由没有安装，应用仍可能走原来的路径；这种情况应先修复权限或启动失败，再修改分流规则。

避免回环与双重接管

TUN 捕获的连接会再经由出站建立网络连接；出站自身的连接不能被原样送回入口形成循环。客户端通常通过接口选择、路由排除或其他机制处理这一问题。设备同时运行其他 VPN、网关软件或第二套接管工具时，这些机制可能互相覆盖。先停用其他接管工具建立对照，再逐一恢复，观察是否出现路由冲突。不能仅凭两套软件各自显示“已连接”，就断定它们可以共同工作。

启用 TUN 后还要决定是否保留系统代理。若应用先把请求发送到本地代理，再被另一层路径处理，可能出现重复接管、绕行或难以理解的日志。客户端不同模式的设计不完全相同，因此不要机械地认为两者必须同时开或必须同时关；按当前模式的说明设置，并分别测试。观察本地代理端口是否仍承担请求，有助于解释为什么关闭系统代理后某些应用的表现发生变化。

MTU、UDP 与局域网访问

MTU 决定接口允许的包大小。路径中的封装与网络条件可能让大包处理出现问题，但随意调低 MTU 也可能增加分段和处理开销。只有出现“握手成功、传输卡住”或特定大请求失败等迹象时，才把 MTU 纳入排查；做小幅调整并复测相同请求，不要把一个数值当作全平台通用答案。UDP 应另行验证，因为网页的 TCP 请求正常，并不能证明依赖 UDP 的应用同样正常。

局域网打印、文件共享与设备发现需要特别检查。部分功能依赖广播或组播，并不是添加一个私有地址直连规则就能全部恢复。先确认普通局域网地址能连接，再观察发现机制是否受虚拟接口或防火墙影响。TUN 接管本机流量，也不等于允许其他设备使用本机代理；共享代理需要单独设置监听范围和防火墙，相关操作见允许局域网连接说明。

按阶段验证与退出恢复

启用后的测试顺序是：确认组件启动，确认接口与路由，再检查 DNS，最后分别测试浏览器、原本不遵循系统代理的应用和本地服务。安卓端使用系统 VPN 接管时，还要检查应用包含或排除范围，以及后台运行限制。若关闭接管后网络仍异常，检查系统代理、DNS 和残留路由是否恢复，不要反复打开开关掩盖残留状态。恢复基线后再按帮助中心中的现象分类继续定位。

FakeDNS 与域名还原

FakeDNS 不返回目标服务的真实地址，而是为域名分配一个受控地址，并保存域名与该地址之间的映射。应用随后连接这个地址时，处理组件通过映射还原域名，再执行路由和出站。这样可以在应用只向网络层提供 IP 的情况下保留域名信息，但前提是查询和后续连接都经过相互配合的处理链。它不是普通 DNS 的别名，也不能靠填写一个解析服务器地址就完成全部配置。

先确认整个请求闭环

完整路径包含应用查询、FakeDNS 返回映射地址、应用连接映射地址，以及入口还原域名四个环节。任何一环绕开处理组件，应用就可能连接到无法访问的受控地址。常见原因包括系统 DNS 没有被接管、应用使用自己的解析通道、目标地址没有进入预期接口，或客户端入口没有启用对应的域名还原能力。因此应先确认 DNS 与流量接管正常，再引入 FakeDNS，而不是在 DNS 已经混乱时继续叠加功能。

不同内核和 TUN 组件可能提供概念相似但字段不同的功能。Xray 的 FakeDNS 配置需要与内置 DNS 和入口嗅探等设置配合；另一组件的 fake-IP 机制不应直接使用 Xray 的字段。只有当前运行组件明确支持并提供相应入口时才进行设置。若客户端仅让用户选择普通 DNS 方案，不要把下面的片段粘贴到未知的输入框，更不要通过修改订阅条目的服务器地址来模拟映射。

地址池与映射容量

以下是 Xray 的地址池片段，单独使用不会开启完整的 FakeDNS 请求链。ipPool 指定受控地址范围，poolSize 指定映射池容量。示例使用的网段具有特殊用途，并不是可供应用直接访问的公网服务地址；还要确认它不会与设备已有网络或其他接管工具的范围冲突。容量应按组件支持范围设置，不宜为了“性能”盲目增大，也不能超过所选地址范围能够容纳的数量。

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

映射池有限，组件可能在容量压力下回收旧映射。应用如果长期缓存一个受控地址，后续连接就可能遇到映射缺失或变化。因此要把映射生命周期和应用缓存一起考虑。某些问题只在长时间运行后出现，而重启后短暂恢复，不能立即判断成服务器不稳定；也可能是应用持有了旧地址，或者接管组件重启后丢失了原映射。排查时记录重启、缓存和复现时间之间的关系。

识别不适合使用映射的场景

局域网服务、只接受实际 IP 的工具、把解析结果传给另一台设备的应用，都可能不适合直接使用受控地址。例如本机得到映射地址后，把它发送给局域网中的另一台设备，而那台设备没有相同映射，就无法建立连接。需要例外时，应使用当前组件支持的域名排除或真实解析机制，并确认例外请求的后续路由一致。不要只排除 DNS 查询，却仍把真实连接送到不适合的出站。

应用自行使用加密 DNS 或直接连接 IP 时，FakeDNS 可能根本没有参与。此时日志里看不到映射并不代表功能坏了，而是请求走了另一条路径。是否需要调整应用解析行为，应按应用本身提供的设置处理；透明地假设所有查询都会被拦截，往往导致误判。嗅探也有协议边界，不能保证从任何连接中恢复原始域名，特别是缺少可识别主机信息的请求。

用小范围试验验证收益

先选一个可重复访问的普通测试目标，确认查询得到受控地址，连接被捕获，日志能对应到原始域名，并且最终命中预期出站。再检查一个局域网目标和一个配置例外的目标，确保它们仍使用真实解析。若只是为了让已有域名规则生效，而当前请求本来就携带域名，FakeDNS 未必带来实际收益。更简单的路由与 DNS 配置通常更容易维护，不必为了启用功能而增加复杂度。

回退时按顺序关闭相关映射设置、恢复解析方案、重启受影响的组件和应用，然后重测基线。只关一个开关但保留旧地址池路由，或者只改 DNS 而让应用继续持有映射地址，都可能让问题延续。把试验配置与稳定配置分别保存，可以在下一次维护时明确知道哪些设置是为 FakeDNS 服务的，避免删除一个字段后留下难以理解的半套请求链。

多订阅维护与更新控制

多订阅管理的重点不是让列表更长，而是让每个来源都有清楚的维护边界。一个来源用于日常连接，另一个来源用于特定环境或备选，就应分别建立分组，并说明用途。订阅拉取成功、服务器参数正确和实际连接可用是三个不同结果，维护时要分别确认。来源之间也不应共用不明的认证信息；无法解释由谁提供、为何存在的链接，不适合加入长期使用的自动更新流程。

建立来源清单与更新节奏

给每个订阅记录来源名称、用途、最后一次人工确认结果，以及是否需要经由代理更新。记录不必放进公开文件，也不需要保存完整链接；重点是能在出现问题时知道该找哪个来源核实。自动更新频率应按提供方的更新方式和自己的使用需求设定。过密的拉取可能触发服务端限流，也会让客户端频繁替换列表；手动更新则适合低频使用或仍在测试兼容性的分组。

启动时自动更新看似方便，但要考虑启动网络尚未稳定的情况。设备刚连接无线网络、代理尚未启动或账户页面需要认证时，订阅请求可能失败。应先建立一条已经保存的可用连接，再按需要更新依赖代理的来源。不能让唯一能工作的连接必须先从订阅取回，而订阅又必须经由这条尚不存在的连接获取，否则就把更新流程做成了循环依赖。

逐组更新，而不是同时替换全部来源

维护多来源时，先更新一个分组，查看增删条目与错误，再测试关键服务器，确认后继续下一个分组。这样即使某个来源返回了错误内容，也不会同时失去全部对照。对于重要的手工修改，应事先复制到独立分组；对于订阅内容本身的变更，应接受其由来源管理的事实，不要期望客户端永远保留已经撤回的服务器。更新策略与本地修改策略要分开设计。

如果更新导致节点数量明显变化，先检查过滤条件、协议兼容性和服务端提示，再判断是否确实发生内容调整。仅比较数量不足以说明质量：同一服务器可能有多个传输入口，同名条目也可能指向不同地址。必要时对比地址、端口、协议与传输参数，不要只看备注。客户端无法解析的条目，应核实其所需内核能力；更新软件可以解决部分兼容性问题，但不能替代正确的服务端参数。

重复条目与故障相关性

两个来源都出现相同备注，不代表它们是不同的备选；地址、端口、认证与传输条件一致时，可能只是同一配置的重复分发。即使地址不同，也可能共享同一服务基础设施，因此不能仅凭订阅数量认为故障已经分散。整理时保留来源信息，确认重复条目是否需要同时维护，再决定隐藏或删除。不要为追求整齐而合并掉所有来源标签，否则未来更新与排错都会失去线索。

故障发生时先判断范围：一个条目失败，优先检查该条目的参数；一个分组全部失败，检查来源状态和共同设置；所有来源都失败，则检查本机网络、时间、运行内核、DNS 和接管模式。这个顺序能够减少不必要的批量删除与重新导入。备用来源也需要定期进行少量真实请求测试，而不是只让它停留在列表里；有记录的可用结果，才比“看起来还有很多服务器”更有参考价值。

停用来源与恢复设置

不再使用的来源可以先停用自动更新，再检查当前活动服务器是否来自该组，最后按需要删除。删除前确认没有路由或自定义配置间接依赖其中的条目，也没有把唯一可用的连接留在该组。迁移设备时，配置副本可能包含订阅地址与认证信息，应通过自己控制的方式转移，并在新设备完成测试后再清理旧副本。客户端设置备份不是适合公开分享的教程附件。

建立一个简单维护记录即可：这次更新了哪个来源、调整了哪项过滤、当前稳定使用哪个分组，以及异常时怎样回退。无需把每一次请求写成繁琐日志，但关键变化应有可读的说明。若主要问题仍是订阅无法解析，回到分组与过滤检查导入链；若订阅正常而特定应用失败，应转向路由、DNS 或 TUN，不要继续通过增加来源掩盖配置问题。

自定义出站与配置验证

出站描述流量离开内核的方式，路由则选择使用哪个出站。服务器列表中的一个条目，不等于可以在自定义规则里直接引用它的备注；规则通常引用运行配置中的出站标签。开始自定义之前，应先明确需要的是额外直连、明确阻断、特定服务器出站，还是多个出站之间的链式关系。目的不同，所需字段也不同。自定义功能适合解决客户端普通设置无法表达的需求，不宜作为日常配置的第一步。

标签必须在同一配置中闭合

每个出站使用清楚且唯一的 tag，规则里的 outboundTag 必须与它逐字一致。标签不是显示名称，也不会因为大小写近似就自动关联。复制规则时最常见的错误，是引用了别人的标签却没有定义对应出站。另一个问题是客户端重新生成配置后改变了出站组织方式，所以长期规则应通过受支持的入口保存，并核对实际生成配置，而不是只确认编辑框中的文本。

下面的 Xray 片段只定义两个基础出站：freedom 用于直连，blackhole 用于阻断。它没有代理服务器出站，也没有入站和完整路由，因此不能作为完整配置启动。实际合并时应检查现有标签，避免重复定义。若想使用前面路由示例的 proxy，还需要在同一配置中存在真实、正确的代理出站；不能用一个空对象来代替服务器参数。

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

直连解析与服务器协议参数

直连出站最终需要连接实际目标地址，涉及域名时就要考虑解析路径。Xray 的 freedom 设置中，domainStrategy 可以改变直连阶段的域名处理，但它与 routing.domainStrategy 不是同一个设置：前者服务于建立出站连接，后者服务于路由匹配。不要因为两者名字相同就同步修改。先判断问题发生在规则选择前还是连接建立时，再调整对应层次。

代理出站应使用服务提供方给出的协议与参数，不能凭一个协议名称猜齐其余字段。地址、端口、认证、传输与安全设置需要配套；启用 REALITY 时，还涉及服务端提供的相关参数，应参考REALITY 术语说明理解字段用途。不同内核支持范围并不完全一致，内核家族关系可查阅Xray 条目。不要为了让配置通过语法检查而把必要参数留空。

链式出站不等于自动容错

当一个出站经由另一个出站建立连接时，需要同时考虑底层连接可达性、域名解析位置和 UDP 支持。Xray 的出站代理关系可涉及 proxySettings，而其他组件可能采用不同字段；必须按当前内核结构建立引用，不能照搬。链条也不能形成环路，例如甲依赖乙、乙又依赖甲。多一层连接通常会多一层故障依赖，不会天然提高可用性，也不能仅凭标签顺序完成自动切换。

自动选择或容错还需要对应的检测与选择机制，并明确什么条件算失败、何时切换以及现有连接如何处理。没有这些机制，仅定义多个出站不会让内核自动轮流尝试。对多数查阅场景，先把每个出站单独验证，再为一个明确目标配置固定规则更稳妥。涉及链式连接时应先验证底层出站，再验证上层服务器连接，最后测试目标请求，避免把三层错误压缩成一句“节点超时”。

先检查结构，再运行对照测试

配置验证分三步：先检查 JSON 是否存在多余逗号、未闭合引号或重复字段；再检查当前内核是否支持各字段，以及标签引用是否完整；最后启动组件观察实际请求。语法合法不代表字段有效，内核启动成功也不代表规则选择符合目标。应特别注意从其他组件复制来的同名字段，以及把片段放错层级的情况。配置错误时先恢复保存的原稿，再逐步加入必要内容。

运行验证至少覆盖目标规则、默认路径、DNS 和本地服务。查看日志是否加载了新配置，是否选择了预期出站，失败是在解析、握手还是传输阶段。测试完成后把临时详细日志恢复到适合日常使用的级别，并删除不再需要的实验规则。稳定配置应能说明每个出站的用途与每条例外的原因；只剩一大段无法解释的文本，后续维护风险往往比最初的问题更高。

如果自定义过程影响了基本连接，先按使用指南恢复快速上手路径，再根据现象回查对应章节。需要更换客户端安装包时使用下载页，不要把配置故障直接归因于安装文件。进阶配置的最终标准不是字段数量，而是请求路径清楚、异常可以复现、修改能够回退，并且日常使用所需的应用都得到实际验证。