网络问题排查
网络问题怎么排查？先判断卡在 DNS、连接、TLS、HTTP 还是页面性能
本篇内容导航
网页打不开、很慢或时好时坏时，最省时间的方法不是连续改设置，而是确认请求已经走到哪一层，再做下一步。
先判断是连接失败，还是页面加载慢
这篇指南用于快速找到问题所在的层级。若已经有具体浏览器错误代码，直接看“网站打不开怎么办”；若能打开但速度慢，转去查看性能排查步骤。
| 看到的现象 | 这通常说明什么 | 下一步先做什么 |
|---|---|---|
| 提示域名不存在、DNS 错误 | 还没有正常进入网页请求阶段 | 核对域名、DNS 解析和不同网络的解析结果 |
| DNS 已得到地址，但连接超时 | 不能再只归因于 DNS | 比较网络、端口可达性、防火墙和服务是否监听 |
| 浏览器出现证书/域名不匹配 | TLS 阶段已经暴露问题 | 核对访问域名、设备时间和证书配置；原因不明时不要提交敏感信息 |
| 收到 404 / 403 | 已经有 HTTP 响应 | 检查 URL、权限或资源是否存在 |
| 收到 502 / 503 / 504 | 请求到达了某个 HTTP 服务，但站点或上游处理异常 | 访客可稍后重试；站长继续查代理、源站和依赖服务 |
| HTML 很快出现，图片/脚本很慢 | 主文档不是唯一瓶颈 | 转到性能工具，看具体慢请求和资源体积 |
第一步：确认问题范围
用同一个 URL 做最小对照：当前设备的 Wi‑Fi、手机数据或另一条独立网络；必要时再换一台设备。只有某个网络失败时，应优先检查该网络环境；多个独立环境同时失败，才更值得怀疑目标站点或公共依赖。
一次只改一个变量。 同时清缓存、换 DNS、关扩展、改代理，看起来动作很多，却会让你失去“到底哪一步起作用”的线索。
第二步：DNS 只回答“域名解析到什么”
DNS 正常解析并不等于网站正常。拿到地址之后，还要建立连接、完成 TLS、发送 HTTP 请求并加载页面资源。若已经解析出目标地址，后续超时就应继续检查连接和服务，而不是反复更换 DNS。
第三步：Ping 是辅助信号，不是网页可用性判决
Ping 可以帮助比较往返延迟和丢包，但有些服务会限制或忽略 ICMP；因此“Ping 不通”不能单独证明 HTTPS 一定不可用，“Ping 很低”也不能证明网页资源和服务器处理一定快。
第四步：把 TLS 警告和 HTTP 错误分开
证书警告出现在安全连接建立阶段；HTTP 4xx/5xx 则说明已经收到了 HTTP 响应。二者排查方向不同。尤其是 502、503、504，通常比“完全连接不上”更靠近站点或上游服务侧。
第五步：能打开但慢，才进入性能诊断
此时再看服务器等待、请求瀑布、图片与脚本体积、缓存和浏览器执行。不要用一次测速结果给网站定性；保持测试 URL、地点、设备和缓存条件尽量一致，才适合比较改动前后差异。
最短排查顺序
- 记下完整错误，而不是只写“打不开”。
- 换一个独立网络或设备，确定问题范围。
- DNS 是否得到预期结果。
- 是否能建立连接，TLS 是否正常。
- 如果已经收到 HTTP 状态码，按状态码继续。
- 页面能打开但慢，再进入性能诊断。
遇到“只有我打不开”时，如何缩小范围
以下是一个排查示例，不是对某个实际网站故障的诊断：同一 URL 在家用 Wi‑Fi 失败，但手机数据可以访问。先检查 Wi‑Fi 网络下的域名解析与访问控制，不要把它直接归结为目标网站宕机。若两种独立网络都能解析域名、但都收到同样的 503，下一步更应该看服务方状态而不是换 DNS。
记录时只需保留四项：具体 URL、完整报错、测试时间、使用的网络和设备。这比截图“打不开”的空白页面更有帮助。已知浏览器错误代码的用户可以直接进入 按错误类型排查；出现明确 HTTP 状态码的用户可查 状态码指南。