V2Ray 进阶配置：订阅、路由、DNS 与 TUN

02 / 订阅整理

订阅分组与服务器过滤

订阅负责批量提供服务器，但服务器数量增加后，选择成本和误操作也会同步增加。有效的整理方法不是把所有节点放进一张长列表，而是先按来源分组，再按用途筛选。v2rayN 适合把默认分组、外部订阅和自建节点分开；v2rayNG、v2flyNG 则可利用订阅配置和备注字段区分来源。分组的边界应稳定，节点备注可以变化，但来源、用途与维护责任不应混在一起。

每个订阅应使用可识别的名称，例如“日常订阅”“测试线路”“自建服务”。名称只表达来源，不把当前节点状态写进名称，因为状态会随时间改变。手工添加的服务器单独保留，不要移动到自动更新的订阅组中，以免更新时难以判断它是否受订阅覆盖。对于不再使用的订阅，先停用自动更新并观察一段时间，再删除其分组；直接清空会同时失去原有备注与选择记录。

过滤器应解决什么问题

服务器过滤适合从长列表中缩小候选范围。常见维度包括备注关键词、协议类型、传输方式和订阅来源。过滤条件首先应保持可解释：输入一个关键词后，使用者能从服务器备注中看出为什么匹配。复杂正则表达式虽然灵活，但订阅命名稍有变化就可能漏选。稳定做法是要求同一订阅的备注具有一致格式，再以地区、用途或线路类别作为关键词。

筛选和路由是两件事。筛选决定界面中看到或批量测试哪些服务器，路由决定连接后某个请求走哪个出站。不要用服务器过滤代替流量分流，也不要因为某个节点被隐藏就认为它从配置中完全删除。部分客户端的过滤只改变列表显示，活动节点仍然可以继续工作；执行批量删除前应先确认当前选中项和分组范围。

关键词与正则的使用边界

简单关键词适合日常选择，例如按备注中的“工作”“自建”或协议名筛选。需要表达多个备选词时，可使用正则的选择符；需要排除测试节点时，可使用负向条件，但要先在小范围内验证。不同客户端的过滤入口和正则能力可能不同，复制表达式之前应确认它作用于服务器备注、地址还是完整显示名称。下面的表达式只展示通用思路，不依赖具体节点数量或速度数据。

工作|自建
^(?!.*测试).*
(VLESS|VMess|Trojan)

第一行匹配备注中包含“工作”或“自建”的条目；第二行排除包含“测试”的名称；第三行按显示名称中的协议词筛选。若订阅使用不同命名方式，应先查看真实备注再调整。过滤结果为空时，先去掉边界符和排除条件，确认基础关键词能匹配，再逐步增加约束。不要一开始就编写很长的表达式，否则难以判断是哪一段导致失配。

更新、去重与失效条目的处理

订阅更新应优先在单个分组内执行。更新后先看条目是否正常解析，再切换活动节点。相同服务器可能因备注不同而重复出现，也可能因为参数不同而只是地址相同；去重时不能只看域名和端口，还应比较用户标识、协议、传输方式、TLS 与路径等关键参数。自动去重适合完全一致的条目，参数存在差异时保留并重新命名更稳妥。

失效条目可分成临时不可达、参数错误和订阅撤销三类。一次连接失败不足以判定长期失效，应先切换本地网络或等待线路恢复；持续出现协议解析错误，则检查订阅是否使用了当前客户端不识别的字段；更新后从订阅中消失的条目通常由来源方撤销，不建议手工复制回自动分组。测速只用于比较当前网络条件下的响应，不能作为永久排序依据。

三款客户端的分组侧重点

v2rayN 的桌面列表空间更大，适合管理多个订阅、批量更新和细化筛选，也是桌面平台的首选。v2rayNG 使用触屏列表，建议减少同时启用的订阅数量，把名称写短并保留明确前缀。v2flyNG 的管理方式与 Android 使用习惯相近，但内核家族不同，导入同一订阅后仍应确认协议和传输参数是否被完整识别。需要重新安装或更换平台时，从下载页按系统选择对应客户端。

