V2Ray 进阶配置手册

CHAPTER 01 / BASELINE

配置基线：先分清客户端、内核与系统网络

进阶配置最容易出现的问题，不是某个参数拼错，而是把不同层级的设置混在一起。v2rayN、v2rayNG 与 v2flyNG 是负责导入订阅、选择服务器、生成配置和控制连接状态的图形客户端；Xray、V2Fly 等内核负责执行协议、路由、DNS 与出站逻辑；系统代理、虚拟网卡和应用自身的网络选项则决定流量是否真正进入内核。排查时必须先确认故障位于哪一层，否则反复更换服务器只能掩盖现象。

建立可恢复的配置起点

开始调整前，先在客户端中导出当前可用配置或记录订阅来源、活动服务器、代理模式、路由方案与 DNS 设置。v2rayN 的订阅信息、服务器列表和路由方案属于客户端管理数据，内核运行时生成的配置则可能随界面选项变化，不应只复制某一段临时 JSON 当作完整备份。移动端还要记录是否启用了 VPN 服务、分应用代理和绕过局域网，因为这些选项会改变实际流量范围。

配置基线应满足三个条件：普通浏览器能够按预期访问网络；客户端日志中没有持续重复的启动错误；选中的服务器条目包含完整的地址、端口、用户标识、传输方式与安全参数。只有基线可用，后续的分流与 DNS 对比才有意义。如果基础连接尚未完成，应先返回快速上手主线，按导入订阅、选择服务器、启动连接和验证流量的顺序处理。

读取日志时先找第一条错误

内核日志往往会在同一故障后连续输出多条信息。真正有价值的是启动后出现的第一条配置错误、解析错误或连接错误。例如，路由规则引用了不存在的出站标签，后续所有连接都会失败；DNS 服务器不可达，后续可能表现为域名超时；系统代理未生效，则客户端日志可能完全没有对应请求。不要只盯住最后一行，也不要把普通的连接关闭记录当成根因。

建议按“客户端是否启动内核—请求是否进入本地入口—域名是否完成解析—路由是否命中预期规则—目标出站是否建立连接”的顺序查看。若客户端没有启动内核，检查配置生成与端口占用；若请求没有进入本地入口，检查系统代理、浏览器独立代理或 TUN 状态；若只有域名失败而直接访问 IP 有响应，重点转向 DNS；若部分站点走错线路，再检查路由顺序和域名集合。

参数来源与优先级

订阅提供服务器连接参数，客户端保存本地覆盖项，路由与 DNS 方案决定运行逻辑，系统网络决定流量入口。订阅更新可能重建服务器条目，因此不适合把长期规则只写在某一个服务器备注里。需要持续保留的分组、过滤和路由策略，应放在客户端的订阅设置、路由方案或独立配置中。若确实需要编辑原始配置，应先确认客户端不会在下一次启动时覆盖它。

完成这一章后，应能明确当前问题属于数据管理、内核运行还是系统接管。这个判断会决定后续工具：服务器条目混乱就处理订阅；访问方向不对就处理路由；域名异常就处理 DNS；只有不遵循系统代理的程序无法接入时，才考虑 TUN。将层级拆开，是整本手册后续配置能够稳定复现的前提。

CHAPTER 02 / GROUPS

订阅分组与服务器过滤

单个订阅也可能包含大量条目。把所有服务器平铺在一个列表中，会让选择、更新和故障定位逐渐失控。分组的目标不是追求复杂层级，而是把“数据从哪里来”“条目适合什么用途”“哪些内容应当暂时隐藏”分开表达。v2rayN 更适合在桌面端集中整理多个订阅；v2rayNG 与 v2flyNG 的移动场景则应保留较少、含义明确的分组，减少切换成本。

先按来源分组，再按用途筛选

订阅来源是最稳定的一级边界。为每个来源设置清晰名称，例如“日常线路”“测试线路”“备用线路”，不要把地区、协议、倍率和用途全部塞进同一个组名。来源分组有助于判断更新失败影响了哪一批数据，也方便单独停用失效来源。用途则适合通过备注关键字和过滤条件处理，例如保留名称中包含“办公”或“低倍率”的条目，隐藏包含“到期”“剩余”“官网”等通知型条目。

