先说结案：“为什么当时只剩 18000”没有找到可以被证据确认的最终根因。 故障形态在后续复测时已经消失，现场又缺少故障时刻的路由器配置快照、UPnP 表和双向抓包。本文记录的是已排除什么、还缺什么证据，而不是宣布一个并未证明的答案。

0. 三条结案结论

结论一：AI 工具超时的根因已经确认

sing-box 当时是 enabled，但实际状态为 inactive。因此 Codex、grok、agy 等程序直连国外服务并超时。恢复 sing-box 后，三者单轮请求均成功。

sing-box 被停止 → AI/开发工具出站超时

这条证据完整，已经结案。

结论二：公网 3000 意外开放的根因也已经确认

排障自动化误调用了路由器 UPnP AddPortMapping，临时创建了：

公网 3000 → 内网 Open WebUI :3000

它后来被删除。这个安全事故发生在排障过程中，不是“只剩 18000”的原因，也不能解释 13000、28888 此前为何一度不可达。详细过程见姐妹篇《我没手动映射 3000，公网为什么还能访问？》。

结论三：“只剩 18000”的历史入站故障没有定根因

当时记录过 18000 可达、13000 和 28888 不可达；但后续外部复测时，13000 已恢复为 HTTP 200，公网 3000 按设计不可达，原来的故障组合无法稳定复现。由于没有保留故障时刻的完整映射表和抓包，下面这些都只能算候选：

• 路由器手动映射当时未生效或状态发生变化；
• UPnP/手动映射表与记忆不一致；
• TUN、策略路由与 Docker bridge 曾影响特定回程；
• 路由器或运营商出现过瞬时状态。

现有证据不足以在这些候选中选出一个。 如果以后再复现，必须先保存现场再改配置。

当前能确认的是健康边界，而不是历史根因：

公网 13000 → 内网 Open WebUI :3000   ✅ 本次复测 HTTP 200
公网 3000                            ❌ 无 UPnP 映射，本次公网不可达
sing-box                             ✅ active + enabled，只负责本机出站

历史上的 18000、28888 只作为排障线索保留，不写成当前状态。

1. 当时看到的“诡异形状”

故障现场记录大致是：

这里必须强调两点：

1. “公网 3000 关闭”不是故障，它是设计要求；
2. “只剩 18000”是当时某个时间窗口的外部观察，不能直接推导出永久状态或唯一根因。

第一反应通常是：

• 是不是 TUN 把入站回包送进代理了？
• 是不是 Docker bridge 和策略路由冲突？
• 是不是运营商只放行某个端口？
• 是不是路由器的映射根本没生效？

这些都可以成为假设，但必须逐层取证。

2. 三个平面必须拆开

家用服务器的网络问题至少有三个平面：

A. 本机出站
   本机进程 → sing-box TUN → 国内直连 / 国外经 VPS

B. 公网入站
   公网客户端 → 家宽公网 IP:外部端口 → 路由器 NAT 映射

C. 本机服务
   宿主机或 Docker 是否监听内网端口

它们的典型故障表现不同：

当天 A 和 B 的现象同时出现，所以直觉会说“透明代理把所有网络都弄坏了”。但：

同时发生，不等于由同一个配置造成。

排查顺序应该是：

先 C（服务）→ 再 B（公网映射）→ 最后检查 A 是否影响回程

3. 先固定对照组，但不要过度解释

18000 当时能从公网访问，是一个很有价值的对照组。它至少能说明：

• 当时存在可用的家宽公网入站路径；
• 如果 18000 是通过同一个 DDNS 名称和同一个公网 IP 测试的，那么该名称与地址至少在该次测试中有效；
• 运营商并非封锁所有入站；
• 路由器至少有一条转发规则在工作。

但它不能单独证明：

• 其他端口一定被运营商封锁；
• TUN 对所有 Docker 端口都有问题；
• 路由器里其他手动映射一定存在且生效；
• 28888 与 13000 的故障原因完全相同。

对照组的作用是缩小范围，不是替代证据。

