结论： 网站打不开按「本机 → 端口 → 域名 → 外部」四步排查：curl -I 127.0.0.1 验服务本身，ss -lntp 验端口监听与安全组，dig 域名 验解析与证书，最后从外部 curl -I 公网IP 验 CDN 回源与 WAF 拦截。九成问题在前两步，全程 10 分钟内可定位到具体层。
"网站打不开"是运维接到最多的报障，也是最容易瞎猜的故障。它的难点在于同一句描述背后可能是十几种完全不同的原因：Nginx 没启动、PHP-FPM 挂了、端口没放行、域名没解析、证书过期、CDN 回源失败、WAF 误拦截、机房封了 80 端口……如果一上来就重启服务或清空缓存，运气好能蒙对，运气不好会把现场破坏掉，连原因都查不出来。
正确做法是分层排查，从内到外逐层证伪。每一层只用一到两条命令给出明确的是/否结论，就能把故障范围收敛到一个具体的组件。本文命令基于 Ubuntu 24.04 LTS + Nginx 1.26 + PHP 8.3。
四步决策树：先记住这张表
结论：四步决策树是本文主干，按顺序执行，每一步都有明确的"通过/不通过"判据，不通过就停在该层处理。
| 步骤 | 检查目标 | 核心命令 | 通过判据 | 不通过说明 |
|---|---|---|---|---|
| 1 本机 | Web 服务本身是否存活 | systemctl status nginx、curl -I 127.0.0.1 | 返回 HTTP/1.1 200 OK 或 301/302 | 服务未启动、配置语法错、PHP-FPM 挂了 |
| 2 端口 | 端口是否在监听、是否被放行 | ss -lntp、curl -I 公网IP | 有 LISTEN 且外部能连上 | Nginx 未监听、防火墙/安全组未放行 |
| 3 域名 | 解析是否指向正确 IP、证书是否有效 | dig 域名、openssl s_client | A 记录等于服务器公网 IP，证书未过期 | 解析错误、解析未生效、证书过期 |
| 4 外部 | CDN、WAF、运营商、备案 | 多地 ping、CDN 控制台、curl -I 带 Host | 回源正常、无拦截页 | 回源失败、WAF 拦截、未备案被阻断 |
执行顺序不能颠倒：本机都不通却去查 CDN，是绝大多数人浪费时间的原因。
第 1 步：在本机测服务本身
结论：先在服务器内部用 curl 访问 127.0.0.1，绕开一切网络和域名因素，直接判断 Web 服务本身是否正常。 这一步通过，说明 Nginx 与后端都没问题，故障在更外层。
# 1. 看服务状态（active (running) 才算正常）
systemctl status nginx
systemctl status php8.3-fpm
# 2. 本机回环测试，指定 Host 头模拟真实访问
curl -I 127.0.0.1
curl -I -H "Host: example.com" 127.0.0.1
# 正常：HTTP/1.1 200 OK 或 301 Moved Permanently
# 500 → 后端程序错；403 → 权限/目录索引；404 → 根目录配错
# 3. 绕过 Nginx 直接测后端（判断是 Nginx 还是 PHP 的问题）
curl -I 127.0.0.1:8080 # 若后端另起端口
SCRIPT_NAME=/index.php SCRIPT_FILENAME=/var/www/html/index.php \
REQUEST_METHOD=GET cgi-fcgi -bind -connect /run/php/php8.3-fpm.sock
# 4. 配置语法检测（改过配置必做）
nginx -t服务起不来的三种高频原因：
# A. 端口被占用（常见于新装 Apache 与 Nginx 并存）
ss -lntp | grep -E ":80|:443"
# B. 配置语法错误
nginx -t # 会给出文件名与行号
# C. 根目录或证书文件不存在
ls -la /var/www/html/
ls -la /etc/letsencrypt/live/example.com/# 查看失败详情（比 status 更全面）
journalctl -xeu nginx --since "10 min ago" | tail -30
journalctl -xeu php8.3-fpm --since "10 min ago" | tail -30第 2 步：验端口监听与安全组放行
结论：本机通但外部不通，问题一定在"端口没被放行"——本机防火墙、云平台安全组，或 Nginx 根本没监听公网地址。 这一层用 ss 与 curl 公网IP 两步定位。
# 1. 看 Nginx 实际监听的端口与地址
ss -lntp | grep -E "nginx|:80|:443"
# 正常：LISTEN 0 511 0.0.0.0:80 users:(("nginx",pid=1234,fd=6))
# 若只有 127.0.0.1:80，说明只监听回环，公网必然访问不到
# 2. 用服务器公网 IP 自测（仍在本机，但走公网网卡）
curl -I http://<你的公网IP>
# 3. 本机防火墙状态
ufw status verbose # Ubuntu 24.04 默认
iptables -L INPUT -n -v --line-numbers
# 4. 放行 80/443（若确认是 ufw 拦截）
ufw allow 80/tcp
ufw allow 443/tcp
ufw reloadNginx 监听配置要点：
# /etc/nginx/sites-available/example.com（Nginx 1.26）
server {
listen 80;
listen [::]:80;
server_name example.com www.example.com;
root /var/www/html;
index index.php index.html;
location / {
try_files $uri $uri/ /index.php?$query_string;
}
location ~ \.php$ {
include snippets/fastcgi-php.conf;
fastcgi_pass unix:/run/php/php8.3-fpm.sock;
fastcgi_read_timeout 60s;
}
}这一层最容易被忽略的是云平台安全组。安全组在虚拟化层生效，服务器内 ufw status 显示放行不代表真的放行——必须登录控制台确认入方向规则允许 TCP 80 与 443，且来源为 0.0.0.0/0。另外国内云服务器若未备案，80/443 会被直接阻断，表现为本地 curl 公网IP 能通、域名访问被拦截页。
第 3 步：验域名解析与证书
结论：IP 能访问但域名打不开，问题只在两处——DNS 解析不对，或 HTTPS 证书过期/不匹配。 用 dig 和 openssl 各一条命令即可确认。
# 1. 查解析结果
dig example.com +short
dig example.com A +noall +answer
dig www.example.com CNAME +short # 用了 CDN 会有 CNAME
# 2. 指定公共 DNS 对比，排除本地 DNS 缓存污染
dig @223.5.5.5 example.com +short
dig @8.8.8.8 example.com +short
# 3. 确认本机解析到的 IP 是否等于服务器公网 IP
curl -s ifconfig.me; echo # 查本机公网出口 IP
# 4. 查证书有效期（截至 2026 年，公开信任的证书有效期已普遍缩短至 90 天）
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
| openssl x509 -noout -dates -subject
# 输出 notAfter 即过期时间
# 5. 强制走 HTTPS 测试并忽略证书校验（判断是否为证书问题）
curl -I https://example.com
curl -Ik https://example.com # -k 忽略证书，若 -k 通而不加 -k 不通＝证书问题解析类故障的处理清单：
- 解析记录值为旧 IP → 到域名解析控制台改 A 记录
- 刚改完未生效 → TTL 决定生效时间，通常 10 分钟到 24 小时，可用
dig @8.8.8.8观察各地生效情况 - 使用了 CDN 但源站 IP 变更未同步 → 到 CDN 控制台更新回源地址
- 证书过期 → 重新签发（见本站点《服务器证书过期怎么处理》）
第 4 步：查外部链路——CDN、WAF 与运营商
结论：前三层全通过但用户仍打不开，问题在服务器之外的链路上，按"CDN 回源 → WAF 拦截 → 运营商/地域 → 备案"顺序查。
# 1. 绕过 CDN 直接打源站（验证是源站问题还是 CDN 问题）
curl -I -H "Host: example.com" http://<源站公网IP>
# 2. 模拟 CDN 回源请求（带真实 Host 与 UA）
curl -I -H "Host: example.com" -A "CDN-Node" https://<源站公网IP>
# 3. 看源站收到的请求是不是来自 CDN 节点（查访问日志）
tail -f /var/log/nginx/access.log
# 若日志里完全没有请求 → 请求根本没到源站，问题在 CDN 或更上游
# 4. 分运营商/地域测试（本机只代表一条链路）
ping -c 4 example.com
mtr -r -c 30 -n example.com判断要点：
- 回源失败：CDN 节点访问源站超时或源站返回 5xx，表现为部分地区间歇性 502。检查源站是否把 CDN 节点 IP 当攻击者封了（fail2ban、ufw 误封是最常见原因）。
- WAF 拦截：返回 403 且响应头带 WAF 特征，或返回一段拦截页面 HTML。到 WAF 控制台看拦截日志，把误判规则加白名单。
- 地域性打不开：用多个在线拨测工具对比，若仅个别运营商不通，多为链路问题，可切换 CDN 或联系机房。
- 未备案阻断：国内节点 80/443 未备案会被直接拦截，需完成 ICP 备案。
按报错码快速分流
结论：浏览器给出的状态码直接指向故障层，学会看码能跳过一半排查步骤。
| 状态码 | 含义 | 最常见成因 | 优先查哪一层 |
|---|---|---|---|
| 无法连接 / 超时 | 请求根本没到服务 | 安全组未放行、Nginx 未监听、域名解析错 | 第 1、2 步 |
| 403 Forbidden | 拒绝访问 | 目录无 index、权限不足、WAF 拦截 | 第 1、4 步 |
| 404 Not Found | 路径不存在 | root 配错、伪静态规则缺失、文件未部署 | 第 1 步 |
| 500 Internal Error | 后端程序异常 | PHP 语法错、权限问题、.htaccess 规则错 | 第 1 步（看 error_log） |
| 502 Bad Gateway | 上游无响应 | PHP-FPM 未启动、sock 路径错、后端超时 | 第 1 步（看 php-fpm） |
| 504 Gateway Timeout | 上游超时 | 后端执行慢、fastcgi_read_timeout 过小 | 第 1 步 + 数据库 |
| 证书警告 | HTTPS 不受信 | 证书过期、域名不匹配、中间证书缺失 | 第 3 步 |
常见误区 / 排错提示
- 一上来就
systemctl restart nginx：可能掩盖真实原因，且若配置语法错，重启会让本还能服务的进程彻底退出。重启前先nginx -t。 - 只测域名不测 IP：域名链路包含 DNS、CDN、WAF 三个额外变量，直接用
curl -I 公网IP能立刻排除这三者。 - 忽略云平台安全组：服务器内
ufw放行不等于安全组放行，两层都要通过才能连通。 - 改完 DNS 立刻判定失败：DNS 有 TTL 缓存，短则几分钟、长则 24 小时，要用
dig @223.5.5.5对比观察，而不是反复改记录。 - 看到 502 就加机器：502 是"上游没响应"，多半是 PHP-FPM 进程耗尽或 sock 路径配置错误，扩容解决不了。
- 忽略日志：
tail -f /var/log/nginx/error.log通常会直接打印出根因（如connect() to unix:/run/php/php8.3-fpm.sock failed），比猜快十倍。 - 证书过期当成网络故障：表现为浏览器红色警告而非连接失败，
openssl x509 -noout -dates一条命令就能确认。
企业QQ咨询
