从一台 N100 小主机开始

房间里原本就预留了网线，接上一台路由器，能上网、能发 Wi-Fi，其实就够了。可我在闲鱼上看到同城有人出一台合适的 N100 小主机，还是没忍住，约了面交。

这台小主机配了 8GB DDR5 内存、128GB NVMe 硬盘，还有六个 Intel I226-V 2.5G 网口，可以拿来做软路由。我想在里面跑些脚本和小服务，以后再接上家庭自动化。自己搭出一套能用的东西，对我来说本来就挺有意思，值得花时间折腾。

动手前，我先理了一遍网络结构：光猫负责什么，谁来拨号，日常上网走哪一段，OpenWrt 放在哪里，虚拟机接哪座网桥，无线设备又接在哪一层。弄清这些以后，我把硬件接好，再给 AI 准备好干活的入口：SSH、公钥、管理页面、PVE 控制台，以及它能读取的配置和日志。

接下来就让 AI 开干。当然，它也很容易把自己正在用的网络改断，最后还得我手动救回来。

搭好的网络大致是这样：

互联网
  │
光猫（按现有拓扑，使用桥接）
  │
TP-LINK 主路由：拨号、主网 DHCP、NAT
  ├── 台式电脑：可以连接上级网络
  │
  └── N100 / Proxmox VE
        ├── 上联网桥 vmbr0
        │     ├── PVE 管理入口
        │     └── OpenWrt WAN
        │             │
        │          路由 / NAT / DHCP / DNS / SQM
        │             │
        └── 下联网桥 vmbr1 ← OpenWrt LAN
              ├── Debian：容器、脚本、轻量服务
              ├── Home Assistant：家庭自动化底座
              └── 物理网口 → H3C NX30 Pro → 手机等无线设备

我以为，只要 AI 不掉线，它就能搞定

帮我修网的 AI 自己也要联网。电脑可能开着代理，SSH 要经过路由，远程管理依赖 Tailscale，有时还得走 DERP 中继。它正在修改的那一段网络，随时可能把它自己踢下线。

所以每次出问题，我都得先分清到底断在哪里：是手机的测试流量不通，电脑的代理断了，AI 连不上模型服务，还是管理主机的 SSH 进不去了。必要时，我得切回上级网络，恢复代理或管理入口，才能让它继续查。

当时我想得挺乐观：接线、掉网、断代理这些事由我处理；AI 的终端出了问题，我可以手工检查；缺了脚本，还能去找网页版 AI 写。只要让它一直保持在线，剩下的事情总能做完。

后来，H3C 的有线中继模式把我折腾得道心破碎。

我把 H3C NX30 Pro 接到下游，设成有线中继，也就是 AP 模式。上游网线接入 H3C，再由它把手机等无线设备接进 OpenWrt 的网络。

手机能拿到地址，国内网站直连也能打开，可一开代理、用上我的节点，网站就打不开了。换到上级 Wi-Fi 或蜂窝网络，同一部手机、同一个节点又都正常；手机继续连着 H3C，换成其他代理节点，也能用。

我把 Astra 开到最高档，让 AI 开始排查。

AI 几次下结论，我几次把它拉回来

换个网络就能用，为什么说节点坏了？

换节点后恢复，AI 给过这样的回答：

明白，换节点后恢复，说明这次故障出在代理节点，先跳过。

可换节点的同时，目标地址变了，经过的上游路径可能变了，沿途设备处理流量的条件也可能变了。换完能用，只能说明这两组条件下的结果不同，还不能认定原来的服务器坏了。

我把那条被它漏掉的事实补了回去：同一个节点，在蜂窝网络和上级 Wi-Fi 下都正常，只有经过 H3C 的这条路径不行。

它随后更正：

明白，之前“节点本身有问题”的结论需要更正：同一节点能在其他网络使用，说明故障与当前网络路径有关。

我自己一开始也说过“现在是否是节点的兼容性问题”这种话。模型可能顺着我的猜测，直接把它说成了结论。

打临时补丁有效

排查早期，我试过调整 MSS，把相关流量的 MSS 临时限制到 1280。两个方向各命中 16 个包，手机还是打不开，于是撤掉了规则。这次尝试没有解决问题。

