V2Ray 进阶配置

路由规则与匹配顺序

路由规则决定一条已进入内核的连接使用哪个出站。规则不负责让应用自动进入代理，也不能修复失效的服务器。理解路由前，先区分入口、匹配条件和出站：入口接收连接，条件检查域名、目标 IP 或端口，出站执行直连、代理或阻断。应用若根本没有进入入口，再完整的规则也不会生效。

先核对生成配置中的标签

v2rayN 和 v2rayNG 提供路由设置入口，可通过图形界面调整规则与预设。编辑前先查看当前配置或运行日志，确认代理、直连和阻断出站的真实标签。下例假定存在名为 proxy、direct 与 block 的出站；这些标签只是可读名称，不能证明当前客户端恰好使用同名标签。

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "domain": ["full:blocked.example"],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "domain": ["domain:example.com", "geosite:cn"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": ["geoip:private", "geoip:cn"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

这是用于说明顺序的路由片段，不是完整客户端配置。示例域名应换成实际业务域名，分类集合需要对应数据文件可用。规则从前到后检查，首先匹配的规则决定去向。末尾的全匹配规则会接住剩余 TCP 与 UDP 流量，因此不能放在局部规则前面，否则后面的域名和 IP 条件没有机会被检查。

理解域名与 IP 条件的边界

full: 用于精确域名匹配；domain: 用于域名及其子域；geosite: 引用域名集合；geoip: 引用 IP 集合。同一规则中同时填写域名和端口，通常意味着连接需要同时满足这两类条件，不是任选其一。若目的是“某域名或某 IP 都直连”，应分别创建两条规则。

domainStrategy 控制路由阶段是否为匹配而解析域名。AsIs 尽量使用原始目标；IPIfNonMatch 在域名条件没有命中后尝试解析并继续匹配 IP；IPOnDemand 遇到需要 IP 判断的规则时可能触发解析。它不是 DNS 服务器列表，也不能保证应用自行执行的解析自动由内核接管。

当域名最终被解析为共享服务地址时，仅靠 IP 分类可能把不同业务放到同一个出口。对需要明确控制的业务，优先使用具体域名规则，并置于宽泛分类之前。若软件依赖登录、图片、验证与更新等多个域名，只加入主站域名可能不够；应结合连接日志补齐依赖，而不是直接放大到全部流量。

嗅探与局域网规则

「启用流量嗅探」可以尝试从受支持的连接内容中恢复域名信息，帮助按域名分流，但不能识别所有协议，也不能解开加密内容。只有目标 IP 的连接不一定能被补回域名。启用后如果某些应用异常，应先检查嗅探相关的目标覆盖行为，并单独回退该设置，避免同时改变 DNS 和路由造成混淆。

局域网直连通常需要私有地址规则，同时还受客户端「绕过局域网」、系统路由与 TUN 排除网段影响。不要因为内核里写了直连规则，就认为所有局域网访问都已绕过虚拟网卡；也不要把私有地址段随意代理到远端。企业网络的内部域名与地址应按实际网络规划设置，尤其要注意远端私网与本地私网重叠。

验证时固定一个服务器，依次测试精确域名、分类域名和未匹配目标，在日志里确认出站标签。若规则编辑后没有变化，检查是否选中了刚修改的路由配置，以及是否需要重新启动连接。分类数据缺失时应先解决加载错误，不要盲目改成更宽泛的直连规则。更多基础概念可在帮助中心继续查阅。

FakeDNS 与虚拟地址映射

FakeDNS 不向应用返回目标服务器的真实地址，而是分配一个内部虚拟地址，并保存它与域名的对应关系。应用随后连接这个地址时，接管组件需要查回域名，再按路由与出站处理。这个机制的价值是保留域名信息，不是让虚拟地址在普通网络中直接可达。离开映射环境后，地址本身通常没有访问目标的意义。

先满足完整的接管条件

要让 FakeDNS 工作，相关 DNS 查询必须进入它的处理路径，应用连接到虚拟地址的流量也必须被同一套接管机制捕获。只有其中一部分生效，会出现解析成功但连接失败。浏览器自行使用加密 DNS 时，可能绕开 FakeDNS；应用缓存旧地址时，也可能继续使用真实地址，导致同一设备上看似不一致。

v2rayNG 中的「启用 FakeDNS」应与 VPN 模式、DNS 设置及嗅探相关配置配合检查。图形开关可能自动生成多处内核配置，因此不要只比较一个布尔值。v2rayN 的 TUN DNS 也可能由接管组件实现相似机制，其配置字段和状态存放位置未必与 Xray 内核相同，不能把一侧的片段直接粘贴到另一侧。

v2flyNG 使用 v2fly 内核，具体能力应以当前界面及配置解析结果为准。遇到未知字段，应回到该内核支持的配置结构，而不是删掉错误提示后继续启用。客户端名称、界面开关与内核配置是三个层次，功能同名不代表字段完全兼容，这一点在跨客户端迁移 DNS 设置时尤其重要。

理解映射池与嗅探协作

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

上例仅展示支持该结构的 Xray 配置中的映射池片段，不是启用 FakeDNS 的完整方案。还需 DNS 使用 FakeDNS、相应入口恢复域名，以及虚拟地址段被接管。ipPool 决定分配范围，poolSize 决定映射容量；它们不是服务器数量，也不反映网络表现。优先采用客户端生成的兼容配置，不要仅添加这一段就开始测试。

映射地址段不能与当前网络或其他虚拟网络发生冲突。企业实验网络、其他隧道工具可能已经使用相同范围，出现冲突时应统一规划。不要把虚拟地址池加入绕过接管的名单，否则应用连接会直接进入普通网络。也不要把这一地址段当作真实目标放进远端的直连策略，映射应在正确的本地处理层恢复。

流量嗅探与 FakeDNS 可以协作，但作用不同。常规嗅探尝试从连接内容恢复域名；FakeDNS 恢复则依赖先前建立的映射。如果连接到来时映射已经丢失，单靠普通嗅探未必能补救。客户端重启、映射淘汰或组件状态不同步，都可能让应用保留的虚拟地址失去对应域名。

识别适用场景与恢复方法

需要稳定按域名分流、而入口常常只获得 IP 时，可以在基础链路稳定后测试 FakeDNS。直接连接固定 IP 的程序、局域网发现、某些校验 DNS 结果的应用，可能不适合这一机制。对这些应用，优先考虑明确的接管排除或普通解析方案，不要以修改更多全局开关代替针对性判断。

启用后先测试普通网页，再测试登录、媒体和后台业务。若只有部分应用失败，记录它是否自带加密 DNS、是否固定连接 IP，以及是否在启用前已经运行。先完全关闭应用后重试；如果仍有问题，关闭 FakeDNS 并保持其他配置不动，使用同一目标做对照，才能判断故障是否来自地址映射。

记录问题时保留域名、出现问题的接管模式和出站标签即可，不需要公开整份配置。若关闭后恢复，而重新启用又稳定复现，继续核对 DNS 接管、地址池路由与映射恢复环节。若两种模式都失败，应返回服务器连接和普通 DNS 检查，不宜继续围绕 FakeDNS 调整无关参数。

配置验证与逐层恢复

进阶配置的验证目标不是“页面偶尔能打开”，而是能够解释某个请求从哪里进入、如何解析、命中哪条规则、最终经哪个出站离开。建立一份最小基线后，再逐项增加分组过滤、路由、TUN 和 FakeDNS。每一步都留下可恢复状态，才能在出现问题时缩小范围，而不是用重装客户端代替定位。

建立固定的验证样本

基线应包含一条已验证可用的服务器、普通 DNS、最简单的路由和明确的入口方式。选择一个日常使用的完整域名、一项局域网资源和一个需要代理的业务作为固定样本。测试过程中保持设备网络与服务器不变，避免一边切换无线网络，一边修改解析器，再凭访问结果推断某项设置有效。

每次修改前记录原值、修改目标和预期结果。例如新增一条精确域名直连规则，预期应是日志中的出站标签改变，而不是笼统地期待“更稳定”。保存并重启连接后，关闭测试应用的旧连接再访问。对于订阅更新，先验证条目能生成；对于 TUN，先验证接口与路由；对于 FakeDNS，先验证虚拟地址能够被恢复。

用日志区分失败阶段

配置解析错误通常出现在启动时，表现为字段、语法或标签问题；监听失败多与端口冲突和权限有关；连接建立后的超时才需要继续检查网络和远端。先找到最早出现的错误，不要只复制后面反复出现的连接失败。前一层没有成功，后一层的错误可能只是结果，修改后一层往往不能解决根因。

临时提高日志详细程度可以帮助确认目标与出站，但不宜长期保留高详细日志。日志可能包含域名、地址和业务活动，分享前应脱敏。截图时也要检查订阅 URL、连接凭据和完整分享链接。排查结束后恢复常用日志级别，并清理不再需要的临时文件，避免敏感配置散落在下载目录或共享文件夹。

同一业务可能建立多条连接。主文档成功而登录失败，常见原因是依赖域名走了另一条规则；图片失败则可能是资源域名、解析结果或地址家族不同。应按失败请求补充规则与验证，而不是看到一处异常就把全部流量改成同一路径。必要时短暂使用简化路由作对照，测试后恢复原有策略。

按相反顺序回退变量

若问题出现在连续调整之后，先回退最近一项：关闭新加入的 FakeDNS，恢复普通 DNS，再撤销新增路由，最后退出 TUN 或 VPN 接管，回到原先的入口。每次回退后用相同样本测试。不要同时清空分组、删除服务器和重置系统网络，否则即使恢复可用，也无法知道原来的故障来自哪里。

停止客户端后仍然无法访问网络，应检查系统代理是否残留、虚拟路由是否恢复，以及其他网络工具是否仍在运行。不要立即删除未知网卡或批量改系统路由；先保存现场并确认归属。只有浏览器异常时，检查浏览器单独设置的代理和加密 DNS；只有一个应用异常时，检查分应用接管与该应用的网络选项。

需要重新建立操作主线时，返回快速上手教程，按导入、模式、连接和验证重新执行；需要查找单个现象时，使用帮助中心。安装包选择留在下载页完成。本手册的配置片段用于解释对应层次，不能取代完整配置；将其用于实际环境前，应核对客户端、内核和当前生成结构。