V2Ray 进阶配置手册

01 / 配置来源

订阅分组与服务器过滤怎么配？

先按来源分组，再按用途筛选服务器。分组解决“这些配置从哪里来、由谁更新”，过滤解决“当前列表需要显示哪些配置”，两者不应混用。v2rayN 的订阅分组通常保存订阅地址、更新选项及备注；服务器列表里的搜索或筛选则用于缩小视图。一个服务器暂时没有出现在列表中，不一定被删除，也可能只是当前分组或搜索条件把它隐藏了。

建立分组前需要记录什么？

先记录分组名称、来源说明和更新方式，再填写地址。名称宜表达来源与用途，例如“日常连接”与“备用测试”，不要只用容易混淆的连续数字。订阅地址往往包含访问凭据，应只粘贴到客户端的地址字段，不放进备注、截图或公共文档。首次保存后先手动更新一次，确认列表出现预期的协议与服务器名称，再考虑自动更新；空列表不应通过反复删除分组来处理。

在 v2rayN 中，可从订阅分组相关入口编辑分组并执行更新；在 v2rayNG 与 v2flyNG 中，先找到订阅设置或对应的分组管理入口。不同界面对“更新当前组”和“更新全部组”的命名可能不同，点击前应确认作用范围。若导入后只有一条服务器，先辨别链接是单条分享链接还是订阅地址，二者的外观都可能是一串较长文本，但更新行为并不相同。

过滤表达式为什么会误删结果？

先确认过滤功能的语义。有些字段只是列表搜索，有些会在更新订阅时筛掉条目；有些使用普通文本，有些支持正则表达式，还有些提供独立的包含与排除条件。不要把其他客户端的表达式直接粘贴过来。若字段明确支持正则，竖线表示“或”、圆点表示任意字符，名称里的括号也可能被解释为语法。先使用单个明确关键词，观察结果，再逐步增加条件。

排除条件应比包含条件更谨慎。若所有条目都被排除，客户端可能保留旧列表，也可能将该组更新为空，具体取决于实现。调整过滤前先备份现有配置，并记下当前使用服务器的名称与协议。过滤后先对照几个已知条目，不要仅凭列表变短就认为设置正确。名称属于可变信息，来源修改命名后，原本有效的关键词可能失效，因此过滤条件也需要定期检查。

更新成功但连接失败，下一步查哪里？

更新成功只说明订阅内容被获取并解析，不证明每条服务器都能建立连接。先查看当前激活项是否仍指向更新后的有效条目，再检查协议、传输、TLS 与认证字段是否完整。手工修改订阅条目可能在下一次更新时被覆盖；需要长期保留的调整，应复制成独立配置并标注来源。不要直接修改原始条目后忘记区别，否则稍后很难判断失败来自远端变化还是本地改动。

02 / 连接去向

路由规则怎么排序与验证？

把明确的例外放前面，把宽泛的兜底放后面。V2Ray 系内核的常见路由行为是按规则顺序检查，命中后选择对应出站；客户端生成配置时还可能插入自身规则，因此界面中看到的顺序需要与最终配置对照。规则能匹配到什么，取决于连接携带的是域名还是地址、是否启用嗅探，以及域名策略是否触发解析。仅仅添加一条域名规则，不代表所有连接都会携带可用域名。

域名、地址与出站标签分别是什么？

domain 描述域名匹配条件，ip 描述目标地址匹配条件，outboundTag 则引用已经存在的出站标签。标签是内部标识，不是界面上随意填写的备注。示例里的 direct、proxy 和 block 都必须在出站配置中存在。给一条规则同时填写域名和地址等不同类别条件，通常意味着这些条件需要共同满足；若本意是“域名或地址任一命中”，应拆成独立规则。

下面是常见 Xray/V2Ray 风格的路由片段，不能当作完整客户端配置导入。它假设所需的 geosite 与 geoip 数据可用，并已经定义对应出站。先拦截广告分类、再处理私有地址与中国域名，最后由客户端的默认出站处理其他连接。域名分类的内容取决于实际数据文件，不是一个永远固定的名单；遇到缺失分类错误，应检查数据支持，而不是继续重排规则。

{
  "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"
      }
    ]
  }
}

