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

配置基线：先固定可复现的工作状态

建立最小可用链路

进阶调整的起点不是“把所有选项打开”，而是建立一条可重复验证的最小链路。先保留一个确认可用的订阅、一个服务器、默认路由和客户端默认 DNS，关闭局域网共享、TUN、FakeDNS 与额外出站。桌面端在 v2rayN 中选择服务器后启用系统代理；Android 端在 v2rayNG 或 v2flyNG 中选择同类服务器并建立连接。此时只验证三个结果：客户端核心能够启动，浏览器请求能够经过预期出口，本地网络资源仍可访问。任何一项不成立，都应先回到订阅参数或服务器状态，而不是继续叠加路由规则。

基线需要包含明确的记录。记下当前客户端、所用内核家族、订阅分组名称、活动服务器名称、系统代理模式以及是否启用了远程 DNS。记录的目的不是长期维护一份复杂台账，而是在改动后能准确回答“哪个设置发生了变化”。客户端更新订阅时可能覆盖服务器对象，但通常不会自动恢复手工修改的全局路由，因此订阅状态与全局配置要分开检查。

区分四个配置层

一套可工作的 V2Ray 图形客户端配置通常包含四层。第一层是服务器对象，保存地址、端口、用户标识、传输方式与安全参数；第二层是订阅和分组，决定这些服务器如何被更新、展示和筛选；第三层是本地接管方式，包括系统代理与 TUN；第四层是核心配置，包含 DNS、路由、入站和出站。服务器能连接，只说明第一层基本正确，并不能证明 DNS 或分流符合预期。反过来，浏览器打不开页面也不一定是服务器故障，系统代理未接管该应用、DNS 返回不合适的结果、规则把流量送往错误出口，都可能产生相似表现。

备份、命名与回退

修改前使用客户端提供的配置导出或备份功能保存当前状态，文件名写明用途即可，例如“默认路由”“TUN 测试前”“双订阅合并前”。不要把多个实验目标塞进同一个备份名称。若客户端支持路由配置档案，可复制现有档案后再编辑；若只支持一套全局配置，则先复制核心配置文本。回退时同时检查系统代理状态，因为恢复配置文件并不总会恢复操作系统中的代理开关。

命名应描述用途而不是情绪判断。“工作直连优先”“全局代理测试”“本地域名保留”比“配置一”“最快配置”更容易维护。服务器名称可保留订阅提供者的原始地区、协议和倍率信息，筛选规则则围绕稳定字段编写。不要依赖列表序号，因为更新订阅后排序可能改变。对路由和出站使用固定标签，例如 direct、proxy、block 与 dns-out，能降低规则引用错误。

用日志确认配置生效

完成每次修改后重新载入核心，观察日志是否出现配置解析错误、端口占用、权限不足或 DNS 请求失败。日志级别先使用信息级别；只有在定位具体问题时短暂切换到调试级别，完成后恢复，以免大量连接明细淹没关键事件。阅读顺序从第一条错误开始，而不是从最后一行反向猜测。若出现 failed to parse config，先检查 JSON 逗号、字段层级和标签引用；若核心成功启动但请求超时，再转向服务器、DNS 与路由。

基线验证完成后，复制一份配置再进入下一章。后续每章都沿用同一原则：先定义目标，修改单一层，重新载入，按日志与实际访问结果验证，失败后回退。涉及具体错误文本时，可结合V2Ray 运行日志阅读方法逐段定位，而不是反复重装客户端。

订阅分组与服务器过滤：控制列表而不是手工删节点

把订阅源与使用视图分开

订阅源负责提供服务器对象，分组负责把对象组织成适合选择的视图。两者不应混为一层。直接删除暂时不用的服务器看似简单，但下一次更新订阅后它们通常会重新出现；更稳定的做法是保留完整订阅源，通过分组、备注和筛选条件控制显示范围。v2rayN 适合按订阅分组维护桌面端的大量服务器，v2rayNG 与 v2flyNG 则更适合保留较少的移动端候选，降低列表滚动和误选成本。

建立分组时先按来源划分，再按用途建立筛选视图。例如“主订阅”“备用订阅”描述来源，“日常使用”“低倍率”“指定协议”描述用途。来源分组用于更新与故障隔离，用途筛选用于实际选择。不要把不同来源改成完全相同的名称，否则订阅更新失败时难以判断受影响范围。手动添加的服务器应放入独立分组，避免更新订阅时误以为手工对象会随源同步。

