文章目录📖 介绍 📖🏡 演示环境 🏡📒 排查实录：从「改了规则还卡」到找到真正的断点🔍 一、现象与定位🕳️ 二、第一轮：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
