[🛠] IT Operations #1: 我如何解决公司路由器“无互联网连接”问题（feat. Codex）

✨ GPT-5.6 Sol 的总结

记录我把手机接到二楼路由器、把Mac浏览器接到公司路由器，让Codex直接诊断真实设备，并在观察过程中实时学习网络知识，最终恢复故障。

今天公司二楼的Wi-Fi出了问题。信号非常好，却无法连接互联网。路由器开着，手机也已经连上，但屏幕始终显示无互联网连接。

眼前的路由器正常通电，LAN指示灯也在闪烁。只看外观根本无法知道连接卡在哪里。

换作以前，我大概会把路由器反复重启几次，检查网线是不是插错了，如果还是不行，就先上网搜索。但两天前，在写懂得积极利用AI后，能做的事情变得无穷无尽时，我学会了一种新的工作方式。

只要把真实设备和画面连接给AI就行。

这次我直接用了这个方法。我用USB把手机连接到Mac，并打开ADB。手机连上出现问题的二楼Wi-Fi。在手机Chrome中打开并登录二楼路由器管理界面，在Mac Chrome中打开并登录公司路由器管理界面。然后，我向Codex下达了任务。

重点不在于我亲自弄懂了路由器的全部设置，而在于我先准备好实体设备、命令执行环境和已经登录的管理界面，让Codex能够真正开展工作。

先弄清楚当前状况。随便修改可能会出问题，所以尽量先尝试用命令解决。

此时Codex已经不再只是一个提供说明的聊天机器人。它可以通过命令读取手机的网络状态，借助Computer Use在我登录好的两个管理界面之间切换，检查并修改真实设置。

连接手机与浏览器，同时展示两个网络

一开始，我甚至不知道为什么打不开192.168.0.1。检查后才发现，两台路由器承担着不同角色。

公司路由器 192.168.0.1
  └─ 二楼ipTIME WAN 192.168.0.86
       └─ 二楼Wi-Fi / LAN 192.168.1.x
            └─ 二楼路由器管理界面 192.168.1.1

Mac连接着公司网络，因此能够打开公司路由器的192.168.0.1。而连接二楼Wi-Fi的手机获得了192.168.1.x地址，并使用192.168.1.1作为gateway。所以，我在Mac浏览器中打开公司路由器，在手机浏览器中打开二楼路由器。

我不只是把画面展示给Codex。ADB已经连接，因此Codex能够读取手机获得的IP与route，并指定二楼Wi-Fi interface，直接检查通信。即使Wi-Fi断开，手机也能通过移动数据成功访问互联网，所以如果只是直接执行ping，就可能误判结果。

adb shell "ping -I wlan0 -c 3 -W 2 192.168.1.1"
adb shell "ping -I wlan0 -c 3 -W 2 192.168.0.1"
adb shell "ping -I wlan0 -c 3 -W 2 1.1.1.1"

adb shell "curl --interface wlan0 -k -sS -o /dev/null \
  -w '%{http_code}' --connect-timeout 5 --max-time 10 \
  https://www.google.com/generate_204"

结果如下。

• 手机能够收到二楼路由器192.168.1.1的响应。
• 从公司路由器192.168.0.1开始便没有响应。
• 外部IP 1.1.1.1也没有响应。
• HTTPS检查以000结束。

我就在旁边看完了整个过程。Wi-Fi有信号，只说明手机和二楼路由器之间已经连接。问题出在下一段，也就是二楼路由器的WAN通往公司网络的区间。

我并没有先翻开网络教材，依次学习LAN、WAN、gateway与双重NAT。看着Codex把真实故障一段段拆开检查，我立刻理解了为什么192.168.0.1与192.168.1.1会同时存在。

DHCP lease正常，通信仍可能被阻断

同一天，开发NAS与数据NAS的IP也发生了变化。我在公司路由器的DHCP client列表中找到当前地址与MAC地址，并设置reservation，让两台NAS下次仍能获得相同地址。我也把通往此前迁移到NAS的年假自动化的HTTP与HTTPS port forwarding改为指向新地址。

