V2Ray 配置进阶手册

一、订阅分组与服务器过滤

订阅是服务器配置的更新来源，分组则是客户端对这些来源及其条目的组织方式。两者应当分开理解：服务器列表里显示了一个分组，不代表该组已经被路由规则引用；切换到某个分组查看，也不等于正在使用其中的服务器。开始整理前，先确认当前选中服务器、所属订阅和正在使用的路由模式，记录一条已经能够连接的配置，避免整理列表时失去排错参照。

按来源建组，再按用途筛选

在 v2rayN 的订阅分组设置中，为每个来源填写可识别的备注，再录入对应地址。建议备注描述来源或用途，例如“日常连接”“测试环境”，而不是把临时服务器名称当作长期组名。保存之后，对指定分组执行更新，检查新条目是否进入预期位置。手动导入的链接尽量单独归组，否则后续清理订阅条目时，容易把需要保留的手动配置一起删除。

订阅地址通常包含访问凭据，应按敏感信息处理。不要把完整地址放进截图、公开问题描述或共享文档，也不要把不同来源的地址相互替换来测试。更新失败时，先看失败发生在下载订阅内容，还是解析内容的阶段：前者可能涉及网络、证书或授权，后者可能涉及订阅格式与客户端兼容性。分组名称只用于本地辨认，修改备注不能修复地址失效。

区分列表搜索与持久过滤

服务器列表上的搜索框通常只影响当前显示结果，订阅分组中的过滤设置则可能影响更新后保留或展示哪些服务器。操作前应阅读字段提示，确认筛选作用于服务器备注、地址还是其他属性。先使用一个确定存在的短关键词测试，核对结果后再增加条件。不要直接将通用正则表达式填入只接受普通关键词的输入框，也不要假定所有客户端都采用相同的匹配方式。

若某个字段明确支持正则表达式，可以用 (?i)(test|backup) 表达不区分大小写的候选关键词，但是否支持这种写法取决于该字段使用的正则引擎；不支持时应使用界面提供的普通文本筛选。包含条件与排除条件需要分别验证，尤其留意空格、全角符号和备注中的特殊字符。条件过宽会留下无关条目，条件过窄则会造成“更新成功但列表为空”。

更新后检查配置身份

订阅更新可能新增、删除或重命名服务器，同名条目也不一定代表完全相同的连接参数。更新后不仅要看备注，还应核对协议、服务器地址、端口和传输方式。对于需要固定使用的条目，应确认客户端在更新后如何保存选择；若旧条目消失，不能仅凭列表仍有高亮就认定已成功切到替代配置。重新选择目标服务器，并通过一次新建连接确认实际行为。

遇到条目重复，先判断是同一来源重复提供，还是多个分组各自包含同一服务器。删除重复项之前保留原始订阅关系，避免下次更新又重新生成，或者误删具有不同传输参数的条目。Android 端的分组与筛选入口可能不同，但处理原则一致：先限制到一个来源，再检查条目内容，最后测试连接。只根据名称相似程度批量删除，往往会掩盖真正的配置差异。

二、路由规则实战

路由处理的是已经进入内核的连接。系统代理决定应用是否把连接送到本地入口，路由再决定这些连接使用哪个出站；两层不能相互替代。配置前先画出实际路径：应用、入口、目标识别、规则匹配、出站。若应用根本没有使用系统代理，修改域名规则通常不会改变它的联网方式。关于这两个开关的区别，可结合系统代理与路由模式对照阅读。

规则按顺序匹配，具体条件放前面

常规字段规则按顺序检查，命中后选择对应出口，因此例外应放在宽泛规则之前。一个合理的基础顺序是：明确的业务例外、需要阻断的类别、局域网地址、常用直连范围，最后才是默认出口。不要仅按“直连、代理、阻断”三个大类随意归档；如果前面的规则已经覆盖目标，后面的精细规则即使写对也不会得到使用机会。

同一条规则里同时填写域名、端口、网络类型等不同字段时，通常要求这些字段共同满足；一个域名数组内部的多个条目则表示候选匹配。把“某个域名或者某个端口”放进同一条规则，容易得到与预期相反的交集效果。需要并集时应拆成多条规则。修改之前先明确是按照域名判断，还是按照解析后的地址判断，这也决定是否需要 DNS 参与。

