Mice-Tailor-Infra 进化论（二）：数据炼金术 —— 揭秘 FCM-Hosts-Next 的自动化工厂

发表于 更新于 分类于 ， ，

引子：域名再美，数据不活也是徒劳

在上一篇《MiceTimer 诞生记》中，我们解决了 Android 端的“执行确定性”问题。但很快，另一个更底层的问题浮出水面：如果你的 Hosts 数据本身就是腐烂的，那么再准时的唤醒也只是在搬运垃圾。

市面上大多数 FCM 优化方案都死在了“数据源”上：要么是几个月更新一次的静态文件，要么是简单粗暴的全局 Ping 扫描。

在 Mice-Tailor-Infra 的哲学里，数据不应该是“捡”来的，而应该是“炼”出来的。今天我们拆解这套全自动化的数据工厂：FCM-Hosts-Next。

1. 诱捕：利用 EDNS 实现“跨境遥感”

获取 Google IP 的第一步通常是 DNS 查询。但如果你在 GitHub Actions 的美国服务器上直接查 DNS，你会拿到一堆美国机房的 IP。这对于国内网络来说简直是灾难。

我们的解决方案是：EDNS Client Subnet (ECS) 诱捕。

在 harvest.py 脚本中，我们并没有直接发起查询，而是构造了一个特殊的 DNS 报文，告诉 Google 的权威 DNS（ns1.google.com）：

“嘿，我是一个来自中国电信骨干网（或台湾省 HiNet）的用户，请告诉我最适合我访问的 mtalk 地址。”

通过轮询中国四大骨干网的 CIDR 段，我们实现了在海外服务器上“遥感”国内最优节点的能力。这就像是在全球布下了无数个传感器，捕捉那一瞬间最适合国内链路的 IP 信号。

2. 甄别：TCP 5228 端口的“侍酒师”

拿到成百上千个原始 IP 后，真正的挑战才刚刚开始。Ping 值低，不代表 FCM 能通。

FCM 走的是 TCP 5228 端口。运营商对 ICMP（Ping）和 TCP 的 QOS 策略完全不同。有的 IP 虽然 Ping 起来只有 30ms，但 5228 端口可能根本握不上手，或者丢包率极高。

于是，我们开发了 Sommelier（侍酒师） 筛选算法：

  • 协议级实测：抛弃 Ping，直接进行 TCP 5228 端口的 Connect 握手测速。
  • 高并发压测：利用 Python 的 concurrent.futures 开启 100 线程并发，在几秒钟内完成对所有候选 IP 的深度体检。
  • 超时判定：将超时硬性限制在 1.5s 左右。在这个追求“秒连”的时代，超过 1.5s 的握手都是不及格的。

3. 爆破：C 段自适应扩展

在 sommelier.py 中，我加入了一个极具“进攻性”的功能：C 段自适应爆破。

Google 的边缘节点往往是成簇部署的（Cluster）。如果我们发现 1.2.3.4 这个 IP 的 5228 端口握手极快，那么极大概率 1.2.3.0/24 或者是 IPv6 的 /124 段内隐藏着更多同样优秀的兄弟节点。

脚本会自动识别这些“冠军网段”，并立刻对该网段进行二次全量扫描。这种**“发现一点，打下一片”**的策略，让我们能从茫茫 IP 海中精准地挖掘出那些隐藏的黄金节点。

4. 阵列：十二金刚负载均衡

最后，我们不再只给用户提供一个 IP，而是构建了一个**“十二金刚防御阵列”**。

通过 LoadBalancer 逻辑，我们将精选出的 Top IP 均匀地分配给 FCM 的各个域名（mtalk, alt1 到 alt8 等）。

  • 双栈支持：同时生成 IPv4、IPv6 和双栈三种 Hosts 模式。
  • 动态轮询：每半小时，流水线都会重新洗牌一次，确保数据永远保持在“出厂新鲜度”。

结语：工业化才是终点

现在的 FCM-Hosts-Next 已经完全脱离了人工干预。它在云端静默运行，每隔半小时捕获、实测、筛选、发布。

这种**“协议实测 + 自动扩容 + 动态分发”**的工业化逻辑，让我们的 FCM 连接稳定性产生了一个质的飞跃。域名和 IP 都不再是玄学，它们只是我们算法过滤器下的一串数字。

下一篇预告：
数据有了，调度也有了，我们如何用 Infrastructure as Code (IaC) 的思想，打造一套能够随时云端热更新的 Sing-box 运行环境？

项目链接

Stay hungry, stay coding.