域名策略该怎么选择？

AsIs 表示路由阶段不为了地址规则主动解析域名；IPIfNonMatch 通常在域名未匹配到规则时再尝试解析，并利用结果继续匹配；IPOnDemand 则在匹配过程需要地址信息时触发解析。策略影响路由求值，不等同于整个系统的 DNS 工作方式。若只是希望特定域名直连，应先用明确域名规则解决，不必为了这一条需求让所有请求都提前进入地址匹配。

“国内网站也绕路”应先检查规则命中，而不是直接切成全直连。确认该域名是否包含在分类中，前面是否有更宽的代理规则，以及应用是否直接连接了缓存地址。若最终配置把默认出站设为代理，未命中的连接走代理属于预期行为。调试时可临时加入精确域名规则，用同一应用重新建立连接；已有长连接通常不会因为配置变化而自动迁移，刷新页面也可能复用旧连接。

如何避免规则越加越乱？

把规则按“本地资源、业务例外、分类规则、兜底策略”分层记录，并为每条例外写清用途。访问局域网设备时，私有地址直连通常比依赖设备域名分类更可靠；企业内部域名还可能需要专用 DNS，单独改出站并不能解决解析。不要把宽泛的全部端口或全部网络匹配提前放置，否则后面的细分规则没有机会生效。修改后分别测试一个明确直连目标、一个明确代理目标和一个局域网目标。

验证时记录目标域名、应用名称、命中的规则和出站标签，不要仅记录“能打开”。有些网站的页面与图片使用不同域名，主页面直连不代表所有资源都走同一出口。需要了解协议字段时，可接着阅读VMess 与 VLESS 的区别；路由选择与协议选择是两个独立层次。

03 / 名称解析

DNS 配置优化先改哪一层？

先画清查询路径，再选择解析器。应用可能使用系统 DNS、浏览器自己的加密 DNS，或经由代理协议把域名交给内核；内核又可能为路由判断和直连出站单独解析。因此，“客户端填了 DNS”不代表所有应用查询都会进入它。优化的第一步是确认谁发起查询、请求走哪个出口、返回结果由谁使用，而不是把多个公共解析器依次加入列表。

本地域名与远端域名为什么要分开？

局域网设备名和企业内部域名往往只有本地或单位提供的解析器能够回答；面向公网的域名则可能因解析器位置返回不同的内容分发地址。把内部域名全部交给公共解析器，可能得到不存在的结果；把所有公网查询固定在本地，也可能得到与代理出口位置不一致的地址。分流 DNS 的目标是让解析结果与后续访问路径匹配，而不是简单地规定某一种解析器始终优于另一种。

下面的片段展示按中国域名分类优先选择一个解析器、其他查询使用另一解析器的基础写法。它只说明 dns.servers 的结构，不保证查询已经按代理或直连发送；内核实现、查询协议及路由设置仍决定请求路径。不要把这段直接覆盖客户端的全部 DNS 配置，尤其在 TUN 环境下，还需要保留客户端为虚拟网卡和 DNS 接管生成的关联设置。

{
  "dns": {
    "servers": [
      {
        "address": "223.5.5.5",
        "domains": ["geosite:cn"]
      },
      "1.1.1.1"
    ]
  }
}

加密 DNS 为什么也可能无法连接？

使用 HTTPS 形式的解析地址，需要先连接解析服务本身；若该地址使用域名，还可能需要先解析这个域名，形成引导解析问题。若代理服务器地址也是域名，而查询又被要求必须经由尚未建立的代理，就会出现循环依赖。处理时先确保服务器域名和解析器域名有独立可达的解析路径，再配置其他域名的查询出口。不要用临时写死的服务器地址长期替代维护，远端地址可能变化。

域名策略与 DNS 服务器选择不要混为一谈。路由里的 domainStrategy 决定何时为了匹配而解析；直连出站也可能有自己的域名解析策略。即使路由使用 AsIs，最终直连一个域名时仍可能需要解析。反过来，路由已经得到地址，也不表示浏览器或其他应用不会另发查询。排查时应分开看“查询请求走向”和“业务连接走向”，不要凭单个解析测试网站下结论。

缓存与双栈环境怎样处理？

