v2rayN
进阶配置手册

订阅分组与服务器过滤

订阅分组解决来源归属，服务器过滤解决列表筛选。两者都不会自动改善服务端连接质量，也不会代替路由分流。先把一个订阅地址放入一个清晰命名的分组，更新后确认该组能显示服务器，再添加过滤条件。若同时新建分组、修改地址并启用正则，空列表出现时就难以判断究竟是哪一步出了问题。

建立分组，明确更新入口

在 v2rayN 的订阅分组设置中新增分组，填写便于识别的备注和订阅地址，保存后回到主窗口。先选中该分组，再执行更新订阅。地址应完整保留提供方给出的路径与查询参数，避免从聊天软件复制时夹带引号、换行或尾部句号。订阅地址通常含有访问凭据，不要把完整地址贴进截图、日志或公开讨论。

更新方式中的“通过代理”与“不通过代理”只控制获取订阅内容时的请求路径。它们不等于给更新出来的所有服务器指定路由。如果当前代理尚未连通，强制通过代理更新可能形成依赖循环：需要新配置才能连接，却又依赖连接才能获取配置。先尝试可达的更新路径，成功导入后再决定是否调整后续更新方式。

保存后先检查三项：分组备注是否正确、订阅地址是否仍完整、更新日志是否显示有效内容被解析。请求成功但列表没有变化，不一定是客户端故障；远端可能仍返回相同内容，也可能返回登录页面或说明文字。不要只看请求结束的提示，要同时观察解析结果和目标分组，必要时暂时关闭过滤后重新确认。

从简单关键字开始编写正则

“服务器过滤（正则）”通常围绕服务器备注做匹配，具体作用于导入还是列表展示，应以当前界面说明为准。先用一个确实存在的名称片段测试，再扩展为多个选项。不要一开始就写复杂的排除式表达式。正则中的竖线表示“或”，圆括号负责分组，方括号表示字符集合；这些符号都不是普通文本连接符。

香港|日本
^(香港|日本)
香港.*专线
\[备用\]

上面四行是独立示例，不要一起复制进同一个输入框。第一行匹配含任一关键字的备注；第二行要求备注从指定关键字开始；第三行要求两个片段按顺序出现；第四行匹配带方括号的文字。若提供方把名称写成其他缩写，这些表达式就可能没有结果。过滤条件必须以实际备注为依据，不能把地区名称当作跨订阅通用规范。

输入错误时先清空正则并保存，确认服务器重新出现，再逐段恢复。需要匹配点号、括号或加号时，注意这些字符具有特殊含义；例如字面点号通常应写成 \.。不同客户端构建采用的正则实现可能存在差异，尤其是环视、内联选项与复杂分组。保持表达式短、可解释，比依赖难以移植的高级语法更稳妥。

区分筛选失误与更新失败

筛选后看不到服务器，先切回“全部”或相应来源分组，清空搜索框，再检查分组过滤。主窗口搜索与订阅设置中的过滤可能叠加，单独修改一处并不一定能恢复显示。确认问题来自筛选后，再决定保留哪些条件。不要为了恢复列表反复删除整个分组，这可能同时丢失备注、更新方式及其他维护设置。

更新失败则按地址有效性、请求路径、响应内容、解析格式的顺序排查。如果同一地址在某条网络路径可获取，换另一条路径失败，优先检查连接与 DNS；如果获取到的是网页而不是订阅内容，应核对地址用途与授权状态。已经导入的服务器仍可使用时，先保留现有配置，不要把更新失败进一步扩大成全部连接不可用。

路由规则实战

路由的核心是顺序匹配：内核检查连接目标及可用元数据，命中规则后选择出站。规则越具体，通常越应该放在宽泛规则前面。配置前先确认当前启用的是哪个路由预设，以及客户端是否会在启动时重新生成内核配置。只修改临时生成文件，可能在切换服务器或重启内核后被覆盖，不能把这种修改当作持久设置。

先确定出站标签，再编写条件

下面示例采用 Xray 的 routing 对象格式，展示广告域名拦截、私有地址直连和指定域名集合直连。它假定完整配置已经定义名为 direct 与 block 的出站。客户端实际生成的标签若不同，必须同步修改；标签是精确引用，不是会自动识别含义的保留中文名称。不要把此对象直接粘贴到只接收规则数组的输入框。

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

