V2Ray 进阶配置

订阅分组与服务器过滤

订阅分组用于维护来源和更新边界，服务器过滤用于缩小当前列表。两者都不会自动改变服务端协议，也不等同于路由分流。建议先按来源建组，再按用途筛选；不要把所有条目合并后依赖名称猜测来源。排查时必须能回答三个问题：条目来自哪个地址、最近一次更新是否成功、当前选中项是否仍属于该组。

建立能追溯来源的分组

在 v2rayN 的订阅分组设置中新增一组，填写简短别名与订阅地址，保存后对该组执行更新。先单独更新新组，不要立即更新全部来源。检查服务器列表是否出现条目，再打开一个条目的编辑界面核对地址、端口和传输类型。界面措辞随发行分支变化时，以“订阅”“分组”“更新”对应功能为准，不把某个按钮位置当作固定条件。

v2rayNG 与 v2flyNG 也应先建立订阅记录，再更新所选订阅。剪贴板导入单条分享链接通常只创建服务器条目，不会自动生成可持续更新的订阅关系。若希望后续更新跟随来源变化，应使用订阅地址入口，而不是把返回内容逐条粘贴进列表。详细操作可对照订阅链接导入步骤及格式说明。

分组名称应表达管理用途，例如“日常连接”“测试配置”“备用来源”。名称不是协议能力的依据；同组条目也可能采用不同协议和传输。订阅地址可能包含访问凭据，不应出现在截图、公开文档或共享日志中。记录来源时只保留可辨认的别名与必要备注，完整地址留在客户端内部，迁移时再通过受控方式处理。

先看完整列表，再逐层过滤

筛选前清除搜索框、地区条件和协议条件，确认完整列表确实存在。随后每次只增加一个条件，例如先按名称关键字，再按协议类型。名称搜索只检索文本，不能证明服务器地理位置或实际出口归属。若列表忽然为空，先恢复筛选条件，再检查订阅更新，不应把“被隐藏”直接判断成“来源失效”，更不应因此删除整个分组。

部分客户端或分支支持正则筛选，但普通搜索框未必按正则解释。只有界面明确提供正则模式时才使用表达式。下面的表达式用于匹配独立出现的三个用途标签，不是内核 JSON。使用前先对少量已有名称测试，确认大小写行为、分隔符和空白处理符合预期；缺少对应模式时，改用逐个关键字筛选，不强行粘贴。

(^|[\s_-])(work|daily|backup)([\s_-]|$)

排序与筛选也要区分。按测试结果排序只改变显示顺序，不一定改变当前活动服务器；测试通过也不代表全部目标都可访问。选择条目后，检查活动标记，再进行真实网页访问。不要只看列表最上方的一项就认定已经切换。对测试用途的条目保留独立分组，避免临时排序后误把不适用的配置设为日常连接。

处理更新覆盖与本地修改

订阅更新通常会按客户端策略重建或替换来源条目，本地改名、改端口或修改传输参数可能被覆盖。需要长期保留的手动配置应复制到独立的手动管理区域，并记录修改原因；不要只修改订阅条目后假定下次更新仍会保留。复制前确认复制的是完整连接参数，而不只是显示名称，避免得到缺少认证或传输字段的条目。

更新后条目减少时，先清除过滤并查看该组更新结果，再判断是否为来源撤回、格式不兼容或请求失败。保留仍可工作的当前连接，避免连续删除和重导入导致证据丢失。若返回内容为空或解析失败，按订阅更新失败自查步骤检查；修复后只更新故障组，验证成功再恢复全量管理。

路由规则实战

路由的任务是把已进入内核的连接交给指定出站，不负责让应用流量自动进入客户端。系统代理未生效时，添加再多域名规则也不会改变该应用的直连路径。排查路由前，先确认本地监听、应用代理和内核运行状态正常，再观察连接日志中的目标与出站标签。只有流量已经进入内核，规则命中结果才有讨论意义。

把精确规则放在宽泛规则之前

常见字段规则按顺序匹配，先命中的规则决定处理方向。规则内部不同条件通常需要同时满足，同一域名列表中的多个条目用于表达候选匹配。把少数明确例外放前面，把较大的域名集合放后面；不要先写覆盖全部流量的条件，再期待后面的例外生效。调整顺序后使用同一个目标重新建立连接，才能观察到差异。