过滤通常包含保留与排除两种方向。保留规则适合明确的小集合，例如只显示备注含“日本”或“新加坡”的服务器；排除规则适合清理通知条目与暂不使用的协议。若同时使用两类规则，应先理解客户端的处理顺序：一般先从订阅获得完整条目，再应用筛选条件。过滤只改变客户端列表视图或导入结果，不会改变远端订阅本身。

正则过滤的安全写法

当普通关键字不足以表达条件时，可以使用正则表达式。地区名称可用竖线表示“任意一个”，排除通知词也可以合并处理。正则应保持短小，并先在少量条目上验证。过度复杂的前瞻、回溯条件不利于维护，也可能因为不同客户端的表达式实现差异而得到不同结果。

保留示例：
日本|东京|新加坡|美国

排除示例：
到期|剩余|公告|网址|流量

精确匹配常见地区前缀：
^(日本|新加坡|美国)[-_ ]

中文、英文缩写和旗帜符号可能同时出现在备注中。若订阅命名不统一，应先观察完整列表，再决定关键词，不要直接套用网上的长表达式。过滤后条目突然归零时，先清空条件确认原始订阅是否正常，再逐段恢复表达式。若只有部分名称未匹配，检查全角空格、连字符和大小写差异。

测速结果不等于可用性结论

服务器筛选常与测速一起使用，但延迟测试只回答某个探测请求是否能够到达，不能完整代表实际协议连接、目标站点访问或持续传输表现。TCP 探测可达，不代表认证参数正确；单次延迟较低，也不代表高峰时段稳定。筛选时应先剔除明显不可连接的条目，再用实际访问验证候选线路，不应只按一个数字永久排序。

更稳妥的流程是：更新单个订阅，确认条目数量与备注结构；应用排除规则，清理通知项；选取少量候选服务器执行连通性测试；启动其中一条并访问常用目标；最后保存适合当前网络的排序。网络环境变化后重新测试，而不是把旧结果当作固定属性。有关节点测速失真与判断方法，可结合站内文章列表中的排障内容继续查阅。

更新后的差异检查

订阅更新后至少检查三项：来源名称是否仍对应原分组；服务器备注是否改变，导致过滤规则失效；当前活动服务器是否被替换或删除。如果订阅方调整了命名格式，旧关键字可能把新条目全部排除。此时先关闭过滤查看原始结果，再更新表达式。若某个来源更新失败，不要立刻执行全部订阅覆盖更新，应单独检查链接状态、是否需要通过已有连接更新，以及返回内容是否仍是客户端能够识别的格式。

分组完成的标准不是列表看起来整齐，而是能够回答三个问题：当前服务器来自哪个订阅，为什么会出现在这个筛选结果中，更新失败时应操作哪一个来源。只要这三项清楚，后续多订阅管理和路由绑定就有稳定基础。

CHAPTER 03 / MULTI-SUBSCRIPTION

多订阅管理与更新策略

多个订阅同时存在时，主要风险不是条目数量，而是来源之间发生覆盖、重名和更新节奏冲突。合理的多订阅结构应让每个来源能够独立更新、独立停用、独立排错，同时避免把订阅地址复制到不必要的位置。桌面端通常由 v2rayN 作为集中管理入口；Android 端可以只导入需要随身使用的来源，避免每次更新都处理大量重复服务器。

给每个来源建立独立身份

新增订阅时，名称应表达用途而不是暴露完整地址，例如“主要桌面”“移动备用”“协议测试”。如果两个来源可能包含同名服务器，可在订阅名称中增加短前缀，并保留客户端提供的来源标识。服务器备注可以变化，订阅身份不应跟着变化。不要使用“订阅一”“订阅二”这类无法回忆来源的名称，也不要用当前日期作为长期名称。

同一地址不应重复添加到多个分组。重复来源会在更新后生成相似条目，导致选择时无法判断实际归属。发现重复时，先比较订阅地址与更新时间，再保留一个管理记录。若客户端支持按订阅移除服务器，应使用来源级操作，而不是在总列表里逐条删除，因为下一次更新可能再次导入。