同一条规则中的不同条件类型通常需要共同满足，而同一数组中的多个候选项用于择一匹配。例如同时写入 domain 和 port，表达的是特定域名并且端口符合条件，不是两个条件任意满足即可。若希望域名或某个地址段均可触发，应拆成两条规则。拆开后还要检查顺序，避免前面的宽泛条件提前接走连接。

没有规则命中的流量如何处理，取决于内核默认行为和客户端生成的完整配置；不能仅凭上述片段断定最终走代理。Xray 通常使用第一个出站处理未匹配流量，但图形客户端也可能插入兜底规则。检查最终配置中的出站顺序与末尾规则，再决定是否显式添加默认路径。配置审阅应包含开头和结尾，而不是只看新增的几行。

理解域名、IP 与规则库的关系

geosite 是域名分类，geoip 是地址分类。它们依赖内核能够读取对应数据文件及其中存在的分类名称。文件存在不代表所有来源都包含同样的集合，输入一个看似合理的分类名也不会自动创建它。出现集合加载失败时，先检查数据文件来源、存放位置与内核日志，不要靠反复切换服务器处理规则库错误。

domainStrategy 决定路由匹配是否为域名补充 IP 信息。AsIs 不会单纯为 IP 规则主动解析域名；IPIfNonMatch 在域名规则未匹配时尝试解析；IPOnDemand 遇到需要 IP 的匹配过程时可能发起解析。选择它们会改变查询时机和开销，并不直接指定连接必须使用哪一个 DNS 服务器。

应用若只向代理提交 IP，内核可能没有原始域名，域名规则就未必有匹配依据。嗅探在部分流量中可以补充域名，但不能恢复所有加密连接的信息，也不能保证每种协议都可识别。遇到“相同网站在不同应用中路径不同”，先看入站收到的是域名还是 IP，再检查嗅探与 DNS 链路，不要先扩大所有直连或代理范围。

用可解释的样本验证规则

验证时选一个明确写入规则的域名、一个私有地址目标和一个未命中目标，分别建立新连接。观察日志中的目标与出站标签，确认命中顺序符合预期。浏览器旧连接可能被复用，修改规则后继续刷新未必重新选路；先关闭相关连接或重启测试应用，再进行比较。规则加载成功与业务请求成功是两项不同结果，都要检查。

某条规则意外覆盖其他规则时，暂时移走最宽泛的匹配项，保留最小规则集合验证。端口、网络类型和进程规则也可能影响判断，尤其是客户端生成的规则与自定义规则并存时。更新数据文件的操作与分类写法可查阅geoip.dat 与 geosite.dat 路由数据库说明；更新前后应使用同一批样本复测。

DNS 配置优化

DNS 配置先回答三个问题：谁发出查询、查询送到哪里、结果交给谁使用。系统解析器、浏览器安全 DNS、客户端内置 DNS 和内核用于路由判断的解析过程可能同时存在。只在客户端填入一个服务器地址，不能保证全部应用都按这条路径解析。优化的目标是路径一致、结果可用和故障可解释，而不是把可填写的选项全部启用。

区分解析服务器与查询出站

下面是 Xray 的 dns 对象片段，用于说明服务器列表和查询类型。queryStrategy 控制该内置 DNS 查询所需的地址类型，不代表关闭整个系统的 IPv6。示例中的加密解析端点也只是一个可测试选项；应确认当前网络能够访问，再决定是否采用。此片段没有包含 DNS 流量路由，不能据此推断请求必然经过代理。

{
  "dns": {
    "servers": [
      "https://1.1.1.1/dns-query"
    ],
    "queryStrategy": "UseIP"
  }
}

指定 DNS 服务器地址与指定查询出口是两件事。部分内核的加密 DNS 请求可参与内部路由，另一些服务器形式可能直接使用本地连接。客户端还可能在界面中提供直连 DNS、远程 DNS 或独立出站选项。这些名称反映客户端封装，不应机械地对应到另一个内核的字段。先确定使用的内核，再按相应文档解释最终配置。