4. 从本机服务开始：先排除 C

对每个服务先做本机检查：

ss -tlnp | grep -E ':3000|:8000|:28888'
curl -I http://127.0.0.1:3000/
curl -I http://127.0.0.1:8000/
curl -I http://127.0.0.1:28888/

这里用 HEAD 只是快速探测；部分正常应用不支持 HEAD，可能返回 405。遇到这种情况应改用普通 GET，不要把 405 当成服务宕机。

再从另一台局域网设备测试：

curl -I http://192.168.x.x:3000/
curl -I http://192.168.x.x:28888/

如果本机和 LAN 都正常，能够排除：

• 容器完全没启动；
• 应用只监听 127.0.0.1；
• Docker 没发布端口；
• 局域网路径完全断开。

但这仍然不能证明公网映射存在。

5. 公网映射必须同时检查两张表

路由器通常至少有：

1. 手动端口转发 / 虚拟服务器表；
2. UPnP 动态映射表。

两张表的语义不同：

手动表：管理员明确声明的长期入口
UPnP 表：内网程序临时或长期申请的动态入口

因此会出现两种看似相反的故障：

• 手动写了端口，但公网不通：检查规则是否启用、内外端口、目标 IP、WAN 接口和服务监听；
• 手动没写端口，但公网能通：检查 UPnP 是否由内网程序添加了动态映射。

本次另一个事故正是后者：排障自动化曾主动创建 公网 3000 → 内网 3000 的 UPnP 映射。那不是 TUN 自动开孔，也不是路由器被穿透。

6. TUN 可能影响回程，但必须用实验确认

透明代理确实可能影响公网入站回程，尤其在 Linux 策略路由、Docker bridge 和自定义 nftables 同时存在时。

可能出现的路径是：

公网 SYN 经路由器 DNAT 到宿主机/容器
服务生成 SYN-ACK
策略路由错误地把回包送入 TUN
回程路径与入站路径不对称
公网客户端看到超时或 reset

所以“查 TUN”是合理的，但不能只凭时间线定罪。

更可靠的 A/B 测试

在维护窗口中短暂停止代理。先安排自动恢复，避免 SSH 中断或操作者忘记重启：

# 两分钟后兜底恢复
sudo systemd-run --unit=sing-box-test-restore --on-active=2m \
  /bin/systemctl start sing-box

sudo systemctl stop sing-box
# 立即从异地 VPS 或手机流量复测目标端口
sudo systemctl start sing-box
sudo systemctl stop sing-box-test-restore.timer 2>/dev/null || true
sudo systemctl is-active sing-box

解释结果：

• 停止后端口立刻恢复：继续查 TUN、策略路由、Docker bridge 和回程；
• 停止后仍不通：优先查路由器映射和服务目标，不要继续折腾出站代理。

本次实际观察到：sing-box 停止后，AI 工具立刻失去国外连接；而缺少公网映射的端口不会因此自动恢复。这证明不能靠长期停代理解决入站问题。

7. 为什么增加 auto_redirect

原配置使用：

"auto_route": true

后来增加：

"auto_redirect": true

sing-box 官方文档建议 Linux TUN 使用 auto_redirect，原因包括：

• 使用 nftables 改善透明路由性能；
• 避免 TUN 与 Docker bridge 的部分冲突；
• 更准确地处理本机输出与转发流量。

但必须说清楚边界：

auto_redirect = 改善本机透明路由
它不会调用路由器 UPnP
它不会创建公网端口映射
它也不能替代路由器手动转发

当前 sing-box 保持 active + enabled，auto_route 与 auto_redirect 同时启用。

8. 一组比“猜运营商”更有效的实验

实验 A：公网视角逐端口验证

必须从异地网络执行：

curl -v --connect-timeout 5 http://公网IP:13000/
curl -v --connect-timeout 5 http://公网IP:3000/

当前预期是：

13000 → HTTP 200
3000  → 连接失败

实验 B：交换内网目标