设计可维护的筛选表达式

服务器过滤通常基于名称中的地区、协议、倍率或用途标签。先观察订阅名称的稳定结构，再写包含或排除规则。若名称长期采用“地区｜协议｜倍率”的格式，可以用关键词组合；若分隔符经常变化，则只依赖稳定词段。正则表达式适合合并同义名称，但应保持短小。筛选“香港或新加坡”可使用 香港|HK|新加坡|SG，排除测试或到期对象可使用 测试|到期|剩余流量。包含规则与排除规则同时存在时，先确认客户端的执行顺序，常见逻辑是先保留包含项，再从结果中移除排除项。

包含：
香港|HK|新加坡|SG

排除：
测试|到期|剩余流量|官网

协议偏好：
VLESS|VMess|Trojan

倍率筛选：
(^|[^0-9])1(\.0)?x([^0-9]|$)

倍率筛选尤其容易误匹配。只搜索字符 1 可能同时匹配端口、编号或“1.5x”，应尽量约束边界。订阅命名不统一时，不要把倍率筛选当作计费依据；先核对订阅提供的信息，再把名称筛选作为列表整理工具。地区筛选也只代表名称标签，不等同于实际网络路径。选择服务器时还要结合真连接测试、协议兼容和实际访问表现，具体方法可参考按延迟、倍率与地区筛选服务器。

排序、测试与选择分工

列表排序用于缩小候选范围，延迟测试用于排除不可连接对象，最终选择仍需以实际业务连接为准。基础延迟只反映探测目标的响应，不完整代表网页加载、长连接或大文件传输。真连接延迟更接近核心建立代理连接的耗时，但也会受到测试目标与当时网络状态影响。正确流程是先用筛选得到少量候选，再做真连接测试，最后用实际应用验证，不要把一次测试结果永久写入分组名称。

自动排序后保留一个已验证的稳定服务器作为回退项。它不必始终排在第一位，但应有清晰备注。频繁更新订阅的用户可以把排序范围限制在当前分组，避免不同来源、不同用途的服务器混排。若某个分组突然为空，先关闭筛选查看原始列表：原始列表存在说明过滤条件不再匹配，原始列表也为空才需要检查订阅更新。

处理重名与重复对象

多个订阅可能提供同名服务器。不要仅凭显示名称判断它们相同，地址、端口、用户标识、传输参数或来源任一不同，都应视为不同对象。客户端的去重功能若按完整配置判断，通常可以安全使用；若只按备注名称判断，则可能误删有效候选。更稳妥的做法是在分组层保留来源信息，通过显示前缀区分，而不是直接修改订阅内的核心参数。

过滤规则需要定期做反向检查：查看被排除项中是否混入正常服务器，查看未分类项是否出现新的命名格式。每次订阅更新后无需全面重做，只要抽查包含、排除和未匹配三个集合。这样既能维持干净列表，也不会因为过度严格的表达式失去可用服务器。

多订阅管理：更新隔离、优先级与故障切换

确定主订阅与备用订阅的职责

多订阅不是把所有服务器堆进同一列表，而是给不同来源分配明确职责。主订阅承担日常选择，备用订阅只在主源更新失败、协议不兼容或特定地区不可用时启用；手动分组保存长期固定或临时测试的对象。职责明确后，更新问题不会扩散到全部列表。v2rayN 中可分别更新订阅组并观察结果，移动端则应控制启用数量，避免每次刷新都重建过大的服务器列表。

为每个订阅保留独立备注，并记录它使用的筛选条件。不要在同一分组中混用“来源”和“用途”两种命名逻辑。例如“主订阅”和“备用订阅”属于来源，“办公”“流媒体测试”属于用途。需要交叉管理时，用筛选视图从来源分组生成候选，而不是移动原始对象。这样订阅更新后，视图可以重新计算，来源边界仍然完整。

安排更新顺序与失败处理

订阅更新应逐源进行。先更新主订阅，确认返回内容可解析、服务器数量没有异常变化、原先的稳定对象仍存在，再更新备用源。一次性更新全部来源虽然省操作，但出现异常时难以识别是哪一个地址、哪种内容格式或哪条网络路径失败。若客户端显示更新成功但列表为空，检查订阅内容是否被筛选规则全部排除；若显示解析失败，则保留旧列表，检查订阅地址与返回格式，不要先清空本地数据。