使用域名形式的加密 DNS 端点时，还存在引导解析：连接解析服务之前，系统先要知道该服务的地址。若引导解析本身依赖尚未建立的代理，就可能出现循环依赖。固定服务地址、明确的引导路径或客户端提供的启动解析机制都可以用于解决，但应选择一种可解释方案，不要并列增加多个不清楚用途的服务器。

按连接路径安排解析策略

直连目标通常应获得当前网络可达的地址，代理目标的解析也应与代理连接行为协调。部分协议会把域名交给服务端解析，此时本地 DNS 可能只为规则判断提供信息；另一些链路会先在本地解析再连接地址。若路由判断使用一组结果，真正连接使用另一组结果，就可能出现分流预期与实际访问不一致，需要同时检查域名保留方式。

遇到 IPv6 相关问题，先确认网络是否拥有可用的 IPv6 路径，再决定地址偏好。解析返回 AAAA 记录本身不代表错误；应用选中一个不可达地址，才会表现为等待或回退。临时仅查询 IPv4 可以作为对照实验，但不能当作所有网络的永久答案。还要检查代理服务端、直连出口和 TUN 是否对 IPv6 使用了相互一致的策略。

浏览器启用自身的安全 DNS 后，可能绕过系统常规解析设置；应用通过已建立的加密连接查询时，也不一定表现为普通 DNS 端口流量。排错时先记录这些设置，再临时统一解析入口。确认客户端路径正常后，逐个恢复应用设置并比较变化。不要同时清空所有系统网络配置，否则即使恢复访问，也难以知道真正起作用的改变。

按“能解析、能连接、选路正确”验证

先在日志中确认查询是否到达预期解析器，再检查是否返回可用地址，最后验证连接是否走目标出站。命令行的系统解析结果只能说明系统这一层，不能代表浏览器内部解析或内核内部 DNS。诊断记录至少应注明测试应用、目标域名、代理模式和测试时间，避免把不同路径下得到的地址放在一起比较。

更换 DNS 后，旧缓存和连接池可能继续保留结果。先关闭测试应用并清理相应缓存，必要时重启客户端内核，然后使用相同目标重新测试。若仅某个域名失败，优先检查域名规则与解析响应；若全部域名失败但 IP 连接可达，再检查解析器可达性和引导路径。普通连接尚未稳定时，不宜继续叠加 FakeDNS。

TUN 模式

TUN 通过虚拟网络接口接收被系统路由引导过来的 IP 流量，再由客户端关联的组件处理。它与系统代理不同：系统代理依赖应用遵守代理设置，TUN 则工作在更靠近网络层的位置。不过，是否接管某条连接仍由路由、排除项、地址族和运行权限共同决定。“启用 Tun”开关亮起，只表示尝试启用功能，不等于每条流量都已按预期处理。

先建立普通连接，再扩大接管范围

启用前先关闭 TUN，通过普通系统代理完成一次正常访问，确认所选服务器和基础协议参数可用。然后记录当前路由预设、系统 DNS 和其他网络工具状态。桌面客户端可能为 TUN 使用独立组件或不同配置结构，不能因为主连接使用 Xray，就把 Xray 的路由字段直接填到另一个组件的 TUN 设置里。以客户端界面支持的字段为起点。

首次开启时，按系统提示完成必要权限授权，等待虚拟接口和路由安装完成，再启动测试应用。不要连续快速切换开关；启动失败后立即再次开启，可能让旧进程或接口状态干扰判断。先查看启动日志中是否有权限不足、接口创建失败或地址冲突，再决定重试。涉及驱动或系统服务时，退出界面不一定代表后台组件已经停止。

避免回环，保留局域网访问

接管系统流量时，客户端连接代理服务器的那条外层连接必须能够正确到达网络，不能再次被自己的接管规则无限送回。客户端通常会处理服务器地址绕行、进程排除或接口绑定，但自定义路由和多层代理可能破坏这些保护。表现为开启 TUN 后所有连接突然停止时，先检查外层连接是否形成回环，再看节点参数是否真的发生改变。

局域网服务需要单独验证。打印机、路由器管理页和本地开发服务可能使用私有地址，也可能先通过局域网名称解析获得地址。仅添加私有地址直连，未必能解决本地名称发现问题；还要看相关查询、广播或组播是否被当前实现接管。不要为了访问一台局域网设备，就把全部网段宽泛排除，应优先使用实际需要的范围。

