V2Ray 配置进阶手册

先建立三层配置模型

快速上手页负责完成导入订阅、选择服务器、开启系统代理和验证访问这条主线。本手册处理主线完成后的细化需求，包括多订阅隔离、复杂分流、DNS 查询路径、TUN 接管范围和自定义出站。开始修改前，先把当前配置拆成三层：最外层是 v2rayN、v2rayNG 或 v2flyNG 的界面设置；中间层是客户端生成并交给 Xray 或 V2Fly 的运行配置；最底层是操作系统的代理、路由表、虚拟网卡和名称解析行为。三个层级会互相影响，但含义不同。

例如，v2rayN 中“设置系统代理”只负责把支持系统代理的应用指向本地监听端口，它不等于路由模式。“绕过大陆”属于内核路由规则，决定请求进入内核后交给 direct 还是 proxy 出站。TUN 模式则从操作系统网络层接管更多连接，即使应用不读取系统代理，也可能被虚拟网卡捕获。把三者混成一个开关，最常见的结果是浏览器正常、命令行失败，或者关闭系统代理后仍有流量经过内核。

每次调整只改一个层级。先保存当前可用配置，再记录修改项、重启内核、查看日志，然后执行固定测试。测试至少包含一个域名请求、一个直接使用 IP 的请求、一个明确应直连的目标和一个明确应走代理的目标。若一次改动同时涉及路由、DNS 与 TUN，日志只能说明最终失败点，无法反推出最先出现偏差的位置。

理解一次请求的实际路径

普通系统代理场景中，应用先连接 v2rayN 暴露的 HTTP 或 SOCKS 入站。内核读取请求目标，必要时执行域名解析，再按路由规则匹配出站标签。命中 direct 时，内核从本机网络直接建立连接；命中 proxy 时，连接交给当前服务器对应的代理出站；命中 block 时，请求在本地终止。TUN 场景多了一步：操作系统先把 IP 数据包送进虚拟网卡，内核需要还原连接目标，然后才进入相同的路由和出站流程。

路由匹配依赖可见信息。SOCKS 入站通常能够携带原始域名，内核可以直接匹配 domain 或 geosite。某些程序先自行解析域名，再只提交目标 IP，此时内核看到的是 IP，域名规则可能无法命中。流量嗅探可以从部分连接的握手信息中恢复域名，但它不是对所有协议都有效，也不应被当作错误 DNS 设置的替代品。排查规则未命中时，必须先确认日志里记录的目标到底是域名还是 IP。

DNS 同样不是独立模块。路由规则可能要求解析目标 IP，DNS 查询本身也需要选择出站，TUN 下系统查询还可能被内核截获。如果将所有 DNS 请求都交给同一个远端解析器，又让该解析器域名依赖代理出站，就可能形成启动依赖：代理服务器尚未连接，解析器也无法访问。解决方法不是重复切换服务器，而是为启动链路保留可直接访问的引导解析方式，并明确哪些查询走 direct、哪些查询走 proxy。

用日志定位层级，不凭界面状态判断

界面显示“已连接”通常只代表内核进程已启动，不能证明每条请求都找到正确出站。排查时先看监听端口是否建立，再看请求是否进入对应入站，然后看路由命中结果，最后看出站连接错误。若日志完全没有测试请求，问题在应用代理、系统代理或 TUN 接管层；若有入站记录但规则与预期不同，问题在目标识别或路由顺序；若已命中预期出站却连接失败，再检查服务器配置、网络可达性与时间设置。

• 确认当前操作对象是订阅原始条目、客户端生成配置，还是系统网络设置。
• 修改前导出客户端配置或记录关键选项，确保可以回到已知状态。
• 测试期间关闭会改写代理设置的其他网络工具，避免端口与路由表相互覆盖。
• 用同一组目标重复测试，先比较路由命中变化，再比较最终访问结果。

桌面端进阶配置优先使用 v2rayN，因为订阅分组、路由规则、DNS 和 TUN 入口集中，日志也便于对照。Android 端可使用 v2rayNG；需要 V2Fly 内核时再选择 v2flyNG。三款客户端的下载入口与平台范围见客户端下载页。配置项名称可能因界面调整而变化，但“入站—路由—DNS—出站”的内核链路保持一致，后续各章均按这条链路说明。

按来源建立分组，不把所有条目堆在一起

订阅分组的第一项作用是标记来源。添加订阅时，为每个地址设置稳定备注，例如“工作配置”“移动备用”或“测试环境”，不要用“订阅一”“新地址”这类无法追溯的名称。更新完成后，服务器条目应保留所属分组关系。后续出现同名条目、路由表现差异或某个来源失效时，可以直接限定问题范围，不必逐条猜测。

