网页正常但 Reeder 等原生 App 无法同步：一次 fake-ip-filter 的踩坑记录

大家好，最近在折腾虚拟网卡（TUN）模式下的分流逻辑，踩了一个非常经典的坑：网页浏览正常，但 Reeder 等原生 App 在开启 TUN 后死活无法同步。
结论先行：在 TUN + fake-ip 模式下，把业务域名加入 fake-ip-filter，可能会因为同步 Real DNS 失败，导致原生 App 在握手前直接断连。

折腾一圈后发现，这不仅是规则问题，更涉及底层 DNS 解析逻辑。分享出来供大家参考，也想请教下各位在大规模节点和自动化维护上有什么高招。

在我的案例中，App 同步失败的根源在于我把个人域名放进了 fake-ip-filter。

过程：开启 TUN 模式后，由于域名在 Filter 列表中，Clash 会强制进行真实解析（Real IP）。
当时上游 DNS 刚好返回了 SERVFAIL，导致 Clash 拿不到目标 IP，连接在握手前就直接断开，报 dns resolve failed。

解决办法：将域名移出 Filter，让 Clash 直接返回 Fake-IP 给 App，解析给 Clash 后台异步处理。

目前我搭建了一个简单的“三通道”入口，方便日常使用（配合 zeroomega 等工具）：

• 7897 (Mixed)：通过订阅的规则表来分流。
• 7898 (Direct)：直连。
• 7899 (Proxy)：代理。

虽然目前的方案解决了“能用”的问题，但维护起来还是不够优雅，想请教下大家：

• 是否有基于访问日志 / DNS 请求的自动化方案
• 能否自动归纳并同步更新 Clash 的 rule-providers 或 fake-ip-filter
• 在多节点、大规模配置下，有没有更优雅的维护思路