修改配置后应重新启动相关连接，并考虑系统、应用、内核各自的缓存。缓存未过期时，测试可能仍使用旧结果。双栈网络还要区分地址记录：只验证 IPv4 成功，不能证明 IPv6 访问也经过预期路径；只关闭某一层的 IPv6 查询，也未必阻止应用使用缓存地址。若网络确实支持双栈，应一起检查解析、路由和出口能力，而不是把关闭 IPv6 当作通用修复。

当 DNS 查询正常但网页仍失败，应回到路由和传输日志。服务器拒绝、TLS 参数不匹配或目标连接被重置，都不是更换解析器就能解决的问题。常见连接现象可在帮助中心继续对照。

04 / 系统接管

TUN 模式与系统代理怎么区分？

TUN 通过虚拟网络接口接收系统流量，系统代理则向支持该设置的应用提供代理地址。浏览器通常能够使用系统代理，某些终端工具、后台服务和自带网络栈的程序却不一定遵循。TUN 适合需要更广泛接管的场景，但会引入权限、路由、DNS 与虚拟网卡的额外关系。应先确认普通代理连接已经可用，再启用 TUN；否则基础连接与系统接管同时失败，排查范围会扩大。

启用前要检查哪些条件？

先保存可用配置，记录原来的系统代理状态，并确认当前客户端提供对应平台的 TUN 功能。v2rayN 在不同桌面平台上可能采用不同的辅助组件或运行方式，TUN 入口也不一定由当前服务器选用的同一内核直接实现；不要仅凭服务器协议判断虚拟网卡支持。启用时按客户端要求授予必要权限，若提示创建接口或修改路由失败，应先解决权限与组件问题，而不是继续调整订阅服务器。

Android 上的 v2rayNG 与 v2flyNG 通常通过系统 VPN 接口实现流量接管，授权弹窗属于系统流程。其他使用同一系统接口的网络工具可能与其互斥，应先停用冲突项再测试。桌面环境也应注意企业 VPN、虚拟机网络与安全软件，它们可能同时修改路由或 DNS。不要为了排查直接删除全部网卡；先停用相关软件，保留原始设置，观察客户端退出后网络能否自动恢复。

为什么启用后局域网设备打不开？

先检查局域网地址是否被接管，以及是否存在更具体的路由或绕过设置。打印机、文件共享与管理页面可能使用私有地址、内部域名或局域网发现协议，三者不是同一种流量。给私有地址设置直连，通常只能处理已经进入内核的普通连接；某些广播、组播和发现功能仍受系统接口及接管机制影响。应先用设备的明确地址测试，再处理名称解析与发现，不要一次增加大量域名例外。

服务器连接自身必须避免再次进入接管形成回环。客户端通常会通过绑定接口、路由排除或其他机制处理，但当默认网卡变化、同时启用另一条隧道或手工修改路由时，这些假设可能失效。若启动后日志不断重复连接同一服务器，或停用 TUN 后立即恢复，应优先检查出口接口与排除规则。不要把服务器地址加入普通业务代理规则来“加强接管”，这反而可能让问题更复杂。

UDP、MTU 与休眠恢复怎么排查？

网页可用而语音、游戏或其他 UDP 应用失败时，先确认所选协议、服务器与传输链路具备对应转发能力；TUN 能接收流量，不等于远端必然支持转发。若出现小请求正常、大内容卡住，再考虑路径 MTU 与分片问题。不要看到超时就随意降低 MTU，应先排除服务器与目标服务故障，再在客户端支持的范围内小幅调整，并保存原值以便恢复。

设备从休眠恢复或切换无线网络后，原接口与默认路由可能变化。此时先重新建立客户端连接，观察虚拟接口是否重新绑定，再检查系统 DNS 是否仍指向有效地址。若退出客户端后仍无法上网，应分别恢复系统代理、DNS 和路由状态，而不是只关闭窗口。浏览器与终端表现不同的情况，可参考系统代理分应用排查，先判断是应用适配问题还是系统接管问题。

05 / 域名映射

FakeDNS 在什么条件下有效？