更新失败时区分三种情况：请求未完成、内容已返回但无法解析、解析成功但结果不符合预期。请求未完成通常从网络、系统代理或订阅地址入手；解析失败重点检查内容格式和客户端兼容；结果异常则比较更新前后的名称与分组。备用订阅只用于维持连接能力，不应自动覆盖主订阅。恢复主源后再按正常顺序切回，避免两个来源同时频繁变化。

控制自动更新的边界

自动更新适合稳定来源，但不应和自动选择服务器绑定成不可观察的黑箱。订阅内容变化后，新增对象可能因排序规则直接出现在前列；如果客户端又自动选择第一项，实际出口就会在没有明确操作的情况下改变。更稳妥的设置是允许订阅定时刷新，但保留当前活动服务器，只有当前对象失效时再手动切换。需要高度稳定的场景可以降低更新频率，并在更新前导出配置。

多设备使用相同订阅时，不必强求完全相同的列表。桌面端可保留更多地区与协议用于测试，Android 端只保留常用候选。配置同步的重点应是分组逻辑、路由目标和 DNS 策略，而不是列表顺序。不同客户端对订阅字段、路由界面和核心选项的呈现方式不同，强行复制整个数据目录可能带入平台相关设置。

避免订阅内容污染全局配置

订阅更新的理想边界是更新服务器对象，不覆盖全局 DNS、路由和本地入站。若客户端支持“更新订阅时导入附加配置”，启用前要理解它会修改哪些层。来源不明的路由模板可能改变默认出口，远程 DNS 配置也可能替换已经验证的解析链路。对于生产式使用，建议把全局规则保存在本地配置档案中，订阅只提供服务器。

手动服务器同样需要隔离。将手工对象放入独立分组并使用明确备注，不要伪装成订阅对象。修改手工对象时先复制再编辑，原对象作为回退。若两条配置只有传输参数不同，在名称中写明差异，例如“WS 测试”“gRPC 测试”，而不是只写“备用一”“备用二”。这些细节会直接影响后续日志定位。

执行可控的故障切换

切换前先确认问题确实位于当前服务器，而不是 DNS 或本地接管。选择备用服务器后重新载入核心，检查日志中的活动出站，再做相同目标的访问测试。切换成功后记录触发原因，不要立即删除原对象；网络路径恢复后还需要它做对照。若主订阅全部对象都失败而备用源正常，优先检查主源共同使用的协议或传输条件。若两个来源同时失败，则应回到系统代理、TUN、DNS 和本地网络层排查。

完成多订阅整理后，应能在一分钟内回答四个问题：当前服务器来自哪个订阅、更新失败时使用哪个备用分组、哪些筛选规则会隐藏服务器、全局路由是否独立于订阅。若答案仍依赖翻找大量列表，说明分组名称或职责还不够清晰，应先整理再进入复杂路由配置。

路由规则实战：按匹配顺序决定流量出口

理解从入站到出站的判定过程

路由规则处理的是已经进入核心的连接。应用先通过系统代理、TUN 或本地代理端口进入某个入站，核心再读取域名、目标 IP、端口、网络类型、进程或入站标签，并按规则顺序选择出站。路由不能接管尚未进入客户端的流量，也不能修复错误的服务器参数。配置前先确认应用请求已经到达核心日志，再讨论它应走直连、代理还是阻断。

规则通常按从上到下的顺序匹配，命中后不再继续。具体条件应放在前面，宽泛条件放在后面，最后用默认出站接住未匹配流量。常见基线是：私有地址直连，本地域名和 IP 集合直连，明确需要代理的域名走代理，其他流量按当前策略进入默认出口。若把“全部域名代理”放在第一条，后续直连规则就不会执行。

选择域名策略

路由中的域名策略决定核心何时把域名解析为 IP 再匹配 IP 规则。使用 AsIs 时，域名请求优先按域名规则判断，不为路由目的主动解析；使用 IPIfNonMatch 时，域名规则未命中后再解析并尝试 IP 规则；使用 IPOnDemand 时，只要后续存在需要 IP 的判断就可能触发解析。一般配置可从 IPIfNonMatch 开始，它兼顾域名规则与 IP 集合，但要确认 DNS 配置能够提供稳定结果。