随后查到了 TTL 差异。经过我同意，AI 做了一次九十秒的定向实验，把相关流量的 TTL 统一设为 64。这回手机能打开网站了；可实验结束、规则自动删除后，我重新连接，又打不开了。

当时的实验记录是：

 23:32，MSS1280临时对照
  双向命中：16 / 16
  手机反馈：仍然打不开
  结束状态：临时规则已删除

 23:47前后，TTL64临时对照
  测试时限：90秒
  规则命中：1228个包
  加规则后：能打开
  删除并重新连接后：又打不开

至少这次实验说明，调整 TTL 能暂时缓解问题，也值得沿着这条线继续查。

AI 接着建议把规则保存下来，让它长期生效。如果只是急着恢复上网，这个办法有用。但我搭这套东西，本来就是想折腾明白：有线中继原本应该正常工作，为什么非得改写包头才能用？加上补丁就收工，我还是不甘心。

其他节点的 TTL 也在变，为什么不断线？

查到这里，我开始主动修改 Linux 测试连接的 TTL。最先试的是建连后从 64 改成 63，以及从 64 改成 65，两种情况下连接都被重置了。模型总结道：

所以“节点遇到 TTL 变化会断线”并非 OpenWrt 独有的问题。

测试能说明这种现象不只发生在 OpenWrt 下，却还不足以说成“TTL 一变就会断线”。

我让它再看另一组结果：有些正常节点的流量里也混着不同的 TTL，连接却能持续传输。普通直连流量会怎样？如果 TTL 变化就会断线，那这些成功的连接又怎么解释？

后来的测试矩阵补上了 64→62，结果连接正常，公网映射也保持稳定。先前那个结论显然说大了。模型后来改口：

因此，这台VPS也能接受TTL变化。真正导致失败的是连接的公网身份在途中变了。

从这里开始，调查的重点变了。TTL 仍然是一条线索，但它发生变化，不代表连接一定会断。接下来要查的是，同一条连接的公网源地址和端口，为什么会在中途改变。

从手机抓包，一路查到硬件转发

回头看，这次排查最初也从常见问题开始：DHCP、网关、DNS、代理配置。OpenWrt 实际发出的 DHCP ACK，加上手机端查到的参数，说明无线设备已经能通过 H3C 拿到正确的网关和 DNS。H3C 当时也显示桥接成功。至少在那一轮观察中，不能再简单地说“AP 没接通”，或者觉得“再开一个 DHCP 就好了”。

接着要确认手机流量是否经过 OpenWrt。查到后面，只在 PVE 上抓包已经不够了。PVE 能看到的是报文经过 H3C 有线上联之后的样子，它的两个接口并不分处 H3C 前后，不能拿来做 H3C 两侧的对照。

于是，我用 Apple 通信组件和 pcapd 建立了 iPhone 的 USB 抓包入口，再把手机发出的报文和 PVE 网口上的报文逐条对应。

凌晨的一轮记录里，手机侧 139 条出站记录的 TTL 都是 64。其中，125 条能在 PVE 下联网口找到对应记录：54 条的 TTL 变成了 63，71 条仍然是 64。再从物理网口往虚拟机接口匹配，找到的 123 条记录中，TTL 没有继续变化。

这样就把范围缩小到了手机 Wi-Fi 观察点和 PVE 下联网口之间，H3C 从无线转到有线的中继路径成了主要疑点。

我又分别看了 2.4GHz 和 5GHz，两个频段都能复现，不像是某个频段独有的问题。在一次 2.4GHz 采集中，173 个客户端源端口的流量都出现了 TTL64/63 混杂的情况。当轮的 SYN、FIN、RST 报文保持 TTL 64，后续 ACK 和数据报文里，却有一部分变成了 63。

看到这种分布，我怀疑报文走了不同的转发路径：建连和退出时走常规处理，后续一部分报文走快速转发。如果某条加速路径把桥接流量按路由流量处理，额外减了一次 TTL，就可能出现眼前这种情况。

但这个猜测还没法坐实。我没有拿到 H3C 内部的流表、驱动状态或寄存器信息，手机 USB 抓包也不等于无线空口抓包。设备型号和固件已经确认是 NX30 Pro、NX30ProV100R010，管理页面里却找不到能直接开关、用来做对照的加速选项。诊断导出接口倒是返回过成功，实际下载文件时却报了 HTTP 404。

