V2Ray 进阶配置
路由、DNS 与 TUN

01 / 配置来源

订阅分组与服务器过滤

分组边界

订阅分组首先是来源管理工具，不是流量分流规则。一个分组通常保存订阅地址、更新选项与该来源生成的服务器记录。把某条服务器移入分组，并不会自动让某类网站使用它；网站走哪个出站仍由当前连接配置和路由决定。先划清这层边界，才能避免把列表整理误当成网络策略。

在 v2rayN 中，先打开订阅分组管理，新建名称清楚的分组，再录入来源提供的订阅地址。名称建议描述用途或来源，例如“日常使用”和“备用连接”，不要只写难以区分的字母。保存后对当前分组执行更新，再回到服务器列表确认导入结果。不同界面的菜单位置可能不同，应以项目名称和功能说明识别入口。

订阅地址往往携带访问凭据，应当按账户信息处理。分享截图前遮住地址和二维码，不要把完整链接粘进公开日志。地址能在浏览器打开，不代表返回内容一定适合当前客户端；登录页、提示页面和格式转换结果都可能被当成普通文本下载，最终表现为更新完成却没有可用记录。

服务器过滤

过滤用于缩小列表或控制更新后保留的记录，但各客户端的过滤作用范围不同。有的只影响当前显示，有的在订阅解析阶段排除条目。第一次设置时，先用简单的名称关键词验证行为：记录更新前的可见内容，保存条件，重新更新该分组，再清空筛选观察。只有理解实际作用，才适合继续组合复杂条件。

若输入框明确支持正则表达式，可用下列模式匹配名称中的两个用途词。竖线表示“或”，括号用于分组。若输入框只支持普通文本，粘贴正则不会获得相同效果。名称由来源决定，可能随更新变化；地区缩写、倍率标注与协议名称也未必有统一格式，过滤条件应保持宽松。

(日常|备用)

先判断输入框是“保留匹配”还是“排除匹配”。相同表达式放在不同模式中，结果会完全相反。出现空列表时，不要立刻重新安装客户端：清空过滤条件、选择全部分组、取消搜索，再更新单个来源。若记录重新出现，问题位于显示或过滤层，而不是服务器连接参数。

更新与手工修改

订阅记录通常由远端数据重新生成。直接修改其地址、端口或传输字段，下次更新可能恢复原值。需要长期保留的调整，应复制为独立的手工记录并使用不同名称，同时说明复制日期与用途。这样既能继续接受来源更新，也能知道哪一条已经脱离订阅管理，避免用旧参数覆盖新配置。

Android 上的 v2rayNG 与 v2flyNG 也应按来源分别管理订阅。导入二维码适合单条配置，订阅导入适合后续批量更新；两者不是同一种数据关系。若从另一台设备迁移，先确认导出的是单条连接、订阅地址还是完整应用配置，再选择对应的导入入口，不要反复尝试不相干的格式。

更新失败时，先保留当前可用记录，再检查系统时间、订阅是否过期以及更新请求是否需要已有代理。某些客户端允许通过当前代理更新，某些更新路径使用直连。先用当前网络能到达的方式更新一个分组，成功后再考虑自动更新；不要让全部来源依赖一条尚未验证的连接。

完成整理后，选一条记录作为测试基线，暂时不要开启自动切换与复杂筛选。先证明该连接在普通系统代理下可用，再进入路由和 DNS 章节。来源管理解决的是“配置从哪里来”，连接测试解决的是“配置是否能用”，这两项验收应分开记录，才能缩小后续故障范围。

03 / 域名解析

DNS 配置优化

解析链路

DNS 优化先解决路径一致性，再考虑响应速度。一次访问可能经过系统解析器、浏览器内置的加密解析、客户端 DNS 与远端服务器解析。只有知道谁发出查询、查询走哪条出站、结果交给谁使用，才能判断改动是否有效。单独替换一个服务器地址，通常不能控制整条解析链路。

系统代理主要转发遵循代理设置的应用请求，不一定接管系统 DNS。浏览器可能把域名直接交给代理，也可能先自行解析；其他程序还可能直接访问固定解析地址。因此，客户端中填入 DNS 并不代表设备上的全部查询都会使用它。应分别检查浏览器设置、系统网络设置以及客户端的接管范围。

远程解析与直连解析的划分，应服务于路由目标。直连资源通常适合使用当前网络可达的解析器，代理资源则需要确认解析请求能经预期路径到达。若加密解析服务器使用域名地址，还需要先解析该服务器本身，这一步称为引导解析；引导路径错误会形成“等待解析器解析自身”的依赖问题。

内核 DNS 示例

