Mac mini网络问题排查

问题背景

近期尝试在Mac mini上通过Ollama来部署一个本地小LLM，在部署后暴露给校园网，可以让我在链接校园网的情况下在其他设备上使用。

但是遇到了一个很诡异的问题，具体表现如下：

• 我在我的笔记本上通过Cherry Studio使用Mac mini Ollama上的模型。Cherry Studio有时会报错“网关错误”
• 使用浏览器直接访问Mac mini的地址+Ollama对应的端口，正常来说，应该显示Ollama is running。但是有的时候会报502错误。
• 在笔记本上ping mac mini的地址： 正常情况

64 bytes from 192.168.x.y ttl=64 time≈1ms

但是有时会发生：

64 bytes from 192.168.x.y: icmp_seq=85 ttl=64 time=0.820 ms
64 bytes from 192.168.x.y: icmp_seq=86 ttl=64 time=0.851 ms
Request timeout for icmp_seq 87
Request timeout for icmp_seq 88
Request timeout for icmp_seq 89
64 bytes from 192.168.x.y: icmp_seq=90 ttl=32 time=0.946 ms
64 bytes from 192.168.x.y: icmp_seq=91 ttl=32 time=0.993 ms
64 bytes from 192.168.x.y: icmp_seq=92 ttl=32 time=2.193 ms

在ttl为32时，无法正常访问Ollama服务

• 当我在笔记本上通过ssh连接Mac mini时，可以观测到，ping记录会出现数条Request timeout，随后恢复为正常的ttl=64

在数月前，我也曾在Mac mini上部署过Minecraft服务器，我在别的设备上游玩，有时也会发生卡顿的情况。按理来说，我的笔记本和Mac mini同时使用同一个路由器，甚至还是通过以太网电缆有线连接的，网络不应该这么不稳定。

考虑到本身我使用的路由器配置比较复杂，我怀疑是路由器本身配置有问题，于是在与gpt充分沟通后，打算使用codex，让codex通过ssh执行指令来检查路由器的log和配置，来排查问题。

问题排查

我要求gpt总结对话，并将gpt总结的内容交给codex。

我所给的提示词如下：

我的路由器在192.168.x.y，当前遇到了问题。我希望你通过SSH连接到路由器，并进行排查 。我已经在路由器的root账号配置了key，因此可以直接通过ssh登陆，无需密码。 我希望你进行排查，但不要进行任何更改。请你找到问题所在，最好能90%确定问题所在，后续告诉我建议的解决方案。 遇到的问题如下：

---
gpt的内容总结

---
路由器的基本情况如下：
...

codex在执行若干命令，并进行思考后，回复我的内容摘选：

结论先说：我现在大约有 90% 以上把握，问题主因不是 OpenWrt 的 ARP / bridge / offload 逻辑，而是 Mac mini <-> 路由器 lan2 这条物理链路在反复掉线重协商。更具体地说，优先怀疑 网线 / 水晶头 / Mac mini 网口或转接器 / 路由器 lan2 口 其中之一，lan2 口本身也有嫌疑。

关键证据：

- brctl showmacs br-lan 显示 Mac mini 的 MAC <.....> 当前学习在 port 2，而 brctl showstp br-lan 映射 port 2 = lan2。也就是 192.168.x.y 确实在 lan2。
- 内核日志里 lan2 大量出现物理链路事件，例如：
    - 2026-03-13 20:42:23 lan2: Link is Down
    - 2026-03-13 20:42:25 lan2: Link is Up - 100Mbps/Full
    - 2026-03-13 20:31:16 lan2: Link is Down
    - 2026-03-13 20:31:23 lan2: Link is Up - 1Gbps/Full
- 从启动到现在，lan2_down=136、lan2_up=136，这已经不是偶发的上层异常，而是 PHY 链路在反复 flap。
- lan2 当前状态就是 carrier=1 speed=100 duplex=full。如果这条链路本来应该是千兆，现在只协商到 100M，这是非常典型的线缆/接触/自协商问题信号。
- proxy_arp_all=0，proxy_arp_br_lan=0，proxy_arp_lan1/2/3=0，没有看到你之前怀疑的 proxy ARP 证据。
- 桥本身也很简单：br-lan 只桥 lan1/2/3 和 Wi‑Fi，STP 关闭。日志里的 entered blocking/forwarding 是端口掉线后重新加入桥的结果，不是 STP 收敛导致的根因。
- flow_offloading=1 和 flow_offloading_hw=1 确实开着，但它们不能解释内核已经明确记录的 lan2 Link is Down/Up。这类日志是物理/PHY 层事件。

总的来说，codex认为问题可能是路由器的lan口、Mac mini的网口、网线等硬件存在问题，建议我更换硬件。

但是我认为。如果是硬件存在问题，不会出现：ssh连接后就恢复正常的情况，这更有可能是软件上的问题。于是我要求codex继续研究。

codex在研究后，要求我在路由器和Mac mini上同时抓包来排查。

于是我将Mac mini连接到显示器，并直接通过键鼠操作（此前我一直使用SSH远程连接），发现问题没有再出现。

我恍然大悟，我想到问题很有可能是macOS存在某种机制，在Mac锁定后，就会暂停某些服务。而当我通过ssh远程连接后，这些服务就会短暂地恢复。

于是，我手动将Mac mini上的显示器关闭时，防止自动进入睡眠设为开。

实际上，此前我也曾设定过不活跃时关闭显示器为永不，但是可能这个设置并不能避免mac自动锁定。 

之后，问题没有再出现。