对 Just My Socks 各节点在宁波移动网络环境下的实际表现进行测速记录，持续更新。

我折腾 FCM 的初衷很简单：让 Android 手机上所有需要 Google 推送的应用，在国内网络、Wi-Fi、移动数据、代理和直连之间都能稳定收到消息。

这件事听起来像是“把 geosite-googlefcm 直连”就完了。真正做起来才发现，Android VPNService、SFA 的托管模式、分应用代理、系统层的“允许应用绕过 VPN”、Google 官方 GMS、microG、IPv6、DNS hosts、TCP 5228 长连接，全都能掺一脚。

最后真正稳定下来的组合反而有点反直觉：

开启 SFA 的分应用代理和托管模式，让托管模式自动绕过中国应用；同时关闭 Android 系统的“允许应用绕过 VPN”。

这篇记录一下完整排障过程，以及最后留下来的配置形态。

我最开始只是想做一件很朴素的事情：让手机和电脑稳定互联。

不是那种“在同一个 Wi-Fi 下面互相发现”的互联，而是无论手机在移动数据、电脑在家里、笔记本在公司，所有设备都能通过一个统一的 tailnet 相互访问。最好 Android 上也不要同时跑 Tailscale、Clash、KDE Connect、各种代理和后台服务。我希望 sing-box 既负责代理，也负责 tailnet，而 KDE Connect 只要相信这个 tailnet 就行。

听起来很合理。

真正做起来以后，我才发现，这里面藏着几个非常典型的现代网络软件陷阱：UI 状态不等于数据面状态，ping 通不等于 TCP 走对了路，抓包看到 100.64.x.x 不等于应用层也能看到 100.64.x.x。最后这个问题甚至一路挖到了 KDE Connect Android 的源码，并被整理成了 KDE Bugzilla 和 KDE Invent Merge Request。

这次记录一场非常典型、也非常折磨人的开发板无线网络排障：Orange Pi 5 Pro 在 Joshua-Riek/ubuntu-rockchip 系统上，开机后短暂能连 5GHz，但几分钟内就会掉回 WORLD / 只剩 2.4GHz，最终断网。

最后真正的解法，不是继续在路由器、DFS、DNS、翻墙环境上兜圈子，而是把这块板子的 Wi‑Fi 驱动路径从 brcmfmac 切到 bcmdhd_sdio。

这篇是给未来的自己留的完整流程：当香橙派5 Pro（或其他 RK3588 板子）系统内核玩坏后，如何通过 U-Boot 的 UMS 模式，在电脑侧用 dd 直接重刷整盘镜像。

引子：告别“纯手工”时代

如果你也是一名 Android 玩机爱好者，你一定经历过这样的痛苦：

1. 机场订阅更新了，得手动去复制链接、更新配置、重启服务。
2. 想要微调一个分流规则，得在手机那个局促的编辑器里改几十行 JSON。
3. 换了台手机，所有的分流逻辑又要重写一遍。

在 Mice-Tailor-Infra 的世界里，这种低效的操作是不被允许的。既然我们已经有了准时的调度（MiceTimer）和高质量的数据（FCM-Hosts-Next），那么最后一步就是：将 Sing-box 运行环境彻底基础设施化。

今天我们要聊的是：如何用 Infrastructure as Code (IaC) 的思想，重构 Android 端的网络治理。

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

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

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

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

序言：索然无味的“稳定”

最近我的 FCM 连接时间稳定得让人有些想打呵欠。Time connected 长期维持在 1.5 小时以上，重连几乎是秒级完成。在玩机圈摸爬滚打这么久，我深知这种“索然无味”背后的含义：基础设施的边界情况被彻底堵死了。

但在几天前，情况完全不是这样。

那时候，我还在依赖最原始的 Shell 脚本配合 while true; sleep 1h 来更新 FCM Hosts。我本以为这很稳，直到我发现：每当我晚上睡觉放下手机，早起一看，Hosts 的同步记录竟然断了五六个小时。

这时候我才意识到，我掉进了 Android 系统那个深不可测的“休眠黑洞”。

背景

在 Root 或使用各类后台管理工具（如墓碑、NoActive 等）后，验证 FCM 推送是否正常工作是一个常见痛点。传统方法依赖他人发送消息，效率低下且不确定。本文提供一种利用 Telegram Bot API 实现的、完全自主的 FCM 推送测试方案。

该方案旨在模拟 App 进程被杀或进入后台限制后，依赖 FCM 唤醒并接收消息的场景。

实战：GitLab 从 v14 到 v18 的跨版本无损升级与 CI/CD 终极排障

1. 背景：偿还四年技术债

本文记录了将一台生产环境 GitLab 社区版 (CE) 从 v14.6.1 (2021 年) 跨越 4 个大版本，无损升级至最新稳定版 v18.5.0 极狐版 (JiHu) 的全流程。本次升级旨在解决旧版本安全漏洞、利用新版效能分析工具进行工作量量化，并实现架构现代化 (IaC)。

核心挑战：

1. 数据库复杂迁移：需执行两次数据库引擎大版本升级（PostgreSQL 12 -> 13 -> 16）。
2. 网络协议冲突：解决 Docker Compose 内部网络与外部 Nginx 反向代理之间的 HTTPS/HTTP 协议冲突。
3. Runner 兼容性：修复 GitLab 18 对旧 Runner 注册信息及 session_server 的底层 Bug。