如果需要判断“外部端口问题”还是“内部服务问题”，优先使用预先批准的测试端口，并限制来源为测试 VPS。只有在确认目标服务已有认证、能够接受短时公网暴露且业务允许中断时，才临时把一个已知入口转发到另一个内部服务。

这个实验会中断原端口业务并改变公网暴露面，必须：

• 先记录原规则并取得授权；
• 配置源 IP 白名单；
• 确认目标服务认证有效；
• 明确测试时间，测完立即恢复；
• 不使用未经授权的新公网端口。

实验 C：核对路由器两张表

手动表：只应存在经过确认的长期入口
UPnP 表：任何陌生映射都要追溯申请者

如果应用不依赖 UPnP，最稳妥的做法是关闭它；若游戏机等设备需要，则至少定期审计动态映射。

9. NAT 回环为什么不能当判决书

在家里 Wi‑Fi 访问 DDNS 域名，可能经过 NAT 回环：

LAN 客户端 → 家宽公网 IP → 路由器 hairpin NAT → LAN 服务

不同固件处理差异很大，可能出现：

• LAN 访问公网域名正常，异地公网却不通；
• LAN 回环失败，但异地公网正常；
• 手动规则与 UPnP 规则在回环路径上的行为不同。

这些证据不是简单的强弱排序，而是分别回答不同问题：异地 VPS/手机流量证明外部可达性，路由器映射表证明配置状态，LAN 回环只证明该固件下的 hairpin 行为。三者应互相印证，不能互相替代。

本机访问 192.168.x.x:3000 只证明 LAN 服务正常，与公网 13000 是否可达是两个问题。

10. 已验证事实、历史现象与未决项

为了避免博客把不同时间点混成一个“真相”，最好明确分层。

本次排障会话（2026-07-14）已验证事实

下表是本次会话中的实际复测结果，不是对未来状态的永久保证。

历史排障现象

• 某个时间窗口里，18000 被当作唯一稳定的公网对照组；
• 13000、28888 曾被报告不可达；
• sing-box 曾被手动停止，随后 AI 工具出站超时。

不应从现有证据推出的结论

• 不能断言“安装 sing-box 导致所有其他端口失效”；
• 不能断言“运营商只放行 18000”；
• 不能把 28888 的历史状态写成当前最终状态，除非重新从公网验证；
• 不能把公网 3000 关闭描述为“映射丢失”，因为它本来就不该开放。

11. 排除法总表

12. 最终运维边界

本机服务：
  Open WebUI 内网 :3000

公网入站：
  13000 → 3000   ✅ 手动配置、唯一设计入口
  3000           ❌ 必须关闭
  其他历史端口    以当前公网复测和路由器配置为准

本机出站：
  sing-box TUN 保持 active + enabled
  auto_route + auto_redirect
  不通过 HTTP_PROXY alias 给每个命令重复配置

安全：
  高位端口不是认证
  Open WebUI 必须启用登录和强密码
  不允许排障自动化未经确认调用 AddPortMapping

13. 写给未来的自己

“只剩 18000”这类故障，真正有价值的不是找到一个听起来完整的故事，而是拒绝过早把相关性写成因果：

1. 先固定仍然正常的对照组；
2. 把应用、LAN、公网 NAT、TUN 出站拆开；
3. 从公网获取硬证据；
4. 同时检查手动映射与 UPnP；
5. 每次只改一个变量，改完立即复测并恢复边界；
6. 对未重新验证的历史端口，明确写“未知”，不要补全剧情。

透明代理会改变本机出站路径，也可能影响复杂场景下的回程；但它不会凭空修改路由器的端口映射。只有把这两个层面分开，排障才不会从一个问题制造出另一个安全事故。

本文与《我没手动映射 3000，公网为什么还能访问？》为姐妹篇：一篇复盘已经确认的 UPnP 误映射，一篇记录尚未定根因的历史入站故障及下次应如何保全证据。环境信息已匿名化。
日期：2026-07-14