本来只是想弄清一个设置该怎么填，最后已经查到了 PPE、HNAT、无线驱动和硬件转发。

TTL 异常之外，连接的公网来源也变了

一个是局部链路上的 TTL 处理不一致。TTL 是 IPv4 包头里的跳数限制，报文经过三层路由时通常会递减，普通桥接则不该额外减一次。这次遇到的也不是 TTL 减到零、报文被丢弃，而是同一条连接经过 AP 相关链路后，有些报文的 TTL 减了，有些没减。

另一个是同一条 TCP 连接的公网来源发生了变化。能确认的是，这个变化出现在 PVE 上联观察点之后、VPS 接收点之前。

前一个现象和手机经过 H3C 的路径有关，后一个还牵涉到我看不见的上游。直接说“H3C 改坏了 TTL，所以全是它的问题”，仍然解释不全。

有一条源端口为 65204 的真实手机连接，很能说明问题。这里用 A、B 代替公网 IP，目标统一称为“问题 VPS”：

观察点SYN 建连报文后续 517 字节数据
iPhone手机:65204，TTL64同源地址和端口，TTL64
H3C 后、PVE 下联网口手机:65204，TTL64同源地址和端口，TTL63
OpenWrt 后、PVE 上联网口OpenWrt WAN:65204，TTL63同源地址和端口，TTL62
VPS公网 A:17858，TTL41公网 B:49691，TTL40

在手机看来，数据始终发在同一条连接里。OpenWrt 出口看到的私网源地址和端口也没有变。可到了 VPS，建立连接的是 A:17858，后续数据却来自 B:49691，服务端找不到与之对应的原有 TCP 连接状态。

包头还能进一步对上：这段数据的 ACK 值是 1667561870，VPS 随后发出的 RST 序号也是 1667561870，手机侧也找到了对应的接收记录。在 VPS 本机的记录里，收到这段数据与发出 RST 之间只隔了约 0.180 毫秒。

这个时间只是 VPS 上的采样结果，不能拿来当跨设备的网络时延。它说明重置紧跟在来源变化的数据之后发生，再结合对应的包头字段，就能把这几条记录联系起来。TCP 找不到相应连接状态时如何处理这类报文，可以对照 RFC 9293 的规则。

换成路由模式后能用了，但非常不稳定

后来我把 H3C 切成路由模式，又同步抓了一轮手机、PVE 两个接口和 VPS 的流量。

这时手机进入 H3C 自己的子网，先由 H3C 做一次 NAT，再经过 OpenWrt 和上级主路由。OpenWrt 仍然在这条路径上，只是前面多了一层路由和 NAT。

这一轮的三条新建连接都有实际传输，服务端也有确认，各自的公网来源保持稳定，没有观察到对应的连接重置。我反复测试，百度和 DuckDuckGo 都能打开。

匹配到的出站报文，TTL 变化也一致了：

手机64 → H3C后63 → OpenWrt后62 → VPS40

报告里一共列了 173 条四个观察点都能匹配的记录，对应 132 个不同的 VPS 观察时间。手机抓包里有重复记录，所以这不等于做了 173 次独立的成功实验。PVE 两个接口和 VPS 的采集丢包计数都是零，但手机接口没有提供同样的计数，也不能因此说所有观察点都没有丢包。

这些记录说明，路由模式下确实出现了稳定传输，包头和连接行为也对得上。不过，切换模式同时改变了客户端子网、NAT 和连接状态，我也没有紧接着再切回 AP 模式，完成同一轮 AP→路由→AP 的往返对照。因此，目前能说的是问题与工作模式有关，还不能认定某个硬件加速模块就是根因。

我暂时保留了路由模式。这样用也有后续麻烦：Home Assistant 在 H3C 上游，以后接到 H3C 后面的设备能不能被发现、Home Assistant 能不能主动访问它们，还得单独测试。无线设备经过 NAT 后，OpenWrt 看到的来源都集中到了 H3C 地址，想按不同终端设置策略也会更麻烦。

而且，能打开网站以后，这个节点的使用体验还是很差，时不时断开。之前走网线时明明表现很好，还是条个人的 CN2/GIA 线路，折腾到这里实在有点郁闷。至少现在还不能说问题已经彻底解决。