主动解析会让路由与 DNS 耦合。若 DNS 返回的地址不稳定、被不同线路分配到不同区域，IP 规则结果也可能变化。因此能用明确域名集合表达的目标优先使用域名规则，只有确实需要根据目标地址判断时再依赖 IP 规则。日志中出现规则结果不符合预期时，要同时查看原始域名、解析后的 IP 和最终出站标签。

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": ["geoip:cn"],
        "outboundTag": "direct"
      }
    ]
  }
}

组合域名、IP、端口与入站条件

同一条规则内不同字段通常按“同时满足”处理，同一字段内多个值通常按“任一匹配”处理。例如一条规则同时写入 network: tcp 和 port: 80,443，表示只处理 TCP 的这两个端口；域名数组中写入多个集合，则任一集合命中即可。不要在一条规则里塞入互相无关的目标，拆成多条并写清用途更容易排查。

入站标签适合给不同本地入口设置不同策略。例如浏览器使用本地 SOCKS 入站，工作软件使用另一个 HTTP 入站，两者可以分别指向代理或直连。进程规则依赖客户端、核心与系统权限支持，不同平台表现并不完全一致，应把它作为精细化补充，而不是唯一分流依据。端口规则适合明确服务，但现代应用可能改用其他端口或 QUIC，单靠端口推断应用类型容易漏匹配。

建立三层规则结构

第一层处理不能送入远程代理的本地目标，例如环回、局域网和私有地址；第二层处理业务例外，例如指定域名直连、特定域名代理、广告或已知风险目标阻断；第三层定义默认出口。每层内部从具体到宽泛排列。修改规则后，用三个测试目标分别覆盖直连、代理和默认路径，避免只验证当前关注的一条规则。

阻断规则应保持可解释。若某应用启动异常，先临时停用阻断规则验证，而不是直接判断服务器故障。UDP 规则也要谨慎，阻断全部 UDP 可能影响 DNS、实时通信或基于 QUIC 的连接；如果目的只是让特定域名回退到 TCP，应优先在对应应用或核心传输设置中处理。局域网访问则应同时检查私有地址直连和 TUN 绕过范围。

用日志验证规则命中

验证时先清空或标记日志时间点，再发起单次请求。观察请求进入哪个入站、识别到的域名或 IP、命中的规则以及最终出站。若日志只显示 IP 而没有域名，应用可能自行解析了目标，域名规则无法直接命中；此时可考虑 TUN 的域名嗅探、FakeDNS，或补充可靠的 IP 规则。若规则命中正确但连接失败，问题位于对应出站或服务器层。

路由维护的核心不是规则数量，而是每条规则都有可说明的目标、稳定的数据来源和明确的回退。季度或订阅结构变化后，检查失效域名、重复集合和永远无法命中的下层规则。遇到“有些应用正常、有些应用失败”时，先比较它们是否进入同一入站、是否使用相同 DNS、是否命中相同出站，再到帮助中心查对应故障分支。

DNS 配置优化：统一解析路径与路由依据

先画清一次查询经过的路径

DNS 问题经常被误判为服务器问题。一次域名访问可能经历应用自身解析、操作系统解析、客户端内置 DNS 和远程解析中的一层或多层。浏览器若启用独立加密 DNS，查询可能绕过系统设置；TUN 接管后，系统查询可能被导入核心；FakeDNS 又会在本地返回合成地址并延后真实解析。优化前先确认谁发起查询、查询进入哪个服务器、结果在哪里被路由使用。

基础配置应尽量形成单一主路径：普通应用把查询交给系统，系统查询由客户端接管，核心根据域名集合选择本地或远程 DNS，返回结果供连接和路由共同使用。若应用自行解析且只把 IP 交给客户端，核心就失去原始域名信息，域名分流能力会下降。此时应统一应用设置，或在 TUN 场景中使用嗅探与 FakeDNS 恢复域名关联。

按域名集合选择解析服务器

DNS 分流与流量分流应保持方向一致。计划直连的本地域名优先交给本地可达的 DNS，计划代理的域名可交给随代理出站访问的远程 DNS。这样能减少解析结果与实际出口不匹配。不要简单地把所有查询发给多个服务器并采用最快响应，因为最快返回不等于最符合路由意图，而且并发查询会增加结果不确定性。

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

