Xray路由与DNS防泄漏进阶配置：JSON原理与实践

先理解路由与 DNS 为什么会互相影响

很多人第一次配置 Xray 分流时，会把注意力全部放在 routing.rules 上，认为只要把国内域名设为直连、国外域名设为代理，所有流量就会自然按照预期运行。实际情况没有这么简单。应用访问一个域名时，通常要先通过 DNS 把域名解析成 IP，之后才建立 TCP、UDP 或其他传输连接。如果 DNS 请求走了错误的出口，或者域名在路由匹配之前已经被本地解析，最终就可能出现 DNS 泄漏、规则判断失效、访问地区异常等问题。

因此，Xray 的路由配置至少包含三条需要同时考虑的链路：第一是应用发出的原始请求如何进入 Xray；第二是 Xray 如何识别目标域名、IP、端口和协议；第三是 DNS 查询本身通过哪个服务器、哪个出站发送。只调整其中一部分，往往只能解决表面现象。例如浏览器网页可以打开，但系统 DNS 仍然向运营商服务器发送查询；又或者域名规则写得正确，却因为应用只提供 IP 地址，导致 domain 规则根本没有机会命中。

进阶配置的目标不是把 JSON 写得越长越好，而是让每一个请求都有清晰、可追踪的处理路径。建议先确定“域名如何识别”，再确定“DNS 如何解析”，最后安排“路由如何选择出站”。这三个问题分开设计，后续无论切换 v2rayN、v2rayNG 还是其他支持 Xray JSON 的客户端，都更容易迁移和排错。

Xray JSON 的核心结构与执行顺序

一个可维护的 Xray 配置，通常可以分为 inbounds、outbounds、routing、dns 和 log 几个部分。inbounds 负责接收本机应用流量，outbounds 定义直连、代理和拒绝等出口，routing 根据规则选择出口，dns 则定义域名查询服务器与解析策略。它们不是互相独立的开关，而是一条从接收请求到完成连接的处理链。

在路由规则中，domain、ip、port、network 和 protocol 是最常用的匹配条件。比如 "domain": ["geosite:cn"] 用于匹配 geosite 数据库中的中国大陆域名，"ip": ["geoip:cn"] 用于匹配中国大陆 IP，"network": "udp,tcp" 则表示同时覆盖 TCP 与 UDP。规则从上到下依次判断，通常采用先处理明确例外、再处理大范围分类、最后使用兜底规则的顺序。

每条规则至少要有一个有效的 outboundTag，例如 proxy、direct 或 block。如果你在规则里写了一个出口标签，却没有在 outbounds 中定义相同的 tag，配置可能无法启动，或者请求无法按照预期转发。修改 JSON 后，应先使用客户端提供的配置检查功能，确认括号、逗号、字段类型和标签引用都没有错误，再进行连接测试。

一个基础的出口结构可以这样理解：{"outbounds":[{"protocol":"freedom","tag":"direct"},{"protocol":"blackhole","tag":"block"},{"protocol":"vless","tag":"proxy","settings":{...}}]}。其中代理出口的具体协议参数应由你的节点信息决定，不能直接照抄示例中的占位内容。本文重点放在路由与 DNS 逻辑，节点认证、传输层和安全参数仍应以服务端提供的配置为准。

sniffing 与 routeOnly：保留域名才能正确分流

当应用通过域名访问目标时，Xray 最理想的情况是直接获得域名，然后使用域名规则判断。可是有些应用在建立连接时只把 IP 地址交给代理，或者先由本地系统完成 DNS，再把解析后的 IP 发给 Xray。此时路由层看到的只有 IP，geosite、域名后缀和关键字规则就可能无法命中。

sniffing 可以从经过的连接中识别 HTTP Host、TLS SNI 等信息，把原本只有 IP 的连接还原出更有价值的域名线索。典型入站配置会使用 "sniffing":{"enabled":true,"destOverride":["http","tls","quic"],"routeOnly":true}。其中 destOverride 表示允许从不同协议中提取目标域名，routeOnly 表示识别到的域名主要用于路由判断，而不是强行修改后续连接目标。

开启 sniffing 并不代表所有流量都能被识别。加密方式、应用协议、QUIC 行为以及应用自身的连接方式都会影响识别结果。对于 TLS，SNI 通常比较有用；对于部分基于 IP 的连接、加密 DNS 或特殊私有协议，Xray 可能仍然只能看到 IP。换句话说，sniffing 是补充信息的机制，不是百分之百的域名恢复工具。

routeOnly 的价值在于降低“识别结果改变真实目标”带来的副作用。配置初期建议先使用 routeOnly，让 sniffing 只参与路由匹配。确认规则稳定后，再根据实际需求评估是否需要其他目标覆盖行为。若某个应用开启后出现连接失败、证书异常或服务端拒绝，第一步应是暂时关闭对应协议的 sniffing 或恢复 routeOnly，而不是立即修改节点参数。

