HTTP 请求全过程复盘：页面打不开时应该按什么顺序排查

资料 在 HTTP 请求过程里列了 10 步：输入 URL、查缓存、DNS 解析、TCP 三次握手、发送 HTTP 请求、服务器处理、返回响应、检查状态、浏览器渲染、关闭连接。这个顺序很适合作为网络排查的骨架。

很多问题看起来都是“接口慢”“页面打不开”“状态码异常”，但根因可能在不同层。可能是 URL 写错了，可能是浏览器拿了旧缓存，可能是 DNS 解析到了错误 IP，也可能是 TCP 端口不通、TLS 证书失败、服务端路由错误，最后才可能是前端渲染出错。

所以排查网络问题时，不要一上来就盯服务端代码。先把链路拆开：请求有没有发出去，发到了哪里，连接有没有建好，服务端有没有返回，浏览器有没有正确解析和渲染。每一步都有不同证据。

用户在浏览器地址栏输入 URL 并按下 Enter，是整个流程的入口。URL 里协议、域名、端口、路径、查询参数都可能影响结果。一个看似小的拼写错误，可能让请求根本没到目标服务。

资料 第二步提到，浏览器会依次在浏览器缓存、系统缓存、路由器缓存中寻找匹配内容。如果缓存命中，就可能直接展示页面，不再走完整网络请求。这就是为什么有些问题只在某个用户机器上出现：他看到的可能是旧缓存。

排查时可以先用浏览器 DevTools 的 Network 面板看请求是否真的发出。状态列如果显示 from disk cache、from memory cache，说明浏览器用了本地缓存。强制刷新、禁用缓存、换无痕窗口，都能帮助判断问题是否和缓存有关。

如果缓存没有直接解决，浏览器发送 HTTP 请求前要先做 DNS 解析。文中写到，浏览器需要先进行域名解析，以获取相应 IP 地址，并提到浏览器 DNS 缓存、路由器缓存、DNS 缓存这些位置。

DNS 错了，后面全都错。域名可能解析失败，也可能解析到旧 IP、错误机房、错误 CDN 节点，或者不同运营商得到不同结果。用户说“我这里打不开，别人能打开”，DNS 和链路差异就要优先看。

常用排查方式是看本机解析结果、公共 DNS 解析结果、权威 DNS 配置、A/AAAA 记录、CNAME 链路、TTL 是否刚变更。只要解析结果不符合预期，就还没到 HTTP 层，不要急着看接口代码。

拿到 IP 后，浏览器要向服务器发起 TCP 连接。资料 第四步写到，获取 IP 地址之后，浏览器向服务器发起 TCP 连接，建立 TCP 三次握手。

这一步出问题，常见表现是连接超时、连接被拒绝、端口不通。连接超时通常表示包发出去了但没有及时得到回应，可能是防火墙、路由、服务没监听、链路丢包。连接被拒绝则更像目标主机可达，但端口没有服务或被主动拒绝。

排查时要确认目标 IP 和端口是否正确，80/443 是否开放，负载均衡是否监听，安全组或防火墙是否放行。抓包里如果看不到 SYN-ACK，问题还在 TCP 建连之前或建连阶段。

相关的 10 步用的是 HTTP 请求过程，实际网站大多是 HTTPS。HTTPS 在 TCP 建好后，还要经历 TLS 握手。证书、SNI、TLS 版本、加密套件、证书链、时间有效期，都可能让连接失败。

如果浏览器报证书错误、域名不匹配、连接不安全，说明问题已经不是普通 HTTP 状态码了。可能是证书过期，可能是 CDN 或网关证书没有配置好，也可能是回源 HTTPS 和对外 HTTPS 的证书边界没处理对。

排查 HTTPS 时，要看浏览器安全面板、证书链、证书域名、证书有效期，也要看服务端是否支持客户端要求的 TLS 版本。尤其多域名、多环境、多 CDN 节点时，证书配置很容易只在某个节点出错。

TCP 或 TLS 建好后，浏览器才真正发送 HTTP 请求。资料 第五步说，握手成功之后，浏览器向服务器发送 HTTP 请求，来请求服务器端的数据包。这个请求里会包含方法、路径、Header、Cookie、请求体等信息。

同一个 URL，不同请求头可能得到完全不同结果。Cookie 决定登录态，Accept 决定期望内容类型，Content-Type 决定请求体解析方式，Authorization 决定鉴权，Host 决定虚拟主机路由。请求参数错了，服务端可能返回 400、401、403、404。

