404到底是不是网络不通？从HTTP链路到Nginx/Tomcat等实战排查

先给结论：绝大多数情况下，网络不通不会显示 404。这个状态码出现的时候，通常说明你的请求已经成功传到了服务器，服务器也正常处理了，但它找不到你要的那个资源。我遇到过很多朋友第一反应就是去查防火墙、查专线、ping 网关，结果折腾半天，最后发现只是路径写少了一层，或者 Nginx 少写了一行 try_files。

这篇文章不是单纯解释一个状态码，而是想把 404 和“网络通不通”这条线彻底理清楚。我会从 HTTP 请求的完整链路讲起，再结合 Nginx 刷新 404、Tomcat 启动后 404、conda 源 404、torchvision 下载 MNIST 报 404、大模型接口返回 404 这些真实场景，最后给你一套 5 分钟上手排查的方法。

1. 搞清楚 404 在网络请求链路中的位置

1.1 一次 HTTP 请求要过多少关

一个请求从你输入地址到看到结果，要经过这些环节：DNS 解析、TCP 三次握手、TLS 握手、发送 HTTP 请求、服务端路由匹配、业务逻辑处理、返回响应。你可以把这个流程想象成寄快递：DNS 是查目的地地图，TCP 是确认收货地址有没有人，TLS 是进小区刷卡，HTTP 请求是快递单本身，404 就是快递已经送到小区但前台告诉你没这个人。

断网通常发生在中间靠前的环节：DNS 解析失败、TCP 连不上、TLS 证书校验不过。这些都发生在真正发出 HTTP 请求之前。服务器根本没有收到请求，自然不可能回一个 404。所以一个原生的 404 响应，本身就说明网络链路已经走通了，至少 TCP 连接已经建立。

很多人会混淆“服务器无响应”和“服务器响应了但找不到”，这两个是完全不同的场景。前者是网络层或连接层的问题，后者是应用层的问题。判断的关键就是看有没有一个 HTTP 状态码回来。

1.2 404 是“服务器收到了，但没找到”

HTTP 状态码按首位数字分成几类：2xx 表示成功，3xx 表示重定向，4xx 表示客户端的问题，5xx 表示服务端的问题。404 属于 4xx，准确定义是“服务器理解了请求，但找不到对应资源”。

注意，404 可以由源站返回，也可以由中间的网关、负载均衡器返回。但无论如何，它都是“有东西在 HTTP 层回话了”。如果网络真断了，你看到的不会是 404，而是 timeout、connection refused、could not resolve host 这一类错误。

2. 网络不通时你看到的到底是什么

2.1 浏览器和 curl 的真实报错长什么样

网络不通时，浏览器和 curl 会给出比较明确的错误提示。我把最常见的几种列出来，方便你对照。