示例先为 geosite:cn 指定本地 DNS，并用 expectIPs 约束返回地址范围；其他明确的非本地域名交给加密 DNS，最后一项作为未匹配查询的回退。实际使用时应根据所在网络选择可稳定访问的 DNS，不要机械保留示例地址。若远程 DNS 需要经代理访问，还要确保它的域名或 IP 不会在解析自身时形成循环。

选择查询策略与地址族

UseIPv4 只请求 IPv4 地址，适合本地 IPv6 不可用或路由尚未配置完整的环境；UseIPv6 只请求 IPv6；UseIP 允许两种地址族。选择策略应以本地链路、代理出站和目标服务三者共同支持为准。只要其中一层无法稳定承载 IPv6，强制返回 IPv6 就可能出现“域名能解析但连接超时”。相反，网络与出站均支持时，长期禁用 IPv6 也会失去可用路径。

判断方法不是看系统是否分配了 IPv6 地址，而是分别测试本地直连、代理出站和 DNS 返回。日志中若先尝试不可达的 IPv6，再回退到 IPv4，页面会表现为首开缓慢；可先临时使用 UseIPv4 验证，再完善 IPv6 路由。不要把地址族问题与域名分流同时修改，否则难以确定改善来自哪一项。

避免 DNS 循环与泄漏路径

DNS 循环通常发生在“解析 DNS 服务器域名本身”需要再次调用同一个 DNS。解决方式是为该服务器提供可直接使用的 IP、通过 hosts 固定引导地址，或设置独立的引导解析器。另一个循环来源是 DNS 出站被路由回普通代理入口，随后再次触发 DNS。为 DNS 查询建立明确的出站标签，并在路由中优先处理，可让路径保持单向。

{
  "dns": {
    "hosts": {
      "resolver.example": "192.0.2.53"
    },
    "servers": [
      {
        "address": "https://resolver.example/dns-query",
        "skipFallback": true
      }
    ]
  }
}

示例中的保留地址仅用于说明字段关系，实际配置必须换成所用解析服务明确提供的地址。所谓泄漏路径，应从配置目标理解：如果计划让某类域名通过远程解析，却被应用自身或系统的另一接口直接查询，就出现了路径偏离。检查时同时观察客户端 DNS 日志和系统网络活动，不要只依赖网页测试结果。

缓存、刷新与故障定位

修改 DNS 后旧缓存可能继续影响结果。先重新载入客户端核心，再关闭并重开测试应用；必要时刷新操作系统缓存。Windows 可在终端执行 ipconfig /flushdns，使用 systemd-resolved 的 Linux 可执行 resolvectl flush-caches。macOS 与 Android 的缓存行为会随系统网络状态变化，切换网络接口或重新建立客户端连接通常能触发更新。执行命令只清理系统缓存，不一定清理浏览器内部缓存。

ipconfig /flushdns

resolvectl flush-caches

排查顺序应固定：先用明确 DNS 工具确认查询是否返回，再检查返回的地址族，然后看路由如何处理该地址，最后检查对应出站连接。若只有一个域名失败，检查域名规则、缓存和服务端响应；若全部域名失败但直接访问 IP 正常，重点检查 DNS 入站、服务器地址与路由循环；若域名和 IP 都失败，则回到接管与出站层。

TUN 模式：接管不读取系统代理的应用

判断是否真的需要 TUN

系统代理只影响主动读取代理设置的应用。命令行工具、部分桌面软件、游戏与自带网络栈的程序可能直接建立连接，这时客户端日志看不到请求。TUN 模式通过虚拟网络接口接管更多系统流量，适合需要统一分流的场景，但它同时引入路由表、DNS 劫持、权限和绕过规则等额外变量。浏览器与常用桌面软件已经能通过系统代理正常工作时，不必为了“配置更完整”而开启 TUN。

启用前先完成前几章的基线：服务器可用、路由规则可解释、DNS 能稳定解析。关闭其他会创建虚拟接口或修改默认路由的软件，记录系统原有代理状态，并保留恢复方式。TUN 启用失败时应先退出客户端，让虚拟接口和路由表恢复，再重新调整；不要在残留接口上连续切换多个实现。