域名条件中的 full: 用于完整域名匹配，domain: 用于域名及其子域范围，regexp: 用于正则。需求能用前两者表达时，不必使用正则。普通字符串可能比预期匹配更宽，容易把无关域名带入规则。IP 条件则用于地址或网段，不应在其中填写带协议头的网页地址；端口与网络类型也应按字段格式单独填写。

下面是路由片段，不是完整配置。它把精确测试域名交给名为 block 的出站，把环回及常用私有 IPv4 网段交给 direct。这两个标签必须在实际 outbounds 中存在。保留现有其他规则时，将本片段中的规则按需要插入数组，而不是用它直接替换整个路由配置。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["full:blocked.example"],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "ip": ["127.0.0.0/8", "10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16"],
        "outboundTag": "direct"
      }
    ]
  }
}

理解域名、地址与解析时机

AsIs 表示路由阶段不主动为域名执行额外的地址解析。若应用只提交 IP，域名规则可能没有可匹配的信息；若应用提交域名，IP 规则在此策略下也不一定获得解析地址。IPIfNonMatch 会在域名匹配未得到结果时尝试解析后再判断，IPOnDemand 则可能在遇到相关 IP 条件时触发解析。启用后应同时检查 DNS 路径。

嗅探可以从部分协议握手中提取域名，但不是任何连接都能提取。加密握手特性、非标准协议和纯地址访问都可能限制结果。不要把嗅探当作替代正确 DNS 配置的万能开关。客户端若提供“仅用于路由”一类选项，还要分清它是否只补充匹配信息，还是会改变后续连接目标；具体行为以所用内核字段为准。

用日志验证，而不是只看网页结果

验证规则时先关闭旧连接，再访问一个精确目标，查看日志中的入站标签、目标域名或地址、选中出站。浏览器连接复用可能使刷新继续使用旧通道，因此修改规则后应重新启动相关应用或建立全新连接。若规则未命中，先检查目标是否经过代理、域名形式是否一致、标签是否拼写正确，再逐步检查规则顺序和解析策略。

需要区分“规则命中但出站失败”和“规则没有命中”。前者应检查对应服务器与协议，后者才需要继续修改匹配条件。没有匹配规则时，常见配置会使用第一个出站，不能假定一定走代理或直连。客户端生成配置可能重排出站，因此应查看实际运行配置，而不是只记住界面上的服务器顺序。

使用地理域名或地址集合时，还需确认资源文件存在、格式与当前内核兼容，并了解集合自身的更新方式。资源缺失可能导致内核启动失败，而不是简单跳过一条规则。先用精确域名建立最小可验证规则，再引入较大的集合；出现问题时回退到前一份可运行配置，按连接后无法打开网页的排查顺序定位。

DNS 配置优化

DNS 配置首先解决“谁发起查询、查询发往哪里、结果用于哪一步”，而不是单纯选择一个解析地址。一次访问可能涉及系统解析器、浏览器安全 DNS、内核内置 DNS 和远端服务器解析。修改其中一处不会自动接管其他路径。先画清应用到解析器的实际链路，再决定是否需要内核解析、特定域名服务器或加密解析传输。

分开检查三类域名

第一类是代理服务器自身的域名，必须在连接建立前得到可用地址；第二类是用户访问的目标域名，可能由本地或远端解析；第三类是解析服务自身的域名，使用加密解析地址时还要完成引导解析。若把这三类域名都配置为依赖尚未建立的代理通道，容易产生循环依赖。应为连接的第一步保留明确、可达的解析路径。

下面的片段使用系统解析器，并允许查询 IPv4 与 IPv6 结果，适合作为理解字段的简化基线。localhost 表示调用系统解析能力，不等于内核在本机开放一个 DNS 服务端口。该片段也不会强制浏览器放弃自身的安全 DNS。它不是所有网络环境的优化答案，目的是让解析来源明确，随后再按需求细化。

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

UseIPv4 与 UseIPv6 可用于限制所需的地址族，但不应仅因某次访问慢就永久关闭一种地址族。先分别验证系统是否获得对应地址、路由是否可达、出站是否支持，再决定策略。解析返回 IPv6 地址不代表连接一定会使用 IPv6；最终选择还受应用、内核、出站配置与系统网络栈共同影响。