用最小片段建立直连与阻断

下面是 Xray / V2Fly 常见字段形式的路由片段，不是完整启动配置。它要求现有配置中已经存在 direct、block 和默认代理出站，并且安装了包含这些分类的规则资源。此处使用 AsIs，表示不为了 IP 规则主动解析尚未获得地址的域名；已经以 IP 形式进入的目标仍可参与 IP 匹配。

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

这里没有写一条名为 final 的字段规则，因为它不是这类 JSON 路由中的通用关键字。未命中规则时，通常使用出站列表中的第一个出站；图形客户端也可能生成自己的兜底规则。应查看最终生成配置，而不是只看界面中的简写名称。若想让剩余 TCP 与 UDP 连接进入代理，可在最后增加相应网络规则，但仍须确认出口和 UDP 能力匹配。

验证域名可见性与规则资源

域名规则生效的前提是内核能够获得目标域名。通过 HTTP 或 SOCKS 入口传递域名，与应用先在系统中解析、再提交 IP 地址，是两种不同情况。流量嗅探可以从部分协议内容中恢复域名，但不是所有流量都能识别。若规则看似正确却没有命中，应先查看日志里的目标形式，再检查嗅探设置，而不是不断增加同一域名的不同拼写。

geosite 与 geoip 依赖相应资源文件和分类。资源不存在、分类名不包含在当前文件中，可能导致启动失败或配置检查报错。先使用客户端提供的资源管理入口，确认文件位置与实际内核一致；不要只把文件放在任意工作目录。每增加一类规则，都选一个可复现的目标建立新连接验证，并记录命中出口。规则数量增加本身不代表分流更准确。

三、DNS 配置优化

DNS 配置需要同时回答三个问题：谁提出查询、查询交给哪个解析器、到解析器的网络连接走哪条路径。系统解析、应用内置解析和内核 DNS 是不同层次，不能用一个“开启 DNS”开关概括。调整前先确定目标问题是解析失败、解析结果不适合当前出口，还是路由拿不到域名。只有明确查询发生的位置，才能判断应修改系统、客户端还是应用自身。

先建立常规解析，再考虑按域名分配

起步时保留一个容易观察的常规解析方案，确认服务器域名和普通访问域名都能解析，再加入分域名服务器。下面仅展示内核 DNS 部分：指定域名优先交给一个解析服务器，其他查询可以使用另一服务器。它不代表查询请求已经自动通过代理，也不控制所有应用的系统 DNS。实际使用前，还应确认这些解析服务器在当前网络可达，并符合设备所在环境的管理要求。

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

带有 domains 的服务器用于优先匹配指定域名，但未匹配时的尝试、失败后的回退以及结果筛选，还会受具体内核与其他字段影响。不要把一段优先匹配配置理解为严格隔离。若需要禁止回退，应查阅当前内核支持的回退选项，再用日志确认；不应把某个客户端界面的“远程 DNS”名称直接当成所有内核都共有的 JSON 字段。

区分路由解析与出站解析

路由层的 domainStrategy 影响是否为了匹配 IP 规则进行解析；直连出站中的同名字段则影响直连目标怎样解析和拨号，两者位置不同、作用不同。例如路由使用 IPIfNonMatch，意味着域名规则未命中后可能解析目标，再尝试 IP 规则；它不等于所有连接都改用某个远程解析器。改变策略后，应同时观察规则命中与解析请求是否增加。

解析代理服务器自身的域名尤其需要注意启动顺序。如果访问某个 DNS 服务必须先经过代理，而代理建立连接又依赖同一个 DNS 服务，就形成了循环依赖。可让服务器域名使用一条可独立完成的解析路径，或使用来源明确、能够持续维护的服务器地址配置。不要用长期固定的临时解析结果代替域名管理，否则服务端地址变化后，连接会在看似没有修改配置时失效。

缓存、双栈与应用独立解析