分组的第二项作用是隔离更新。订阅更新通常会重新读取远端内容，并对该分组中的条目执行新增、修改或移除。更新前若手工改过服务器地址、端口或传输参数，下一次同步可能覆盖本地修改。需要长期保留的自定义条目应复制为独立本地配置，并在备注中写明来源与用途；不要依赖“改完后不再更新”这种隐含约定。临时修改则应记录原值，测试结束后删除副本。

分组的第三项作用是控制批量操作。测试服务器、导出选中项、批量启用或删除时，先限定当前分组。尤其在多订阅场景中，相同备注可能来自不同来源，单看显示名称无法判断它们是否共享服务器配置。建议让分组名表达来源，让条目备注表达区域、协议或用途，两者承担不同信息，避免把所有属性都塞进一个超长名称。

过滤规则只负责缩小可见集合

服务器过滤适合处理条目很多、命名稳定的订阅。常见条件包括按备注包含词、正则表达式、协议类型或分组筛选。先使用包含词建立简单规则，确认结果后再升级到正则。正则需要明确大小写、空格、连字符和全角字符差异。例如要保留备注中含“备用”或“测试”的条目，可使用 备用|测试；若要排除这些条目，应使用客户端提供的排除条件，不要用过度复杂的否定表达式模拟全部逻辑。

过滤与删除的含义不同。过滤后的条目仍保存在订阅分组中，只是不出现在当前视图或候选列表；删除条目后，下次更新可能再次出现。若某类条目长期不需要，优先在分组的过滤条件中排除。若仅需临时聚焦一个协议或区域，使用视图过滤，不要修改订阅内容。过滤结果为空时，先清空规则恢复完整列表，再逐项添加条件。这样可以判断是订阅确实无条目，还是过滤表达式覆盖范围过大。

保留条件：
(备用|测试).*(VLESS|Trojan)

排除条件：
过期|维护|临时

解释：
先匹配用途词，再匹配协议词；
排除条件独立执行，不与保留条件写成一条复杂表达式。

示例用于说明过滤顺序，实际匹配对象是订阅提供的服务器备注。

更新订阅时保留可回退状态

执行更新前，先确认当前服务器属于哪个分组，并记下当前可用条目的备注。更新后不要立即批量删除旧条目，先观察新增、移除和参数变化。若客户端支持更新时保留原条目，短期排错可以开启；稳定后再清理重复项。长期同时保留旧、新两套条目会造成选择混乱，也可能让自动选择逻辑继续使用已经不再维护的配置。

订阅地址读取失败时，按网络层次排查。第一步确认地址完整且没有前后空格；第二步确认订阅更新请求采用的代理方式，是直连、跟随系统代理还是通过当前内核；第三步查看返回内容是否为客户端可识别的订阅格式。返回登录页面、错误提示文本或空内容时，客户端可能只显示“解析失败”。此时切换服务器通常没有作用，应先处理订阅请求本身。

订阅更新成功但没有新条目，依次检查当前分组、过滤条件、重复项处理和协议支持。某些条目可能因为备注相同而被视为重复，也可能因当前内核不识别对应字段而未导入。v2rayNG 默认面向 Xray 配置；v2flyNG 面向 V2Fly 内核。订阅里包含特定内核扩展时，应让客户端与内核能力对应，而不是手工删除未知字段后继续使用。

建立稳定的服务器选择流程

服务器测试只能说明测试时刻、测试方法和测试目标下的表现，不能代替协议参数检查。先排除配置字段不完整、地址无法解析或传输层不匹配的条目，再做连接测试。选择后用真实应用请求验证路由和 DNS，不要只看客户端测试结果。若多个条目共用相同域名，DNS 缓存和连接复用还可能让短时间测试结果互相影响，切换后应等待旧连接结束或重启对应应用。

建议保留一个已验证的基准条目。修改路由、DNS、TUN 或自定义出站后，始终先用基准条目测试。若基准条目也失败，问题更可能出在本地配置；若只有新条目失败，再检查该条目的协议、端口、传输、安全层和服务器名称。通过这种对照，可以避免把本地规则问题误判成订阅问题，也能防止在排查过程中连续切换多个变量。

订阅导入格式和桌面端、Android 端入口可继续查看V2Ray 订阅链接导入教程。本章重点是导入后的管理：来源可追溯、更新可回退、过滤可撤销、选择有基准。满足这四项后，多订阅和复杂路由才有稳定基础。

先确定出站标签，再编写匹配条件

路由规则的结果不是“允许”或“拒绝”，而是把请求交给指定出站。常见标签包括代理出站 proxy、直接连接 direct 和阻断出站 block。客户端生成的实际标签可能不同，因此复制规则前必须先查看当前出站名称。规则中引用不存在的标签时，内核可能拒绝启动，也可能让该规则无法得到预期结果。

