编号：2025-12-18
负责人：ayazumi
签发：Kimi AI 助手
---
一、事故摘要
2025-12-18 06:23 左右，用户发现部署于 Ubuntu 笔记本的 Cloudflare Tunnel 双实例 同时失联，外网 SSH、Web 全部不可达。经远程排查，确认 Wi-Fi 接口曾正常重连，但 路由器 NAT 表在 WAN 重拨后未恢复，导致 入/出方向隧道包被持续丢弃；直至 12-18 18:24 用户母亲携带新设备回家，触发路由器广播唤醒，NAT 转发面恢复，服务瞬间上线。
---
二、Timeline（UTC+8）
时间事件状态
12-15 05:49路由器例行 PPPoE 重拨（租约到期）WAN 重新获取 IP
12-15 05:49→12-16 07:05电脑 Wi-Fi 完成重连，但路由 NAT 未恢复隧道重试失败
12-16 07:05电脑 Wi-Fi 再次掉线→重连同上
12-18 18:24用户母亲手机连 Wi-Fi，路由转发面唤醒隧道立即握手成功
12-18 18:25用户成功 SSH 登录，uptime 11 天未重启服务恢复
---
三、根因分析（RCA）
1. 直接原因
家用路由器固件缺陷：WAN 重拨后 未重新下发 NAT/防火墙规则，导致 Cloudflare Tunnel 的出站 443 可以握手，但回程包被丢弃，表现为“隧道永远重连失败”。
2. 放大因素
- 电脑仅用 单链路 Wi-Fi，无有线/蜂窝备份。
- 路由器 无定时重启/自动修复机制，NAT 表长期僵死。
- 用户此前未察觉，因 未对外暴露服务，无持续心跳监控。
3. 排除项
- Ubuntu 系统未崩溃（uptime 11 天）。
- Wi-Fi 驱动自救成功（日志显示 `disconnected → associated → completed`）。
- Cloudflare Tunnel 配置正确，断线后持续重试（日志见 `connection retry/backoff`）。
---
四、影响范围
项目影响
对外 SSH不可达 约 3 天
对外 Web不可达 约 3 天
数据丢失0（服务未宕机，仅网络不可达）
用户行程无需紧急回家，无额外成本
---
五、整改措施（已落地/计划中）
措施类型完成时间责任人
1. 路由器启用“每日 04:00 自动重启”临时规避2025-12-18 23:00用户
2. 笔记本加入 Wi-Fi watchdog 脚本（30 秒巡检）自愈增强2025-12-19 00:00用户
3. 部署备用 4G USB 网卡 + 低 metric 路由物理冗余2025-12-22 前用户
4. 接入 Home Assistant 智能插座，硬重启路由终极保底2025-12-25 前用户
---
六、经验教训
1. 家用宽带“凌晨重拨”是常态，NAT 僵死≠断线，需要主动刷新机制。
2. 单链路 + 单出口 = 高概率失联，至少保留一条异网备份。
3. 日志只能证明端侧正常，转发面故障需端侧以外手段解决（定时重启 / 冗余链路）。
---
七、结论
本次事件定性为 “路由器 NAT 僵死导致的假性断网”，电脑与服务本身健康。
通过“定时重启 + 链路冗余”双措施，预计可将未来同类中断时间从数天数小时降至 <30 秒，无需再人工回家复位。
负责人：ayazumi
签发：Kimi AI 助手
---
一、事故摘要
2025-12-18 06:23 左右，用户发现部署于 Ubuntu 笔记本的 Cloudflare Tunnel 双实例 同时失联，外网 SSH、Web 全部不可达。经远程排查，确认 Wi-Fi 接口曾正常重连，但 路由器 NAT 表在 WAN 重拨后未恢复，导致 入/出方向隧道包被持续丢弃；直至 12-18 18:24 用户母亲携带新设备回家，触发路由器广播唤醒，NAT 转发面恢复，服务瞬间上线。
---
二、Timeline（UTC+8）
时间事件状态
12-15 05:49路由器例行 PPPoE 重拨（租约到期）WAN 重新获取 IP
12-15 05:49→12-16 07:05电脑 Wi-Fi 完成重连，但路由 NAT 未恢复隧道重试失败
12-16 07:05电脑 Wi-Fi 再次掉线→重连同上
12-18 18:24用户母亲手机连 Wi-Fi，路由转发面唤醒隧道立即握手成功
12-18 18:25用户成功 SSH 登录，uptime 11 天未重启服务恢复
---
三、根因分析（RCA）
1. 直接原因
家用路由器固件缺陷：WAN 重拨后 未重新下发 NAT/防火墙规则，导致 Cloudflare Tunnel 的出站 443 可以握手，但回程包被丢弃，表现为“隧道永远重连失败”。
2. 放大因素
- 电脑仅用 单链路 Wi-Fi，无有线/蜂窝备份。
- 路由器 无定时重启/自动修复机制，NAT 表长期僵死。
- 用户此前未察觉，因 未对外暴露服务，无持续心跳监控。
3. 排除项
- Ubuntu 系统未崩溃（uptime 11 天）。
- Wi-Fi 驱动自救成功（日志显示 `disconnected → associated → completed`）。
- Cloudflare Tunnel 配置正确，断线后持续重试（日志见 `connection retry/backoff`）。
---
四、影响范围
项目影响
对外 SSH不可达 约 3 天
对外 Web不可达 约 3 天
数据丢失0（服务未宕机，仅网络不可达）
用户行程无需紧急回家，无额外成本
---
五、整改措施（已落地/计划中）
措施类型完成时间责任人
1. 路由器启用“每日 04:00 自动重启”临时规避2025-12-18 23:00用户
2. 笔记本加入 Wi-Fi watchdog 脚本（30 秒巡检）自愈增强2025-12-19 00:00用户
3. 部署备用 4G USB 网卡 + 低 metric 路由物理冗余2025-12-22 前用户
4. 接入 Home Assistant 智能插座，硬重启路由终极保底2025-12-25 前用户
---
六、经验教训
1. 家用宽带“凌晨重拨”是常态，NAT 僵死≠断线，需要主动刷新机制。
2. 单链路 + 单出口 = 高概率失联，至少保留一条异网备份。
3. 日志只能证明端侧正常，转发面故障需端侧以外手段解决（定时重启 / 冗余链路）。
---
七、结论
本次事件定性为 “路由器 NAT 僵死导致的假性断网”，电脑与服务本身健康。
通过“定时重启 + 链路冗余”双措施，预计可将未来同类中断时间从数天数小时降至 <30 秒，无需再人工回家复位。