公网曾经“只剩 18000”：这次没抓到入站根因，我们到底确认了什么？

先说结案：“为什么当时只剩 18000”没有找到可以被证据确认的最终根因。 故障形态在后续复测时已经消失，现场又缺少故障时刻的路由器配置快照、UPnP 表和双向抓包。本文记录的是已排除什么、还缺什么证据，而不是宣布一个并未证明的答案。

0. 三条结案结论

结论一：AI 工具超时的根因已经确认

sing-box 当时是 enabled，但实际状态为 inactive。因此 Codex、grok、agy 等程序直连国外服务并超时。恢复 sing-box 后，三者单轮请求均成功。

sing-box 被停止 → AI/开发工具出站超时

这条证据完整，已经结案。

结论二：公网 3000 意外开放的根因也已经确认

排障自动化误调用了路由器 UPnP AddPortMapping，临时创建了：

公网 3000 → 内网 Open WebUI :3000

它后来被删除。这个安全事故发生在排障过程中，不是“只剩 18000”的原因，也不能解释 13000、28888 此前为何一度不可达。详细过程见姐妹篇《我没手动映射 3000，公网为什么还能访问？》。

结论三：“只剩 18000”的历史入站故障没有定根因

当时记录过 18000 可达、13000 和 28888 不可达；但后续外部复测时，13000 已恢复为 HTTP 200，公网 3000 按设计不可达，原来的故障组合无法稳定复现。由于没有保留故障时刻的完整映射表和抓包，下面这些都只能算候选：

• 路由器手动映射当时未生效或状态发生变化；
• UPnP/手动映射表与记忆不一致；
• TUN、策略路由与 Docker bridge 曾影响特定回程；
• 路由器或运营商出现过瞬时状态。

现有证据不足以在这些候选中选出一个。 如果以后再复现，必须先保存现场再改配置。

当前能确认的是健康边界，而不是历史根因：

公网 13000 → 内网 Open WebUI :3000   ✅ 本次复测 HTTP 200
公网 3000                            ❌ 无 UPnP 映射，本次公网不可达
sing-box                             ✅ active + enabled，只负责本机出站

历史上的 18000、28888 只作为排障线索保留，不写成当前状态。

1. 当时看到的“诡异形状”

故障现场记录大致是：

这里必须强调两点：

1. “公网 3000 关闭”不是故障，它是设计要求；
2. “只剩 18000”是当时某个时间窗口的外部观察，不能直接推导出永久状态或唯一根因。

第一反应通常是：

• 是不是 TUN 把入站回包送进代理了？
• 是不是 Docker bridge 和策略路由冲突？
• 是不是运营商只放行某个端口？
• 是不是路由器的映射根本没生效？

这些都可以成为假设，但必须逐层取证。

2. 三个平面必须拆开

家用服务器的网络问题至少有三个平面：

A. 本机出站
   本机进程 → sing-box TUN → 国内直连 / 国外经 VPS

B. 公网入站
   公网客户端 → 家宽公网 IP:外部端口 → 路由器 NAT 映射

C. 本机服务
   宿主机或 Docker 是否监听内网端口

它们的典型故障表现不同：

当天 A 和 B 的现象同时出现，所以直觉会说“透明代理把所有网络都弄坏了”。但：

同时发生，不等于由同一个配置造成。

排查顺序应该是：

先 C（服务）→ 再 B（公网映射）→ 最后检查 A 是否影响回程

3. 先固定对照组，但不要过度解释

18000 当时能从公网访问，是一个很有价值的对照组。它至少能说明：

• 当时存在可用的家宽公网入站路径；
• 如果 18000 是通过同一个 DDNS 名称和同一个公网 IP 测试的，那么该名称与地址至少在该次测试中有效；
• 运营商并非封锁所有入站；
• 路由器至少有一条转发规则在工作。

但它不能单独证明：

• 其他端口一定被运营商封锁；
• TUN 对所有 Docker 端口都有问题；
• 路由器里其他手动映射一定存在且生效；
• 28888 与 13000 的故障原因完全相同。