一条规则可以按域名、IP、端口、入站标签、网络类型或协议特征匹配。域名条件适合明确站点和 geosite 分类；IP 条件适合局域网、私有地址和 geoip 分类；入站标签适合把不同本地端口或 TUN 流量送往不同出站。不要在同一条规则里堆放彼此无关的条件，因为同一规则内的不同字段通常按同时满足处理，范围会比直觉更窄。

规则列表按顺序检查，首个命中项结束匹配。因此精确规则应放在分类规则之前，分类规则应放在最终兜底之前。例如某个属于 geosite:cn 的域名必须走代理，应先为该域名单独写 proxy 规则，再写 geosite:cn 到 direct。若顺序相反，分类规则先命中，后面的例外永远不会执行。

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": [
          "geoip:private"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": [
          "domain:internal.example"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": [
          "geosite:cn"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": [
          "geosite:geolocation-!cn"
        ],
        "outboundTag": "proxy"
      }
    ]
  }
}

这是一段内核路由结构示例。出站标签需要与客户端生成配置保持一致。

理解 domainStrategy 的影响

AsIs 表示路由阶段优先使用原始目标，不主动为了 IP 规则解析域名。请求携带域名时，域名规则可以匹配；只有 IP 目标才能直接进入 IP 规则。它的行为简单，适合主要按域名分类的配置。缺点是域名未命中任何规则时，后续 geoip 条件无法接管，除非应用已经把目标解析成 IP。

IPIfNonMatch 表示先尝试域名规则，未命中时解析域名，再尝试 IP 规则。它适合“域名分类优先，IP 地理分类兜底”的结构，也是常见的平衡选择。需要注意，路由阶段发生的解析使用内核 DNS 配置；DNS 配置不完整时，表现会像路由规则失效。日志里若出现解析错误，应先修复 DNS，不要继续增加域名例外。

IPOnDemand 会在遇到可能需要 IP 的规则时更早触发解析。复杂规则中它可能增加查询次数，并让原本只需按域名判断的请求受到 DNS 结果影响。除非明确需要提前获得 IP，不建议把它作为解决“规则不命中”的通用开关。选择策略时，应根据规则结构决定，而不是根据名称判断哪一个更“完整”。

用可解释的层级组织规则

建议将规则划分为五层。第一层处理内网与本机资源，例如 geoip:private 和内部域名，通常走 direct。第二层是必须覆盖分类结果的精确例外。第三层是协议或应用特定规则，例如按入站标签区分浏览器端口与开发工具端口。第四层是 geosite、geoip 等大范围分类。第五层是最终兜底，明确未匹配请求走 proxy 还是 direct。

阻断规则应保持可追溯。若直接加入范围很大的分类列表，应用失败时难以判断是远端问题还是本地 block 命中。先从明确域名开始，并让日志保留路由结果。对于 UDP、局域网发现、时间同步等系统流量，不要因为“看起来不需要”就全部阻断；TUN 模式下这些请求可能影响网络状态判断和应用启动。

端口规则需要同时考虑目标端口与传输协议。只按 53 匹配可能同时覆盖 TCP 与 UDP DNS；只按网络类型匹配 UDP 又会包含其他实时通信。若目标是单独处理 DNS，应同时限定端口、网络和入站来源。若目标是让某个应用固定走指定出站，优先为它设置独立入站端口或使用客户端支持的进程匹配能力，而不是用一组不断扩张的目标域名猜测应用行为。

处理 geosite 与 geoip 更新后的变化

分类数据库会影响同一规则的匹配范围。更新后若部分域名改变路径，先确认数据文件被当前内核读取，再确认分类名存在，最后查看精确域名是否被归入新的集合。不要通过重复添加相同规则覆盖问题；首个命中原则不会因为规则重复而改变。相关文件作用、替换入口与规则失效排查可查看geoip.dat 与 geosite.dat 更新方法。

完成路由配置后，将规则导出为一份带说明的清单。至少记录规则顺序、每层目的、依赖的出站标签和数据库分类。客户端界面中的预设模式适合快速选择，但自定义规则一旦增加，就应以实际生成配置为准。这样在更新客户端、切换内核或迁移设备时，可以判断差异来自界面预设，还是来自内核字段变化。

区分系统 DNS、内核 DNS 与应用自解析

系统 DNS 是操作系统提供给普通应用的名称解析入口。内核 DNS 是 Xray 或 V2Fly 配置中的解析模块，主要为路由判断、代理服务器地址解析和被接管的 DNS 请求服务。部分浏览器或应用还会使用自己的加密 DNS，绕过系统设置。三条路径可能同时存在，因此“修改了 DNS”必须说明修改的是哪一层。