选择栈实现与基本参数

客户端可能提供 system、gVisor 或 mixed 等网络栈选项。system 栈更依赖操作系统能力，通常性能路径直接；gVisor 使用用户态网络栈，兼容表现与系统栈不同；mixed 尝试组合处理 TCP 与 UDP。不存在对全部环境都最优的选择。先使用客户端默认值，只有出现特定应用无法连接、UDP 异常或休眠恢复失败时，再逐项切换并保留日志对照。

MTU 决定虚拟接口承载的数据包大小。设置过大可能在复杂链路中产生分片或丢包，表现为小页面正常、大请求卡住；设置过小则增加包数量与处理开销。没有明确证据时保持默认。若需要排查，可逐步降低 MTU 并测试同一目标，不要同时更换网络栈和 DNS。严格路由选项能减少流量绕过，但也可能影响本地网络访问，应配合绕过地址使用。

设置局域网与保留地址绕过

TUN 接管后，打印机、网络存储、路由器管理页或开发环境可能被错误送入代理。应优先让环回地址、私有地址和链路本地地址直连，并确认局域网发现所需的 UDP 流量没有被宽泛阻断。常见私有范围包括 10.0.0.0/8、172.16.0.0/12 与 192.168.0.0/16，但企业网络可能使用其他内部地址，应以实际路由表为准。

绕过私有地址不等于允许局域网设备访问客户端代理端口。局域网共享是另一项入站设置，需要单独决定是否开启，并限制监听地址和防火墙范围。只为本机使用时，代理入站应继续绑定环回地址。若开启共享，先确认本地网络可信，再设置访问范围；TUN 的路由绕过不能替代入站访问控制。

处理 DNS 劫持与域名识别

TUN 模式要实现可靠域名分流，通常需要把系统 DNS 查询导入核心。若只接管连接而不接管 DNS，应用可能先在系统外部获得 IP，核心只能按 IP 路由。启用 DNS 劫持后，确认查询进入客户端内置 DNS，并避免把客户端自身的解析请求再次劫持。端口 53 是传统 DNS 的常见入口，但应用自带加密 DNS 时仍可能绕过，需要在应用设置和路由层共同处理。

嗅探可以从部分连接中恢复目标域名，但不应视为所有协议都可靠。启用后检查是否误写目标地址，尤其是使用自定义证书、内网域名或特殊服务发现的应用。出现连接建立后立即断开时，可临时关闭目标覆盖，只保留域名识别做对照。FakeDNS 是另一种保持域名映射的方法，适合 TUN 场景，但需要独立地址池和正确的回收策略，下一章单独说明。

按现象定位 TUN 故障

若启用后完全断网，先检查核心是否成功启动、虚拟接口是否创建、默认路由是否指向预期位置，以及 DNS 是否仍有可达路径。若只有局域网失败，检查私有地址直连和严格路由；若只有 UDP 应用失败，比较网络栈、UDP 路由和服务器协议支持；若休眠恢复后失败，重新建立 TUN 接口并观察旧路由是否残留。不要先删除全部客户端配置，TUN 故障通常位于接管层。

验证完成后，分别测试浏览器、原先不读取系统代理的应用、局域网资源、DNS 查询和 UDP 业务。五类测试都能解释路径后，TUN 才算稳定。若需求仅是让单个命令行程序使用代理，优先为该程序设置明确的代理环境变量，比全系统接管更容易维护。

FakeDNS：保留域名信息并延后真实解析

理解合成地址的作用

FakeDNS 收到域名查询后，不立即把真实目标地址交给应用，而是从预设地址池返回一个合成 IP，并保存“合成 IP—原始域名”的映射。应用随后连接这个合成 IP，TUN 或透明接管层把连接送回核心，核心查表恢复域名，再按域名规则选择 DNS 与出站。这样即使应用只连接 IP，核心仍能获得原始域名，域名分流也更稳定。

合成地址不是远程服务器地址，也不应被普通路由当作公网目标。它只在本机接管链路内充当映射索引。如果请求绕过 TUN 直接发往网络，合成地址自然无法访问。因此 FakeDNS 必须与能够截获后续连接的接管方式配合使用，单独打开内置 DNS 中的 FakeDNS 选项并不能完成闭环。

