封面：局域网部署排障复盘

今天折腾了一个看起来很简单、但实际很容易卡住的问题：在同一个内网里部署一个本地服务，让其他设备都能访问。

一开始我是在 Linux 上跑的。服务启动之后，本机能打开，局域网里的其他设备也能访问。后来我又在 Mac 和 Linux 之间试了几次，访问链路都是通的。到这里我基本确认两件事：

  1. 服务本身大概率没有问题。
  2. 当前局域网环境大概率也没有问题。

但问题出现在 Windows 上。

同样是把服务部署起来，换到 Windows 机器之后，本机看起来可以运行，但同一个内网里的其他设备就是访问不了。这个现象很典型：服务好像没坏，网络也不像完全不通，但从其他设备连进 Windows 这一步卡住了。

先把问题分层

第一章配图：先把问题分层

这类问题最容易让人一上来怀疑代码、框架、前端页面、端口、路由，甚至怀疑是不是整个局域网有问题。

但如果 Linux 和 Mac 都能正常访问，就说明问题不能简单归结为“服务不可用”。

更合理的排查方式，是把它分成几层：

  1. 服务有没有真的启动？
  2. 服务监听的是 127.0.0.1 还是 0.0.0.0？
  3. 端口有没有对外开放？
  4. Windows 防火墙有没有拦截入站连接？
  5. Windows 当前网络类型是“公用网络”还是“专用网络”？
  6. 如果服务跑在 Docker、WSL 或虚拟机里，端口映射是否正确？
  7. 路由器或局域网本身是否做了设备隔离？

这里面最关键的一点是：服务能不能在本机跑起来，和其他设备能不能通过网络访问到它，是两件事。

本机访问 localhost 成功，只能证明程序在本机能响应。它不能证明局域网里其他设备也能连进来。

Windows 上最容易忽略的点

第二章配图：Windows 入站访问排查

Windows 和 Linux/Mac 的差异，经常不在服务代码本身，而在“入站访问”这层。

比如服务如果只监听 127.0.0.1，那它只接受本机访问。局域网其他设备访问 Windows 的内网 IP 时，请求根本进不到这个服务。

又比如 Windows 防火墙默认可能会拦截某些端口的入站连接。服务启动了，端口也在本机打开了，但外部设备连接时仍然会失败。

还有一个常见细节是网络类型。如果 Windows 把当前网络识别成“公用网络”，它对入站连接会更保守；如果是可信任的内网环境，通常需要确认它是不是“专用网络”。

所以 Windows 部署失败时，我不会只看服务日志，还会额外看这些东西：

1
2
3
4
5
服务监听地址：127.0.0.1 还是 0.0.0.0
Windows 防火墙入站规则
当前网络类型：公用网络 / 专用网络
端口是否真的对外开放
Docker / WSL / 虚拟机端口映射

用 Cloudflare Tunnel 验证服务是否可用

第三章配图：Cloudflare Tunnel 验证服务可用

后来我用了 Cloudflare Tunnel 的临时通道，也就是 *.trycloudflare.com 这种地址，把本地服务暴露出去。

结果很有意思：通过这个公网临时地址，页面可以访问了。

这一步的价值不只是“访问成功了”，而是它帮我把问题切开了。

Cloudflare Tunnel 的工作方式大致是：本机主动向 Cloudflare 建立一条外连隧道，外部用户访问 Cloudflare 提供的 URL 时，流量再通过这条隧道转回本机服务。

这意味着它绕开了一个关键环节：外部设备不需要直接连进 Windows 机器。

所以当 *.trycloudflare.com 能访问时，至少说明：

  1. 服务本身大概率是活的。
  2. 服务对 Cloudflare Tunnel 进程是可达的。
  3. 真正的问题更可能出在“局域网设备直接访问 Windows 机器”的入站链路上。

换句话说，Cloudflare Tunnel 不是直接修好了 Windows 的局域网访问问题，而是提供了另一条访问路径，帮我验证服务本体没有死。

这次排障带来的结论

第四章配图：服务可用不等于网络可达

这次问题给我的最大提醒是：

服务可用，不等于网络可达；本机可访问，不等于局域网可访问。

Linux 和 Mac 跑通，建立了一个基线：服务逻辑和局域网环境大体没问题。

Windows 跑不通，说明问题更可能集中在 Windows 的监听地址、防火墙、网络类型、端口暴露、Docker/WSL 映射这些位置。

Cloudflare Tunnel 跑通，又进一步说明：服务本身是能工作的，只是直接从内网访问 Windows 的这条链路出了问题。

以后再遇到类似问题，我会按这个顺序排查：

  1. 本机访问 localhost:端口 是否成功。
  2. 本机访问 本机内网 IP:端口 是否成功。
  3. 其他设备访问 服务器内网 IP:端口 是否成功。
  4. 确认服务监听地址是否为 0.0.0.0。
  5. 检查 Windows 防火墙入站规则。
  6. 检查当前网络类型是否为专用网络。
  7. 如果使用 Docker/WSL/虚拟机，检查端口映射。
  8. 必要时用 Cloudflare Tunnel 这类工具验证服务本身是否可用。

这类问题看起来是“网络不通”，但真正有价值的排查方式，是把它拆成一层一层的问题：服务是否运行、端口是否监听、本机是否可达、局域网是否可达、外部隧道是否可达。

只要分层清楚，排障就不会变成纯靠运气乱试。