安排更新顺序与失败隔离

稳定做法是先更新当前正在使用的主来源，确认可连接后，再依次更新备用来源。全部并行更新虽然操作更少，但某个来源返回异常内容时更难定位。自动更新间隔不宜设置得过密；订阅内容通常不是实时状态流，频繁请求不会让线路本身更稳定。需要自动更新时，应选择能够覆盖日常变更的周期，并保留手动更新入口用于故障恢复。

更新失败可按四个方向判断：地址本身失效；当前网络无法直接访问订阅地址；服务端根据请求特征拒绝返回；返回内容格式与客户端不兼容。第一步是在客户端中单独更新该来源并查看提示；第二步尝试在已有可用连接下执行经代理更新；第三步确认地址复制时没有多余空格、换行或截断；第四步检查返回的是订阅数据还是普通网页。更完整的分支可参考订阅更新失败排查与自动更新设置。

合并、转换与本地规则的边界

订阅转换适合处理客户端格式差异、筛选字段和合并输出，但转换链越长，定位问题越困难。若 v2rayN、v2rayNG 或 v2flyNG 能直接识别原始来源，应优先直接导入。确需转换时，应明确转换过程是否只改变封装格式，还是同时改写协议参数、服务器名称与路由规则。任何改变连接参数的步骤，都可能造成原始订阅可用而转换结果失败。

不要把本地长期路由规则依赖在远端订阅的临时备注上。备注可用于筛选服务器，却不适合作为域名分流条件。路由应按目标域名、IP、端口、进程或入站标签编写，与服务器列表来源分离。这样即使切换订阅，访问策略仍保持一致。只有需要将某类目标固定送往特定服务器时，才把路由规则与一个稳定的出站标签关联。

移动端与桌面端的同步取舍

多设备之间无需追求服务器列表完全相同。桌面端可能需要多个出站、复杂路由和 TUN 接管，移动端更适合精简来源与简单分应用规则。可以同步订阅来源名称和核心筛选原则，但应分别保存系统相关设置。尤其不要直接把桌面端包含本地监听端口、进程规则和桌面 DNS 地址的完整配置复制到移动端。

清理旧来源的顺序

停用来源时，先取消自动更新，再切换到其他已验证服务器，随后从该来源移除服务器，最后删除订阅记录。直接删除当前活动来源，可能让客户端仍显示旧连接状态，但下一次启动时无法恢复。清理后重新检查活动服务器、默认出站与路由标签，确认没有规则继续引用已删除对象。

多订阅管理达到稳定状态后，每个来源都应有明确用途和更新方式；任何来源失败都不会阻断其他来源；路由与 DNS 不依赖临时服务器备注；桌面与移动端只共享必要的数据。这样的结构比简单合并成一条超长订阅更容易维护，也更适合后续添加自定义出站。

CHAPTER 04 / ROUTING

路由规则实战：匹配条件、顺序与出站

路由的作用是把已经进入内核的连接，根据目标域名、目标 IP、端口、网络类型、进程或入站标签送往指定出站。它不会自动让应用流量进入客户端，也不会修复服务器连接参数。系统代理或 TUN 负责入口，路由只处理入口之后的方向选择。理解这条边界，可以避免把“应用没有经过客户端”误判成“分流规则未命中”。

从三类出站开始

常见基础结构包含代理出站、直连出站和阻断出站。代理出站指向当前选中的服务器或自定义代理链；直连出站由本地网络直接访问目标；阻断出站用于拒绝明确不需要的连接。每个出站应有稳定且含义清楚的标签，例如 proxy、direct、block。路由规则通过标签引用出站，因此修改标签后必须同步修改所有引用。

规则顺序通常采用从具体到一般。先放明确的阻断、内网直连、指定域名或指定进程规则，再放较大的域名集合与 IP 集合，最后由默认出站接住未匹配流量。如果把宽泛规则放在前面，后面的精确规则永远没有机会执行。例如先匹配全部 TCP 流量到代理，再写某个域名直连，直连规则就可能失效。

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