“允许来自局域网的连接”与 TUN 也不是同一个开关。前者通常影响代理监听地址和其他设备能否接入本机端口，后者影响本机流量接管。没有让其他设备使用本机代理的需求时，不必额外扩大监听范围。确有需求时，还应检查防火墙、认证选项与可信网络边界，避免将代理端口暴露到不必要的网络接口。

UDP 能否正常使用，要同时满足应用流量进入接管范围、客户端相关组件支持、所选协议和服务端路径支持等条件。某项实时通信失败不能只归因于 DNS；也可能是 UDP 转发、目标端口或路径限制。先用普通网页连接确认基本链路，再选实际使用的应用验证 UDP，不要用一个只测试 TCP 的成功结果替代全部验证。

识别冲突并按层恢复

其他 VPN、虚拟机网络、容器网络和企业网络工具可能同时写入路由或 DNS。排查时一次只保留一套接管工具，先停止其他接管功能，而不是直接卸载软件。观察问题是否随某个接口启停而出现，并记录接口和网段关系。睡眠唤醒、切换无线网络或接入有线网络后失效，通常还需要检查出口接口是否被正确重新选择。

恢复顺序是先关闭 TUN，再确认后台组件退出，然后检查系统代理、DNS 和默认路由是否回到预期状态。如果普通网络仍异常，再按系统网络设置恢复已记录的原值。不要把重置全部网络当作第一步。macOS 的权限问题可参考安装放行与网络授权步骤；Android 后台中断则应另查应用省电策略。

FakeDNS

FakeDNS 用合成地址代替真实解析结果，并保存“合成地址到域名”的映射。当应用向合成地址发起连接时，内核利用映射找回域名，再进行路由或代理处理。它的价值是保留域名关联和减少某些预先解析步骤，不是提供一个可以在公共网络直接访问的真实服务器地址。理解这一点，才能判断为什么绕过接管后连接会立即失败。

先确认 DNS 与连接由同一链路处理

使用 FakeDNS 的前提是发出合成响应的组件和接收后续连接的组件能够共享映射。如果 DNS 被一个组件接管，连接却交给另一个不了解映射的组件，就只剩无法访问的合成地址。桌面客户端可能为不同模式使用不同内核，切换前应检查具体实现。不要因为两处设置都叫 FakeDNS，就认为配置格式和映射生命周期完全相同。

下面片段展示 Xray 的相关字段：建立一个地址池，指定内置 DNS 使用 FakeDNS，并在指定入站启用对应嗅探覆盖。三个部分应分别合并到完整配置的同名层级；入站对象中的片段尤其不能替换整个入站，因为监听地址、端口和协议等原有字段仍须保留。只有相关配置链路接通后，这些字段才会共同发挥作用。

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

对应入站的嗅探设置示例：

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

ipPool 指定合成地址池，poolSize 限制映射容量。示例地址段用于测试用途，不应被当作普通公网目标直连。设置前检查虚拟机、实验网络或企业内部网络是否已经使用同一范围。若发生冲突，需要按所用内核支持的范围规划另一套方案，并同步检查接管路由，不能只改地址池字符串就结束。

处理缓存、映射丢失与应用兼容

映射通常依赖运行中的内核状态。内核重启后，应用可能仍缓存旧合成地址，而新实例尚不知道该地址原本对应哪个域名。表现是刚重启后部分应用失败，清理缓存后恢复。启用或关闭 FakeDNS 时，应同时考虑系统解析缓存、浏览器缓存和长连接，按顺序重启相关测试应用，避免把缓存遗留误判为规则错误。

部分应用会自行验证地址类型、保存解析结果，或把地址传给另一个进程使用。合成地址在这些流程中可能触发不兼容。局域网名称、设备发现和某些直接使用 IP 的业务，也未必适合全部纳入 FakeDNS。遇到单个应用异常，先用真实解析做对照，再考虑按域名或应用排除；排除位置与语法应以实际 DNS 组件为准。

