v2rayN 进阶配置手册

01 配置基线与验证顺序

进阶配置的起点不是增加规则，而是保存一个已经可用的状态。先确认所选服务器能完成一次真实网页访问，再记录当前服务器所属分组、系统代理状态、路由配置名称、内核类型和是否启用 TUN。记录不必包含订阅地址或服务器凭据；这些信息足够判断后续变化发生在哪一层，也方便在调整失败时恢复原来的组合。

把客户端、内核与系统接管分开

v2rayN 负责图形界面、订阅管理和配置生成，实际连接由选用的内核处理。系统代理则告诉遵循该设置的应用把请求交给本地入口，它本身不是隧道。TUN 在更低一层接管网络包，但仍需要正确的路由和出站。界面显示正在运行，只能说明相关进程已启动，不能单独证明域名解析、服务器握手和目标访问都成功。

先在“设置”中查看本地监听端口和当前内核，不要按教程截图猜端口。浏览器若使用独立代理扩展，应暂时统一为跟随系统；应用若有自带的代理设置，也要记下它是否覆盖系统选择。否则同一台电脑上会同时存在几条流量路径，一个网页成功而另一个失败，容易被误判成路由规则不稳定。

先做小范围验证，再扩大接管

建议先关闭 TUN，只使用“系统代理 → 自动配置系统代理”，保留一份简单路由。依次访问一个普通域名页面、一个局域网地址和实际需要使用的应用。网页测试要包含重新打开页面，而不只是刷新已经缓存的标签。局域网测试可使用自己路由器的管理地址；不要照抄别人网络中的网段，也不要把公开服务地址当作局域网目标。

测试记录应写“哪一个应用、访问什么类型的目标、出现什么错误”。例如域名打不开但局域网管理页可用，说明问题不必从所有网络接口查起；只有一个应用失败，则先检查它是否采用独立代理或加密 DNS。错误发生时间也值得记录，便于在日志中找到对应连接，而不是从一整页历史信息里猜测原因。

一次只改一个可解释的变量

每次调整后先保存，再按界面提示重载配置或重启服务。修改服务器参数、DNS 或 TUN 参数后，旧连接可能继续沿用原路径；验证时关闭相关应用连接并重新发起请求。不要同时更换服务器、开启 FakeDNS、导入整套路由。即使访问恢复，也无法知道是哪项生效，更无法判断另外两项是否留下了潜在问题。

阅读日志时先分清启动错误与请求错误。配置无法解析、监听地址被占用，属于服务启动阶段；连接超时、名称解析失败、远端拒绝则发生在请求阶段。前一类应先恢复配置结构或解决端口冲突，后一类再沿着入口、解析、规则、出站逐层查。提高日志详细程度只用于短时复现，排查结束后恢复常用级别，避免日志持续增长。

如果基础访问尚未成功，先回到配置教程完成主线，再继续本页。安装包与平台选择在客户端下载页；某个现象需要快速判断时，可查常见问题。本章建立的记录方式会贯穿后面各章：始终先确认发生变化的层次，再选择下一步，而不是把所有开关轮流打开。

02 订阅分组与服务器过滤

订阅分组解决的是服务器来源管理，不是流量分流。一个分组可以对应一个订阅来源，也可以存放手动导入的记录；给分组改名，不会改变服务器实际连接参数。建议先按来源和用途命名，例如日常订阅、备用订阅、手动配置。名称用于辨认，不应写入订阅密钥，也不要把完整地址放进备注，避免截图时连同凭据一起暴露。

先确认分组，再执行更新

在“订阅分组 → 订阅分组设置”中检查目标分组的地址、启用状态和可用的过滤选项。保存后从“订阅分组”菜单执行更新，留意当前命令针对当前分组还是全部分组。多个分组存在时，界面正在显示的分组不一定等于更新命令的作用范围；更新结束后，应切回目标分组核对记录变化，而不只看一条完成提示。