修改 DNS 后，浏览器、操作系统和内核可能仍保存旧结果，既有连接也不会立即重新解析。测试时应关闭目标应用的旧连接，必要时按系统提供的方法清理缓存，再建立一次新请求。IPv4 与 IPv6 结果也应分别观察：如果解析返回了 IPv6 地址，但所选出口或当前链路无法完成相应连接，症状可能表现为等待后才恢复，而不是直接报告 DNS 错误。

应用内置的加密 DNS 可能绕过系统解析路径，这时仅修改系统 DNS 看不到预期变化。在 TUN 环境下，也不能假定所有加密查询都能通过端口规则识别。先在可控测试中暂时关闭应用独立解析，确认系统路径的行为，再决定是否需要兼容它。涉及企业域、局域网设备名和分离解析的环境，应保留原有解析入口，避免将内部名称发送到不认识它们的公共解析器。

四、TUN 模式与系统接管

TUN 使用虚拟网络接口接收系统 IP 流量，适合不能方便设置 HTTP 或 SOCKS 代理的应用。它与系统代理的区别在于入口层次，而不是“开启后所有流量一定走代理”。进入 TUN 的连接仍会经过路由规则，局域网、直连与阻断可以继续存在。客户端显示的 TUN 功能还可能由额外的网络组件实现，不能据此认定当前 Xray 或 V2Fly 配置天然拥有同一套 TUN 字段。

建立接管前的基线

启用之前，先在系统代理模式下验证服务器可连接、常用域名可解析，并确认基础路由符合预期。随后关闭其他可能接管系统网络的工具，记录当前网卡、默认网关和 DNS 状态，再启用 TUN。首次测试只打开必要的接管选项，不同时加入进程规则、复杂排除列表和 FakeDNS。这样出现问题时，可以明确判断是入口变化造成，还是原本的出站配置有误。

权限错误与网络错误要分开处理。桌面系统可能要求管理员授权、虚拟接口创建权限或辅助组件许可；Android 客户端通常通过系统 VPN 授权接管应用流量。授权完成仅说明系统允许创建入口，不说明流量已经成功送到远端。若界面提示启动失败，应先检查权限、组件文件和接口冲突，不要在还未创建入口时反复更改服务器协议。

防止回环，保留局域网访问

代理组件自身的外连必须避免再次进入同一个 TUN 入口，否则可能形成回环，表现为连接不断重试或日志快速重复。客户端通常会处理自动路由与自身流量排除，但自定义网络配置可能破坏这些默认行为。若开启后系统整体失去访问能力，先退出 TUN 恢复网络，再检查自动路由、接口绑定和排除设置，不要在断网状态下同时重装多个网络组件。

局域网访问还涉及私有地址、组播发现、广播和本地 DNS。路由中添加私有地址直连，有助于常规地址访问，但不保证所有设备发现协议都能穿过接管环境。验证时先用明确地址访问本地网关或已知设备，再测试名称解析和自动发现。若按地址可访问、按名称失败，应优先检查 DNS；若只有自动发现失败，则应继续检查组播与应用发现机制。

分阶段检查 DNS 与 UDP

TUN 可以接收到 UDP，并不意味着所选服务器或协议路径一定能够传递这些连接。应分别测试普通网页、依赖 UDP 的应用和局域网访问，不能用浏览器打开一个页面代替全部验证。遇到特定应用失败时，查看它是否使用独立解析、特殊目的端口或另一个网络接口，再决定是调整接管范围、DNS 路径，还是换用具备所需能力的现有出站。

结束测试时先关闭 TUN，再确认虚拟路由与 DNS 已恢复，最后检查系统代理是否仍处于需要的状态。异常退出后若网络未恢复，先重新打开客户端并正常关闭接管功能，再检查系统设置。macOS 的安装放行与网络权限可参阅权限处理说明；安装包和平台入口集中放在下载中心，本章不提供额外组件下载。

五、FakeDNS 与域名映射

FakeDNS 用虚拟地址代替真实 DNS 结果，并在内部保存域名与虚拟地址的映射。应用拿到虚拟地址后发起连接，接管组件或内核再根据映射恢复目标域名。它的重点是保留域名信息，让路由与后续解析更容易协作，而不是提供一组可以直接连接的真实地址。若查询经过 FakeDNS，连接却绕过对应接管链路，应用就可能拿着虚拟地址直接联网并失败。