按失败阶段缩小范围

解析超时和连接超时是不同故障。前者可能表现为没有获得地址，后者则是在已经获得地址后无法完成连接。只通过网页加载失败无法区分这两种情况。应对照内核日志中的查询结果与后续拨号错误，必要时临时使用信息级别日志；避免长期输出过多细节，也不要公开包含目标域名或订阅地址的完整日志。

系统层可用 nslookup example.com 观察系统解析情况；它不代表查询经过内核内置 DNS。比较结果时，记录当前网络、时间与应用解析设置，避免把不同解析路径的差异误判成配置损坏。若系统解析正常而客户端仍失败，重点检查内核解析的传输路径、相关路由条件，以及代理服务器域名是否依赖同一条故障路径。

再考虑分域解析与缓存

内网域名通常依赖所在网络提供的解析器，统一改成公共解析可能让内部名称失效。为特定域名指定解析服务器时，应使用所用内核支持的域名匹配方式，并确认备用查询策略是否会把这些查询交给其他服务器。不同内核对回退字段和优先级的支持不完全相同，不应在 v2rayNG 与 v2flyNG 之间直接复制所有高级字段。

加密 DNS 可以改变查询传输方式，但仍需要解析服务可达、证书验证正常和系统时间准确。使用域名形式的服务地址时，先解决引导解析；使用地址形式时，也要确认所需的证书与服务器名称条件。不要同时更换解析地址、路由模式和 TUN 设置，否则成功或失败都难以归因。每一步完成后保留一个可恢复的配置副本。

缓存会让修改后的测试结果暂时沿用旧值。验证时可以重启相关应用与客户端，必要时按系统提供的方法清理解析缓存，不要反复修改服务器地址来“刷新”。网络从家庭切换到办公环境后，还要重新检查内网域名与接口相关设置。本章验证完成的标准是能够解释每类查询的来源与去向，而不只是某个网站偶然恢复访问。

TUN 模式与流量接管

TUN 模式通过虚拟网络接口接收网络层流量，适用于不读取系统代理设置的应用。它解决的是接管范围，不会自动修复错误的服务器参数，也不保证所有协议都由同一路径处理。启用前先验证普通代理模式可用，再检查权限、路由和 DNS；否则原有连接故障与接管故障叠加后，往往表现为整个系统无法访问网络。

先建立能恢复的基线

在桌面端优先用 v2rayN 完成一次系统代理连接，记录活动服务器、路由模式与 DNS 设置。停止其他正在接管流量的虚拟网卡或隧道工具，再启用客户端提供的 TUN 入口。某些实现需要管理员权限或辅助服务，也可能由独立组件承担接管工作；应以客户端当前提供的功能为准，不把界面中的 TUN 开关直接等同于某个内核顶层字段。

Android 上的 v2rayNG 与 v2flyNG 通常通过系统的 VPN 接口接管应用流量。首次启动时应阅读系统授权提示，确认授权对象是当前客户端。系统通常不允许多个此类接管服务同时生效，切换客户端时应先停止前一个。这里的系统接口名称描述的是接管机制，并不表示客户端已经拥有可连接的远端服务，服务器配置仍需单独准备。

检查权限、默认路由与回环

启用后先确认虚拟接口建立、内核持续运行、默认流量方向符合预期。若客户端一启动就不断重连，可能是代理服务器自身的连接被重新送回虚拟接口，形成回环。正确实现需要把自身出站流量排除或绑定到真实网络接口。不要用大量宽泛的直连规则掩盖问题，应先检查客户端的接口选择、自动路由与进程排除能力。

局域网访问应单独验证。打印机、共享目录和内部服务可能使用私有地址、链路本地地址或专用域名。将常用私有地址设为直连只是其中一部分，还需检查虚拟接口路由、名称解析与防火墙。若设备可以通过地址访问但名称失败，应返回 DNS 章节；若地址也不通，再检查接口路由和网段冲突，不必立即修改服务器协议。

把接管范围与传输能力分开

流量进入 TUN 后，是否能成功处理 UDP 仍取决于接管组件、所选协议、服务器端能力和路由规则。浏览器网页成功不代表实时通信或其他 UDP 应用也可用。应选择实际需要的应用做独立测试，查看其网络类型与错误记录。遇到不兼容情况时，先缩小接管范围或使用应用自身支持的代理入口，不要盲目切换所有参数。