订阅地址通常是一条能够获取服务器集合的网络地址，而分享链接代表单个连接配置。把分享链接填入订阅地址栏，不保证能被更新器当作订阅处理。对于剪贴板里的单条链接，使用“服务器”菜单中对应的导入功能；对于订阅来源提供的地址，放进分组设置。两种入口的差别可继续阅读分享链接与订阅地址的区别。

显示筛选与更新过滤不是一回事

主窗口的搜索或分组选择通常只是缩小当前显示范围，记录未必被删除。分组设置中的过滤条件则可能在更新时决定哪些服务器被保留。排查“更新后没有服务器”时，先清空主窗口搜索文字，再确认所选分组，最后检查更新过滤。按这个顺序处理，可以避免把暂时隐藏的记录误认为订阅解析失败。

不同构建可能提供名称过滤或正则表达式选项。只有字段说明明确采用正则时，才把表达式填进去；普通文本过滤未必解释括号和竖线。正则中 HK|JP 表示匹配任一片段，^(HK|JP)- 则要求名称以指定前缀开头。先在少量已知名称上验证，再扩大范围，避免因大小写、空格或全角符号差异把目标记录全部排除。

^(HK|JP)-

上面的表达式只演示名称前缀匹配，不代表地区真实性，也不会自动选择更快的服务器。若来源改变了命名格式，原过滤条件就可能失效。名称包含地区词也不等于实际出口位置；需要保留哪些记录，应以来源说明和实际用途判断。不要把复杂过滤规则当成连接质量检测，更不要用一次测试结果永久删除整组记录。

过滤失败时按数据流定位

可以把更新过程拆成获取、解析、过滤和显示四步。获取失败时检查地址有效性和更新所用网络；解析失败时确认返回内容确实是订阅数据，而不是登录页或到期说明；解析成功但列表为空时检查过滤条件；列表有记录却看不到时检查搜索与分组。每一步的处理不同，直接反复点击更新通常不会提供更多信息。

手动导入的记录最好放入单独分组。订阅刷新可能重建该来源下的服务器集合，直接修改订阅记录的名称或连接参数，之后可能被来源数据覆盖。确实需要本地修订时，先复制到手动管理分组，并注明修改原因。复制只建立独立记录，不会让已过期的认证信息重新有效，也不能替代来源端的参数更新。

服务器列表恢复后，再检查活动服务器是否仍指向有效记录。订阅删除或替换了原记录时，旧选择可能不再适用；应重新选择并完成真实连接验证。更完整的失败分支见订阅更新失败自查步骤。分组整理完成后再进入路由配置，能把“选错服务器”和“规则走错出口”这两类问题分开。

03 路由规则与匹配顺序

路由规则决定进入内核的请求交给哪个出站处理，不负责把应用流量吸引到客户端。一个没有使用系统代理、也没有进入 TUN 的应用，不会因为添加了域名规则就开始遵守它。调整前先按第一章确认接管路径，再打开“设置”中的路由配置入口，复制现有方案用于试验，保留原方案以便随时切换。

先写目标，再写出口

规则可以按域名、目标地址、端口或入口等条件匹配。对同一条 Xray 字段规则，多个不同条件通常需要同时满足；同一列表里的多个域名则作为可选匹配项。若把域名和地址条件写进同一条规则，它不等于“满足任意一个就直连”。不确定组合语义时，拆成两条独立规则，更便于阅读日志和排查覆盖关系。

规则按顺序检查，先命中的规则先决定去向。因此局部例外应放在宽泛规则之前，兜底条件放在后面。比如明确的内部域名直连应先于覆盖全部域名的代理规则。新增一条规则后没有变化，先检查上方是否已经命中；不要立刻怀疑规则未保存。客户端界面排序也属于配置的一部分，导入后应重新核对。

理解域名策略的触发条件

domainStrategy 控制路由匹配过程中对域名进行地址解析的时机，不等于整个客户端的 DNS 总开关。AsIs 优先保留域名参与匹配；IPIfNonMatch 在域名规则没有匹配后尝试解析，再考虑地址规则；IPOnDemand 在匹配需要地址信息时触发解析。具体可用值应以当前内核支持范围为准，不能跨内核照搬。