上例先让私有地址直连，再处理指定域名与域名集合。domain: 表示匹配该域名及其子域名，full: 更适合只匹配完整主机名，keyword: 会匹配包含指定片段的域名，范围最大，误匹配风险也最高。规则语义会随内核配置格式变化，客户端界面生成的方案通常更适合日常维护；直接编辑 JSON 时，要确认字段属于当前内核支持的配置结构。

域名与 IP 匹配如何衔接

当路由只收到域名时，域名规则可以直接判断；当规则需要按 IP 集合匹配时，内核可能需要先解析域名。domainStrategy 决定何时进行这一步。仅按域名规则工作时，可以避免额外解析；需要“域名规则未命中后再按 IP 判断”时，可使用对应的按需解析策略。若无条件先解析所有域名，会增加 DNS 请求，也可能让路由使用的解析结果与应用预期不一致。

GeoSite 是域名集合，GeoIP 是 IP 地址集合。两者依赖本地数据文件，规则写法正确但数据过旧时，仍可能出现新域名未覆盖或地址归类变化。更新后应重启内核，让运行配置重新加载数据。具体更新和误分流排查可参考GeoIP 与 GeoSite 数据库更新教程。

内网、局域网与私有地址

家庭路由器、打印机、文件共享和本地开发服务通常使用私有地址，应优先直连。否则访问本地设备可能被送往远端出站而失败。除私有 IP 集合外，还要留意 localhost、.local 名称和企业内部域名。内部域名往往只能由局域网 DNS 解析，应在 DNS 分流中指定本地解析服务器，并在路由中安排直连。

TUN 模式下，客户端接管范围更广，内网直连规则尤其重要。若开启 TUN 后无法访问路由器管理页，先检查私有地址是否绕过代理、虚拟网卡路由是否覆盖了局域网网段，再确认系统防火墙。不要为了恢复一个本地地址而关闭全部路由规则，精确增加直连目标更容易验证。

规则未生效的逐项排查

先确认请求确实进入内核，再在日志中观察目标是域名还是 IP。若只看到 IP，纯域名规则可能无法匹配；若目标域名已命中前面的宽泛规则，调整顺序；若引用 GeoSite 或 GeoIP，检查数据文件是否加载；若规则指向自定义出站，检查标签完全一致；若客户端提供“绕过局域网”“全局”“规则”等模式，确认当前模式没有覆盖自定义方案。

验证时选择一个目标，分别测试直连、代理和阻断三种可观察结果。不要同时拿多个站点判断，因为网页可能加载不同域名的主资源、图片和接口，看起来会像同一请求走了多条线路。浏览器缓存与持久连接也会影响结果，修改规则后应重启内核，并建立新的连接。路由的稳定标准是规则意图、命中顺序和出站标签能够逐条解释，而不是某次刷新恰好成功。

CHAPTER 05 / DNS

DNS 配置优化：查询路径、分流与泄漏排查

DNS 决定域名如何转换为地址，也会影响路由是否能够按域名或 IP 正确匹配。进阶配置中最常见的混乱，是系统 DNS、应用内置 DNS、客户端 DNS 和远端出站解析同时存在，却没有明确哪一层负责哪个域名。优化的目标不是堆叠更多服务器，而是建立一条可解释的查询路径：请求从哪里进入、由哪个服务器解析、查询本身走哪个出站、结果交给哪条路由。

区分系统查询与内核查询

普通系统代理模式下，部分应用可能先在系统侧解析域名，再把 IP 交给代理；另一些支持代理协议的应用会把域名交给客户端。TUN 模式可以接管更多 DNS 流量，但仍可能遇到应用使用加密 DNS 或自带解析器。日志中若只出现目标 IP，说明域名信息可能在进入内核前已经丢失，此时按域名分流的效果会受限。

内核 DNS 服务器既可以使用传统 IP 地址，也可以使用支持加密传输的服务地址，具体能力取决于内核和客户端生成方式。选择时应同时考虑可达性与出站路径。一个解析服务器本身需要通过代理访问，而路由又依赖它的解析结果时，可能形成循环依赖。基础解析入口应当在当前网络下明确可达，再为特定域名安排其他服务器。

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