查询与连接必须进入同一套映射链路

启用前先确认当前内核和客户端确实提供完整支持，包括 DNS 返回、地址池接管和域名恢复三个部分。不要只因为配置字段能保存，就认定功能已经贯通。下面展示支持该结构的内核配置片段，用于说明地址池与 DNS 服务器的关系；它仍需合并到已有配置，并配套入口、路由和出站。示例中的地址池属于基准测试用途地址范围，不应当作正常公网目标访问。

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

ipPool 指定可分配的虚拟地址范围，poolSize 控制池容量。地址池需要与真实网络、其他接管工具的地址范围协调，不能仅为“看起来特殊”就随意改成一个正在使用的网段。池容量也不是越大越好，应按内核实现与实际使用需要选择。更换地址池之后，应用缓存里的旧地址不会自动更新，需要重新解析并建立新连接。

入口恢复域名，不能只返回虚拟地址

在支持 FakeDNS 恢复的入口中，常见做法是启用对应嗅探能力。下面仍是入口对象内部的片段，不应覆盖整个 inbounds 数组。fakedns 用来尝试从映射恢复域名，HTTP 与 TLS 嗅探则补充部分应用层识别。是否允许这些值、是否需要额外入口设置，应以当前内核实际支持为准，图形界面生成配置也可能采用不同实现。

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

某些配置还提供 routeOnly，使嗅探结果只用于路由判断，而不改写实际连接目的地。这个选项不能不加区分地套用到 FakeDNS：如果最终目的地仍是虚拟地址，连接就无法按真实域名建立。应先确认域名恢复和目的地处理已经完成，再讨论只用于路由的嗅探策略。将不同文章里的嗅探选项拼接起来，通常比保留客户端默认设置更难排查。

识别缓存残留与旁路查询

关闭 FakeDNS 后，应用可能继续使用已缓存的虚拟地址。此时应关闭相关应用连接，清理必要的解析缓存，再重新测试；只重启内核未必能清除浏览器或系统中的结果。反过来，启用后如果应用继续使用原有真实地址，也不能立即判断 FakeDNS 未工作。应先发起一次确定经过目标解析路径的新查询，再观察返回地址和随后的域名恢复日志。

应用内置 DNS、固定 IP 连接和局域网名称会形成边界情况。固定 IP 本来就没有域名可恢复；内部域名则需要能够回答它的真实解析器。建议先让 FakeDNS 只服务于可控测试范围，确认网页、局域网和必要应用都正常后再扩大使用。若问题仅在开启后出现，优先恢复常规 DNS 与原接管方式，保留日志对照，而不是同时扩大地址池和增加多组回退解析器。

六、多订阅管理与更新边界

多订阅管理的目标是让来源、更新和使用关系可追踪，而不是把所有条目合成一个难以辨认的大列表。每个订阅都应有独立备注、更新策略和用途记录，测试来源与日常来源分开。订阅提供连接参数，但不应被默认视为全部应用设置的管理者。导入前先确认内容属于服务器列表，还是包含路由、DNS 等项目的完整配置，避免把更大范围的变更当成普通服务器更新。

区分来源下载与配置应用

更新可以拆成三个阶段：获取远程内容、解析为客户端条目、将选中条目用于当前连接。某个阶段成功不代表后续阶段已经完成。看到更新完成后，应检查条目变化和当前选择，再建立一次新连接。有些应用会继续使用既有会话，即使新配置已经加载，也无法从旧网页是否保持打开判断切换结果。需要观察新连接的实际出口和运行日志。

订阅更新所用的网络路径也要单独核对。通过当前代理获取订阅，可能解决直连不可达的问题，但如果订阅恰好负责修复当前失效服务器，就会出现“更新依赖失效连接”的困境。应保留可用的更新方式或独立备用配置，明确哪些来源需要经过代理。不要在不知道字段含义时反复切换更新代理选项；先看错误是在连接、授权、证书还是解析阶段发生。

限制自动更新带来的不确定性

自动更新适合稳定来源，但应选在能够检查结果的时段，而不是一开始就设置频繁更新。先手动完成数次更新，确认来源格式稳定、条目选择可保留，再启用自动策略。订阅含有时间敏感的授权信息时，也要留意地址是否会失效。频繁重试不能修复授权问题，反而会使日志充满重复错误，掩盖最初发生的原因。