完成整理后，应做一次可恢复性检查：记住当前活动订阅与服务器，手动更新单个分组，确认更新不会改变自建节点，再重启客户端验证选择是否保留。如果客户端在更新后切换了活动项，检查是否启用了自动选择或当前条目已被订阅替换。订阅地址属于持续访问凭据，不应写进公开截图、日志或共享规则文件；排错时只需说明订阅解析结果和错误类型。

04 / 名称解析

DNS 配置优化与分流解析

DNS 配置决定域名如何获得地址，也影响域名规则和 IP 规则之间的衔接。系统 DNS、客户端内置 DNS、浏览器加密 DNS与应用自带解析可能同时存在，若查询没有经过预期路径，就会出现“路由写对但仍然走错出站”的现象。优化之前先确认查询来源：系统代理通常不会自动接管所有 DNS，TUN 模式更适合把系统查询统一送入客户端，但仍要处理浏览器或应用自行发起的加密查询。

DNS 分流的基本目标是让不同域名选择合适的解析服务器，并让查询本身通过正确出站发送。域名分类、查询服务器和路由出站是三个独立决策。某个域名被分配给特定 DNS 服务器，不代表其业务连接一定使用同一条出站；还需要路由规则做对应约束。反过来，只写业务路由而不处理解析路径，应用可能先取得不合适的地址，随后触发错误的 IP 规则。

服务器顺序与匹配范围

内核 DNS 可以配置多个服务器，并为服务器附加域名匹配列表。专用匹配应放在通用服务器之前。内部域名可指向局域网 DNS，指定外部域名可使用加密查询，其余域名交给默认服务器。若客户端支持 skipFallback 一类控制项，可阻止已匹配的域名继续向后备服务器查询；但启用前应确保专用服务器稳定，否则匹配域名没有可用结果时也不会自动获得后备答案。

{
  "dns": {
    "queryStrategy": "UseIP",
    "servers": [
      {
        "address": "192.168.1.1",
        "domains": [
          "full:intranet.example",
          "domain:office.example"
        ],
        "skipFallback": true
      },
      {
        "address": "https://dns.example/dns-query",
        "domains": [
          "domain:service.example"
        ]
      },
      "localhost"
    ]
  }
}

示例把内部域名交给局域网解析服务器，把指定服务交给一个示例加密查询地址，其余请求使用本机解析。实际配置时，加密查询域名本身也需要能够解析并建立连接，形成的引导解析不能依赖尚未可用的同一条加密通道。解决方法是让系统或基础 DNS 先解析查询服务器域名，或直接使用客户端支持的引导机制。若日志持续显示查询服务器域名解析失败，应先处理这层依赖。

查询策略与地址族

queryStrategy 控制返回哪类地址。UseIP 允许使用可用地址族，UseIPv4 只请求 IPv4，UseIPv6 只请求 IPv6。选择应以本地网络和出站链路是否完整支持对应地址族为准。系统拿到 IPv6 地址但代理链路无法建立 IPv6 连接时，应用可能先等待失败再回退，表现为首次访问明显变慢。此时可以暂时使用 IPv4 策略验证，但长期方案仍应检查本地网络、节点出站和路由规则对 IPv6 的处理。

不要把所有解析问题都通过固定地址族掩盖。某些服务会根据地址族提供不同接入，局域网内部服务也可能只在特定地址族可用。调整后分别测试内部域名、常用公网域名和纯 IP 连接，确认没有破坏其他路径。若只有一个应用异常，检查它是否启用了独立 DNS 或连接优化功能，因为该查询可能根本没有进入客户端。

DNS 与路由如何配合