这段示例表达的是分域名选择解析服务器，而不是要求所有网络照抄。domains 限定该服务器负责的域名集合，expectIPs 可用于检查返回地址是否符合预期范围，queryStrategy 决定查询地址类型的倾向。若当前网络无法访问某个解析入口，应替换为可达服务，而不是继续增加超时重试。

DNS 分流与路由分流要一致

域名准备直连时，通常应使用适合本地网络的解析路径；域名准备通过代理出站时，可以让查询同样经过对应出站，避免解析位置与访问位置差异过大。两套规则不必逐条重复，但大方向应一致。若路由让某域名直连，而 DNS 查询强制经过远端出站，连接可能仍能工作，却会增加延迟和排查难度。

内部域名是最需要明确分流的场景。企业或家庭局域网的内部名称通常只有本地 DNS 能够回答，应为相应域名后缀指定本地解析服务器，并在路由中直连对应地址。若公共 DNS 返回不存在，客户端不会自动知道还要向内部服务器重试。相反，公共域名不应全部交给只在局域网有效的服务器，否则离开当前网络后会整体失效。

缓存、TTL 与切换后的旧连接

DNS 结果可能被应用、系统、客户端和内核分别缓存。修改解析设置后立即刷新页面，未必触发新查询；已建立的连接也不会因为 DNS 改变而自动迁移。验证时应关闭旧连接、重启内核，并在必要时清理系统 DNS 缓存。不要把缓存时间设置得极短来追求“实时”，这会增加查询数量，也不能解决服务器本身返回错误的问题。

服务器地址变化频繁的业务，应尊重合理 TTL 并建立失败重试；固定内部服务则可以保留适度缓存。若同一域名在不同网络返回不同地址，切换网络后要特别留意旧缓存。移动端从无线网络切换到蜂窝网络时，重新启动连接通常比等待所有缓存自然过期更可控。

DNS 泄漏的判断与修复

所谓 DNS 泄漏，核心是本应经过指定路径的查询被系统或其他应用发送到了未计划的解析服务器。判断时不能只看网页上显示了几个 DNS 地址，还要结合当前网络、代理模式和预期路径。系统代理模式无法天然接管所有应用的 DNS；TUN 模式覆盖更广，但也需要正确拦截 DNS 流量。浏览器启用独立加密 DNS 后，还可能绕开系统与客户端设置。

修复顺序是先明确预期，再减少旁路：关闭或调整应用自己的解析器；让系统 DNS 请求进入客户端；为内核 DNS 指定明确出站；检查路由是否把查询送错方向；最后重新测试。若只在某个应用中出现，优先检查该应用设置，而不是改动整个系统。完整操作可阅读DNS 泄漏检测与修复实操。

DNS 配置完成的标准，是能够解释每类域名由谁解析、查询走哪条出站、结果如何参与路由，并能在日志中观察到对应过程。服务器数量越多不代表效果越好；一条短而清晰的查询链，通常比多个随机备用地址更稳定。

CHAPTER 06 / TUN

TUN 模式：系统流量接管与边界控制

TUN 模式通过虚拟网络接口接收系统流量，适合不遵循系统代理、无法单独设置代理或包含 UDP 请求的程序。它解决的是流量入口覆盖范围，不负责自动选择正确服务器，也不会替代路由与 DNS。开启后，客户端需要配置虚拟网卡、系统路由和 DNS 接管，因此故障范围会从单个应用扩大到整个系统网络。应在普通代理模式已经稳定可用后再启用。

启用前的检查

先确认 v2rayN 或 Android 客户端在普通模式下能够使用当前服务器，并保存原有配置。桌面端需要具备创建虚拟网卡和调整路由所需的系统权限；安全软件或企业策略可能限制这些操作。还要记录本地局域网网段、正在使用的 VPN 类软件、虚拟机网络和容器网络，因为多个虚拟接口可能争夺默认路由。

启动 TUN 前关闭其他会修改系统路由的连接工具，避免同时接管。若必须共存，应明确每个接口的路由优先级和目标网段，不要依赖启动顺序碰运气。客户端异常退出后如果网络中断，先退出相关进程并恢复系统网络，再检查残留虚拟接口和 DNS，而不是反复重启浏览器。