若客户端允许更新时保留原条目或删除失效条目，应理解两者取舍：保留有助于临时回退，但列表可能积累已经不能使用的配置；删除能保持来源一致，却可能让当前使用项立即消失。先确认是否有独立备份，再决定清理策略。对于临时手工修改过的服务器，不应假定下次订阅更新会保留修改，必要时将其复制为明确标记的独立配置。

合并、去重与来源可信度

去重需要比较实际连接参数，而不是只比较备注。相同服务器地址可能对应不同端口、传输路径或安全设置，不能直接合并；不同名称也可能是同一连接的重复表达。应在单一来源内先整理，再检查跨来源重复，保留来源标识。若客户端的自动去重算法没有说明比较字段，先在测试分组试用并查看结果，不要直接对全部日常条目执行不可逆清理。

来源还可能附带远程资源地址或不熟悉的扩展字段。只导入必要内容，遇到要求覆盖系统设置、修改全部路由或额外授权的步骤，应停下来核对用途。不要把订阅地址提交给不明在线转换服务，因为地址可能包含访问凭据，转换也可能改变配置语义。对格式不兼容的来源，优先确认提供方支持的客户端格式，再考虑本地可审查的处理方式。

迁移设备时保留关系，不复制全部运行状态

跨设备迁移建议记录分组名称、订阅用途、必要规则和手动配置，再通过客户端支持的导出与导入完成。桌面端的路径、端口和网络权限不应原样套用到 Android，设备特有的 TUN 设置也需要重新确认。导入后按来源逐一更新，先恢复一条基础连接，再补充进阶规则。这样可以区分来源问题与平台差异，而不是面对一个同时包含多种变更的故障现场。

七、自定义出站与标签引用

出站定义连接离开内核时采用的处理方式，路由通过标签引用它。常见的代理、直连和阻断并不是三个固定按钮，而是配置对象及其关联关系。开始自定义前，先确认客户端允许编辑的是完整配置、局部出站，还是图形路由字段；这几种入口的合并方式不同。直接修改运行时临时文件，可能在切换服务器或重启后被覆盖，不能作为稳定配置来源。

先建立可追踪的标签关系

每个需要引用的出站使用清楚且唯一的 tag，路由中的 outboundTag 必须逐字对应。大小写、空格和拼写差异都可能造成引用失败。下面示例完整展示两个基础出站对象，但不是建议用它替换客户端的全部出站数组；若这样替换，原来的代理出站也会消失。应在现有配置结构中检查是否已经存在同名对象，避免重复定义。

{
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {}
    }
  ]
}

freedom 表示按本机网络条件直连目标，blackhole 用于丢弃匹配连接。直连并不等于目标必然可达，它仍受本机 DNS、地址族、网关和防火墙影响。阻断也不一定表现为统一错误，应用可能显示连接失败或自行重试。测试时应结合实际出口日志，不要只根据网页提示推断规则是否生效。

默认出口与显式路由要一起检查

未命中路由时，常规内核配置通常使用第一个出站；客户端也可能生成兜底规则。因此调整出站顺序是实质性行为变更，不只是列表整理。上面的片段若被独立使用，首项为直连，绝不等同于“默认代理”。需要默认使用代理时，应确认现有代理对象的位置或客户端生成的最终规则，不能因为界面上选中了服务器，就忽略完整配置的实际顺序。

若需要让某一业务走单独出口，先在最终配置中确认相应对象确实存在，再增加最具体的路由条件。订阅分组里的多个服务器通常不会自动全部变成可引用出站，当前选中服务器也可能始终使用固定标签。要实现多出口并存，必须由客户端支持相应生成功能，或维护能够完整启动的自定义配置；仅填写一个服务器备注作为标签并不能创建出口。

代理链需要明确拨号关系

多级转发与多出口选择是两件事。多出口选择让不同连接使用不同路径，代理链则让同一连接依次经过多个处理阶段。配置链式拨号前，应确认当前内核支持的字段、每级服务器的可达性以及是否形成回环。不要在没有确认协议支持范围时，把一个内核的拨号字段直接复制到另一个内核。先分别验证每个出口，再组合成链路，才能定位故障发生在哪一段。