下面是 Xray 配置中的局域网直连片段。它只展示 routing 字段，假设配置里已存在标签为 direct 的出站，并已加载相关规则数据。应合并到现有配置对应位置，而不是作为完整客户端配置导入。域名规则和地址规则分开写，方便区分域名命中与地址命中。

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

geosite:private 和 geoip:private 依赖内核可读取的规则数据，不能视作所有运行环境都自带的固定文本列表。日志若提示数据文件不存在，应检查客户端管理的规则资源是否可用。对于自己的特定内部域名，可使用明确域名规则；对于实际局域网网段，可写对应地址范围，避免把不相关的网络一并直连。

用精确规则验证，再扩大覆盖

域名写法会影响匹配范围。Xray 中 full:example.com 匹配完整域名，domain:example.com 可覆盖该域及其子域，正则匹配则需要额外理解表达式语义。不要为了匹配一个站点，直接使用可能碰到大量无关域名的关键词。初次验证可先选完整域名，确认出口正确后，再根据业务需要扩大到子域。

验证时应重新建立请求，并观察对应的出站标签。一个网页会访问多个域名，主页面直连不代表图片、登录接口和媒体资源也走同一路径。若页面只加载一部分，可逐项检查实际失败的目标，而不是把整个规则表切成单一出口。日志中出现地址而没有域名，还需检查应用是否先自行解析，以及是否有可用的域名识别信息。

路由调整结束后同时测试普通网页、局域网服务和一个需要代理的目标。测试含义也要分清：服务器的 Tcping 可达不代表规则或目标访问成功，具体区别见延迟测试结果解读。保留简单可解释的规则，通常比叠加多份互相覆盖的规则集合更容易维护。

04 DNS 解析路径与配置优化

DNS 的问题不是只选一个解析服务器就结束。浏览器、操作系统、代理内核和远端服务器都可能参与名称解析。首先问清楚“哪个组件正在解析哪个域名”。浏览器启用自己的加密 DNS 时，系统 DNS 设置未必影响它；通过代理传递域名时，本地可能不需要先取得目标地址。只有把解析位置和连接位置放在同一张路径图里，设置才有意义。

区分服务器域名与目标域名

代理服务器自身若使用域名，建立连接前必须获得它的地址，这一步不能依赖尚未建立的同一条代理通道。目标网站的域名则可以按配置交给本地内核或远端处理。常见循环是：DNS 请求要求走代理，而代理服务器域名又必须通过该 DNS 才能解析。遇到启动后所有请求停住，先检查这种先后依赖，而不是只延长超时。

在“设置”中找到 DNS 相关配置，先查看当前内核和可编辑字段。v2rayN 可能分别管理不同内核的 DNS 设置；名字相近不表示结构相同。使用内置模板时，先保留模板基本结构，只修改确实需要的上游和规则。完整覆盖成网上的一段 JSON，可能同时丢失客户端生成的本地监听、路由关联或 TUN 所需配置。

解析策略必须与网络条件一致

下面展示 Xray 内置 DNS 的字段片段，使用一个地址形式的上游，目的是说明 servers 和 queryStrategy 的位置。该上游能否直达，仍取决于本地网络；片段也不会自动把操作系统所有 DNS 请求转交给内核。实际使用时应结合自己的可信解析服务、网络要求和完整路由配置，而不是把示例当成通用最优设置。

{
  "dns": {
    "servers": ["1.1.1.1"],
    "queryStrategy": "UseIP"
  }
}

UseIP 允许获取两类地址；选择只查询某一地址族，会影响目标的可达路径。如果本地没有可用的相应网络，却优先得到无法使用的地址，可能表现为首次访问等待后才成功。反过来，强制只查另一类地址也可能让依赖特定网络的服务失效。先确认实际接口、默认路由和目标支持情况，再考虑缩小查询范围。

普通 DNS、加密 DNS 与代理传输是不同概念。加密解析保护解析传输过程，但不自动决定网站连接走哪个出口；把 DNS 地址写进列表，也不表示它一定随代理连接发送。若采用加密上游，还要考虑上游域名自身如何解析和连接。配置检查应同时看 DNS 上游、解析请求的出站路径和目标请求的出站路径。