规划独立且不冲突的地址池

地址池需要避开本地真实网络、企业内网、容器网络和已有虚拟接口使用的范围。配置前查看系统路由表，确认候选网段没有被真实路由占用。地址池过小会在大量域名并发时频繁回收映射，过大则可能与其他网络规划产生冲突。保持客户端默认范围通常最稳妥；只有确认冲突时才更换，并同步检查 TUN 路由是否覆盖新范围。

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

198.18.0.0/15 常用于基准测试网络，部分客户端默认将其用于合成地址，但仍需检查本地网络是否已有同范围路由。poolSize 控制可用映射数量，不应超过地址池实际容量。配置字段会随核心家族和客户端生成方式不同而变化，使用图形界面时优先让客户端生成结构，再检查最终核心配置，不要把示例整段覆盖到不兼容的层级。

决定哪些域名使用 FakeDNS

并非所有查询都需要合成地址。本地域名、局域网服务、打印机发现和需要真实 IP 返回给应用的工具，通常应继续使用普通 DNS。计划按域名代理的公网目标更适合进入 FakeDNS。可以先只为明确的非本地域名集合启用，验证稳定后再扩大范围。若直接把全部查询交给 FakeDNS，本地服务可能获得不可用的合成结果。

排除列表要覆盖局域网后缀、开发环境域名和依赖真实地址的诊断工具。应用若会把 DNS 结果展示给用户、写入配置或交给另一台设备使用，也不适合接收本机专用的合成 IP。FakeDNS 解决的是透明接管下的域名关联，不是通用 DNS 加速器，也不应把合成结果传播到局域网其他设备。

协调嗅探、路由和真实解析

FakeDNS 恢复原始域名后，路由先按域名规则决定出口，随后真实 DNS 应沿与该出口一致的路径执行。若域名被判定直连，就使用适合直连链路的解析器；若走代理，则使用为代理路径设置的解析器。否则虽然成功恢复域名，最终仍可能得到不适合对应出口的地址。日志应能连续看到合成映射、域名命中和真实目标连接。

嗅探与 FakeDNS 可以配合，但职责不同。FakeDNS 依靠查询映射恢复域名，嗅探依靠连接内容识别域名。两者同时启用时，要明确是否允许覆盖目标地址。若同一连接出现域名判断冲突，可先关闭嗅探覆盖，仅保留 FakeDNS；若应用完全不发起可接管的 DNS 查询，FakeDNS 无法建立映射，此时嗅探仍可能提供信息。

识别缓存与映射失效

应用、系统和客户端都可能缓存合成结果。修改地址池或关闭 FakeDNS 后，旧合成 IP 可能继续被应用使用，表现为部分域名持续失败。处理顺序是断开 TUN、重新载入核心、刷新系统 DNS 缓存、重启测试应用，再重新建立连接。不要在连接仍活动时频繁切换地址池，否则旧映射与新路由会短暂并存。

若只有运行时间较长后开始失败，检查地址池容量、映射回收和应用的 DNS 缓存周期。若特定域名首次正常、后续异常，比较真实 DNS 返回是否变化，以及旧连接是否复用了过期映射。若所有合成地址都无法连接，重点检查 TUN 是否接管该网段，而不是调整远程服务器。

最终验证应包含普通公网域名、明确直连域名、局域网域名和应用自带解析四类目标。普通公网目标应生成映射并按域名路由，直连与局域网目标应按排除策略获得真实地址，自带解析的应用则需要确认是否进入接管链路。只有四类结果都符合设计，FakeDNS 才真正改善了域名分流，而不是增加新的不透明层。

自定义出站：标签、链式转发与最终排错

先定义出站职责与标签

出站是路由规则的最终目的地。最小配置通常包含代理、直连和阻断三个职责，分别使用稳定标签 proxy、direct 与 block。自定义出站适合增加指定接口直连、独立 DNS 出站或链式转发，但每增加一个出站，都要同时维护标签、路由引用和故障回退。标签区分大小写，重命名后必须搜索全部规则，避免路由仍指向旧名称。

图形客户端通常会根据当前服务器生成主代理出站。直接修改生成对象可能在切换服务器或更新订阅后被覆盖，因此自定义部分应放在客户端支持的附加配置、预设档案或自定义出站区域。先确认客户端的合并顺序：同名字段是覆盖、追加还是拒绝。无法确认时，导出最终核心配置并检查实际结果，而不是只看界面中的输入片段。