DNS 查询本身也是网络请求，需要路由决定直连还是代理。加密 DNS 使用普通 TCP 或 HTTPS 连接时，可以按服务器域名或 IP 指定出站。若查询经代理发送，确保代理出站在解析前已经具备可连接的服务器地址；订阅节点使用域名作为服务器地址时尤其要注意启动阶段的解析依赖。最稳妥的启动链路是让节点服务器域名可由基础 DNS 解析，再由已建立的代理处理后续专用查询。

路由使用 IPIfNonMatch 时，域名规则未命中会触发 DNS 解析，然后再匹配 IP 规则。此时 DNS 服务器返回的地址会直接影响路由结果。若同一域名存在多组地址，缓存结果变化可能让流量命中不同规则。应尽量优先使用稳定的域名规则，IP 规则用于区域集合、私有地址和确实需要按地址判断的目标，而不是为每个域名手工维护地址。

缓存、泄漏路径与验证方法

验证 DNS 时先关闭浏览器的独立解析选项，或明确把它纳入测试范围。重新连接客户端后清理系统与浏览器的相关缓存，再发起一次全新查询。日志中应能看到域名、选中的 DNS 服务器、返回地址以及后续业务连接的路由结果。只使用网页型检测工具无法说明所有系统查询路径，因为它观察到的是当前浏览器，而不是终端、后台服务和其他应用。

如果普通系统代理下 DNS 仍由本地网络处理，这是接管范围的差异，不一定是配置错误。需要统一接管更多应用时再启用 TUN，并为 DNS 设置明确入站与路由。若启用 TUN 后出现解析循环，检查 DNS 请求是否再次进入 TUN、是否缺少查询服务器的直连或代理例外，以及 FakeDNS 是否与真实解析规则重叠。完整的分流解析案例可继续查看V2Ray DNS 分流解析配置详解。

06 / 域名映射

FakeDNS 的工作方式与适用边界

FakeDNS 会为域名返回保留地址池中的临时地址，并在内核内部保存域名与该地址的映射。应用连接这个临时地址时，内核根据映射恢复原始域名，再执行路由和真实连接。它解决的主要问题是：某些应用先自行发起 DNS 查询，随后只把 IP 连接交给 TUN，导致内核失去原始域名，域名规则无法命中。FakeDNS 把域名信息保留到后续连接阶段，使分流判断更稳定。

FakeDNS 不是普通 DNS 服务器的替代品，也不会凭空改善所有解析。内核恢复域名后，真正建立连接时仍需要按配置完成解析或交给相应出站。若路由、真实 DNS 或出站配置错误，FakeDNS 只会让问题更难观察。因此应在 TUN 基础链路和普通 DNS 已经稳定后启用，并明确哪些查询进入 FakeDNS、哪些内部域名必须返回真实地址。

地址池与映射容量

FakeDNS 配置包含地址池和映射容量。地址池必须使用专门保留的范围，不能与局域网、企业网络、容器网络或现有虚拟接口重叠。发生重叠时，系统可能把临时地址送往真实网络，或者把真实内部地址误交给 FakeDNS。容量决定可同时保存多少域名映射；容量不足会淘汰旧映射，应用仍持有旧地址时可能无法恢复域名。日常使用应保留客户端默认值，只有确认存在大量并发域名且日志显示映射淘汰时才调整。

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

198.18.0.0/15 是常见的基准测试保留地址范围，许多实现将其用于虚拟映射。使用前仍需检查本地网络和其他工具是否占用该范围。配置片段只表示内核中的 FakeDNS 对象；要让查询真正进入它，还需要对应 DNS 设置、入站嗅探和 TUN 接管。单独添加对象不会自动改变系统查询路径。

嗅探与目标覆盖

入站嗅探用于从连接中识别域名或协议信息。配合 FakeDNS 时，常见目标覆盖包含 HTTP、TLS 与 FakeDNS 映射。是否启用目标覆盖应根据客户端模板决定：覆盖能让路由使用恢复后的域名，但也可能改变某些特殊连接的目标处理。先使用客户端提供的标准 FakeDNS 模式，查看生成配置，再进行定制。不要把所有协议识别选项一次性打开。