以下是主配置中的局部 dns 对象。中国大陆域名优先交给指定服务器，其他查询使用 DoH 地址。示例用于解释按域名分配解析器的结构，不承诺适合所有网络。DoH 请求在具体内核与配置下如何选出站，仍须结合路由和日志验证，不能根据地址前缀推断其必然走代理。

{
  "dns": {
    "queryStrategy": "UseIPv4",
    "servers": [
      {
        "address": "223.5.5.5",
        "domains": ["geosite:cn"]
      },
      "https://1.1.1.1/dns-query"
    ]
  }
}

domains 用于指定优先匹配该服务器的域名范围，但查询失败后的行为还受回退选项与内核实现影响。它不应被理解为严格的网络隔离策略。若需要限制某类查询绝不访问其他解析器，应进一步确认当前内核支持的回退字段、失败行为和真实网络路径，再设计规则，不能只保留这段示例。

queryStrategy 在这里限定内核 DNS 的查询策略，不会关闭操作系统的 IPv6，也不会阻止所有应用自行查询其他记录。选择 IPv4 可用于隔离双栈问题，但不是通用提速开关。若当前网络和服务器都能正确处理 IPv6，应单独验证后再决定是否保留，而不是长期隐藏相关故障。

缓存与分层验证

更换解析配置后，旧结果可能继续留在系统、浏览器、应用和内核缓存里。先关闭目标应用并重启客户端，再按系统提供的方式刷新缓存。比较时使用同一个域名并记录解析结果与实际连接地址；不要仅刷新网页一次就认定新配置生效，页面资源可能来自本地缓存或仍在复用旧连接。

出现“地址能访问、域名打不开”时，先查 DNS；出现“域名能解析、连接失败”时，继续查路由和远端连接。解析成功只说明拿到了结果，不说明结果适合当前网络路径。某些服务按解析器位置返回不同接入地址，直连解析结果再交给远端出站，可能带来不必要的绕行或连接失败。

如果只有浏览器表现异常，暂时关闭其自定义安全 DNS，恢复跟随系统的设置后对比；如果只有某个应用异常，检查它是否使用独立解析或固定地址。测试结束后再决定最终策略。这里的临时关闭是为了缩小问题范围，不是建议所有网络都采用同一种解析方式。

客户端的“远程 DNS”“直连 DNS”等表单字段可能由配置生成器转换成多个内核对象。优先使用同一套表单完成设置，不要同时在自定义 JSON 中再写一套相反配置。需要手工扩展时，查看最终生成文件，确认没有重复对象与覆盖关系，再把有效修改记录到独立的变更说明中。

05 / 域名映射

FakeDNS

虚拟地址与原始域名

FakeDNS 为域名返回池内的虚拟地址，并在内部保存地址与域名的映射。应用随后连接该虚拟地址时，配套入口恢复原域名，再交给路由和出站。它不是公共解析器，也不是让目标网站拥有新地址。它的价值在于保留域名信息，减少本地真实解析对后续分流判断的影响。

这套机制要求查询与连接处于同一条受控链路。只有 DNS 查询进入 FakeDNS，而后续连接绕开客户端，应用就会尝试直接访问一个并非真实服务器的地址。相反，若连接进入了入口，但查询由浏览器的独立加密 DNS 完成，客户端可能从未建立映射，域名恢复也就无法按预期发生。

因此不要把 FakeDNS 当作普通 DNS 地址填进系统。先确认客户端及入口组件明确支持对应模式，再按照同一套实现配置查询接管、地址池路由和映射恢复。v2rayN 调度的 TUN 组件可能使用自己的虚拟地址机制，不能因为功能名称相似，就同时启用另一套内核 FakeDNS。

Xray 局部配置

下面展示 Xray 中的三个相关层级：顶层地址池、DNS 服务器列表，以及需要合并到目标入口的嗅探对象。地址池使用保留的基准测试地址段，不是公网目的地址。此片段没有创建透明入口，也没有添加系统路由；缺少这些配套条件时，复制它不会让整台设备自动获得 FakeDNS 功能。

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

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

ipPool 定义虚拟地址范围，poolSize 控制映射池容量。池中地址只是标识，不应该被当成真实远端地址交给直连出口。配置前还要检查现有局域网、其他隧道和测试网络是否使用同一范围。地址范围冲突会让部分连接被错误送到物理接口或其他虚拟接口。

destOverride 中的 fakedns 用于按映射恢复目标。这里显式使用 routeOnly: false，因为仅用于路由判断、却仍保留虚拟地址作为实际连接目标，无法满足这段示例的目的。普通 HTTP 或 TLS 嗅探与 FakeDNS 映射并不是同一机制，不应只根据字段名称相近就互换。

兼容性与故障定位