此外，嗅探会增加一点处理工作，也可能让隐私边界变得更复杂。只在自己控制的设备和合法网络环境中使用，并避免为了追求“规则全命中”而无条件开启所有协议。更稳妥的做法是从 http、tls 开始，确认需求后再考虑是否加入 quic。

DNS 分流：把查询请求纳入 Xray 路由

DNS 防泄漏的关键不是简单地把 DNS 地址改成公共服务器，而是确保查询请求的来源、传输方式和出口都符合你的路由设计。如果客户端仍把域名交给操作系统解析，系统就可能使用本地网络下发的 DNS；即使最终代理连接没有泄漏，DNS 查询记录也可能暴露访问目标。因此，进阶配置通常会让 Xray 接管 DNS 查询，并为不同域名设置不同的解析服务器。

一个常见思路是：国内域名交给国内 DNS，国外或代理域名交给远程 DNS，并通过 expectedIPs、domains 或客户端支持的 DNS 路由字段控制匹配范围。配置形式可以抽象为 {"dns":{"servers":[{"address":"https://dns.example-direct/dns-query","domains":["geosite:cn"]},{"address":"https://dns.example-proxy/dns-query","skipFallback":true},"localhost"]}}。这里的域名和服务器地址只是示意，实际使用时应替换成你信任且能够访问的解析服务。

如果远程 DNS 本身需要经过代理才能访问，就不能把它当成普通直连服务器处理。你需要确认客户端版本是否支持为 DNS 查询指定出站，或者使用 Xray 文档中对应版本的 DNS 配置方式。不同核心版本和客户端界面可能对字段支持程度不同，不能只看网上一段旧 JSON 就判断当前版本一定可用。

防止 DNS 泄漏还需要检查系统层面的残留设置。开启 TUN 或透明代理时，操作系统、浏览器和其他 VPN 软件可能各自拥有 DNS 行为；多个工具同时接管 DNS，容易出现端口冲突、查询循环和随机失败。建议只保留一个主要的 DNS 接管者，并关闭浏览器自带的安全 DNS，或把浏览器的 DoH 策略明确纳入你的设计。否则浏览器可能绕过 Xray，直接向自己的 DoH 服务查询。

验证时不要只看网页是否能打开。可以先关闭客户端，观察系统 DNS 是否恢复正常；再开启客户端，分别测试国内域名、国外域名、一个不存在的域名，以及直接输入 IP 的地址。若只有域名访问异常，重点检查解析路径；若域名与 IP 都异常，再回到出站、路由和节点状态排查。

FakeDNS 与 geosite：减少解析与规则之间的冲突

FakeDNS 的思路是为域名返回一个虚拟 IP，并在后续连接阶段根据这个虚拟地址还原原始域名。这样，即使某些应用只把 IP 交给代理，Xray 仍有机会保留域名信息并执行域名路由。它特别适合需要透明代理、TUN 或复杂分流的场景，但同时也会增加配置复杂度，并不是所有应用都适合直接启用。

使用 FakeDNS 时，必须留意虚拟地址池不能与真实局域网、公司网或家庭网络冲突。常见做法是规划一个专用的保留网段，并在路由中把这个网段交给 Xray 处理。配置逻辑可以写成 {"dns":{"queryStrategy":"UseIP","fakeDns":[{"ipPool":"198.18.0.0/16","poolSize":65535}]}}，但具体字段名称、位置和客户端暴露方式可能随 Xray-core 版本变化，导入前应核对当前核心文档与客户端生成的默认配置。

geosite 和 geoip 也不要混用。geosite:cn 是域名集合，适合判断网站名称；geoip:cn 是 IP 地址集合，适合判断已经解析出的目标 IP。最稳妥的策略通常是先用域名规则，再用 IP 规则补充，最后设置明确的代理或直连兜底。例如顺序可以是：私有地址直连、广告与恶意域名拒绝、国内域名直连、国内 IP 直连、其余流量代理。

示意性的路由片段可以写成 {"routing":{"domainStrategy":"IPIfNonMatch","rules":[{"type":"field","ip":["geoip:private"],"outboundTag":"direct"},{"type":"field","domain":["geosite:category-ads-all"],"outboundTag":"block"},{"type":"field","domain":["geosite:cn"],"outboundTag":"direct"},{"type":"field","ip":["geoip:cn"],"outboundTag":"direct"},{"type":"field","network":"tcp,udp","outboundTag":"proxy"}]}}。这里的 IPIfNonMatch 表示域名没有命中时，再尝试解析为 IP 并继续匹配。它能提升 IP 规则的覆盖率，但也意味着 DNS 解析会参与更多请求，因此必须与前面的 DNS 设计保持一致。

把 sniffing、DNS 与路由组合起来