看到 MiMo 2.6 的训练方案，我想到这次排障

这次折腾下来，我开始怀疑：像这样隔着好几层网络、有些地方看不到、还得反复修正猜测的任务，模型是不是练得还不够？

我说的“练得不够”，不只是读过多少 OpenWrt 文档。模型已经能解释 NAT、部署系统，也会写抓包脚本。我更想知道，它有没有充分练过这种需要连续追查、根据新结果推翻旧判断的现场任务。这是我从这次经历里生出的猜测，还不能据此判断它实际接受过哪些训练。

小米近期公开的 MiMo-V2.6 资料，让我有了一个可以参照的例子。官方发布了模型权重、技术报告、七千多个 RL 任务环境，以及端到端强化学习框架。这里公开的内容不能理解成全部预训练和 mid-training 数据，但已经能看出一部分智能体能力是怎样训练的。相关内容见小米官方发布说明。

技术报告第 7 页的 §3.2 介绍了 mid-training：把真实智能体任务轨迹与其他数据混合，为后续大规模 RL 做准备。第 4 节又讨论了训练规模、环境、工具框架和评价反馈。除了知识问答，训练也关注模型怎样完成一整段任务。我关心的就是这部分，以及过程中做得好不好，究竟由什么来判断。相关说明见 MiMo-V2.6 技术报告。

拿这次排障来说，我希望模型面对一张不完整的拓扑时，先弄清每个测试究竟经过了哪些设备。一个结果支持了猜测，还应该再找可能推翻它的对照；反例出现了，就修改总结，撤回说得太满的结论。看不到设备内部，也可以想办法设计下一项实验，继续缩小范围。通用原理能帮助分析，却不能直接拿来当作这次故障已经发生的事实。

怎么评价这段过程，也会影响模型最后把事情做到哪一步。如果只看“网站最后能不能打开”，加一条 TTL 补丁可能就够了。可如果目的是找到根因，就还得看它有没有分清临时缓解和彻底修复，能不能解释那些成功的反例，以及有没有把未经证实的猜测说成结论。

AI 在跑，我的判断得跟得上

开始之前，我已经大致理解了整套网络，所以能把硬件接好、管理入口准备好，让 AI 很快完成部署。等到真正排障时，才发现光知道整体结构还不够。

手机、Debian、PVE 发出的测试流量，各自经过哪些设备，我得分清。管理电脑通过哪条代理访问模型服务，改动哪个地方会同时切断测试和求助通道，也得心里有数。接口名尤其不能想当然：机箱上的物理网口、PVE 的 nic0/nic1、OpenWrt 虚拟机里的 eth0/eth1，要逐个确认对应关系，不能光看名字就认成同一个。

还得能跟着数据包往下查。DHCP 拿到地址，DNS 完成解析，TCP 建连成功，各自只能说明对应的一步走通了。即使 TCP 已经连上，也不代表后续数据会一直留在同一个 NAT 映射里。前面已经查清的部分，不能一遇到新问题，又被一句“网络不通”全部抹掉。

更费心的是记清每个判断从哪里来。手机上反馈“能打开”，和在一个接口抓到包，能说明的事情不一样；多个位置的报文能对应起来，和在同平台代码里找到一种可能机制，也不能混为一谈。旧结论被推翻后，还得在交接材料里写清楚，否则下一轮模型很可能又把它当成事实，重新走一遍老路。

先用着，等新模型再来试

目前 H3C 继续用路由模式，虽然能上网，节点仍然时不时断开。有线中继模式的根因调查暂时停在这里，还有两处没查清：H3C 内部到底怎么处理这些报文，连接的公网来源又是在上游哪一段发生了变化。

以后有条件，可以保持上游不变，换一台 AP 做对照；也可以在相邻时间里完成 AP→路由→AP 的往返测试。如果能拿到厂商支持的加速开关或诊断资料，就有机会继续检查 H3C 内部的情况。上游这边还缺 WAN 状态、边界处的包头或 NAT 状态，有了这些，才能进一步缩小问题范围。

我也打算等新模型出来，再把这个问题交给它试试。原始包头、实验矩阵、分析脚本都留着，已经撤回的判断和仍然缺少的证据也一起记下来。下次接着查，至少不用再从“是不是 DNS”开始。