给出站绑定接口或源地址时，也要考虑网络变化。固定无线接口可能在切换到有线连接后失效，固定源地址可能在重新获取地址后不再属于本机。此类字段适合网络条件明确的场景，不应作为所有连接失败时的通用修复项。若只需要普通直连，保留系统选路通常更容易维护；确有多网卡需求，再记录接口变化时的检查与回退步骤。

检查生成结果，再保存为长期方案

自定义内容保存后，先执行客户端提供的配置检查，再观察实际启动日志。重点检查标签是否唯一、引用是否存在、默认出口是否正确，以及自定义对象是否被合并或覆盖。发现界面设置与运行结果不一致时，应以实际生效配置为排查依据。生态与内核差异可参阅Project V、V2Fly 与 Xray 关系说明；确定配置支持范围之后，再决定是否切换内核。

八、验证、日志与配置回退

进阶配置应当具有可重复的验证过程。每次修改只解决一个明确问题，并在修改前写下预期结果，例如“某个业务域名进入指定出站”“局域网地址继续直连”。不要同时更新订阅、切换内核、开启 TUN 和更换 DNS，再根据一次网页访问判断成败。变更范围越大，故障越难归因，最终往往只能全部恢复，失去原本有价值的测试结论。

建立最小测试矩阵

至少准备四类检查：普通域名访问、明确的直连目标、需要代理的业务连接、局域网资源。每类选择稳定且有权限访问的对象，记录预期入口与出站。涉及 UDP、双栈或特定应用时再增加对应项目。测试应新建连接，而不是反复刷新一个可能复用旧会话的页面；应用连接池和浏览器缓存都可能让配置切换看起来没有变化。

日志按连接阶段阅读

首先看内核是否正常启动；若启动都没有完成，就不需要继续测试远端访问。接着看本地入口是否收到连接，再看目标域名或地址、规则选择和出站错误。端口占用属于本地监听阶段，解析失败属于 DNS 阶段，连接超时可能涉及远端可达性，而证书相关报错通常出现在安全握手阶段。这些问题不能用同一种“换服务器”操作笼统处理。

日志级别应满足当前排查需要，完成后恢复日常级别，避免长期开启过细记录。分享日志时隐藏订阅地址、用户标识、认证字段和不必要的内部域名，仅保留错误前后的相关行。时间也很重要：一次手动测试对应哪几行日志，应尽量清楚，避免把后台应用的请求当成目标请求。常见报错的进一步拆解见运行日志阅读方法。

按最近变更反向恢复

回退先恢复最近一项变更，再重新测试基线。若问题由 FakeDNS 引入，恢复常规 DNS 后还需清理旧映射结果；若由 TUN 引入，关闭接管后检查系统路由和 DNS；若由自定义出站引入，恢复标签与默认出口顺序。不能只关闭界面上的一个开关，就认定所有衍生状态已经撤销。每一步恢复后都检查新连接，避免缓存造成误判。

应长期保留一份已验证配置和一份必要说明，说明包括客户端、实际内核、入口方式、所依赖的规则资源和特殊权限。备份不需要囊括所有临时日志，但应能恢复关键配置关系。软件更新后，先确认基础连接，再检查自定义部分；若出现启动崩溃，可转到启动闪退与目录权限排查，不要把应用启动问题误判为路由故障。

把有效配置整理成查阅记录

验证通过后，为每项非默认设置写一句原因，例如“此域名需保留内部解析”“此业务使用独立出口”。记录应描述需求，而不只是抄写字段值，这样环境变化时才能判断设置是否仍然必要。订阅更新、网络切换和内核切换之后，重新检查与它们直接相关的项目；没有受影响的部分不必全部重做，维护才能保持可控。

如果仍无法定位，将问题缩小到一条连接、一组规则和一个出口，准备脱敏后的配置片段与对应日志，再对照故障排查问答。需要重新建立基础操作路径时，返回入门指南；需要调整安装平台或设备架构时，前往下载中心。本手册的目标是让每次配置变化都有依据、有验证，也有明确的恢复路径。