文章目录
- 📖 介绍 📖
- 🏡 演示环境 🏡
- 📒 排查实录：从「改了规则还卡」到找到真正的断点
- 🔍 一、现象与定位
- 🕳️ 二、第一轮：DNS 分流核查（命中第一个根因，但不是全部）
- 🩹 第一轮修复（部分有效）
- 📡 三、第二轮：抓包取证（发现客户端 DNS 旁路）
- 📵 手机在用自带加密 DNS
- 🧾 连接跟踪表说话
- 🚧 第二轮应对（收窄但未解决）
- 🎯 四、第三轮：找到决定性断点（本案例最大收获）
- 🛠️ 五、最终修复
- 📈 修复效果（conntrack 实测对比）
- 🧰 技术要点沉淀
- 📋 运维避坑清单
- ⚓️ 相关链接 ⚓️
📖 介绍 📖
手机连上家里 WiFi，应用商店批量更新：多个应用排队「等待中」，能下的卡在 88%、99% 一直转圈，最后全部断流。同一台手机切 4G，秒过。而家里软路由（iStoreOS + OpenClash TUN 透明网关 + MosDNS + AdGuardHome）其他一切正常——网页秒开、视频流畅，唯独这件事不对劲。
这个案例值得写，是因为它不是单一故障，而是四层断链叠加——DNS 分流错、fake-ip 排除、防火墙直连、客户端加密 DNS 旁路，每一层都能单独致病，而且前三层的修复对真正的病灶完全无效。排查走了一圈弯路，最后靠连接跟踪表抓到决定性证据。
全文按真实排查时间线写：现象 → 弯路 → 决定性断点 → 最终修复 → 避坑清单。纯网络工程向，命令可照抄。
🏡 演示环境 🏡
- 🏠 软路由：iStoreOS，OpenClash（TUN 模式，Meta 内核）
- 🧭 DNS 链：MosDNS 分流 + AdGuardHome 去广告
- 📱 终端：手机（Android，连接路由 WiFi）
- 🌐 全程内网取证：n
