进行 FullCombo Shark DNS 故障排查时，第一步不是寻找“最优设置”，而是先确定哪些现象能从官方资料中找到明确对应，哪些只能算推测。FullCombo Shark 是用于 OpenWrt 上定制 Mihomo 的 LuCI 应用，包名为 luci-app-fchomo，要求 OpenWrt 24.10 或更高版本以及 firewall4。这意味着所有与 DNS 有关的判断，都应回到该项目的 README 与 LuCI 界面源码本身，而不是泛化的 OpenWrt DNS 教程或通用 Mihomo 讨论。尤其需要区分 FullCombo Shark DNS 劫持问题与 FullCombo Shark DNS 智能路由排查，两者在官方说明中的位置不同，混在一起容易把“界面有这项配置”误认为“界面说明了行为机制”。
先区分两个现象来源：DNS 劫持与 DNS 智能路由
官方 README 明确列出 DNS 劫持，其用途是阻止绕过网关的 53 端口查询行为。这是资料边界中少数可以直接引用的功能描述。遇到 FullCombo Shark DNS 劫持问题，管理者首先应确认当前看到的异常是否属于“设备绕过网关直接向外部 53 端口发起查询”这一类现象。README 没有记录劫持的具体实现位置、放行规则或对 DoT/DoH 的处理，因此不应把“存在 DNS 劫持功能”扩展为“劫持一定按某条规则执行”或“劫持一定重定向到某个上游”。
与劫持并列的是 README 中关于 DNS 请求可依据 EDNS-Client-Subnet 或策略进行智能路由的说明。FullCombo Shark DNS 智能路由排查应围绕“界面是否提供了与策略相关的 DNS 项”以及“这些项的字面名称是什么”展开，而不是先假设智能路由失败是因为某个缓存未刷新。官方说明只写到“可依据 ECS 或策略进行智能路由”，没有记录策略失败回退路径、ECS 缺失时的行为，也没有记录智能路由与劫持之间如何衔接。将这两者分开记录，是后续所有安全判断的前提。
这里需要特别说明一个容易混淆的点：README 中“DNS 劫持”出现的语境与“DNS 智能路由”出现的语境，在官方文本里是并列的两项功能描述，而不是同一个功能从两个角度表述。排查时如果同时观察到“设备存在绕过网关的 53 端口查询”和“查询结果与策略预期不符”，应当分成两条独立的观察记录，分别对应 README 中的两段内容，而不是试图用一种解释同时覆盖两个现象。官方资料没有说明这两者之间是否存在先后关系或覆盖关系，合并处理只会让记录失去可回查的边界。
FullCombo Shark DNS 配置检查：只记录界面实际出现的标签
FullCombo Shark DNS 配置检查的核心动作，是打开 LuCI 中对应页面，逐项记录与 DNS 有关的标签和字段。官方 client.js 源码中出现了这些标签：DNS server、DNS policy、Bootstrap DNS policy (Node)。其中 DNS server 标签下包含 Default DNS server 与 Fallback DNS server 字段。这里要特别小心：标签名称是事实，标签背后的行为不是。Default DNS server 从字面看是默认 DNS 服务器，Fallback DNS server 从字面看是回退 DNS 服务器，但官方源码只给出了这些英文名称，没有在 README 中进一步解释每个字段的取值格式、是否允许为空、空值时走哪条路径、回退触发条件是什么。
因此在做 FullCombo Shark DNS 配置检查时，建议采用“三层记录法”。第一层记录页面确实显示哪些标签，不要凭记忆补全。第二层记录每个字段当前显示的值，若字段为空就记为空，若显示列表就记下列表文本。第三层记录本次要排查的现象到底与哪个标签或字段可能相关，但只写“可能相关”，不写“一定由此导致”。例如看到 FullCombo Shark DNS 解析异常，页面里又有 Fallback DNS server 字段，可以记下“页面存在 Fallback DNS server 字段，当前值为某值，异常表现为某现象”，而不能直接写成“Fallback 设置错误导致解析异常”。官方资料没有授权这种因果连接。
三层记录法的价值在于，当问题被提交到官方仓库或与他人讨论时，接收者能够清楚地看到哪些是页面事实、哪些是观察者关联。如果记录中直接写“Fallback 设置错误导致解析异常”，接收者无法判断这是经官方确认的结论还是记录者的私下推断。将三个层次分开写，即使最终被指出理解有误，原始信息仍然可以被重新组织，而不需要推翻重来。
DNS policy 与 Bootstrap DNS policy (Node) 的边界
Bootstrap DNS policy (Node) 是另一个容易出现推断失真的标签。从字面看，它与引导阶段的 DNS 策略有关，并且标注了 Node。但 README 没有专门为这个标签撰写行为说明，client.js 中也没有展示该字段的选项列表或默认值。管理者可以做的，是确认该标签是否出现在自己的页面上，并把它与 DNS policy 分开记录。不要把 Bootstrap DNS policy (Node) 自动等同于“用于解析代理节点域名”，也不要把 DNS policy 自动等同于“用于分流国内与国外域名”。这些理解在一般 Mihomo 配置中可能常见，但在 FullCombo Shark 的官方资料边界内未被记载，不能作为判定依据。
同样，DNS server 标签虽然包含两个字段，但官方没有说明这两个字段与“界面依据 Mihomo 文档提供可视化配置”之间的具体映射关系。项目说明只提到界面依据 Mihomo 文档提供可视化配置，没有说每个标签都一一对应 Mihomo 的某个配置键。因此在 FullCombo Shark DNS 解析异常场景中，看到 DNS server 下有 Default DNS server，不能推断它一定写入 Mihomo 配置文件的某个特定段落，也不能推断 Fallback DNS server 一定写入另一个对应段落。这些对应关系可能成立，但官方资料没有明示，排查时应保持“未证实”状态。
“界面依据 Mihomo 文档提供可视化配置”这句话本身也需要加以限定。它表明的是该 LuCI 界面的设计参考了 Mihomo 文档，而不是说界面中每一个元素都能在 Mihomo 文档中找到行为解释。Mihomo 文档是另一个独立的信息源，即便其中对某些配置项有详细说明，也不能自动套用到 FullCombo Shark 的同名字段上，除非 FullCombo Shark 的官方资料明确声明了该套用关系。这个信息源之间的隔离，是资料边界型排查必须守住的一条线。
安全的排查顺序：阅读、记录、再回官方说明
由于官方事实有限，FullCombo Shark DNS 故障排查更适合采用保守顺序。第一步，重新打开项目 README，只圈出与 DNS 直接相关的两段：一段关于 DNS 劫持，一段关于 ECS 或策略智能路由。第二步，打开 LuCI 页面，找到 DNS 相关区域，按前文方式记录 DNS server、DNS policy、Bootstrap DNS policy (Node)、Default DNS server、Fallback DNS server 等标签及当前显示值。第三步，把观察到的异常写成中性的现象描述，例如“设备查询某域名时返回地址与预期不同”“页面某字段为空”“某策略项显示了某文本”，不要加入“因为”“所以”“应该是”等连接词。
第四步，将现象描述与 README 中的两段说明并排放置，看是否落在明示范围内。如果现象是“有设备绕过网关直接查询 53 端口”，README 确实提到了阻止此类行为；如果现象是“DNS 请求依据 ECS 或策略路由后结果异常”，README 只说明了存在智能路由能力，没有说明异常判据。第五步，如果页面中某字段名称与现象看起来相关，但 README 未解释该字段，应停止推断。此刻能做的只是把页面截图、字段值、异常描述整理成一份记录，再去官方仓库查看是否有更新说明、源码注释或 issue 中由维护者确认的信息。
如何记录问题现象
在整理现象记录时，每条记录应包含四个部分：观察时间、观察位置、观察到的内容、观察方式。观察时间记录问题发生或复查的时刻；观察位置写明是 LuCI 界面的哪一个标签区域，还是某个网络行为的描述；观察到的内容只写实际可见的文本、值或行为，不写判断；观察方式说明是通过页面直接查看、截图保存还是其他方式获得该信息。这样做的好处是，当记录积累到多条之后，阅读者仍然能够区分每条信息是独立观察还是从前一条推导而来。
例如某条记录可以写成“LuCI 界面 DNS server 标签下 Default DNS server 字段显示为某值，通过页面直接查看获得”，而不是“默认 DNS 没有生效”。前者是可回查的观察记录，后者已经包含了一个未经官方资料证实的行为判断。另一个例子是“某设备发起向外部地址的 53 端口查询”，这句话是观察记录；“劫持没有拦截该查询”则加入了因果推断，因为 README 虽然提到阻止此类行为，但并未说明在何种条件下阻止或未阻止。保持记录与推断分开，是后续与维护者沟通时最容易被采纳的方式。
何时停止推断
停止推断的边界非常清楚：只要下一步需要用到“取值格式”“匹配顺序”“回退条件”“缓存行为”“上游地址”“日志路径”“错误码”“具体命令”中的任何一项，而该信息不在上述官方事实中，就应停止。比如管理者看到 Fallback DNS server 为空，不能推断“空值会导致解析走默认 DNS”；看到 Bootstrap DNS policy (Node) 为某个列表项，不能推断“该策略只在启动阶段生效”；看到 DNS 劫持开启后仍有部分查询异常，不能推断“劫持未覆盖某类查询”。这些内容在官方 README 与 client.js 中均未出现。
对于 FullCombo Shark DNS 解析异常，官方资料能够支持的说法只有：该项目提供了 DNS 劫持功能；该项目说明 DNS 请求可依据 ECS 或策略进行智能路由；LuCI 界面源码中出现了 DNS server、DNS policy、Bootstrap DNS policy (Node)、Default DNS server、Fallback DNS server 等标签；界面依据 Mihomo 文档提供可视化配置。超出这些说法的任何“根因分析”，都不是资料边界型排查，而是个人推断。管理者如果需要在生产环境中继续定位，应把已整理的现象记录提交到官方仓库，等待维护者确认，或等待官方文档补充相应字段说明。在此之前，不应对配置进行无法回退的修改，也不应把某个标签的存在当成某种行为已经发生的证据。