如果某条规则将合成地址段直接排除到系统网络，连接可能在还原域名前就离开接管链路。反过来，只为合成地址添加“代理”规则也不一定正确，因为内核可能已经在匹配前恢复原始域名。检查日志中的最终目标信息，理解当前实现先还原还是先匹配，再调整规则。不能将真实地址分流经验原样套到合成地址上。

用开关对照确认收益与边界

建立对照时保持服务器、路由预设和测试应用不变，仅切换 FakeDNS。先确认目标域名获得的是合成地址，再观察后续连接是否恢复为域名，以及最终出站是否符合规则。若看不到合成结果，可能是应用绕过了该 DNS；若有合成结果却无法连接，则重点检查接管范围、映射和入站还原能力，而不是继续更换解析服务器。

关闭时先让应用停止建立新连接，再关闭相关功能并清理旧缓存，最后恢复真实解析测试。FakeDNS 并不是每套配置的必选项；普通 DNS 与路由已经满足需求时，可以保持现状。只有明确需要域名关联、且能够维护完整接管链路时再引入。遇到难以解释的故障，回退到真实解析往往是最有价值的第一组对照实验。

多订阅管理

多订阅管理的重点不是把所有来源放进一个列表，而是保留来源、更新路径和使用目的之间的对应关系。建议按来源建立独立分组，再用备注说明用途。工作环境、家庭环境或测试用途可以形成自己的命名约定，但不要把密码、账号或完整订阅地址写进名称。分组备注应让配置在一段时间后仍容易理解，而不是只在导入当天看得懂。

建立来源记录与更新节奏

每个分组至少记录来源用途、更新方式和过滤条件，记录保存在自己的设备即可。自动更新间隔应服从实际需要与提供方限制，不要为了让列表“看起来新”而频繁请求。订阅内容不会因为请求次数增加而自动改善，反复刷新还可能遇到限流。出现更新失败时，先保留上次可用配置，再调查该分组的问题，不要同步修改全部来源。

首次整理时按分组逐个更新，确认每个来源都能独立获取和解析，再考虑批量更新。这样可以辨认哪一条地址失效，哪一组需要改变请求路径。若批量任务中只有部分失败，先检查失败组的响应与授权状态，而不是立即改变全局 DNS 或代理模式。全局修改会影响原本正常的分组，并使失败范围进一步扩大。

同一来源可能提供多个格式入口，不能单凭地址外观看出内容是否相同。选用与客户端兼容的入口，保留必要的参数；不要把网页控制台地址和订阅地址混淆。若地址需要登录或已经过期，客户端无法靠重试修复授权。此时应通过原提供方的正常管理界面重新取得有效入口，而不是在客户端里拼接猜测的路径。

区分重复名称、重复配置与当前选择

服务器备注不是唯一身份。两个来源可能使用相同备注，却连接不同服务器；同一服务器也可能因为备注变化而看起来像新增项目。判断重复时应在本地比较实际协议、地址、端口和身份参数，避免只按名称删除。客户端的去重实现可能有自己的判断标准，执行前先确认作用范围，必要时导出当前设置，给误删保留恢复路径。

订阅更新可能替换服务器对象，也可能改变排序和备注。当前选中项是否保持，取决于客户端如何关联新旧配置，不能假定永远不变。每次大幅更新后，先检查当前分组和所选服务器，再恢复日常使用。如果原项目已从远端移除，应重新选择一个实际可用的项目，不要依赖列表位置相同就认为连接目标没有改变。

订阅内项目一般由提供方维护，手动修改其中的字段可能在下次更新时被覆盖。需要长期保留的自定义配置，应放在明确独立的手动分组，并记录为何修改。不要把同一服务器在多个分组中复制多份却不标明用途，否则排查时容易改错对象。确认配置来源，比把备注写得很复杂更重要。

迁移、备份与隐私边界

迁移到另一台设备前，先确认要迁移的是客户端设置、订阅来源还是单个服务器配置。不同导出方式包含的信息不同，二维码和分享链接也可能携带完整连接身份。只通过可信渠道传输，完成后清理不必要的临时副本。公开求助时用经过删减的设置说明替代完整导出文件，日志中出现的订阅路径和查询参数同样需要处理。