MTU 调整应放在基础链路确认之后。若只有部分较大传输卡住，才结合网络环境考虑分片或路径 MTU 问题；没有统一适用于所有网络的固定值。每次只调整一档并复测相同目标，同时记录原始设置，失败立即恢复。若连最基本的域名解析和短连接都失败，优先处理权限、路由与 DNS，而不是先反复试验 MTU。

从睡眠恢复、切换无线网络或连接有线网络后，真实接口名称与网关可能变化。表现为启动时正常、切网后失效时，应停止并重新建立接管，观察自动接口选择是否更新。长期使用时记录触发条件，比重复导入订阅更有价值。订阅管理不负责维护系统路由，重新获取服务器列表通常不能解决接口已经失效的问题。

本章完成后应分别验证三类目标：普通网页、一个原本不读取系统代理的应用、一个实际需要的局域网服务。三者结果能够区分接管范围、远端传输和内网例外。只看系统显示服务已启动不足以证明接管正确；还需确认关闭客户端后网络能够恢复，避免把临时成功建立在未清理的旧路由之上。

FakeDNS 地址映射

FakeDNS 把域名映射为受控地址池中的合成地址，再在流量进入内核时还原域名。它用于保留域名语义与辅助路由，不是一个替代所有解析工作的公共 DNS 服务。真实连接最终仍需要可用的目标和出站。启用它之前，应先掌握 DNS 查询路径与 TUN 接管边界，否则容易出现应用拿到合成地址、连接却没有进入能够还原映射的内核。

理解查询与连接必须形成闭环

完整路径包含三个环节：应用查询交给提供 FakeDNS 的解析路径，获得合成地址后发起连接，该连接再由对应内核捕获并还原域名。缺少任何一环都会失败。仅在配置里添加地址池不会自动把系统查询送进去；仅开启 TUN 也不代表内核已经把所有 DNS 查询交给 FakeDNS。应分别验证查询来源、返回地址与连接入站。

以下为 Xray 风格的内核片段，展示地址池、解析服务器与 SOCKS 入站嗅探的关系，不是完整客户端配置，也不是跨内核通用模板。这里监听仅限本机；SOCKS 入站的嗅探只负责其接收到的连接，不会自动接管系统 DNS。将同类设置用于 TUN 时，需要使用客户端实际提供的接管与 DNS 配置入口，不能直接照搬这个入站。

{
  "fakedns": [
    {
      "ipPool": "198.18.0.0/15",
      "poolSize": 65535
    }
  ],
  "dns": {
    "servers": ["fakedns"]
  },
  "inbounds": [
    {
      "tag": "local-socks",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": true
      },
      "sniffing": {
        "enabled": true,
        "destOverride": ["fakedns"]
      }
    }
  ]
}

地址池不是服务器列表

ipPool 表示可用于合成映射的地址范围，poolSize 控制映射池容量。地址数量不是服务器数量，也不代表可用连接数。池内地址不应作为真实远端服务器地址保存到订阅或手动条目中。若网络本身使用了相同范围，可能产生冲突，启用前应检查现有路由与内部网络规划，而不是只确认配置文件语法通过。

上例中的范围用于基准测试等特定用途，不是可直接访问的公网目标。应用拿到它之后必须经过正确的还原路径。若日志显示客户端尝试把该范围直接发往真实网络，说明映射没有被消费或连接绕开了接管。此时增加普通代理规则通常不是根本修复，应先检查嗅探能力、入站位置与 DNS 返回值是否来自同一运行实例。

注意内核差异和应用行为

v2rayNG 与 v2flyNG 所用内核不同，FakeDNS 的字段支持、配置形态和联动方式应分别确认。不能仅凭两款客户端界面相似就复制整个自定义 JSON。v2rayN 也可能通过不同组件实现流量接管，必须先确认当前实际运行的内核和配置生成方式。需要理解分支背景时，可阅读Xray 与 V2Fly 内核关系说明。