{
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {
        "domainStrategy": "UseIP"
      }
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {
        "response": {
          "type": "none"
        }
      }
    }
  ]
}

为直连出口指定地址族或接口

多网卡设备可能同时连接有线、无线、虚拟网络和企业网络。默认直连由系统路由选择接口，自定义直连出站可在核心支持时指定发送地址或地址族，使某类流量固定走特定本地接口。配置前先确认该地址长期存在；使用动态分配地址时，休眠、重连或切换网络后可能失效。若目标只是访问局域网，优先依赖系统路由和私有地址直连，不必强制绑定接口。

指定地址族时要与 DNS 查询策略一致。直连出站只允许 IPv4，而 DNS 返回 IPv6，连接仍会失败；代理出站支持双栈也不代表本地直连支持。排查时分别记录 DNS 结果、路由标签和出站实际拨号地址。多网卡环境还要检查 TUN 创建的路由优先级，防止自定义直连再次进入 TUN 形成回环。

理解链式转发的适用边界

链式转发让一个代理出站通过另一个出站建立连接，可用于明确的网络拓扑或入口限制。它会增加握手层次、延迟和故障点，不适合用来替代服务器筛选。配置链路前先分别验证前置出站与最终出站独立可用，再连接两者。任何一层的 DNS、地址族、UDP 支持或传输失败，都会表现为最终连接失败。

链路必须无环。出站 A 通过 B，B 就不能再通过 A；DNS 出站也不能依赖一个最终又需要该 DNS 才能解析的代理。为每一层使用清晰标签，例如 proxy-entry 与 proxy-exit，日志中才能判断失败发生在哪个阶段。默认路由只应指向最终业务出口，前置出站通常由转发关系调用，不需要再由宽泛规则直接命中。

建立独立 DNS 出站

当核心支持 DNS 出站时，可以把内部 DNS 查询通过专用标签送往指定路径。这样路由规则能够把 DNS 流量与普通连接分开，减少循环。典型结构是内置 DNS 产生查询，DNS 出站负责发送，路由优先把对应入站或协议指向 dns-out。如果远程解析器需要代理访问，则让 dns-out 通过明确代理路径，而不是依赖默认规则猜测。

{
  "outbounds": [
    {
      "tag": "dns-out",
      "protocol": "dns",
      "settings": {
        "address": "1.1.1.1",
        "port": 53,
        "network": "tcp"
      }
    }
  ],
  "routing": {
    "rules": [
      {
        "type": "field",
        "inboundTag": ["dns-in"],
        "outboundTag": "dns-out"
      }
    ]
  }
}

示例说明标签关系，不代表所有客户端都用同一字段生成 DNS 出站。使用加密 DNS 时，地址、端口和传输还需按核心支持方式配置。验证重点是查询只经过一次入站和一次出站，没有重新回到普通 DNS 入口。若日志持续重复同一域名，优先怀疑解析循环。

按层执行最终排错

复杂配置失败时，从请求入口向外逐层检查。第一步确认应用流量是否进入系统代理或 TUN；第二步确认 DNS 是否获得可用结果并保留域名；第三步确认路由命中预期标签；第四步确认标签对应的出站存在且参数有效；第五步才检查远端连接。每一步都需要日志证据。跳过入口和路由直接更换服务器，往往只会暂时改变现象。

错误可按范围缩小：全部应用失败，多半位于核心启动、接管或默认出站；单个应用失败，比较其代理方式、协议和 DNS 行为；单个域名失败，检查域名规则、缓存和真实解析；只有 UDP 失败，检查网络栈、路由与出站能力；只有局域网失败，检查私有地址与 TUN 绕过。把现象映射到配置层，比记忆单条“修复命令”更可靠。

完成配置后，不要把最终结果视为永久不变。订阅命名、网络接口、系统权限和业务域名都会变化，应在出现明显行为变化时重新执行基线测试。需要更换客户端时，可先阅读v2rayN、v2rayNG 与 v2flyNG 横向评测；需要重新安装时进入客户端下载页；遇到具体日志错误则结合运行日志定位步骤处理。保持配置分层、标签稳定和改动可回退，比持续增加规则更重要。