FakeDNS 返回的是供内核识别的合成地址，不是目标网站的真实地址。应用拿到合成地址后发起连接，内核再把它还原为先前查询的域名，随后进行路由或远端连接。它的价值是保留“这个连接原来访问哪个域名”的信息，尤其适合域名在系统解析后容易丢失的接管场景。前提是查询和后续连接都进入同一套可关联的处理流程，只有一半被接管就可能直接失败。

为什么必须同时接住查询与连接？

如果查询由内核回答，业务连接却绕过内核，系统就会尝试直接访问一个并非真实服务器的地址。反过来，若应用使用自己的加密解析取得真实地址，连接虽然进入 TUN，FakeDNS 也未必有对应映射。先确认 DNS 请求进入哪个入口，再确认返回地址的流量由谁接收；不能仅凭“启用了 TUN”就认为映射链已经完整。不同客户端对 FakeDNS 的集成方式不同，某些接管方案使用另一种配置格式，应按实际组件判断。

下面是采用相关配置格式的 Xray/V2Ray 内核片段，仅展示合成地址池与 DNS 服务器选择。它还需要与受支持的入站、嗅探恢复及路由共同配置，不能单独粘贴后就认为功能已经启用。地址池应避免与实际使用的测试网络重叠；若环境已有同网段路由，应先处理冲突。使用图形客户端时，优先使用其提供的整套选项，避免只改一个字段而遗漏关联设置。

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

FakeDNS 与嗅探是不是一回事？

不是。FakeDNS 根据先前的查询记录恢复域名，嗅探则尝试从连接早期的数据中识别应用层目标信息，例如某些 HTTP 或 TLS 信息。嗅探不保证所有协议都能识别，也不能把任何地址自动还原为域名；FakeDNS 则依赖映射存在。部分内核通过嗅探配置中的特定选项衔接 FakeDNS，但这不改变两者的数据来源区别。开启前应阅读当前内核支持的字段，不能混用不同配置格式的选项名。

还要区分“只用于路由判断”和“重写实际连接目标”。有些嗅探设置仅把识别出的域名用于规则匹配，实际连接仍使用原地址；另一些设置可能让后续出站按域名重新解析。两种行为对内容分发、证书校验与特殊应用兼容性都有影响。若某个应用在开启嗅探后失败，应先关闭目标重写或使用客户端支持的排除规则进行对照，不要直接把所有域名规则删掉。

停止接管后为什么仍有应用连不上？

应用可能缓存了合成地址。FakeDNS 停用后，缓存中的地址仍会被用于新连接，但此时已经没有内核负责还原。应先关闭相关应用的连接并清理其解析缓存，必要时重新启动应用；系统缓存与内核映射也要一起考虑。若只清理系统缓存，浏览器自身仍保留旧结果，问题可能继续存在。切换配置时尽量不要让应用持续建立新连接，否则旧映射与新解析结果会交错出现。

兼容性验证应覆盖浏览器、需要局域网发现的应用，以及使用独立 DNS 的程序。若普通 DNS 已经能够保留域名并满足分流要求，不必为了选项更全而启用 FakeDNS。需要使用时先单独验证一个应用，确认查询、映射恢复与出站都符合预期，再扩大接管范围；出现异常就回到普通 DNS 配置，而不是同时叠加更多嗅探与重写设置。

06 / 更新维护

多个订阅怎样管理才不互相覆盖？

把远端维护的订阅与本地维护的配置分开。多个订阅可以提供不同来源或用途的服务器，但不会自动形成故障切换，也不会因为名称相似就共享参数。建议每个来源单独建组，本地修改另外保存，并在备注中说明用途。这样更新失败时可以只处理一个来源，删除旧订阅时也更容易看清影响范围。不要把所有地址和手工服务器长期混在同一组，尤其不要依赖显示顺序记忆当前使用项。

同名服务器与重复导入怎么处理？

先比较来源与关键连接参数，再判断是否重复。两个服务器名称相同，可能使用不同端口、协议或传输；同一条配置改了名称，也不一定是新的服务器。客户端去重逻辑可能按地址、协议字段或内部标识处理，不能假定“去重”一定保留手工修改。批量整理前先导出备份，挑选几个已知条目验证，再执行大范围清理。若只是列表难找，优先改进分组和筛选，而不是删除所有看似相似的条目。