栈模式与 MTU

不同客户端和内核可能提供 system、gVisor 或 mixed 等网络栈选项。系统栈通常更贴近操作系统网络行为，兼容性与性能受平台实现影响；用户态栈便于在客户端内部处理数据包，对某些环境更稳定，但也可能与特定协议或应用存在差异。没有明确故障时使用客户端推荐值即可，出现 UDP、局域网或特定应用异常时再切换对比。

MTU 决定单个数据包的最大尺寸。设置过大可能在复杂网络路径中产生分片或丢包，表现为网页能打开但上传、视频或部分接口卡住；设置过小则增加额外开销。不要一看到连接慢就随意降低 MTU。应先确认问题只在 TUN 下出现，再用逐步调整方式比较，并在每次调整后重新建立连接。恢复默认值也应作为对照组。

局域网与保留地址绕过

TUN 接管后，应明确绕过私有地址、回环地址和当前局域网需要直连的网段。打印机、网络存储、路由器管理页与本地开发服务都依赖这一点。只设置“绕过局域网”开关仍不够时，应查看实际地址范围，并用精确 IP 或网段规则补充。企业网络中还可能存在非典型内部地址，需要按实际路由表处理。

如果本地设备通过主机名访问，还要同步配置内部 DNS。仅让目标 IP 直连，但域名交给公共解析服务器，仍会得到不存在或错误地址。局域网问题应分成“名字能否解析”和“地址能否直连”两步验证。先用 IP 测试连通，再测试域名，就能判断问题位于 DNS 还是路由。

按应用控制与 UDP

移动端常用分应用代理控制哪些程序进入连接。包含模式适合只让少量应用进入，排除模式适合让大多数应用进入但保留本地服务直连。应用更新或更换包名后，旧选择可能失效，应定期检查列表。桌面端的进程路由依赖内核和权限，进程名相同也可能对应不同路径，规则应在实际日志中验证。

UDP 流量包括部分 DNS、实时通信和新型传输协议。服务器与协议链不支持相应 UDP 行为时，TUN 能接收到数据包也无法保证目标可达。排查时先判断是全部 UDP 失败，还是某个应用、某个目标失败；再检查出站能力、路由和 MTU。不要把 UDP 故障简单归因于虚拟网卡。

关闭后的网络恢复

正常退出客户端时，自动路由和 DNS 应随之恢复。若异常退出后网络仍不可用，先确认 TUN 接口是否仍存在，再检查默认路由和系统 DNS 是否保留了临时值。重新打开客户端后执行一次正常启动与正常停止，有时可以触发清理流程。仍未恢复时，使用系统网络重置功能，并重新连接当前网络。

TUN 的稳定标准不是“所有流量都接管”，而是接管范围符合预期、局域网边界清晰、DNS 不旁路、关闭后系统能够恢复。对只使用浏览器和支持系统代理应用的场景，普通代理模式更简单；只有确实存在入口覆盖需求时，TUN 才是合适工具。

CHAPTER 07 / FAKEDNS

FakeDNS：虚拟 IP 映射、适用条件与兼容性

FakeDNS 不直接向应用返回域名的真实地址，而是从保留地址池分配一个虚拟 IP，并在内部保存“虚拟 IP—原始域名”的映射。应用连接这个虚拟地址时，内核根据映射恢复域名，再执行域名路由和实际解析。它的主要价值是在 TUN 场景中保留域名信息，避免应用先获得真实 IP 后让内核只能按地址判断。

映射过程如何工作

应用发起 DNS 查询后，请求被 TUN 或 DNS 劫持规则送入内核。FakeDNS 为域名分配虚拟地址并返回，应用把这个地址当作目标建立连接；内核识别地址属于 FakeDNS 池，从映射表取回域名，然后按域名规则选择出站，必要时再通过目标出站解析真实地址。整个过程要求 DNS 请求和后续连接都经过同一个可识别映射的内核实例。