对照组的作用是缩小范围，不是替代证据。

4. 从本机服务开始：先排除 C

对每个服务先做本机检查：

ss -tlnp | grep -E ':3000|:8000|:28888'
curl -I http://127.0.0.1:3000/
curl -I http://127.0.0.1:8000/
curl -I http://127.0.0.1:28888/

这里用 HEAD 只是快速探测；部分正常应用不支持 HEAD，可能返回 405。遇到这种情况应改用普通 GET，不要把 405 当成服务宕机。

再从另一台局域网设备测试：

curl -I http://192.168.x.x:3000/
curl -I http://192.168.x.x:28888/

如果本机和 LAN 都正常，能够排除：

• 容器完全没启动；
• 应用只监听 127.0.0.1；
• Docker 没发布端口；
• 局域网路径完全断开。

但这仍然不能证明公网映射存在。

5. 公网映射必须同时检查两张表

路由器通常至少有：

1. 手动端口转发 / 虚拟服务器表；
2. UPnP 动态映射表。

两张表的语义不同：

手动表：管理员明确声明的长期入口
UPnP 表：内网程序临时或长期申请的动态入口

因此会出现两种看似相反的故障：

• 手动写了端口，但公网不通：检查规则是否启用、内外端口、目标 IP、WAN 接口和服务监听；
• 手动没写端口，但公网能通：检查 UPnP 是否由内网程序添加了动态映射。

本次另一个事故正是后者：排障自动化曾主动创建 公网 3000 → 内网 3000 的 UPnP 映射。那不是 TUN 自动开孔，也不是路由器被穿透。

6. TUN 可能影响回程，但必须用实验确认

透明代理确实可能影响公网入站回程，尤其在 Linux 策略路由、Docker bridge 和自定义 nftables 同时存在时。

可能出现的路径是：

公网 SYN 经路由器 DNAT 到宿主机/容器
服务生成 SYN-ACK
策略路由错误地把回包送入 TUN
回程路径与入站路径不对称
公网客户端看到超时或 reset

所以“查 TUN”是合理的，但不能只凭时间线定罪。

更可靠的 A/B 测试

在维护窗口中短暂停止代理。先安排自动恢复，避免 SSH 中断或操作者忘记重启：

# 两分钟后兜底恢复
sudo systemd-run --unit=sing-box-test-restore --on-active=2m \
  /bin/systemctl start sing-box

sudo systemctl stop sing-box
# 立即从异地 VPS 或手机流量复测目标端口
sudo systemctl start sing-box
sudo systemctl stop sing-box-test-restore.timer 2>/dev/null || true
sudo systemctl is-active sing-box

解释结果：

• 停止后端口立刻恢复：继续查 TUN、策略路由、Docker bridge 和回程；
• 停止后仍不通：优先查路由器映射和服务目标，不要继续折腾出站代理。

本次实际观察到：sing-box 停止后，AI 工具立刻失去国外连接；而缺少公网映射的端口不会因此自动恢复。这证明不能靠长期停代理解决入站问题。

7. 为什么增加 auto_redirect

原配置使用：

"auto_route": true

后来增加：

"auto_redirect": true

sing-box 官方文档建议 Linux TUN 使用 auto_redirect，原因包括：

• 使用 nftables 改善透明路由性能；
• 避免 TUN 与 Docker bridge 的部分冲突；
• 更准确地处理本机输出与转发流量。

但必须说清楚边界：

auto_redirect = 改善本机透明路由
它不会调用路由器 UPnP
它不会创建公网端口映射
它也不能替代路由器手动转发

当前 sing-box 保持 active + enabled，auto_route 与 auto_redirect 同时启用。

8. 一组比“猜运营商”更有效的实验

实验 A：公网视角逐端口验证

必须从异地网络执行：

curl -v --connect-timeout 5 http://公网IP:13000/
curl -v --connect-timeout 5 http://公网IP:3000/

当前预期是：

13000 → HTTP 200
3000  → 连接失败