应用若自行使用加密 DNS，可能绕过预设的系统查询路径，拿到真实地址而不是合成地址。另一些应用会直接使用缓存地址或固定 IP，因而没有域名映射可恢复。不要以某个浏览器成功就推断所有应用都经过 FakeDNS。应选取一个新域名建立测试，并结合查询日志与连接日志观察；需要时暂时统一测试应用的解析设置。

映射通常属于当前内核运行状态，重启后旧缓存中的合成地址未必仍能对应原域名。若重启客户端后只有部分应用失败，应先清理这些应用的解析缓存或重新启动应用，而不是重新获取订阅。退出 FakeDNS 时同样需要处理缓存，避免客户端停止后应用继续把合成地址当作真实目标。网络切换和休眠恢复后也应检查这一点。

域名还原成功后，路由才能根据域名条件做进一步选择；路由正确不意味着远端解析一定正确。若日志已经显示原始域名与预期出站，故障应继续向真实解析和连接阶段排查。建议先只对测试环境启用 FakeDNS，确认关闭后可以恢复普通解析，再扩大使用范围。没有明确域名保留需求时，保持现有正常解析通常更便于维护。

多订阅管理与更新策略

多订阅管理的核心是隔离更新风险和明确切换依据，而不是让列表尽可能长。每个来源都有自己的地址、格式、有效期与连接条件；一个来源更新失败，不应影响其他已工作的分组。管理时把来源、用途和当前活动项分别记录，避免把重复名称误认为同一服务器，也避免更新后仍依赖已经被撤回的旧条目。

按来源隔离，按用途选择

每个订阅地址建立独立分组，再用别名区分日常、测试与备用用途。不要把不同来源的原始地址拼接成一个地址，也不要把多个订阅返回内容直接粘到同一导入框后期待客户端自动维护来源关系。合并后的静态条目可能失去更新关联；即便当时可以连接，后续新增、撤回和参数变化也难以追踪。优先保持客户端原生的订阅记录。

重复名称不代表连接参数相同。判断重复项时至少比较协议、服务器地址、端口与传输设置，认证信息则应留在本地核对。不同来源可能使用相同别名，却指向不同服务；同一个地址也可能因认证或传输不同而形成不同条目。清理前先确认当前活动连接来自哪一组，保留可用基线，避免为了列表整洁误删唯一能够工作的配置。

分组不是故障自动切换器。把一组命名为“备用”不会让客户端在当前连接失败时自动使用它。自动选择、负载分配或探测属于另外的功能，是否存在以及如何生效要看客户端与内核。若没有明确配置这些机制，应把备用组视为手动切换资源，并记录选择入口与验证方法，不要依赖分组名称推断运行行为。

给更新建立固定顺序

新增来源时先独立更新一次，检查解析结果和一个代表条目，再安排日常更新。使用定时更新前，确认客户端在计划执行时是否仍在运行、网络是否可用、更新请求走哪条路径。不同客户端对更新请求是否使用当前代理的处理可能不同，应查找对应选项并实测。订阅更新成功与服务器连通性是两个指标，不应合并为一个结论。

更新失败时先看错误类型，再决定是否切换请求路径。连接超时可能与当前网络有关，认证失败或地址过期则需要检查来源状态，解析为空还可能是格式不兼容。避免短时间连续重试全部来源，这既增加排查噪声，也可能触发来源侧的请求限制。先只处理故障组，保持其他分组原状，并用最近一次成功更新的状态作对照。

服务器列表更新后，检查活动项是否仍存在、是否被重建、是否切换到默认项。有些客户端会尽量保留选择，有些操作可能改变当前条目；不能假定行为完全一致。确认活动标记后重新建立一次连接，再测试常用目标和必要的局域网访问。如果更新只改变了显示名称而实际连接参数未变，也应避免无意义地重做路由配置。

迁移时拆分管理数据与连接数据

跨设备迁移应分别检查订阅记录、手动条目、路由规则、DNS 设置和系统接管选项。导出一个服务器分享链接通常不包含分组更新计划，也不会携带系统代理或 TUN 的完整状态。迁移后先在普通代理模式验证连接，再逐项恢复高级设置；不要把另一台设备的接口名称、网段假设和权限状态一并照搬到新环境。