在普通系统代理模式下，应用若把域名交给 SOCKS 或 HTTP 代理，内核可以看到域名并按自身配置处理；应用若先用系统 DNS 得到 IP，再连接代理，内核可能只看到 IP。TUN 模式下，系统 DNS 请求可以被虚拟网卡捕获，但应用自带的加密 DNS 仍可能作为普通 HTTPS 请求运行。排查解析差异时，先关闭应用内自定义解析功能，用系统默认路径建立基线，再逐层恢复。

DNS 配置的目标不是单纯追求某个解析器响应更快，而是保证查询可达、结果适用于当前网络、路由能依据结果作出一致判断。若域名规则按 geosite 决定出站，而应用提前解析后只提交 IP，最终会改由 geoip 或兜底规则决定。两种结果都可能正常，但必须符合设计预期。

为不同域名设置明确的解析服务器

内核 DNS 可以配置多个服务器，并按域名分类选择。内部域名应交给能识别内部区域的解析器；常规直连域名可使用本地网络可达的解析器；需要通过代理访问的解析服务则必须指定对应出站或确保路由规则不会形成循环。不要把所有服务器简单并列后期待内核自动选出“最佳”结果，不同内核与配置字段对并发查询、回退和预期 IP 的处理并不相同。

{
  "dns": {
    "hosts": {
      "router.internal": "192.168.1.1"
    },
    "servers": [
      {
        "address": "223.5.5.5",
        "domains": [
          "geosite:cn"
        ],
        "expectIPs": [
          "geoip:cn"
        ]
      },
      {
        "address": "1.1.1.1",
        "domains": [
          "geosite:geolocation-!cn"
        ],
        "skipFallback": true
      },
      "localhost"
    ],
    "queryStrategy": "UseIP"
  }
}

示例展示分类查询结构。实际地址与出站路径应按当前网络条件配置。

hosts 适合固定少量内部名称或覆盖特定解析结果。它不是大型域名列表的替代品，也不应保存频繁变化的外部地址。domains 用于限定解析服务器负责的域名集合，顺序和匹配优先级需要结合内核规则理解。expectIPs 用于检查返回地址是否符合预期分类；它能辅助回退，但分类数据库过旧或目标使用跨区域分发时，过严条件可能拒绝本来可用的结果。

选择 IPv4 与 IPv6 查询策略

UseIP 通常允许返回可用的 IP 类型，具体行为受系统和内核支持影响。UseIPv4 只请求或保留 IPv4 结果，适合当前网络没有稳定 IPv6 路由的环境。UseIPv6 只使用 IPv6，前提是本地、代理服务器和目标链路都具备对应连通性。不要因为某次 IPv6 连接失败就永久关闭全部 IPv6；先判断失败发生在本地出口、代理出站还是目标站点。

双栈环境中的典型问题是 DNS 返回 IPv6 地址，但当前出站只能建立 IPv4 连接。应用可能先等待 IPv6 超时，再回退 IPv4，表现为首次打开缓慢。处理时可在内核 DNS 中临时使用 UseIPv4 验证。如果延迟消失，再检查系统 IPv6 路由和出站支持；若没有变化，瓶颈不在地址族选择。反过来，强制 IPv4 后某些仅提供 IPv6 的内部资源会失效，因此内部域名最好使用单独服务器和规则。

避免 DNS 循环和启动依赖

代理服务器地址如果是域名，内核启动时必须先解析它。若唯一 DNS 服务器只能通过尚未建立的代理出站访问，就形成循环依赖。为服务器地址准备可直接访问的引导解析器，或在可靠前提下配置静态映射。静态映射需要自行维护地址变化，因此更适合受控环境，不适合把动态服务长期固定到单一 IP。

另一种循环发生在 DNS 路由规则：将所有 53 端口流量送入专用 DNS 出站，而专用出站自身又产生被相同规则捕获的 53 端口请求。解决方法是用入站标签、目标地址或专用出站标签缩小规则范围，确保内核自己的上游查询能够离开循环。TUN 下还需避免把虚拟网卡发出的查询再次重定向回同一入站。

缓存排查应采用先清理、后复现的顺序。依次清理应用缓存、系统 DNS 缓存和内核缓存，再只发起一次查询。若不清理缓存，修改解析服务器后仍可能使用旧结果，导致误判。确认配置稳定后再恢复正常缓存，因为完全禁用缓存会增加查询量，也会让网络短暂波动更直接地影响每次连接。

最后用“内部域名、明确直连域名、明确代理域名、代理服务器域名”四类目标分别测试。查看每类查询是否进入预期服务器，并对照路由日志确认最终出站。DNS 正常的标准不是所有域名都由同一个服务器回答，而是每类名称都沿可解释的路径获得可连接结果。

明确 TUN 解决的问题