内部域名与公共域名分开处理

企业或家庭内部域名可能只有本地解析服务器知道。若全部交给公共解析服务，它们可能返回不存在，或者得到与内网无关的结果。应为明确的内部后缀选择本地可达的解析路径，同时保留局域网直连规则。注意有些打印机或设备发现使用的是局域网名称发现机制，不能单纯靠修改公共 DNS 修复。

验证 DNS 更改时要考虑多层缓存。操作系统、浏览器和内核可能分别保留结果；关闭旧连接、重启相关应用后再测试，必要时使用系统提供的缓存清理功能。系统查询工具显示的结果只代表那次查询所经过的解析路径，不必然等于代理内核使用的结果。比较测试时，务必写清使用的是哪个查询入口。

所谓优化应有明确目标，例如让内部域名正确返回、减少无效的地址族尝试，或消除解析依赖循环。只凭一个网页打开更快就切换整套 DNS，容易把缓存差异误认成配置收益。每次改完保留相同应用、相同目标和相同接管方式，再检查日志中的解析错误是否确实消失。

05 TUN 模式与系统接管

TUN 通过虚拟网络接口接收系统网络包，适合需要接管不遵循系统代理的应用。它不是“连接更强”的按钮，也不会修复失效的服务器参数。启用前先完成系统代理下的基础验证，再记录当前网络接口、其他隧道软件和局域网访问情况。这样出现问题时，可以判断是原连接链路失败，还是新加入的系统接管层改变了流量路径。

权限与接口是第一道检查

在 v2rayN 主窗口找到“启用 Tun”控制项，先查看“设置”中的 TUN 相关参数，再按客户端提示启动。Windows 可能需要管理员权限或相应服务支持；macOS 与 Linux 也可能涉及系统授权及接口操作权限。不要把其他平台的驱动处理方法照搬过来。安装入口和平台说明见客户端下载页，具体依赖以所用构建提示为准。

开启后先查看日志是否显示接口成功建立、路由是否添加成功。若出现权限不足、接口创建失败或设备被占用，先处理启动阶段问题，再测网站。此时反复切换服务器意义不大，因为流量可能还没有进入内核。若接口建立成功却所有连接失败，再检查默认路由、DNS 和服务器地址是否能从正确接口发出。

避免多个接管器争用同一路径

其他虚拟专用网络、虚拟机网络、容器桥接和安全软件，都可能改变接口优先级或路由。排查时不要同时运行多套全局接管方案。先退出暂时不需要的接管器，再重新启用 TUN；若环境必须并存，应分别明确哪些目标属于哪条路由。只看任务栏图标不能判断是否退出，必要时在系统网络设置中确认接口和路由状态。

系统代理与 TUN 可以因配置需要同时存在，但初次测试最好只验证一种接管方式。否则浏览器先把请求送进本地代理，再由系统路由处理，观察到的路径会更难解释。也不要自行把本地代理端口设为另一层代理的上游，除非确实理解完整链路；错误的回送关系可能造成连接循环和资源占用。

局域网与名称解析一并验证

开启 TUN 后，应测试路由器管理页、局域网共享和内部业务域名。访问失败可能来自目标地址被错误送往代理，也可能是内部域名改由公共 DNS 解析。前者检查局域网地址规则和系统排除路由，后者回到 DNS 章节。不要把整个地址空间加入直连来修复单一设备；先确认真实子网和目标地址，保持例外范围可解释。

默认路由接管还需要避免代理连接绕回虚拟接口。客户端通常会生成相应保护规则，但多网卡、网络切换或自定义配置可能改变条件。若启用后服务器自身连接立刻超时，关闭 TUN 能恢复，应重点查看服务器目标的出口和真实网络接口。先回到客户端默认 TUN 设置验证，再逐项恢复自定义参数。