实验 B：交换内网目标

如果需要判断“外部端口问题”还是“内部服务问题”，优先使用预先批准的测试端口，并限制来源为测试 VPS。只有在确认目标服务已有认证、能够接受短时公网暴露且业务允许中断时，才临时把一个已知入口转发到另一个内部服务。

这个实验会中断原端口业务并改变公网暴露面，必须：

• 先记录原规则并取得授权；
• 配置源 IP 白名单；
• 确认目标服务认证有效；
• 明确测试时间，测完立即恢复；
• 不使用未经授权的新公网端口。

实验 C：核对路由器两张表

手动表：只应存在经过确认的长期入口
UPnP 表：任何陌生映射都要追溯申请者

如果应用不依赖 UPnP，最稳妥的做法是关闭它；若游戏机等设备需要，则至少定期审计动态映射。

9. NAT 回环为什么不能当判决书

在家里 Wi‑Fi 访问 DDNS 域名，可能经过 NAT 回环：

LAN 客户端 → 家宽公网 IP → 路由器 hairpin NAT → LAN 服务

不同固件处理差异很大，可能出现：

• LAN 访问公网域名正常，异地公网却不通；
• LAN 回环失败，但异地公网正常；
• 手动规则与 UPnP 规则在回环路径上的行为不同。

这些证据不是简单的强弱排序，而是分别回答不同问题：异地 VPS/手机流量证明外部可达性，路由器映射表证明配置状态，LAN 回环只证明该固件下的 hairpin 行为。三者应互相印证，不能互相替代。

本机访问 192.168.x.x:3000 只证明 LAN 服务正常，与公网 13000 是否可达是两个问题。

10. 已验证事实、历史现象与未决项

为了避免博客把不同时间点混成一个“真相”，最好明确分层。

本次排障会话（2026-07-14）已验证事实

下表是本次会话中的实际复测结果，不是对未来状态的永久保证。

历史排障现象

• 某个时间窗口里，18000 被当作唯一稳定的公网对照组；
• 13000、28888 曾被报告不可达；
• sing-box 曾被手动停止，随后 AI 工具出站超时。

不应从现有证据推出的结论

• 不能断言“安装 sing-box 导致所有其他端口失效”；
• 不能断言“运营商只放行 18000”；
• 不能把 28888 的历史状态写成当前最终状态，除非重新从公网验证；
• 不能把公网 3000 关闭描述为“映射丢失”，因为它本来就不该开放。

11. 排除法总表

12. 最终运维边界

本机服务：
  Open WebUI 内网 :3000

公网入站：
  13000 → 3000   ✅ 手动配置、唯一设计入口
  3000           ❌ 必须关闭
  其他历史端口    以当前公网复测和路由器配置为准

本机出站：
  sing-box TUN 保持 active + enabled
  auto_route + auto_redirect
  不通过 HTTP_PROXY alias 给每个命令重复配置

安全：
  高位端口不是认证
  Open WebUI 必须启用登录和强密码
  不允许排障自动化未经确认调用 AddPortMapping

13. 写给未来的自己

“只剩 18000”这类故障，真正有价值的不是找到一个听起来完整的故事，而是拒绝过早把相关性写成因果：

1. 先固定仍然正常的对照组；
2. 把应用、LAN、公网 NAT、TUN 出站拆开；
3. 从公网获取硬证据；
4. 同时检查手动映射与 UPnP；
5. 每次只改一个变量，改完立即复测并恢复边界；
6. 对未重新验证的历史端口，明确写“未知”，不要补全剧情。

透明代理会改变本机出站路径，也可能影响复杂场景下的回程；但它不会凭空修改路由器的端口映射。只有把这两个层面分开，排障才不会从一个问题制造出另一个安全事故。

本文与《我没手动映射 3000，公网为什么还能访问？》为姐妹篇：一篇复盘已经确认的 UPnP 误映射，一篇记录尚未定根因的历史入站故障及下次应如何保全证据。环境信息已匿名化。
日期：2026-07-14