系统代理依赖应用主动读取操作系统代理设置。浏览器和部分桌面程序通常支持，某些命令行工具、游戏启动器或自带网络栈的程序则可能忽略。TUN 模式创建虚拟网卡并调整路由，让更多 IP 流量进入内核，再由路由规则选择 direct、proxy 或 block。它扩大了接管范围，但不会自动修正错误的服务器、路由或 DNS 配置。

开启 TUN 前，先在普通系统代理模式下确认基准服务器可以连接，域名解析正常，直连与代理规则符合预期。否则切换 TUN 后同时增加虚拟网卡、路由表、DNS 劫持和权限变量，排查范围会显著扩大。建议保存一份普通代理配置，TUN 失败时先关闭 TUN 并恢复系统网络，再验证基础链路是否仍然正常。

v2rayN 在 Windows、macOS 和 Linux 上提供桌面端，但不同系统创建虚拟网卡、修改路由和请求权限的方式不同。界面中的核心概念相同：选择 TUN 入站、设置栈类型、决定自动路由和严格路由、配置 DNS 接管，并确保内核以足够权限运行。平台安装入口见Windows 下载、macOS 下载与Linux 下载。

选择网络栈与自动路由

TUN 实现通常提供不同网络栈选项。系统栈更接近操作系统原生行为，兼容性路径清晰；用户态栈在部分环境中更便于跨平台处理，但对特定协议、分片和本地网络的表现可能不同。没有明确需求时，先使用客户端默认推荐项。出现 UDP、局域网或特定应用异常时，再切换栈进行单变量对照，不要同时修改 MTU、DNS 和路由规则。

自动路由负责把符合范围的系统流量送进虚拟网卡。启用后应检查默认路由、局域网路由和代理服务器地址的例外路径。代理服务器自身的连接不能再次进入同一个 TUN 入站，否则会产生回环。客户端通常会为服务器地址和必要系统网络添加排除项，但服务器使用域名且解析结果变化时，仍需查看日志确认实际地址没有被错误接管。

严格路由用于减少流量绕过 TUN 的路径。开启后，局域网访问、虚拟机网络、容器网络和企业网络客户端可能受到影响。先在关闭严格路由的状态下完成基础验证，再根据接管需求开启。若开启后只有局域网资源失败，应为私有地址和对应网段保留 direct 路由，并确认这些目标没有被更前面的代理规则命中。

处理权限、防火墙与路由残留

创建虚拟网卡和修改系统路由通常需要提升权限。若客户端界面提示 TUN 已开启，但系统中没有对应接口，先检查权限请求是否完成，再查看内核启动日志。不要反复点击开关；失败的启动可能留下进程或部分路由。先停止内核，退出客户端，确认虚拟接口和相关进程状态，再重新启动。

防火墙可能按程序路径、网络接口类型或网络配置文件控制访问。客户端更新或切换桌面版与经典 WPF 版后，程序路径可能变化，旧规则不一定继续匹配。出现“系统代理正常、TUN 完全无流量”时，检查内核进程是否允许通过新虚拟接口通信。出现“部分应用正常、部分应用立即失败”时，再检查应用是否绑定了特定物理接口或使用不被当前栈支持的网络方式。

异常退出后，系统可能暂时保留 DNS 或路由设置。处理顺序是先正常关闭 TUN，再退出客户端，然后恢复系统自动获取 DNS 和默认路由。只有确认客户端进程已停止后，才进行系统网络重置。直接在内核运行时删除虚拟网卡，会让客户端继续持有失效接口，日志中出现更多派生错误。

按症状缩小 TUN 故障范围

若开启后所有网络立即中断，先检查默认路由、内核是否成功监听以及代理服务器是否被回环接管。若域名失败但直接 IP 正常，重点检查 DNS 接管和上游查询出站。若网页小资源正常、大资源卡住，保持其他设置不变，测试 MTU 是否过高。若只有 UDP 异常，查看当前服务器协议、TUN 栈和路由规则是否允许 UDP，不要先改 DNS。

若关闭 TUN 后网络仍异常，确认虚拟网卡是否消失、系统 DNS 是否恢复、默认路由是否指向物理网络。重启客户端内核不等于恢复操作系统设置；需要先执行客户端的停止或恢复操作。完成恢复后，再用不经过客户端的基础网络请求确认系统状态，最后重新开启普通代理模式。

TUN 稳定后再配置进程规则、严格路由和 FakeDNS。每新增一项，都重复“域名请求、IP 请求、直连目标、代理目标、局域网资源”五组测试。TUN 的价值是扩大接管覆盖，不是把所有流量强制交给单一出站。最终路径仍由路由规则决定，因此直连网段、DNS 出站和服务器回环例外必须明确。

理解“返回假地址、保留真域名”的过程

应用发起域名查询时，FakeDNS 不立即返回目标的真实 IP，而是从专用地址池分配一个临时地址，并保存“临时地址—原始域名”的映射。应用随后连接这个临时地址，TUN 入站捕获连接后，内核根据映射恢复原始域名，再执行域名路由和真正的远端连接。这样即使应用只提交 IP 数据包，内核仍能按 geosite 或精确域名规则判断出站。