工程化配置的重点是模块边界清楚。入站只负责接收流量与提供必要的嗅探信息；DNS 模块负责解析策略；路由模块负责决定出口；出站模块负责真正建立连接。不要把所有字段压缩成一行，也不要在每个规则里重复写一大段相同参数。JSON 保持适度换行和固定顺序，未来升级或迁移时会省下很多时间。

一个组合后的结构可以按以下顺序组织：入站中设置 sniffing.enabled 为 true，将 destOverride 设为 http、tls 和按需加入的 quic，同时启用 routeOnly；DNS 中分别定义直连解析与代理解析；路由中先处理私有地址和明确拒绝项，再处理 geosite、geoip，最后使用代理兜底。这样的结构比“先写几十条规则，最后发现 DNS 不知道走哪里”更容易验证。

路由策略可以概括为下面几条原则：

  • 局域网、回环地址和本机服务优先直连，避免 TUN 或透明代理影响本地管理页面。
  • 广告、恶意域名等明确不需要访问的目标优先进入拒绝出口，减少后续解析和连接。
  • 优先使用域名规则识别站点，再用 IP 规则覆盖只有 IP 的连接。
  • 代理 DNS 与代理流量使用一致的出口逻辑，避免解析结果与实际访问地区不一致。
  • 最后保留一个明确的兜底出口，避免未匹配请求因为没有标签而失败。

需要特别注意的是，路由规则不是越多越精确。大量重叠的域名、IP 和进程规则会让维护成本快速上升，也会让你很难解释某个请求为什么命中了某条规则。建议先建立少量高置信度规则，使用日志验证命中情况，再根据真实需求扩展。每增加一组规则，都应明确它解决的是哪一个实际问题。

验证配置：从日志到分层排错

修改完成后，第一步是验证 JSON 语法与核心启动状态。若客户端直接提示配置错误，应先检查逗号、括号、字符串引号、数组格式和字段层级；若能启动但无法连接，再检查出站标签是否一致。不要在 JSON 还无法加载时讨论 geosite 是否准确，那属于不同层级的问题。

第二步是查看路由日志。将日志级别临时调整到能够显示路由判断的级别，分别访问一个国内域名、一个需要代理的域名、一个广告域名和一个局域网地址，观察实际命中的 outboundTag。如果域名没有被识别，检查 sniffing、入口类型和应用是否只发送 IP；如果规则命中了却访问失败，再检查出站与节点参数。

第三步是单独验证 DNS。确认 DNS 请求是否由 Xray 处理，解析服务器是否按照预期区分直连与代理，浏览器是否绕过系统设置使用自己的 DoH。使用 FakeDNS 时，还要确认虚拟地址池没有被其他网络占用，并检查 TUN 的路由表是否把该网段送回客户端。遇到“网页能开但某些应用完全不能用”，通常要优先看应用协议、UDP 支持和虚拟地址回收，而不是只改域名列表。

  1. 先确认客户端能加载 JSON，且所有出站标签都存在。
  2. 再用单个节点验证代理出站本身可用。
  3. 开启 sniffing 后测试域名规则是否能命中。
  4. 接管 DNS，分别测试直连解析与代理解析。
  5. 最后再启用 FakeDNS、TUN 和更多复杂规则。

这种逐层增加功能的方式看起来慢，实际上比一次性导入完整配置更快。每一层都能留下一个稳定基线：节点正常、路由正常、DNS 正常，最后才是 FakeDNS 或透明代理的兼容性问题。排错时也应一次只改一个变量，并记录改动前后的表现，避免多个开关同时变化后无法判断真正原因。

维护策略与常见安全边界

geosite、geoip 数据库和 Xray-core 都可能更新，规则行为也会随数据版本发生变化。配置文件应与核心版本一起记录，至少保留修改日期、使用的核心版本和自定义规则说明。不要把一份在 v2rayN 上正常运行的 JSON 不加检查地复制到 v2rayNG 或其他客户端，因为入口、TUN 权限、DNS 接管方式和默认字段可能不同。

建议把节点认证信息与路由模板分开管理。分享配置或发布排错日志时，删除服务器地址、UUID、密码、私钥、短 ID 和订阅链接。日志中也可能出现完整域名、请求目标和本地网络信息，不要为了证明规则命中就把全部日志原样公开。配置工程化不等于把敏感信息集中到一个容易传播的文件里。

最后要记住，DNS 防泄漏只是隐私与网络行为管理的一部分。它不能保证所有应用都绝对不会上报域名，也不能替代系统安全更新、浏览器隐私设置和可信的节点来源。实际部署时应遵守当地法律法规与网络服务条款，选择合法合规的使用场景。把 JSON 写清楚、把日志看明白、把每一次变更控制在可回滚范围内，才是 Xray 分流从“能用”走向“可维护”的关键。