移动设备上的接管机制与桌面虚拟接口并不完全相同。v2rayNG 和 v2flyNG 使用 Android 系统的连接授权机制，其他同类接管应用可能占用同一位置；后台省电限制还可能使连接中断。分应用代理决定哪些应用进入接管范围，不等同于桌面路由规则。具体授权与后台设置可查安卓连接授权与分应用代理说明。

关闭后确认系统恢复

验证完成后，按正常顺序关闭 TUN 并观察接口、路由和解析状态是否恢复。若客户端异常退出后网络仍不正常，先重新启动客户端再正常停止接管，随后检查系统代理残留；必要时通过系统网络设置恢复原状态。不要直接删除无法辨认的接口或路由。切换无线网络、从休眠恢复后也应重测，因为真实接口变化可能使旧的接管状态失效。

TUN 的验收至少包括四项：原有网页仍可用，不遵循系统代理的目标应用能够连接，局域网访问符合预期，关闭接管后普通网络恢复。四项中任何一项失败，都应回退到已知可用基线，按接口、路由、DNS、出站逐层定位。保留这个顺序，比反复修改底层参数更容易找到可复现的原因。

06 FakeDNS 与域名映射

FakeDNS 在收到域名查询时，可以返回一段专用地址池中的合成地址，并保存域名与该地址的映射。应用随后连接这个地址，接管链路再据此找回域名。它的主要价值是让后续路由保留域名信息，不是给网站分配新的真实地址，也不是让原本不可达的服务器变得可达。真实连接最终仍要交给正确的出站处理。

映射必须在同一条链路里闭合

使用 FakeDNS 至少需要三个环节配合：查询确实进入合成地址服务、返回的地址被系统路由送回接管器、内核能够在连接处理中恢复对应域名。只打开其中一个开关可能导致应用拿到合成地址，却沿普通网络发出连接。排查时应检查完整链路，而不是只在查询结果里看到地址池范围就认为功能已经正常。

Xray 的 FakeDNS 与其他内核的合成地址机制有各自的配置结构。v2rayN 的 TUN 可能使用与当前代理连接不同的内核组件，不能根据主窗口服务器所选内核，推断 TUN 配置也采用同一种语法。先确认编辑的是哪一层配置，再查看客户端是否已有匹配的模板；能用受支持的界面选项时，优先让客户端生成配套字段。

理解地址池与容量字段

下面是 Xray 顶层 fakedns 字段片段，仅用于说明地址池和容量的写法。198.18.0.0/15 属于特殊用途范围，不是公共网站真实地址。片段本身没有配置 DNS 查询入口，也没有完成接管和域名恢复，不能单独作为可运行的客户端配置。合并前要确认自己的网络没有把该范围用于内部业务。

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

ipPool 指定可分配的地址范围，poolSize 控制映射池容量。增大容量不是通用提速方法，也不会改变远端带宽；它影响映射维护所需资源与可容纳的条目。若网络环境长期访问大量不同域名，应观察实际运行情况，而不是随意设成极大值。调整地址池还会影响已经被应用缓存的旧结果。

兼容性问题通常出在绕行与缓存

部分应用会自行使用加密 DNS，查询可能绕过 FakeDNS，随后直接连接真实地址。另一些应用会把解析结果交给不经过接管器的子进程，导致合成地址失去恢复机会。还有应用需要检查解析地址的类别，可能不接受特殊用途范围。此时应为相关应用或域名保留真实解析路径，并同时确认路由例外，而不是不断更换地址池。

内部域名通常应谨慎处理。如果某个域名用于访问本地设备，返回合成地址后又被送入不合适的代理出口，局域网访问就会失效。先确认内部名称是否需要真实地址、是否由本地 DNS 回答，再配置对应排除。合成地址排除、DNS 上游选择和局域网直连属于不同层次，不能只改其中一项就假定其余两项自动配套。

用对照测试判断是否需要保留

验证时先保持同一服务器、同一路由和同一应用，比较普通解析与 FakeDNS 两种状态。观察域名规则是否能够稳定命中、目标连接是否成功、局域网是否保持正常。不要只比较一次页面加载时间；缓存、连接复用和服务器负载都可能影响结果。若功能没有解决明确问题，却增加兼容性分支，保留普通解析通常更容易维护。

