本地正常、线上打不开：从现象开始整理排查证据

AgentField 编辑整理｜排查指南。文中的实验仅在隔离的本地演示服务进行，不代表任何线上站点的故障结论；域名为待替换占位符。

“本地能打开，线上不行”还不足以决定该改哪里。先保留出错的完整路径、发生时间、浏览器提示，以及使用的网络和登录状态。首页正常，也不能替代出错子页面的检查。每轮只验证一个猜测，避免同时改域名、证书和应用配置后失去线索。

先留下一次请求的证据

下面用于 macOS / Linux 终端。先建一个空的临时工作目录，将 URL 换成你有权检查的公开页面；每次使用新的输出文件名，避免误读上次留下的内容。

curl -q --silent --show-error \
  --connect-timeout 5 --max-time 15 \
  --output response.html \
  --write-out 'HTTP=%{http_code}\nTYPE=%{content_type}\n' \
  'https://your-site.example/problem-path'

-q 放在首个选项，跳过个人 curl 配置；两个超时分别限制连接阶段和整个请求。保存终端错误与 HTTP 值，再查看本次实际收到的正文。这条命令不自动跟随重定向，也不执行页面脚本；未收到 HTTP 响应时出现的 000 不是服务器状态码。curl 参数说明

按出错层次决定下一步

1. DNS：域名能否解析。 curl 错误 6 表示主机名无法解析。先核对域名拼写和实际使用的解析环境；这条错误本身不能证明全网 DNS 都失效。
2. 连接：能否连到服务。 错误 7 表示连接失败。检查目标端口、服务监听和网络路径；先收集证据，再改防火墙。错误 28 表示超时，单凭它不能锁定原因。
3. TLS：HTTPS 证书能否验证。 错误 60 表示证书认证未通过。记录原始错误，并核查域名、有效期和证书链；不要加 -k 跳过验证后宣称修复。
4. HTTP：服务返回了什么。 收到 301、302 等重定向响应时，检查 Location 和目的地；4xx、5xx 时保留状态与响应摘要。curl 默认可能在完整收到 404 或 503 后仍退出成功，因此必须同时检查 HTTP 值与正文。curl 错误码说明

这些信号帮助缩小排查范围，并非原因判决。200 表示这次 HTTP 请求成功，页面是否符合预期还需要进一步验收。MDN：200 OK

页面外壳、资源和接口分别检查

打开 Chrome 开发者工具的 Network，再重现问题。先检查页面文档请求，再按 JS、CSS、Fetch/XHR 分类查看；点开失败项，记录请求地址、状态和 Response 摘要，需要时用 Initiator 找到是谁发起请求。Chrome Network 官方指南