1. DNS 名称解析
用DNS 实时查询确认 A、AAAA、CNAME 是否指向预期目标，并比较三个公共递归解析器是否仍缓存旧答案。
Guided Checklist
生成专属排查入口
清单会生成本站 DNS、SSL、HTTP 和综合体检入口；不会假装已经执行尚未发起的网络检测。
先用外部结果确定故障在哪一层
网站打不开时，最容易浪费时间的做法是同时修改 DNS、证书和服务器。先从用户能够观察到的结果开始，每次只排除一层，才能知道哪次修改真正解决了问题。
2. TLS 证书握手
用SSL 检测核对证书信任链、覆盖域名、有效期和 TLS 版本。浏览器证书警告通常发生在 HTTP 之前。
3. HTTP 响应链
用HTTP 重定向检测查看最终状态、跳转循环、响应时间和缓存头，区分路径错误、权限拒绝与服务端异常。
4. 综合公网体检
域名健康体检会并行读取 DNS、HTTPS、证书、安全响应头、robots.txt 与 sitemap，适合先形成完整快照。
按现象选择排查方向
| 用户看到的现象 | 优先检查 | 常见原因 |
|---|---|---|
| 域名不存在或无法解析 | NS、A/AAAA、CNAME、DNSSEC | 记录写错、权威 DNS 委派错误、缓存未刷新、DS 不匹配。 |
| 连接超时 | 安全组、防火墙、80/443 监听 | 端口未放行、进程未监听公网、路由或运营商链路异常。 |
| 证书不受信任或域名不匹配 | 证书链、SAN、SNI、到期时间 | 漏掉 www、部署了错误证书、中间证书缺失、旧节点未更新。 |
| 403 / 404 / 429 | 权限、路由、WAF、限流 | 路径不存在、访问策略拒绝、反爬规则或请求频率过高。 |
| 502 / 504 | 上游进程、端口、超时和日志 | 后端未启动、proxy_pass 错误、应用阻塞或数据库响应慢。 |
| 只有部分地区或设备失败 | AAAA、CDN 节点、缓存、地区策略 | IPv6 服务异常、地理调度差异、旧 DNS 缓存或节点配置不一致。 |
服务器内部的六步检查
- 确认域名确实指向这台服务器。把公网 DNS 结果与云主机公网 IP 对比；若使用 CDN，应确认回源地址和源站访问限制。
- 确认端口正在监听。在 Linux 上使用
ss -lntp查看 80、443 与上游端口，监听在127.0.0.1的应用只能由本机代理访问。 - 确认 Nginx 配置能加载。先执行
nginx -t，通过后再 reload；不要在语法校验失败时直接重启。 - 绕过公网直接请求上游。用
curl -I http://127.0.0.1:应用端口/判断问题在应用本身还是反向代理。 - 同时看错误日志与应用日志。Nginx 的
connect() failed、upstream timed out和证书读取错误分别对应不同方向。 - 修复后从公网复测。本机 curl 成功只证明服务器内部链路正常，还要再次检查公网 DNS、HTTPS 和最终状态码。
ss -lntp
nginx -t
systemctl status nginx --no-pager
curl -I http://127.0.0.1:3000/
tail -n 100 /var/log/nginx/error.log遇到网关错误时，可继续阅读 Nginx 502 / 504 专题排查指南。
常见问题
本机能打开，别人打不开，说明什么？
本机可能命中了 hosts、本地 DNS 缓存、内网地址或已登录状态。应从其他网络检查公网 DNS、IPv6、证书、WAF 与 CDN 节点，不能只用服务器本机结果下结论。
为什么修改 DNS 后有的人立即生效，有的人没有？
不同递归解析器保存旧记录的时间不同，本地系统和浏览器也可能缓存。比较多个解析器并结合旧 TTL 判断，避免反复修改导致排查窗口重新开始。
502 和 504 应该先改超时时间吗？
不应该先盲目加大超时。先确认上游进程是否运行、端口是否正确、请求是否卡在数据库或外部接口；只有业务确实需要长任务时再调整代理超时。
作者与维护
作者与维护：iphelp站长工具箱站长 核对方式：公网实测与官方资料 最后核对：2026年8月21日
本文依据公开协议、官方文档与本站实时检测结果维护。发现结果差异时，请通过反馈表单提供页面、现象与复现时间。