排查时要把请求复制出来看。方法是不是 GET/POST 用错，路径有没有多斜杠，查询参数有没有编码，Cookie 有没有带上，跨域预检有没有通过。很多“服务端没问题”的争论，最后都是请求报文本身不一样。

资料 第六步写到，服务器处理从浏览器端收到的请求，接着将数据返回给浏览器。服务器处理这一层通常包括网关路由、鉴权、业务逻辑、缓存、数据库、第三方服务调用、文件读取等。

如果请求已经到服务端，状态码和日志就很重要。404 可能是路由不存在，401/403 可能是认证或权限，500 可能是应用异常，502/503/504 可能和网关、上游服务、超时、服务不可用有关。

排查服务端时，要把请求 ID、访问日志、错误日志、应用链路追踪、数据库慢查询、缓存命中率放在一起看。浏览器只看到一个状态码，服务端日志才能告诉你请求在内部走到了哪里。

资料 第七、八步说，浏览器收到 HTTP 响应后，会查询状态；状态成功则进行下一步，不成功则弹出相应指示。这里的“状态”首先就是 HTTP 状态码。

2xx 表示请求成功，3xx 表示重定向，4xx 多数表示客户端请求或权限问题，5xx 多数表示服务端或网关问题。状态码不是最终答案，但能帮你确定排查方向。比如 301/302 循环会导致页面一直跳，304 说明用了协商缓存，401 说明未认证，403 说明无权限。

还要看响应头和响应体。Content-Type 错了，浏览器可能按错误方式解析；Cache-Control 错了，用户可能一直拿旧内容；Set-Cookie 错了，登录态可能保存不住；CORS 头错了，前端可能拿不到响应。

资料 第九步提到，浏览器会读取页面内容，进行渲染，解析 HTML 源码，生成 DOM 树，解析 CSS 样式，处理 JS 交互，最后展示页面。到这一步，网络请求可能已经成功了，但页面仍可能白屏。

比如 HTML 返回 200，JS 文件加载失败，页面会报错；CSS 加载慢，页面会闪动；接口返回成功但字段结构变了，前端代码可能抛异常；图片资源 404，不影响主文档状态码，却影响页面展示。

所以“页面打不开”要分清：是主文档没拿到，还是资源没加载，还是脚本执行失败，还是接口报错。DevTools 的 Network、Console、Performance 三个面板要一起看，不能只盯一个请求。

资料 最后一步写到关闭 TCP 连接，也就是四次挥手。结合前面 Keep-Alive 文章要补一句：现代 HTTP/1.1 默认长连接，很多请求结束后不会马上关闭 TCP，而是根据 Connection 头、服务器超时策略、客户端连接池决定是否复用。

如果每个请求都新建连接再关闭，建连开销会高；如果连接长期不关，又会占用服务端资源。抓包里频繁看到三次握手和四次挥手，可能说明 Keep-Alive 没生效；连接长期堆积，可能说明空闲超时时间太长或客户端没有释放。

排查性能时，这一步也不能忽略。慢不一定是业务慢，可能是每次都在重复 DNS、重复 TCP、重复 TLS。连接复用是否生效，会直接影响大量小请求的体验。

第一，先确认请求有没有发出去。URL、缓存、浏览器策略、跨域预检、本地代理，都可能让你以为请求到了服务端，其实没有。DevTools Network 是第一现场。

第二，确认请求连到了哪里。DNS 解析结果、CDN 节点、目标 IP、端口、TCP 握手、TLS 证书，都决定请求是否真的到达正确入口。解析错或连接失败时，服务端业务日志里通常什么都没有。

第三，确认服务端如何响应。看状态码、响应头、响应体、访问日志、错误日志、链路追踪。第四，最后看前端渲染。资源是否加载、JS 是否报错、接口数据是否符合预期、页面是否被缓存，这些都属于浏览器侧问题。

如果被问浏览器输入 URL 后发生了什么，可以按 相关的 10 步回答：输入 URL，查浏览器/系统/路由器缓存；没有命中就做 DNS 解析拿 IP；然后建立 TCP 连接，HTTPS 还要做 TLS 握手；连接建立后发送 HTTP 请求。

接着说服务端处理请求并返回 HTTP 响应；浏览器收到响应后根据状态码决定下一步；成功时解析 HTML、CSS、JS，构建 DOM 和渲染树，布局绘制页面；最后根据连接策略关闭 TCP 连接或保持 Keep-Alive 复用。

如果是排查题，就按层次讲：先看请求有没有发出去，再看 DNS 和连接，再看 HTTP 状态码和响应头，再看服务端日志，最后看浏览器渲染和前端错误。这样回答比单纯背流程更像真实工程排查。