在这个过程中，我也在刚好需要的时候学会了DHCP是什么。

• 普通DHCP分配会把空闲IP租给设备。
• DHCP reservation会在特定MAC地址连接时分配同一个IP。
• 在设备本身设置固定IP，与在路由器中设置DHCP reservation并不是一回事。

然而，二楼路由器的问题无法仅用DHCP reservation解释。ipTIME管理界面显示外部IP为192.168.0.86，状态也是已连接互联网。公司路由器中也有记录，表明同一个IP当前已租给ipTIME。

中途，Codex只查看了DHCP列表的当前page，误以为.86不存在。client超过90台，列表分成了多个page，而我已经在另一页见过那条记录。

不是有吗？

我再次指出MAC地址与.86的lease记录后，调查方向改变了。问题不在于没有获得IP，而是要寻找获得IP后阻断通信的设置。

断开WAN后重新连接，结果仍然一样。access control已经开启，但blacklist为空。随后，我在IP&MAC绑定界面找到了原因。.86绑定的不是当前ipTIME WAN MAC，而是以前使用过的desktop MAC。

DHCP server：当前把192.168.0.86租给ipTIME
IP&MAC binding：将192.168.0.86记录为旧PC MAC的地址

DHCP把地址分给了当前设备，但security设置认为这个地址属于另一台设备。因此，ipTIME在管理界面上看起来已经拿到IP，却无法与公司路由器通信。

获得IP与能够使用该IP通信不是同一回事。沿着故障查下去，我自然理解了这一区别。

只删除一条旧绑定，并在真实Wi-Fi上重新验证

我没有关闭路由器的整套security功能，只删除了.86对应的那一条旧IP–MAC绑定，然后重新协商ipTIME的WAN连接。

这一次，结果立刻变了。

192.168.0.1  ping成功
1.1.1.1      ping成功
HTTPS        204
Android Wi-Fi VALIDATED

恢复后，我又添加了DHCP地址reservation，让当前ipTIME WAN MAC始终获得.86。DHCP reservation会持续把同一地址分给当前设备，IP–MAC绑定则强制限定可以使用该地址的设备。这次故障正是因为两条记录指向了不同设备。

互联网恢复了，但二楼ipTIME仍在公司网络下建立了单独的192.168.1.x网络，双重NAT结构没有改变。若改为AP或hub mode，不仅要调整DHCP和管理IP，还要同时改变真实网线究竟插在WAN还是LAN端口。远程贸然操作，可能会同时失去管理界面与二楼所有设备，因此今天只修复了已经确认的互联网故障原因。

不是学完网络后再修，而是在修复过程中学习

今天我所做的事情，核心并不是提前学完网络知识后再修路由器。

问题发生后，我立刻拿出了7月22日发现的工作方式。先完成只有我能做的实体连接与登录。让手机连上二楼Wi-Fi，再通过USB连接Mac。分别打开两台路由器的管理界面。限定修改范围，并在Codex漏看DHCP记录时重新指出。

接下来，Codex便可以开始行动。它用命令确认通信能够抵达哪个区间，通过Computer Use读取两个管理界面的设置，逐一排除可能原因，只修改必要的一项，然后在同一部手机上重新验证。

我没有先把各种网络知识分别学完，再进入实战。眼下需要的概念直接附着在真实画面与命令结果上进入脑中。DHCP、MAC地址、gateway、LAN与WAN、IP–MAC绑定、双重NAT不再是需要背诵的术语，而成了解释眼前故障为何发生的工具。

AI也不是从一开始就永远正确。像漏看.86一样，它也会作出错误判断。但只要我查看真实画面，再次指出不合理之处，Codex就会立即进入下一项检查。我不需要预先知道所有命令和设置menu，但必须始终承担判断结果是否异常、重新确定目标的角色。

两天前，我第一次意识到，把浏览器和手机连接给AI，就能扩大自己可以直接处理的领域。今天，我把这个发现积极用在了真实的公司故障上。

先花几周学习陌生领域，再等某天投入实战，并不是唯一的方法。还可以和AI一起解决真实问题，在当下只学习所需的部分，并立刻做出结果。