日志应关注域名能否恢复及出站选择是否符合预期，而不是只关注合成地址本身。映射信息可能属于运行状态，重启内核后不应假定旧映射仍存在。应用长时间保留旧结果时，就可能出现重启后才发生的连接失败；应先让应用重新解析，再判断是否需要改变配置。

普通 DNS、TUN 和路由都稳定后，才适合引入 FakeDNS。按这个顺序，若出现异常，只需回退新增的一层即可。若当前构建没有明确支持的设置入口，也没有完整的配套配置说明，不要把另一个内核的片段硬塞进模板。先保持可解释的真实解析链路，再依据明确需求决定是否继续试验。

07 多订阅管理与更新策略

多个订阅来源并存时，管理重点是来源可追溯、更新可控制、故障可隔离。不要把所有服务器复制进一个没有来源标记的分组；这样虽然列表看起来统一，更新失败后却难以确认哪些记录已经失效。建议每个来源独立分组，另设手动配置分组，备注只写用途与维护说明，订阅地址保留在专用字段中。

更新范围与更新路径分别设置

先确定需要更新当前分组还是全部分组，再选择客户端提供的更新方式。有的来源在直连环境下可获取，有的需要通过现有可用代理访问；这决定了更新请求本身的网络路径，不决定更新后服务器的默认路由。切换更新方式前，必须确认用于获取订阅的现有连接仍然有效，否则会形成“需要新服务器才能更新旧服务器”的循环。

如果主订阅失效，而更新又依赖主订阅中的活动服务器，应切换到已经验证可用的备用连接，或者按来源允许的方式直接获取。不要把尚未验证的记录当成恢复工具。至少保留一个可独立验证的回退方案，并记录它的来源和有效条件；回退方案的价值在于减少依赖，不在于堆积更多名称相似的服务器。

避免高频更新与重复导入

订阅更新不是连接重试按钮。来源未改变时，连续刷新通常只会重复获取同一批参数；还可能触发来源端的频率限制。自动更新间隔应结合来源说明和实际变更频率设置，手动更新则用于确认参数变化。若连接失败，先读错误类型：认证失效、远端超时和订阅获取失败是不同问题，不能用同一个刷新动作处理。

同一个来源被多次添加时，列表可能出现重复记录。清理前先确认分组地址是否相同、是否有不同用途的过滤条件，以及活动服务器属于哪一份。重复名称不必然表示完全相同，服务器地址、传输方式和认证参数也可能不同。不要只按显示名称批量删除；应先保留已知可用记录，再逐组整理。

为手工修订建立独立边界

订阅记录由来源维护，更新时可能覆盖本地改动。确实需要修订传输参数、服务器地址或显示备注时，先复制到手动分组，并注明修订对象。之后来源变更参数，手工副本未必同步；应定期对照来源说明检查。把手工副本与订阅记录分离，既防止修改被覆盖，也提醒维护者这条记录有额外的本地责任。

一次完整维护应有固定顺序：先备份当前设置，更新一个来源，检查记录是否合理，再验证活动服务器，最后处理其他分组。不要在更新全部来源后立刻批量去重、改过滤和切换路由。动作拆开后，即使某个来源返回异常内容，也能明确知道是哪一步引入变化，不会把整个服务器集合同时置于未知状态。

备用不等于自动切换

分组里存在多条记录，并不代表客户端会自动选出可用服务器。当前活动服务器、路由绑定的出口和可能存在的选择策略需要分别检查。某些测试结果只表示握手可达，不能证明真实目标访问成功；下载测速也只反映特定时间的吞吐。关于测试方式的边界，可结合Tcping 与真连接延迟说明阅读。

管理完成后留下简短维护记录：哪个分组更新成功、哪个暂缓、当前活动服务器是否重新验证、手工副本是否需要跟进。记录只写状态，不抄入敏感字段。这样下一次故障可以从上次已知状态继续，而不是再次整理整个列表。更新失败的分支处理仍按获取、解析、过滤、显示四步进行，不因订阅数量增加而改变。