启用后先检查一个普通域名的解析结果是否落在配置池内，再观察连接是否被正确还原为域名。若结果仍是真实公网地址，应检查查询是否进入目标 DNS 链路；若得到虚拟地址却连接失败，应优先检查地址池流量是否回到配套入口，以及入口是否使用同一份映射状态。

某些程序会在本地检查地址类型、拒绝保留地址，或者把解析结果传给另一台设备使用。这类场景可能不适合 FakeDNS。局域网设备发现、依赖真实地址的业务和特定网络诊断工具，应按客户端支持的方式设置真实解析例外。例外需要同时处理解析与路由，不能只把虚拟地址范围设为直连。

重启后，系统或应用可能仍缓存着旧虚拟地址，而新进程中的映射表已经变化。这会造成“刚启用能用，重启后局部失败”的现象。应先清理相关缓存并重启目标应用，再判断配置是否有误。不要把旧虚拟地址写进长期 hosts 记录，也不要把它当成服务的固定连接地址保存。

如果普通 DNS 与域名嗅探已经满足分流需求，没有必要为了增加设置项而启用 FakeDNS。它适合解决明确的域名保留问题，不是所有网络的默认优化。应先用单个应用验证收益与兼容性，保留可快速恢复的配置副本，再逐步扩大使用范围。

07 / 出口编排

自定义出站

标签与协议对象

出站定义收到流量之后如何建立下一段连接。路由中的 outboundTag 只是引用，必须对应实际出站对象的 tag。标签拼写区分大小写，建议使用短小且用途明确的名称。创建一条指向不存在标签的规则，不会让客户端自动生成连接，可能在启动检查或实际转发时产生错误。

先区分客户端生成的出站和手工扩展的出站。v2rayN 通常根据当前服务器生成远端连接对象，切换服务器后该对象可能重建。若直接编辑临时文件，修改可能在重启时丢失。应使用客户端明确提供的自定义配置入口，并确认其行为是合并、替换还是完全接管主配置。

下面是独立的局部示例：直连、阻断，以及转交到本机另一项 SOCKS 服务的出站。它不包含远端服务器认证数据。示例假设该本地服务确实监听于指定地址，且不是当前入口本身；复制前必须核对监听端口，避免把流量再次送回同一处理链而形成循环。

{
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {}
    },
    {
      "tag": "local-socks",
      "protocol": "socks",
      "settings": {
        "servers": [
          {
            "address": "127.0.0.1",
            "port": 10810
          }
        ]
      }
    }
  ]
}

freedom 表示按内核所处网络直接建立连接，不代表绕开本机所有其他网络工具。若系统默认路由已经指向另一个隧道，直连出站仍可能经过它。判断实际出口时，应同时查看操作系统路由与客户端日志，不能仅凭标签叫 direct 就断言使用了物理网络。

blackhole 用于丢弃匹配流量。阻断出站适合明确不需要建立连接的目标，但不应作为配置错误时的默认补丁。若某项服务失败，先确定是否误命中阻断规则，再调整匹配范围。让请求静默失败可能表现为长时间等待，因此排错时要把阻断规则单独列出来核对。

规则接入与默认出口

下面的规则将一个文档示例域名交给本地 SOCKS 出站，应插入宽泛兜底规则之前。示例域名只用于展示语法，实际使用时改成业务需要的目标。对更大的服务范围，应依据真实请求补全域名，而不是直接把全部端口交给本地服务，导致无关应用也被改变出口。

{
  "type": "field",
  "domain": ["full:example.com"],
  "outboundTag": "local-socks"
}

当没有规则命中时，内核通常使用默认出站，常见配置中与出站数组首项有关。上面的示例首项为直连，因此不能把它整段替换到原配置后，仍假定未匹配流量会走代理。应保留原有远端对象并明确兜底策略，或者重新检查数组顺序，确保最终行为与预期一致。

链式连接的边界

本机服务转交与内核内部链式连接不是同一种配置方式。前者先连接另一个监听端口，由对方继续处理；后者依赖具体内核支持的出站组合字段。不同内核的字段和作用层可能不同，不能把一个实现中的传输设置复制到另一个实现。优先选择客户端明确支持且便于观察的方案。

增加一层转交后，需要分别验证每一段。先让本地 SOCKS 服务独立工作，再验证内核能连接该端口，最后测试规则是否命中。若前一段正常而完整链路失败，检查名称解析位置、UDP 支持以及额外封装的要求。不要同时修改两端设置，否则无法知道哪个变化导致结果不同。

自定义出站稳定后，保存用途说明、标签映射和恢复方式。敏感连接参数留在受保护的客户端配置中，不要复制进普通维护文档。日常只调整必要规则，避免每次切换订阅都重写全部出站；配置来源与出口编排分离，才能让更新和回退保持可控。