临时地址只在本机映射范围内有意义，不应被发送到局域网或真实外部网络。若 TUN 没有接管该连接、路由表将其送到物理网卡，应用会直接失败。因此 FakeDNS 必须和 DNS 接管及 TUN 路由一起启用。单独在 DNS 配置中加入 FakeDNS 服务器，却没有让返回地址对应的连接进入内核，会得到“解析有结果、连接全部失败”的典型现象。

FakeDNS 主要解决域名信息丢失问题，不会提升服务器连接能力，也不会替代上游真实解析。内核恢复域名后，仍需根据出站方式解析真实目标或把域名交给远端。上游 DNS 不可达、路由标签错误或服务器不支持目标连接时，FakeDNS 无法修复这些问题。

规划地址池，避免与真实网络重叠

地址池应使用专门保留且不与当前局域网、企业网络、虚拟机网络或容器网络重叠的范围。若临时地址与真实内部网段重叠，访问内部资源时可能被误认为 FakeDNS 映射，或外部域名的临时连接被送往真实内网。启用前检查系统路由表，记录物理网络、VPN、虚拟机和容器使用的网段，再选择不冲突范围。

地址池大小决定同时可维护的映射数量。普通桌面使用不需要盲目扩大范围；过大的范围会增加与现有网络重叠的机会。映射存在生命周期，应用缓存的临时地址必须在映射有效期内继续可识别。若应用长期缓存 DNS，而内核重启后映射消失，旧连接可能短暂失败。此时清理应用 DNS 缓存并重新查询即可，不应把旧临时地址写入 hosts。

{
  "dns": {
    "servers": [
      {
        "address": "fakedns",
        "domains": [
          "geosite:geolocation-!cn"
        ]
      },
      "localhost"
    ],
    "fakedns": [
      {
        "ipPool": "198.18.0.0/15",
        "poolSize": 65535
      }
    ]
  }
}

示例地址段用于基准说明。启用前仍需确认本机及所在网络没有占用相同范围。

决定哪些域名进入 FakeDNS

不建议把所有查询一次性切换到 FakeDNS。内部域名、局域网设备名称和必须由本地 DNS 回答的区域应保留真实解析。先让需要域名路由、且会被 TUN 接管的外部域名进入 FakeDNS；其他查询继续由对应解析器处理。分类范围越清晰，出现问题时越容易判断是映射、真实解析还是路由规则导致。

某些应用会比较 DNS 结果、建立直连 UDP 会话或把地址传给系统外的其他设备。这类流程可能不适合临时地址。若某个应用在普通 TUN 下正常，开启 FakeDNS 后失败，先为它涉及的域名设置真实解析例外，而不是立即关闭全部 FakeDNS。确认例外有效后，再判断是否需要扩大该应用的域名集合。

FakeDNS 与流量嗅探可以配合，但职责不同。FakeDNS 在查询阶段建立映射，适用于被接管的 DNS 请求；嗅探从连接内容中尝试恢复域名，适用于没有映射但握手包含域名的流量。两者同时启用时，应查看日志中的目标恢复来源。若目标域名错误或规则异常，逐一关闭其中一项测试，避免无法判断最终域名由哪条路径得到。

按映射链路排查失败

第一步确认应用查询是否进入内核 DNS。若查询没有被接管，返回的是普通真实 IP，后续不会产生 FakeDNS 映射。第二步确认返回地址属于配置的地址池。第三步发起连接并检查 TUN 是否捕获该临时地址。第四步确认内核能从映射恢复域名。第五步查看恢复后的域名命中了哪条路由规则。五步按顺序验证，可以准确判断断点。

如果返回临时地址但连接没有日志，问题在系统路由或 TUN 接管。如果有连接日志但无法恢复域名，检查映射是否因内核重启失效，以及应用是否使用了缓存旧地址。如果域名恢复正确却命中错误出站，回到路由规则顺序处理。如果已经命中正确出站但仍失败，则检查真实 DNS 与出站连接，不再继续修改 FakeDNS。

完成配置后，分别测试首次查询、重复查询、内核重启后的旧缓存以及局域网名称。首次与重复请求用于检查映射复用，重启测试用于确认应用缓存恢复行为，局域网测试用于验证真实解析例外。FakeDNS 配置稳定的标准是域名分流可解释，内部资源不受影响，重启后通过重新查询能够恢复，而不是所有 DNS 结果都变成临时地址。

为每个订阅定义职责