{
  "inbounds": [
    {
      "tag": "tun-in",
      "protocol": "tun",
      "sniffing": {
        "enabled": true,
        "destOverride": [
          "http",
          "tls",
          "fakedns"
        ],
        "routeOnly": true
      }
    }
  ]
}

routeOnly 表示识别结果主要用于路由判断，不直接替换最终连接目标，适合希望降低目标改写影响的环境。具体字段是否由当前内核和客户端配置方式支持，应以客户端生成结果为准。若配置载入时报未知字段，先撤回自定义片段，使用界面中的 FakeDNS 选项，再检查内核家族和配置格式是否匹配。

不适合交给 FakeDNS 的目标

局域网域名、企业内部域名、打印与发现服务通常需要真实地址，应绕过 FakeDNS 并交给内部 DNS。依赖本地地址判断、证书绑定或特殊解析结果的应用，也可能不适合虚拟映射。排除规则应尽量具体：先排除明确内部域名和保留后缀，再观察是否存在额外异常。直接把大范围域名全部排除，会让 FakeDNS 失去保留域名的意义。

部分应用会验证 DNS 返回地址、绕过系统解析或使用自己的加密查询。前两种情况可能导致 FakeDNS 不生效，后一种情况可能让查询直接作为普通 HTTPS 连接进入 TUN，此时内核只能从连接特征尝试恢复域名。若日志中看不到 FakeDNS 查询，不要反复修改地址池，先确认应用的查询是否进入客户端。

常见故障的判断顺序

启用后完全无法解析，先检查 DNS 是否把查询送入 FakeDNS；能返回临时地址但连接失败，检查 TUN 是否接管该地址范围，以及入站能否恢复域名；只有内部服务失败，检查内部域名排除和局域网 DNS；使用一段时间后偶发失败，检查映射容量、应用缓存和休眠恢复。每种症状对应不同层，不能用更换 DNS 服务器解决全部问题。

验证时可以观察查询是否返回保留地址，再在内核日志中确认同一地址被映射回原域名，并查看最终出站。不要使用系统工具直接连接临时地址来判断服务器可达性，因为它本来就不代表真实服务器。关闭 FakeDNS 后，应清理应用和系统的相关 DNS 缓存，避免应用继续连接已经失效的临时地址。

与真实 DNS 分流并存

成熟配置通常同时存在 FakeDNS 和真实 DNS：普通公网域名可先返回临时地址以保留域名，内部域名直接向局域网 DNS 查询真实地址，节点服务器域名通过基础 DNS 完成启动解析，少数指定服务再使用专用加密查询。每一组域名只能有明确优先级，避免同一目标既被内部 DNS 匹配又进入 FakeDNS。调整后分别测试公网网页、内部服务、节点重连和系统休眠恢复，确认映射在生命周期变化后仍能重建。

08 / 出站编排

自定义出站、链式转发与系统化排错

出站是路由决策的最终目标。常见出站包括代理节点、直接连接、阻断以及转发到本地或上游 SOCKS 服务。自定义出站适合把特定业务交给独立出口、复用本机已有服务或建立清晰的测试路径。配置重点是标签唯一、协议参数完整、依赖关系没有循环。路由只通过标签引用出站，因此改名后必须同步更新所有规则。

图形客户端通常会根据当前节点生成主要代理出站，同时加入直连和阻断出站。手工扩展时不要覆盖这些基础对象，除非已经确认客户端的合并方式。更稳妥的方法是使用客户端提供的自定义配置、预配置或模板入口，新建一个唯一标签，再用一条具体路由进行测试。直接修改运行时文件会在切换节点或重启后失效，也可能让界面状态与实际配置不一致。

添加本地 SOCKS 上游

{
  "outbounds": [
    {
      "tag": "local-socks",
      "protocol": "socks",
      "settings": {
        "servers": [
          {
            "address": "127.0.0.1",
            "port": 1081
          }
        ]
      }
    }
  ]
}