桌面 v2rayN 与 Android 的 v2rayNG、v2flyNG 可以导入兼容的订阅内容，但图形界面的分组设置、路由预设和应用范围不会必然随订阅迁移。尤其是自定义路由与 DNS，应在新设备上按其内核重新配置并验证。安装包选择见客户端安装包页面，不要仅按旧设备文件名判断新设备的架构。

Android 后台断连还可能来自省电限制，而不是多订阅冲突。先确认前台运行时能正常连接，再检查 VPN 授权、分应用范围和后台限制，相关步骤见v2rayNG 分应用代理与省电白名单。长期维护时定期删除确认失效的来源，保留有用记录，让列表规模与实际需求保持一致。

自定义出站

自定义出站用于表达客户端常规界面之外的连接路径，例如把指定目标交给本机另一个代理监听端口。它涉及出站协议、标签引用、监听可达性和防回环，不只是新增一条规则。先画清“应用进入哪个入站、规则选中哪个标签、该标签连接哪里”，再编辑配置。尚未理解普通代理路径时，不建议直接叠加多个自定义转发层。

以本地 SOCKS 出站建立最小示例

下面是 Xray 格式的三个出站对象，分别表示直连、阻断以及连接本机 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": 1080
        }
      ]
    }
  }
]

此示例没有设置认证，仅适用于目标监听本身按预期允许连接的情况。实际服务若需要认证，应使用该内核支持的用户字段，并将真实身份信息只保留在本地。不要为了省去配置步骤而扩大监听范围或关闭已有认证。回环地址指向运行内核的同一网络环境；如果内核运行在容器或隔离环境里，它未必指向宿主机上的服务。

准备好出站后，再添加一条最具体的测试规则。下面使用保留示例域名说明标签引用，不要求该域名提供实际业务。实际验证时换成自己明确需要测试的目标，并保留规则在合适位置。outboundTag 必须与出站的 tag 完全一致，大小写、连字符和拼写都不能随意变化。

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

理解转交与链式代理的区别

把业务连接交给本地 SOCKS 服务，表示由那个服务继续处理后续连接，不等于所有代理服务器之间已经按指定顺序串联。真正的链式代理还需要明确外层连接如何拨号、域名在哪里解析以及每一层如何认证。不同内核的链式字段并不通用，不能将 sing-box 的字段名直接搬进 Xray 配置，也不要凭名称相近推断行为相同。

最危险的错误是让两套代理相互指向：客户端甲把请求交给乙，乙的上游又回到甲，或者 TUN 把本地代理的外层连接再次接回原入站。排查时从最终出口反向追踪，确保每一跳都能到达下一跳，且存在明确的终点。先关闭 TUN，用单一应用代理验证自定义出站，再逐步恢复系统级接管，可以明显缩小问题范围。

多个出站还会放大 DNS 与 UDP 的差异。某个本地 SOCKS 服务能够处理 TCP，不代表它也支持所需的 UDP 转发；域名由前一层解析还是交给后一层，也会影响规则和可达性。测试时分别检查域名目标、地址目标和实际应用协议，不要把“端口可以建立连接”当作整个链路已经完成验证。

持久保存、检查与回退

优先使用客户端提供的自定义配置、出站或路由编辑入口。某些入口接收完整配置，另一些只接收对象片段，粘贴前先检查界面说明与现有结构。JSON 的对象、数组和字符串必须保持合法，不能添加注释或尾随逗号。标签重复、引用不存在的标签，以及把数组放进对象字段，都可能导致启动失败或产生难以观察的覆盖行为。

保存后先观察内核是否成功加载，再建立一条全新连接，确认日志中的出站标签与目标监听一致。若加载失败，先恢复改动前的配置，不要同时更换服务器或更新订阅。若加载成功但连接被拒绝，检查本地服务是否启动、监听地址是否正确及端口是否一致；若连接建立后仍失败，再沿下一跳检查协议、认证与解析。

形成可维护方案后，记录用途、依赖服务、监听端口和回退步骤，避免下次启动时忘记先运行上游服务。关于内核与客户端的关系，可继续阅读Project V、V2Fly 与 Xray 生态说明；遇到跨章节问题，可到常见问题按现象查找。始终保留普通系统代理可用的基线，自定义出站故障时先回到这条最短路径。