AX9000 旁路由实践：从树莓派迁到 Debian x86，双出口、MPTCP 与 Tailscale
这套网络的目标是让主路由少做事，把代理、多出口调度和远程接入交给独立网关。最初用树莓派，后来迁到 Debian x86 软路由；LAN 设备仍以 AX9000 为网关，不需要逐台改设置。
截至 2026-10-31，x86 已接替树莓派，代理、双出口、Tailscale、监控台和自动更新均已配置。 树莓派已退出网关职责，随后短暂上线供只读恢复测速历史。本文保留当前架构与操作入口，逐次调试、完整配置和验收细节放在仓库文档。
为什么这样改
AX9000 在叠加代理、Tailscale、Wi-Fi 上游、多 WAN 和 mwan3 时出现过偶发重启，单 WAN 相对稳定。因此先把代理和 Tailscale 搬到树莓派，再重装 ImmortalWrt，让主路由只保留接入、DHCP、单 CPE WAN 和必要转发。
树莓派后来也发生过整机失联，重启后恢复。日志突然中断，曾观察到硬盘灯停止闪烁；没有足够证据确认是供电、存储、内核还是某个服务。最终换成 x86，并选择重新配置，而非复制旧机私密配置。这些是这套设备的运行经历，不代表已经定位了重启根因。
| 时间 | 关键变化 |
|---|---|
| 9 月 14–15 日 | 代理、Tailscale 出口迁到树莓派；IPv6 改为 ULA + NAT66 |
| 9 月 18–20 日 | 重装 AX9000，双出口迁到树莓派；增加 IoT 隔离、测速和实时调度 |
| 9 月下旬 | 引入 MPTCP、慢速隔离、Go 采集器和 Zashboard；保留 LAN 真实来源 IP |
| 10 月上中旬 | 撤销 Cachy 固定 CUP；加入游戏/流媒体避让、容量预测、按需链路诊断；移除自动重启 watchdog |
| 10 月 30 日 | Debian x86 分模块重建并接管；随后恢复 Pi 测速历史，加入 UU 游戏保护 |
| 10 月 31 日 | 补装 UFW、Docker Home Assistant；恢复 Cachy 直连固定 CUP |
逐模块配置见 x86 迁移记录。需要追查某次旧修改时，可查精简前的文章。旧 Pi 的地址、接口和 UFW 命令不能直接套用到新机；10 月 31 日另按新拓扑补装 UFW。
当前拓扑与设备分工
1 | |
| 设备 | 地址与职责 |
|---|---|
| AX9000 | ImmortalWrt 25.12.2；192.168.32.1 /
fda2:a01e:2cb2::1；主 LAN、DHCP、IoT、CPE
WAN、NAT66、旁路转交和故障回退 |
| Debian x86 | Debian 13.7；192.168.32.2 /
fda2:a01e:2cb2::2；Mihomo、DNS、双出口、Tailscale、监控台 |
| Tailscale | 新机 100.93.74.74，名称 debian-x86；Exit
Node 和 192.168.32.0/24 子网通告，接收远端子网路由 |
| CUP | 新机无线口 wlo1，5GHz；校园网新入站受原生 nftables
cup_guard 限制 |
| IoT | 独立 2.4GHz Wi-Fi；192.168.40.0/24 /
fda2:a01e:2cb2:10::/64 |
新机 IPv4 由 AX9000 按有线 MAC 固定 DHCP 分配，IPv6
::2/64 由新机 NetworkManager 静态配置。路由器原先遗留的
::2 别名已删除；现在 ::2
属于新机，不再是旧 Cachy SNAT 身份。有线仍接收 RA 默认路由，CUP
地址动态获取。
新机采用两层防火墙：cup_guard 先阻止校园网主动入站，UFW
再管理主机端口。SSH、RDP、DNS、代理及面板向主 LAN 开放，Tailnet 继续受
ACL 控制；Mihomo/Tailscale 转发已放行。查看
sudo ufw status verbose 和
sudo nft list table inet cup_guard，前者不包含所有规则；配置与回退说明。
AX9000 还把以下目的网段交给新机，IoT 防火墙不会因此自动放行：
| 目的网段 | 下一跳 | 新机后续路径 |
|---|---|---|
10.0.0.0/8 |
192.168.32.2 |
CUP |
100.64.0.0/10 |
192.168.32.2 |
Tailscale |
192.168.1.0/24 |
192.168.32.2 |
Tailscale 远端子网 |
fd7a:115c:a1e0::/48 |
fda2:a01e:2cb2::2 |
Tailscale |
数据包、DNS 和回程
主 LAN 的公网 TCP/UDP 经 AX9000 送入新机的 mihomo0
TUN。Mihomo 决定直连、代理或拒绝；新建出站连接按规则选择 CPE/CUP。新机
MAC 在 AX9000 上豁免转交，避免绕圈。
普通业务保留终端真实 IPv4/IPv6，所以 Mihomo 能区分设备。TUN 回 LAN
的回复通过表 20221 先回
AX9000，再交给终端，保持主路由连接跟踪的往返路径一致。DNS 仍保留 hairpin
SNAT。NetworkManager 重新应用有线配置后，专用钩子恢复回程路由。
主 LAN 与 Exit Node 的普通 TCP/UDP 53 查询被转给 Mihomo，系统 DNS
也使用本机。Mihomo 采用 redir-host，公网 DNS 上游为
DoH；.lan 和 LAN 反向查询交回 AX9000，.ts.net
交给 Tailscale。客户端自带 DoH/DoT 不受 53
端口重定向约束，不能保证所有查询都必经本机。
11 月 4 日按当前线路实测调整国内 DoH：阿里 223.6.6.6 经
CUP-Direct，采样中位数约 6.4 ms；保留 DNSPod
1.12.12.12 按普通双出口策略访问。国外保留经代理的
Cloudflare/Google，前者本次约 169 ms、后者约 189
ms。不是严格主备，也不保证长期排名。热加载后国内常见查询约 7–10
ms；原配置当时也已接近这一水平，本次主要固定快速路径。订阅更新保留 DNS
配置；没有新增定时测速。查看
sudo cat /var/lib/mihomo-update/dns-benchmark-2026-11-04.json，完整采样、应用记录与回退见迁移文档。
IPv6 使用 LAN ULA，经过 AX9000 的有线路径由 NAT66
出网；没有恢复不可路由的公网 /64 扩展。CUP 有自己的 IPv6
上游。IPv6 有地址不代表链路正常，曾出现 CPE
重启后才恢复上游连通的情况。
隔离与故障回退
- CUP 入站：拒绝校园网主动访问 SSH、RDP、面板等服务，以及主动转发进 LAN；保留已建立连接回包、DHCP、必要 IPv6 控制报文和 Tailscale UDP。LAN/Tailnet 管理保留。
- IoT：独立网段，通过防火墙限制访问主 LAN、管理网及 Tailnet 等私网；默认经 CPE 直出。静态路由只决定下一跳，不会绕过防火墙。
- AX9000 旁路健康：只做新机
7890的本地 SOCKS5 握手，不用 Google/百度判断新机是否活着。每轮等待 30 秒，连续两轮决定切换，接管租约 120 秒；失败后主 LAN 回到主路由直连。
新机自己的 Tailscale Exit Node 不受 AX9000 这项回退保护。维护 Mihomo 前，应先取消远程客户端的该出口选择，再撤销 AX9000 旁路接管，不能直接把“停代理”当作无影响操作。
双出口如何调度
普通新连接按容量、实时占用、延迟与健康状态分配；已有连接保持出口。CPE 的实际 WAN 计数由 AX9000 的受限 SSH 强制命令读取，CUP 直接采样新机无线口，避免把 LAN 内部传输误当成 CPE 出口负载。
| 机制 | 当前行为 |
|---|---|
| 实时调度 | 每 2 秒采集，约每 6 秒调整普通新连接分配；两线 IPv4/IPv6 分别检查健康 |
| 完整测速 | 阿里、腾讯、华为、中科大、南大多源采样；至少间隔 2 小时 |
| 活动避让 | 检测到游戏/流媒体时暂缓测速；结束后需连续安静 5 分钟，仍不能绕过两小时间隔 |
| 慢速隔离 | 多源均低于 5 Mbps 时停止给该出口/地址族分配普通新连接；约 15 分钟单独复测，连续两轮达到 10 Mbps 后恢复 |
| 每日训练 | 北京时间 04:30，使用最近 30 天真实测速，近期数据权重更高；无新数据时可保留模型 |
| 容量预测 | 每 5 分钟更新时段容量基准；评估不通过、数据不足或模型过期时回退实测/运行基准 |
训练和预测只计算本地数据，不会主动测速。模型估计的是镜像下载容量，不是代理节点带宽，也不是游戏延迟。10 月 30 日从 Pi 恢复 1,571 条历史通道记录，映射接口后与新机 4 条合并，共 1,575 条；未覆盖权重或重置测速冷却。重训后有线 IPv4/IPv6 通过，CUP 仍回退实测；游戏时段缺测不能靠凭空补点解决。详见容量预测与补测。
10 月 31 日重新将 Cachy 的固定来源地址直连流量送往
CUP，代理流量仍按原策略使用 VPS/MPTCP。AX9000 为其预留 IPv4
192.168.32.201 与 DHCPv6 地址
fda2:a01e:2cb2::201，并启用主 LAN 的 managed RA
标志。随后仅关闭主 LAN 的
SLAAC（dhcp.lan.ra_slaac=0），保留 RA/DHCPv6，IoT
不变。已撤掉 IPv6
地址同步服务，并清理临时部署文件与过渡备份；最终只保留静态租约和固定来源分流。IPv4
与 ::201 新连接均已实测命中 CUP。通过
ubus call dhcp ipv6leases 已确认 Cachy 取得
::201，状态为 bound / static。旧 SLAAC
地址可能继续存在到过期或重新联网，过渡期间这些来源仍不在固定规则内。已有连接不强制换出口，CUP
故障时固定流量不自动回退 CPE。配置与边界说明。iCloud
相关域名和 racknerd-us-cf 节点仍固定 CUP。
MPTCP 与普通负载均衡的区别
普通调度决定一个新连接选哪个出口；指定直接 VLESS/TCP 节点的 MPTCP 则允许同一连接建立两条子路径。已验证荷兰节点的同一连接同时通过有线和 CUP 传输，但这不保证字节均分、总带宽相加或看视频时两线始终满载。
当前关闭内核全局黑洞退避，单连接 TCP 回退仍保留。某出口被测速隔离时，指定节点的后续新连接改走可用出口的普通 TCP；隔离解除后，新连接恢复 MPTCP。切换不主动关闭已有连接，因此慢接口的流量不一定立即归零。CF WebSocket/CDN 节点没有套用这套 MPTCP 策略。
11 月 2 日加入的 🇸🇬 gomami-singapore 因被 GFW
屏蔽且已退款，11 月 3 日撤销：Debian 移除节点、策略组引用和 MPTCP
策略，并通过 local-routing.json 的
excluded_nodes（完整节点名含国旗）防止订阅更新重新加入。热加载保留其他选择和已有连接；未再连接已退款服务器，也未做测试。马来西亚节点仍跳过手动测试。详见
MPTCP
文档。
监控台与游戏诊断
| 服务 | LAN 入口 | Tailnet 入口 |
|---|---|---|
| 双出口观察台 | http://192.168.32.2:8088/ |
http://100.93.74.74:8088/ |
| Home Assistant | http://192.168.32.2:8123/ |
http://100.93.74.74:8123/ |
| Zashboard | http://192.168.32.2:9090/ui/ |
http://100.93.74.74:9090/ui/ |
| SSH / RDP | .2:22 / .2:3389 |
相同端口，使用 100.93.74.74 |
8088 负责速率、权重、隔离、训练与测速暂停状态、MPTCP
和游戏连接观察；9090 管理 Mihomo 节点和策略。后者密钥在新机
/etc/mihomo/controller-secret，不要放进 URL
或公开文档。8088 仅开放主 LAN/Tailnet，后端只监听
loopback，关闭页面不影响调度。
10 月 31 日另以 Docker 部署 Home Assistant，安装小米官方
Xiaomi Home 集成；首次创建管理员及米家 OAuth
授权由使用者完成。配置保存在
/var/lib/homeassistant，容器使用 host
网络并限制资源，Docker 不接管网关 NAT；8123 只向 LAN/Tailnet 开放，IoT
隔离保留，先走米家云接入。日志、备份和更新方法。
速率历史保留最近 24 小时，每分钟落盘；6h/24h 横轴显示完整所选范围，未采集时段留空。新机历史从迁移时开始，不补画旧 Pi 数据。
游戏页默认 Cachy，支持 GTAOL、地平线 6、UU 加速、Xbox 和 STUN 候选筛选。在 Mihomo 之前读取 LAN UDP 包头，按真实五元组分别统计；同一源端口的不同目标不会合并。Mihomo 的 UDP 源会话可能复用，所以面板会话的目标地址不一定等于每个实际包的目标。
UU 保护结合 Cachy 的服务连接、同节点探测和持续双向 UDP，兼顾 IPv6 控制请求与 IPv4 加速流量。面板已实测显示“UU 加速”暂停原因；仅打开官网或短探测不触发。外层加速节点不是内层玩家地址，协议改变或缺少线索时可能漏识别，详见识别边界。
手动 ICMP/NextTrace 必须选择近期观测记录：确认 DIRECT 才测试本地两条路径，确认代理则从对应 VPS 测对端；关联不明或远端未配置时拒绝，不用直连结果冒充代理路径。目前新机只恢复荷兰远端探针，马来西亚及 RackNerd/CF 未配置。
NextTrace 显示逐跳 IP、AS 与归属名称，荷兰还能按需观察代理 socket 的实际 UDP 出口。ICMP 未回复率不是游戏 UDP 丢包率，候选端口不证明玩家身份，IP 地区也不代表玩家位置。 地理位置服务只查询展示的公网 IP，不发送客户端地址或包内容。原理和权限见游戏诊断文档。
日常维护速查
以下命令在新机执行；只查看状态不需要运行测速或更新。
1 | |
在 AX9000 查看旁路接管：
1 | |
proxy/direct
是最近状态，实际接管还取决于内核中未到期的租约。主路由日志主要在内存中；现有
journal、测速和面板历史不等于整机故障取证已部署。
| 需要查什么 | 新机位置 |
|---|---|
| Cachy、iCloud、CF 固定出口与 MPTCP 本地策略 | /etc/mihomo/local-routing.json |
| 测速阈值、来源与活动保护配置 | /etc/rpi-dualwan-speedtest.json |
| 训练历史 / 模型 | /var/lib/rpi-dualwan/capacity/ |
| 监控台速率历史 | /var/lib/rpi-dualwan-dashboard/traffic.sqlite |
| MPTCP / 活动采集快照 | /run/mihomo-mptcp/status.json、/run/rpi-flow-monitor/status.json |
| 手动诊断历史 | /var/lib/rpi-game-latency/history.json，有任务才生成；7
天/最多 120 轮 |
暂停观察台不影响路由，但不要顺手停止
rpi-flow-monitor，它还供游戏/流媒体暂停测速使用。复杂规则修改、停用与回退见操作指南，其中旧
Pi 接口须按当前 x86 映射核对。
自动更新
| 内容 | 北京时间 | timer |
|---|---|---|
| 订阅、GeoIP、GeoSite | 每日 04:15，随机延后 0–10 分钟 | mihomo-update-data.timer |
| Mihomo 稳定核心、Zashboard | 每周一 04:40，随机延后 0–10 分钟 | mihomo-update-software.timer |
下载先走代理，失败后直连；校验官方 SHA256 和候选配置后才替换，保留本机 DNS/TUN 与本地分流规则。锁被占用时等待，不静默丢掉一次更新。两个 timer 会补执行关机期间错过的计划，所以可能在白天运行；不包含 Debian、Tailscale 或 8088 自编监控台升级。
1 | |
正式结果在
/var/lib/mihomo-update/*-status.json，检查结果另存
*-check-status.json。data 更新会重启 Mihomo；software
只有更换核心时重启，单独更新 Zashboard
不重启。下载/校验失败保留现用内容，但替换后的启动失败没有自动回滚；正式重启可能中断代理连接。
需要立即正式更新时，使用
sudo systemctl start mihomo-update@data.service、mihomo-update@software.service
或仅面板的 mihomo-update@dashboard.service。暂停自动任务用
sudo systemctl disable --now mihomo-update-data.timer mihomo-update-software.timer，恢复把
disable 改为 enable。
当前边界与配置来源
已验证主 LAN 的 Google/哔哩哔哩 IPv4/IPv6 访问、真实来源显示、远程 Exit Node、双路径承载和监控台；更新的检查模式也通过。未做冷启动、物理断线或大流量长期压力验收，游戏实际对局仍需结合现场观察。
此次迁移在模块 7 结束。 本机持久化故障采样按要求暂不配置，RackNerd 日志上传没有恢复，自动重启 watchdog 保持移除。WebDAV、Home Assistant、OpenSpeedTest 等旧 Pi 应用也未迁移，不能把旧地址当作仍在线的服务。
源码包中的 scripts/stage-x86.py 和
scripts/stage-x86-dashboard.py 用于渲染新机配置及构建 amd64
采集器，不能直接使用旧 Pi 的 ARM64
部署清单。附件没有订阅、密钥、完整运行配置或测速历史，不是一键还原包；旧单脚本附件保留原链接，当前部署请以完整源码包和
x86 文档为准。