跨设备迁移也需要保留管理关系。只导出单条分享链接，通常不会带走订阅更新设置、路由、DNS 与客户端偏好；导出完整配置又可能包含更多敏感信息。迁移前应明确希望转移的是服务器参数还是整个客户端环境。桌面与 Android 客户端并不保证共享同一套完整配置结构，最稳妥的做法是重新建立订阅，再按章节迁移规则，而不是将桌面内部配置直接当作移动端配置导入。

自动更新应在什么时候启用？

先手动更新并验证，再设置周期。更新频率应结合来源实际变化，不必为了保持“新”而频繁请求。设备休眠、网络切换或来源暂时不可达，都可能让定时更新失败。某些客户端只有运行期间才执行任务，因此设定周期不代表关机时仍能更新。也要辨别普通更新与经代理更新：前者可能直连获取，后者依赖当前连接可用；当订阅只有通过代理才能获取时，应保留一个已经验证的可用配置。

更新与切换当前服务器是两件事。来源移除当前条目后，客户端可能继续使用已加载配置直到重启，也可能在重载时提示无效。更新完成后检查当前激活项是否仍存在，再主动重新建立连接并验证。不要把自动选择某条服务器当作默认功能，除非确实配置了客户端支持的选择机制。界面排序、测试结果排序和当前激活状态彼此独立，排在第一行并不等于正在使用。

订阅获取失败要按什么顺序查？

先检查地址是否完整，再检查获取路径，最后检查格式。复制时漏掉查询参数、末尾多出空格、来源返回登录页面，都可能被显示为解析失败。先看错误属于连接超时、认证拒绝还是内容解析，再决定下一步。连接失败应检查网络和代理更新路径；认证拒绝应核对来源授权；内容解析失败则检查格式兼容性。不要把完整订阅地址粘贴到公共求助帖，错误信息也可能回显其中的凭据。

备份文件也应作为敏感资料保存。分享截图前遮住地址、认证字段和个人备注；完成迁移后再清理临时导出文件。若准备换装客户端，可从客户端下载页按平台选择，先验证新环境再移除旧环境。多订阅管理的目标是让来源、更新与本地改动可追溯，不是让列表尽可能长；能够清楚说明每个分组的用途，比保留大量重复配置更有价值。

07 / 配置组合

自定义出站怎样与路由衔接？

先定义出站，再用路由引用标签。出站描述连接怎样离开内核，路由描述哪些连接交给哪个出站。客户端中的“自定义配置”可能表示整份配置接管，而不是向现有配置追加片段；“自定义出站”也可能只允许编辑某个字段。操作前先确认编辑边界，否则粘贴一个出站对象可能被当作完整配置解析，或者覆盖客户端自动生成的本地监听与 DNS 设置。

标签与默认出站有哪些约束？

出站标签应唯一、稳定且易于识别。路由引用标签时要保持大小写和拼写一致，不能将服务器备注误当标签。常见 V2Ray/Xray 配置在没有规则命中时使用首个出站，但图形客户端可能重排或生成默认项，因此必须以最终运行配置为准。不要为了让某条业务走直连而随意改变全部出站顺序，应优先添加对应路由。这样修改范围明确，也更容易回退。

下面是基础出站片段，展示直连、阻断和连接本机 SOCKS 服务三种结构。它不是一份完整配置，只有当本机指定端口确实存在可用的 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": 1081
          }
        ]
      }
    }
  ]
}

链式连接为什么不等于多个订阅？

多个订阅只是多个配置来源；链式连接则要求某个出站的底层连接经由另一个出站或辅助服务。具体字段取决于运行内核及协议实现，不同内核的组合方式不能互换。即使界面允许选择前置代理，也要确认它作用于订阅获取、服务器连接还是业务流量，三者范围不同。先画出每一跳的目标地址与连接责任，再动配置，比只盯着“前置”名称更可靠。

每增加一跳都会增加依赖，故障时应从最外层可达性开始检查。先单独验证本机辅助服务，再验证它能否连接目标服务器，最后验证业务规则是否真正选中该出站。不要同时开启多个彼此指向的代理，尤其不要让系统代理、TUN 和本机 SOCKS 服务互相转发。出现日志快速重复或连接不断建立又中断时，应先排除回环，再检查认证和传输参数。