添加第二个订阅前，先说明它解决什么问题。可以按工作环境、设备用途、协议能力或备用关系划分，但不要仅因为“条目更多”而叠加来源。每个订阅应有唯一备注、明确更新方式和独立过滤条件。若两个来源提供大量同名条目，名称前增加短分组标记，确保日志和当前服务器栏能直接识别来源。

主订阅用于日常选择，备用订阅仅在主来源更新失败或特定环境下启用，测试订阅则不参与自动选择。职责写入分组备注后，批量更新和清理才有依据。若所有订阅都长期启用并混合展示，误选旧条目、重复条目或测试配置的概率会持续增加，也无法判断某次参数变化来自哪个来源。

不同订阅可能使用不同协议字段和内核扩展。导入成功不代表当前内核能完整运行。Xray 与 V2Fly 的能力差异可查看Xray 内核与 V2Fly 内核差异解读。v2rayN 可在桌面端承担主要配置管理；Android 端根据内核需要使用 v2rayNG 或 v2flyNG。跨客户端迁移时，应迁移标准分享链接或受支持的订阅格式，不要假设客户端私有设置可以原样互换。

安排更新顺序和失败回退

批量更新时按“备用—测试—主用”的顺序执行。先更新非主用分组，可以提前发现订阅格式变化、过滤规则失效或重复项处理异常。确认导入结构正常后，再更新主用分组。更新期间保持当前已连接条目不变，待新列表检查完成后再切换，避免更新与连接切换同时发生。

订阅更新失败不应立即删除分组重新添加。先记录返回错误，确认请求路径和地址有效性，再尝试单独更新。删除并重建可能丢失分组过滤、更新策略和本地备注，也会让旧条目与新条目之间的对应关系消失。如果确需重建，先导出分组设置或截图记录关键项，并为新分组使用临时名称，验证后再替换旧分组。

对更新结果执行四项检查：条目总类是否合理、当前条目是否仍存在、过滤后是否有可选项、协议字段是否能被当前内核识别。这里不依赖固定数量，因为订阅内容会变化。重点是比较结构，而不是追踪一个容易过时的数字。若更新后列表突然为空，优先关闭过滤；若列表存在但全部无法启动，检查内核兼容与共享字段变化。

处理重复条目与本地副本

重复判断不能只看备注。相同名称可能对应不同地址或协议，不同名称也可能指向相同服务器。清理前至少比较地址、端口、协议、传输、安全设置和服务器名称。客户端的自动去重策略若只覆盖部分字段，仍可能留下功能上相同的条目。反过来，手工按名称删除可能误删不同用途配置。

需要修改订阅条目时，复制成本地副本，并在备注中加入“本地测试”与来源分组名。副本不参与订阅更新，可以用于比较传输参数、路由策略或内核差异。测试完成后，将有效修改反馈到可维护的配置来源，或保留一份有清晰说明的本地条目。不要积累大量无法追溯的副本；它们在几次更新后会与原始配置脱节。

本地路由、DNS 与 TUN 设置通常属于客户端级配置，不应复制进每一个服务器条目。把服务器连接参数与本地网络策略分开后，切换订阅不会重置路由逻辑，也更容易判断问题属于服务器还是本地策略。只有需要特定服务器专属出站链时，才在自定义配置中建立明确引用。

迁移时只带走可解释配置

迁移前列出订阅地址、分组备注、过滤表达式、当前服务器、路由规则、DNS 设置和 TUN 选项。先在新设备导入订阅并验证基础连接，再迁移过滤和路由，最后迁移 DNS、TUN 与 FakeDNS。不要直接把整份生成配置覆盖到不同系统，因为入站监听地址、虚拟网卡、文件路径和权限要求可能不同。

迁移后的第一轮测试使用同一基准服务器和同一组目标。若服务器连接正常但规则不同，比较路由顺序和分类数据库；若域名行为不同，比较系统 DNS、内核 DNS 和应用设置；若仅 TUN 异常，检查新系统的权限、路由与防火墙。分层迁移虽然步骤更多，但每一步都有明确回退点。

多订阅管理完成后，建议保留一份文字化配置说明，记录各分组职责、过滤含义和迁移顺序。说明不需要保存服务器敏感字段，只需描述结构。这样在客户端界面变化或重新安装后，仍能按职责恢复，而不是依赖对旧界面位置的记忆。

从最小出站集合开始

一个可维护的配置至少包含主代理出站、直接出站和阻断出站。主代理出站承载当前服务器连接，direct 让内核使用本机网络连接目标，block 终止明确不需要的请求。先确保三者工作，再增加备用代理、特定接口直连或链式出站。出站越多，路由标签、DNS 路径和日志判断越复杂。

每个出站必须使用唯一且稳定的 tag。标签是路由规则、DNS 查询和其他出站引用的连接点，不只是界面名称。建议使用小写英文和连字符，例如 proxy-main、proxy-backup、direct-work。修改标签后，必须搜索全部配置引用；遗漏一处就可能导致内核启动失败或流量落入兜底。