08 自定义出站与配置回退

自定义出站适合图形界面现有选项无法表达、且维护者能够解释完整链路的情况。先明确目标：是为某类目标建立独立直连出口，还是需要更复杂的转发关系。若只是让一个域名直连，优先用路由编辑器，不必替换整份配置。自定义配置增加自由度，也把字段兼容、标签引用和更新维护交回给使用者。

先确认配置归属

v2rayN 中普通服务器记录通常由客户端生成运行配置，自定义配置则可能保留更多原始结构，两者不能假定具有完全相同的界面联动能力。使用“服务器”菜单里的自定义配置相关入口前，先确认要求导入完整文件还是引用现有文件，并选择匹配的内核类型。文件能够被导入，不表示所有字段都被当前内核接受。

编辑前复制已知可用文件，在副本中操作。Xray 与 V2Fly 存在共同概念，但具体字段及扩展能力应分别核对；其他内核的出站类型和路由结构也不能直接互换。最先检查顶层字段、入站监听和出站标签，再添加新功能。若一开始就覆盖客户端生成的入口，可能导致系统代理仍指向旧端口，表现为整个客户端不可用。

用最小片段理解标签引用

下面的 Xray 片段定义一个直连出站和一个拒绝出站，并让示例域名走拒绝出口。它只包含 outbounds 与 routing，不含本地监听，因此不是完整运行配置。合并时应保留现有代理出站和所需规则，并避免覆盖同名标签。示例用于说明引用关系，不要求实际阻断自己的业务域名。

{
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "reject",
      "protocol": "blackhole",
      "settings": {}
    }
  ],
  "routing": {
    "rules": [
      {
        "type": "field",
        "domain": ["full:example.com"],
        "outboundTag": "reject"
      }
    ]
  }
}

这里 outboundTag 必须与出站的 tag 完全一致。显示名称与标签是不同概念，大小写或拼写变化都可能破坏引用。未匹配规则的流量在常见 Xray 配置中会使用首个出站，因此调整数组顺序也可能改变默认行为。合并片段时不能只看新增规则，还要重新确认原有默认出口是否保持不变。

复杂转发先画依赖，再写配置

需要多层转发时，先用文字写清本地入口、第一跳、后续连接和最终目标之间的依赖。每个服务器域名由谁解析，每个连接通过哪条出站建立，都应能单独说明。不同内核实现链路转发的字段不同，不能仅凭“上游代理”几个字套用配置。若链路中任何一跳又依赖自身，就会出现递归连接或无法启动的问题。

配置文件先检查 JSON 语法，再检查内核语义。JSON 不允许注释和末尾多余逗号；字符串中的反斜杠和双引号要正确处理。语法通过后仍可能存在字段不受支持、标签不存在、规则数据缺失等错误。查看客户端日志中的首条有效错误，先修正启动失败原因，再处理后续连接信息，避免被重复错误淹没。

以可恢复作为验收条件

启动成功后，先测最小目标，再测原本可用的普通请求和局域网请求。日志需要能对应到预期出站，而不是只看到连接没有报错。若自定义方案替换了原配置，关闭系统代理或 TUN 后还应检查本地端口是否残留。恢复原方案必须有明确操作路径，不能依赖临时记忆中的几项开关。

后续更新客户端或更换内核时，应重新验证自定义字段和默认行为。先保留原可用方案，再在副本上迁移；不要在唯一配置上直接叠加新模板。若需求能够重新用图形路由、DNS 设置或分组管理表达，可以退回受客户端管理的方式，减少需要手工同步的内容。自定义配置应服务于明确需求，而不是成为维护目的。

本页的查阅顺序也就是排错顺序：先确认服务器与入口，再看路由和解析，最后检查 TUN、FakeDNS 及自定义链路。基础操作回到快速上手教程，常见现象查常见问题，客户端选择与安装查下载页。始终保留一个已验证状态，下一次调整才有可靠的比较对象。