备份可能含订阅访问凭据、服务器认证信息和个人访问偏好，应放在受控存储中，不作为公开故障材料。需要共享排查信息时，只摘取错误类型、字段名称与已经去除敏感内容的局部片段。不要因为备份文件是文本就认为可以直接上传。恢复前先确认备份所属客户端与内核，避免导入后自动覆盖仍可工作的管理配置。

删除来源时先切换到另一个已验证的连接，停止该组的更新计划，再删除订阅记录与不再需要的条目。最后检查是否存在仍指向旧条目的客户端规则或自定义出站关联。列表清理结束后复测一次连接，确认不是沿用尚未断开的旧会话。这样才能让多订阅管理保持可追溯，而不是依赖历史缓存维持表面正常。

自定义出站与配置验证

出站定义连接如何离开内核，路由通过标签选择出站。服务器条目、出站对象和路由规则是关联关系，不是同一个对象。客户端通常会根据选中的服务器生成出站；如果改用完整自定义配置，界面中的服务器切换可能不再自动改变该配置。动手前必须确认当前入口接收的是完整 JSON、出站片段，还是客户端专用的规则格式。

先用不含远端认证的最小配置验证结构

下面是一份用于本机功能测试的完整基础配置，使用 V2Fly 与 Xray 常见的 SOCKS、直连和阻断结构。它不连接任何远端代理，只验证本地监听、标签引用和路由行为。端口被占用时需要先停止冲突服务或调整监听端口。不要把它作为订阅节点配置导入；应在支持完整内核配置的入口使用，并提前保存原有设置。

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "tag": "local-socks",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": true
      }
    }
  ],
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {}
    }
  ],
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["full:blocked.example"],
        "outboundTag": "block"
      }
    ]
  }
}

配置中的 direct 与 block 是自行约定的标签，不是仅凭名称就能生效的保留关键词。真正的行为由 protocol 决定；改标签时必须同步更新所有引用。此例未匹配连接会使用首个直连出站，精确测试域名则交给阻断出站。测试域名只用于观察规则，不提供实际站点内容。

按语法、语义、运行三个阶段检查

语法检查先确认双引号、逗号、数组与对象闭合，标准 JSON 不接受注释和末尾多余逗号。语义检查再确认字段属于当前内核、标签引用存在、端口和地址格式正确。最后才启动并观察运行结果。文件能够被 JSON 工具读取，只能证明语法成立，不能证明协议受支持、服务器可达或路由符合预期。

运行时先观察监听是否成功，再让一个测试应用使用本机 SOCKS 地址与对应端口。若需要域名规则，应用应把域名交给代理端处理；应用先在本地解析后只提交 IP 时，精确域名规则可能没有匹配条件。普通访问成功后，再尝试测试域名并观察阻断行为，确保看到的是当前内核处理结果，而不是应用绕过代理后的失败。

示例监听在环回地址，适合本机测试。将监听扩大到所有接口会改变访问边界，特别是没有认证的 SOCKS 服务可能被同一网络中的其他设备使用。确有共享需求时，应另外设计认证、防火墙和允许来源，而不是只把监听地址改成任意地址。客户端的“允许局域网”选项同样需要理解其开放范围，不能仅为排错临时打开后长期保留。

接入真实出站时保留回退路径

真实远端出站应从已经验证的服务器参数生成，再按当前内核支持的协议字段调整。不要混用 V2Fly 与 Xray 独有参数，也不要只复制协议名称而遗漏传输、安全层和服务器名称等关联设置。参数不完整时优先返回客户端的正常服务器编辑入口核对；需要选择内核时，结合客户端对比判断，不通过反复更换客户端掩盖参数缺失。

多出站配置应使用能表达用途的唯一标签，并为每条路由记录选择理由。需要链式转发时，还要确认内核实际支持的连接方式与字段，区分“先选一个出站”和“经另一出站拨号”。两者不是增加两个对象就会自动形成的关系。初次验证时只加入一个真实出站和一条精确规则，成功后再扩展，避免出现循环引用或难以追踪的默认路径。

客户端可能在启动、切换服务器或更新订阅时重新生成运行配置，直接编辑临时生成文件的改动可能丢失。长期设置应放在客户端明确支持的自定义入口，并确认重启后仍然生效。回退时恢复上一份配置，重新启动内核，再检查系统代理与 TUN 状态；不要只替换文件却继续使用旧进程，导致界面内容与实际运行状态不一致。