示例建立名为 local-socks 的出站，把连接交给本机 1081 端口的 SOCKS 服务。使用前应确认该端口确实监听，并避免它的流量再次被同一 TUN 捕获后送回自身。若上游需要认证，应在客户端支持的配置结构中添加实际凭据，并只保存在本地。测试时先用一个明确域名指向该出站，不要直接把全局流量切过去。

{
  "routing": {
    "rules": [
      {
        "type": "field",
        "domain": [
          "domain:service.example"
        ],
        "outboundTag": "local-socks"
      }
    ]
  }
}

规则中的标签必须与出站标签逐字一致。配置加载失败时先检查 JSON 结构、重复逗号和字段位置；加载成功但不走上游时检查规则顺序与域名是否命中；已经命中却连接失败时再检查本地端口、上游认证和循环路由。分层检查比反复更换节点更快。

链式转发的风险控制

链式转发会让一个出站通过另一个出站建立连接。它适合有明确网络拓扑的环境，但会增加解析依赖、连接层数和故障点。开始前先画出路径：应用进入哪个入站，路由选择哪个业务出站，该出站通过哪个前置出站连接，节点服务器域名由谁解析。路径中任何一段重新回到前面的入口，都可能形成循环。

链式结构不应通过模糊的全局规则实现。为前置出站和业务出站使用明确标签，为上游服务器地址加入必要的直连或指定路由，并保留一个不经过链路的基础连接用于回退。出现超时后，先分别验证每一跳可用，再组合测试。若单独可用而组合失败，重点检查 DNS 启动依赖、UDP 支持和 TUN 对上游连接的再次捕获。

直连与阻断出站

直连出站用于局域网、内部服务和不需要代理的目标。阻断出站用于明确拒绝连接。阻断规则应具体，并放在宽泛代理规则之前。直接使用大范围分类可能影响登录、支付、更新或嵌入资源，因此添加后要验证页面主域名与资源域名。对于只想避免某个应用使用代理的场景，优先使用进程规则或入站隔离；若客户端和内核不支持稳定的进程识别，再使用可解释的域名与 IP 条件。

直连并不表示绕过所有客户端处理。流量可能先进入 TUN，再由内核选择直连出站；也可能在系统路由层直接绕过 TUN。两种方式对日志、DNS 和本地服务兼容性有不同影响。需要记录和统一路由时可让流量进入内核后直连；局域网发现、设备访问等对本地网络敏感的流量，通常更适合在系统路由层绕过，并同时保留私有地址直连规则。

按日志建立排错矩阵

高级配置排错应回答四个问题：流量是否进入客户端，域名由谁解析，哪条路由命中，最终出站是否建立连接。日志级别只在排错期间提高，完成后恢复常规级别，避免大量记录影响查找。日志中若没有目标请求，检查系统代理、应用代理或 TUN；有请求但没有域名，检查 DNS 接管和嗅探；路由标签错误，调整规则顺序；出站连接失败，检查对应服务器和上游。

形成长期可维护的配置

可维护配置应尽量少依赖节点名称、临时地址和界面排序。路由引用稳定的出站标签，DNS 使用明确域名组，订阅保持来源边界，TUN 与 FakeDNS 只在需要时启用。每个自定义对象都写明用途，并保留能正常工作的基础配置。发生故障时先停用最近增加的对象，确认基线恢复，再把问题缩小到一条规则或一个出站。

配置完成后进行四轮验收：重启客户端验证配置可加载；切换节点验证路由不依赖旧节点；更新订阅验证自定义分组和标签未被覆盖；重启系统验证 TUN、DNS 与系统代理能正确建立和恢复。只通过一次网页访问不算完成。涉及内部网络时，再验证局域网服务、内部域名与系统休眠恢复。

如果问题仍无法定位，先回到快速上手主线验证最小连接，再到帮助中心核对安装配置与故障排查条目。涉及系统代理、DNS 或速度差异时，也可结合本站技术笔记中的分层案例继续检查。