协议参数和传输参数可以分开复制吗？

应作为一组核对。地址、端口、认证、传输类型、TLS 名称和附加安全参数共同决定能否建立连接。只更换出站协议而保留旧传输参数，可能得到结构合法但无法工作的配置。REALITY 与相关流控字段也要与服务端一致，不能因为某项看起来更先进就自行开启。关于字段关系可阅读REALITY 与 XTLS Vision 原理说明，再回到当前内核确认支持范围。

如果客户端保存后自动恢复原值，可能是订阅更新、模板生成或界面重新写入配置所致。不要反复修改运行中的临时文件，应找到实际配置来源，或采用客户端支持的持久化自定义入口。完整自定义配置还可能绕过部分图形界面选项，界面显示开启不等于对应字段已经写入。最终应以运行日志、生成配置与实际连接结果三者共同判断。

08 / 验证闭环

配置修改后怎么验证与回退？

把“能够连接”拆成几个可观察阶段，才能判断修改是否正确。订阅能够更新、内核能够启动、服务器连接成功、DNS 返回结果、路由选中出站、应用访问完成，是不同的检查点。进阶配置应保留一份已经确认可用的基线，每次只改一类设置。若同时改协议、DNS、TUN 和规则，即使最终恢复连接，也很难知道哪个变量真正影响结果。

先建立一组固定测试目标

选择自己有权访问且行为明确的目标，分别覆盖直连、代理和局域网场景，并用同一个应用重复测试。不要仅使用一个综合检测网页，因为它可能由多个域名、缓存内容与第三方资源组成。记录目标、时间、当前服务器、模式及现象即可，不需要公开认证信息。若测试域名本身改变了内容分发地址，单次结果也不能代表规则长期有效，应结合日志查看实际命中。

测试前先结束旧连接。浏览器可能复用连接，后台应用可能维持长会话，路由保存后这些会话不会必然重建。必要时关闭相关应用再打开，而不是只刷新一次。对照测试应保持其他条件一致，例如同一网络、同一解析方式和同一目标。网络切换本身就会改变默认路由与 DNS，不能把切换网络后的变化全部归因于刚刚调整的客户端设置。

日志应该从哪一行看起？

先看启动阶段是否成功加载配置，再看目标连接附近的错误。字段不支持、标签不存在、数据文件缺失与端口占用属于启动或加载问题；连接拒绝、认证失败、解析超时则发生在后续阶段。没有任何目标相关日志时，应怀疑应用流量根本没有进入客户端，而不是先更换服务器。调高日志级别只用于短期定位，完成后恢复适当级别，避免长期积累包含访问目标的记录。

服务器超时应从本地条件逐步向远端排查。先确认系统时间、网络连通与订阅参数，再检查内核日志中的传输和安全设置；仅凭列表中的一次测试结果，不足以证明应用层可用。某些测试只建立到服务器的连接，不会完整访问业务目标。可对照节点超时排查顺序，将本地、链路和服务端问题分开记录，避免反复改动已经正确的规则。

怎样安排可执行的回退顺序？

先撤销最近一次配置修改，再重载客户端并重建连接；如果仍失败，关闭 TUN 或其他接管，恢复原来的系统代理与 DNS 状态。涉及 FakeDNS 时，还要处理应用与系统缓存，避免合成地址残留。回退不是把所有开关全部关闭，而是回到一组已经验证的状态。记录基线时应包含当前模式和默认出站，否则只恢复规则文件，仍可能因为模式不同得到另一个结果。

备份应区分客户端数据与可移植片段。完整数据便于同一环境恢复，规则和 DNS 片段便于理解差异，但两者都可能包含敏感内容。客户端升级或跨平台迁移前，先保留旧配置，再验证新环境对字段与数据分类的支持。不要把另一内核能加载的片段视为通用标准；遇到不支持字段，应查明对应功能是否有等价配置，而不是仅删除报错字段让内核勉强启动。

最终应能够回答三个问题：这次改了哪一层、哪些证据说明生效、失败时怎样恢复。能回答这三点，配置才具备可维护性。下一次遇到相似问题时，优先复用同一组测试与记录方式，而不是继续叠加临时规则。