如果 DNS 请求进入 FakeDNS，但应用连接绕过了 TUN，系统会尝试访问一个并不存在于公网的虚拟地址；反过来，如果连接进入 TUN，而 DNS 由应用自己的解析器直接完成，内核可能只看到真实 IP，FakeDNS 就没有参与。启用前必须先确保 DNS 接管与流量接管形成闭环。

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

示例使用基准测试用途的保留地址段作为虚拟池，并只为指定域名集合选择 FakeDNS。实际字段与放置位置取决于内核配置格式和客户端生成方式，应优先使用客户端提供的开关与模板。地址池不得与本地局域网、企业网络、其他虚拟接口或已有路由重叠。池大小也不是越大越好，只需覆盖正常使用期间的活跃映射。

适合启用的场景

当 TUN 已稳定运行、域名规则很多、应用经常在本地先解析域名，FakeDNS 能帮助内核保留域名语义。它也适合需要减少真实解析前置步骤的场景：路由先按域名选择出站，再由目标路径完成实际解析。这样可以避免本地解析结果过早决定目标地址。

如果主要使用支持远程解析的系统代理，日志中已经能看到完整域名，FakeDNS 带来的收益通常有限。简单网络不必为了参数更多而启用。FakeDNS 是解决域名信息丢失的工具，不是通用加速开关，也不会改善服务器本身的连接质量。

不适合直接启用的场景

依赖真实 IP 展示、地址白名单、局域网发现或直接比较 DNS 结果的应用，可能无法接受虚拟地址。部分安全软件会把保留地址段连接视为异常；某些游戏、设备控制程序或企业客户端也可能绕过系统 DNS，导致映射链不完整。内部域名通常应继续交给局域网 DNS，并直接连接真实地址，而不是进入 FakeDNS。

需要通过 IP 规则精确控制的目标也应谨慎。如果路由在恢复域名之前就把虚拟 IP 当作普通地址处理，可能命中错误规则。配置中应确保 FakeDNS 地址识别发生在正确阶段，并避免为虚拟地址池编写普通直连规则。关于机制、适用边界与应用兼容问题，可继续阅读FakeDNS 原理详解。

缓存与映射失效

应用可能缓存虚拟 IP，而内核重启后映射表已经清空。此时应用继续连接旧虚拟地址，内核无法恢复原域名，表现为重启客户端后短时间内部分站点失败。关闭旧连接、清理应用 DNS 缓存或重启应用通常可以恢复。频繁重启内核会增加这种现象，因此调试时每次改动后要重新发起完整查询。

地址池耗尽或映射数量异常增长时，应检查是否有程序持续生成随机子域名查询。盲目扩大池只能延后问题。先确认请求来源，必要时为该类域名绕过 FakeDNS或限制应用接管范围。启用完成后，应分别验证普通域名、内部域名、仅按 IP 访问的目标和重启后的缓存恢复。只有这四类行为都可解释，FakeDNS 才算稳定接入。

CHAPTER 08 / OUTBOUNDS

自定义出站、代理链与完整排错流程

自定义出站用于把不同目标送往不同连接路径，或在直连、代理、阻断之外增加 DNS 专用、前置代理和特定服务器出站。它是前面订阅、路由与 DNS 结构的汇合点：服务器参数决定出站能否连接，路由标签决定哪些请求进入，DNS 路径决定目标如何解析。自定义出站越多，标签与依赖关系越需要明确记录。

标签是配置之间的接口

每个出站都应使用唯一、稳定、只表达用途的标签。不要把服务器地址、地区和日期全部写入标签，因为订阅更新后这些信息容易变化。可以使用 proxy-main、proxy-backup、direct、block、dns-out 等名称。路由规则、DNS 服务器和代理链只通过标签引用，显示名称可以更详细。

删除或重命名出站前，应搜索所有引用位置。配置能够解析不代表引用一定有效，部分错误只会在对应规则首次命中时出现。最稳妥的做法是先新增出站并单独测试，再把一条精确域名规则切换过去，验证成功后逐步扩大范围，最后删除旧出站。

{
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {}
    },
    {
      "tag": "dns-out",
      "protocol": "dns",
      "settings": {
        "address": "1.1.1.1",
        "port": 53,
        "network": "tcp"
      }
    }
  ]
}