客户端根据当前服务器自动生成的代理出站可能在切换服务器后变化。若自定义规则引用客户端固定保留的逻辑标签，应确认切换后标签仍存在；若直接引用某个手工出站，则该出站必须独立保存。不要通过复制整段生成配置锁定当前服务器，这会让订阅切换和更新失去作用。

{
  "outbounds": [
    {
      "tag": "proxy-main",
      "protocol": "vless",
      "settings": {
        "vnext": [
          {
            "address": "server.example",
            "port": 443,
            "users": [
              {
                "id": "00000000-0000-4000-8000-000000000000",
                "encryption": "none"
              }
            ]
          }
        ]
      },
      "streamSettings": {
        "network": "tcp",
        "security": "tls",
        "tlsSettings": {
          "serverName": "server.example"
        }
      }
    },
    {
      "tag": "direct",
      "protocol": "freedom"
    },
    {
      "tag": "block",
      "protocol": "blackhole"
    }
  ]
}

示例中的地址与标识仅用于展示结构，实际连接参数应来自有效配置。

为 direct 出站指定清晰边界

direct 并不表示流量绕过内核，而是请求进入内核后由 freedom 出站从本机网络建立连接。它仍会受到内核 DNS、地址族策略和出站绑定设置影响。局域网、内部域名和明确直连分类通常指向 direct，但必须确保路由规则顺序正确。若 TUN 已接管 direct 流量，还要防止该出站连接再次被系统路由送回 TUN。

在多网卡环境中，可以为特定 direct 出站设置发送接口或源地址，让工作网络与普通网络分开。配置前先确认接口名称稳定，并验证目标网段可从该接口到达。系统休眠、网络切换或接口重建后，绑定名称可能失效。出现“默认 direct 正常、自定义 direct 失败”时，先移除绑定恢复基线，再检查接口和源地址，不要修改目标路由规则。

阻断出站应只接收明确匹配的流量。block 命中通常表现为本地立即失败，与远端超时不同。日志中若能看到请求进入 block，就不应继续检查服务器。为便于排查，阻断规则集中放置并写明目的，避免分散在多个预设和自定义列表中。

谨慎使用代理链

链式出站让一个代理出站通过另一个出站建立连接。它适用于有明确网络拓扑的场景，但会增加一次或多次连接层。每一层都涉及服务器解析、路由、传输与错误处理。配置前先分别验证每个出站单独可用，再建立引用；链路失败时从最外层连接开始查看，确认请求实际到达哪一层。

出站引用必须避免环路。若 proxy-a 通过 proxy-b，而 proxy-b 又通过 proxy-a，两者都无法建立基础连接。更隐蔽的环路来自路由：proxy-b 的服务器地址被规则重新送回 proxy-a，而 proxy-a 又依赖 proxy-b。解决方法是为链路中的服务器地址设置高优先级规则，并明确它们应经 direct 还是某个前置出站。

链式配置还需要考虑 DNS。每个服务器域名由哪一层解析、查询走哪个出站、解析结果是否被 TUN 接管，都应事先确定。最稳妥的方法是先使用可直接解析的入口服务器建立第一层，再让后续连接经过已建立出站。不要让最底层连接依赖最上层的 DNS 路径。

用标签闭环验证整份配置

完成自定义出站后，列出所有标签及其引用方。每条路由规则引用的出站都必须存在；每个链式引用都必须指向可独立建立的前置出站；DNS 专用出站不能依赖自身；TUN 排除路径必须覆盖代理服务器连接。然后检查是否有从未被引用的出站。未引用项不一定错误，但通常意味着旧配置残留或预期规则尚未建立。

• 使用主代理出站测试明确代理域名，并在日志中确认标签。
• 使用 direct 测试局域网与明确直连目标，确认没有返回 TUN 入站。
• 使用一条临时精确规则测试备用出站，完成后删除临时规则。
• 触发一个明确阻断目标，确认日志显示本地 block 命中。
• 重启内核后再次测试，排除仅由旧连接或缓存维持的假正常状态。

配置无法启动时，先验证 JSON 结构，再查重复标签、未知出站引用和协议必填字段。能够启动但路径错误时，查看路由首个命中项。路径正确但连接失败时，再检查目标出站本身。不要把启动错误、路由错误和连接错误放在同一轮修改中处理。

至此，订阅、过滤、路由、DNS、TUN、FakeDNS 与出站形成完整闭环。后续新增规则时，从请求入口沿链路逐层判断，不从最终报错反向猜测全部配置。若需要重新建立基础环境，可回到使用指南按快速主线操作；若需要更换客户端或桌面版本，可进入V2Ray 客户端下载页。配置完成后保留一份结构说明和可工作基线，下一次调整只改变一个变量。