示例展示直连、阻断和 DNS 出站的基本标签关系。代理服务器出站通常由订阅和客户端生成，不建议把认证参数重复粘贴到多个本地配置中。若客户端支持将当前服务器作为默认代理出站，应保留这种动态引用，使切换服务器时路由无需改写。只有需要固定某条线路时，才创建独立出站。

代理链的方向与依赖

代理链表示一个出站通过另一个出站建立连接。例如目标流量先进入业务出站，该出站再指定前置出站作为传输路径。配置时必须分清“谁通过谁连接”，避免把方向写反。链条中的每一层都会增加连接建立步骤和排错范围，只有明确需要前置路径时才使用。

代理链最常见的故障是循环依赖：出站 A 通过 B，B 又通过 A；或 DNS 解析 A 的服务器地址需要经过 A 本身。应让链条最终落到一个可直接建立连接的出口，并尽量使用可直接解析或固定可达的服务器地址。验证时先测试最外层基础出站，再逐层加入上层，不要一次启用整条链。

按入站、端口与进程选择出站

除了域名和 IP，还可以根据入站标签、目标端口、网络类型或进程进行分流。入站标签适合把不同本地监听端口绑定到不同出站，例如一个端口使用主线路，另一个端口用于测试备用线路。端口规则适合明确协议服务，但现代应用常在同一端口承载多种业务，不能只凭端口判断内容。进程规则适合桌面端按应用控制，实际支持与权限取决于内核和系统。

规则组合应避免范围重叠。若某个进程规则与域名规则同时存在，前后顺序会决定结果。建议先写最明确的入站或进程规则，再写目标域名规则，最后放通用集合。每条规则旁边记录用途，比单纯依靠复杂名称更容易维护。客户端界面若支持备注，应写明命中条件和目标出站。

一套可重复的排错流程

第一步恢复最小配置：一个已验证服务器、一个代理出站、一个直连出站，不启用复杂路由、TUN 和 FakeDNS。确认基础连接后，第二步加载 DNS 配置并验证域名解析；第三步加入一条精确路由，观察命中；第四步启用 TUN，验证系统流量与局域网；第五步才加入 FakeDNS 或代理链。每一步都保留日志和结果。

如果问题只在订阅更新后出现，比较活动服务器与协议参数，不要先改路由。如果只有某类域名失败，检查 DNS 分流和 GeoSite 数据。如果只有不支持系统代理的应用失败，检查 TUN 入口。如果开启 FakeDNS 后大面积失败，恢复真实 DNS 并检查映射闭环。如果自定义出站失败，先用精确规则测试该出站，不要让全部流量切换过去。

日志记录应包含操作时间、修改项、当前模式和首条错误。无需保存大量重复连接关闭信息。对比两次配置时，只比较实际改变的部分；同时调整 DNS、路由和出站，会让差异失去价值。遇到术语或界面含义不清时，可先查看配置与排障文章，需要重新安装客户端时前往下载页选择 Windows、macOS、Android 或 Linux 对应版本。

长期维护的最小清单

定期维护不需要每天重做配置。订阅层检查来源是否仍有效、过滤是否误伤；路由层检查 GeoIP 与 GeoSite 数据以及标签引用；DNS 层检查解析服务器可达性与应用旁路；TUN 层检查虚拟接口、局域网绕过与关闭恢复；FakeDNS 层检查地址池冲突和应用兼容；出站层检查链条是否仍有必要。内核切换时，还要确认配置字段与协议特性是否兼容。Xray 与 V2Fly 的差异可阅读Xray 内核与 V2Fly 内核区别对比。

一套可维护的进阶配置，应该能够用短句解释每个组件的职责：订阅提供服务器，分组管理来源，过滤减少噪声，DNS给出地址，路由选择方向，TUN扩大入口，FakeDNS保留域名，自定义出站建立目标路径。任何无法解释用途、无法单独验证或删除后没有影响的规则，都值得重新评估。配置越接近这种清晰结构，更新客户端、切换服务器和迁移设备时就越不容易失控。