Nginx 配置出错时，最怕的是直接 restart，结果整个站点下线。正确做法是先用 nginx -t 检查语法，再 reload；如果 reload 失败，先看错误行号、include 文件和日志，不要连续改一堆配置。
Nginx 官方文档说明：reload 时 master 进程会先检查新配置，如果成功才启动新 worker；如果失败，会回滚并继续使用旧配置。这也是为什么上线前必须养成 nginx -t 的习惯。
sudo systemctl status nginx --no-pager
sudo nginx -t
如果 nginx -t 报错，它通常会给出文件和行号，例如：
nginx: [emerg] invalid number of arguments in "proxy_pass" directive in /etc/nginx/sites-enabled/app.conf:18
这时不要猜，直接打开对应文件对应行。
推荐发布流程：
sudo nginx -t
sudo systemctl reload nginx
不建议一上来：
sudo systemctl restart nginx
reload 失败时旧 worker 通常还在，线上服务可能没有中断；restart 失败时，可能直接没有 Nginx 进程提供服务。
看日志：
sudo journalctl -u nginx -n 100 --no-pager
sudo tail -n 100 /var/log/nginx/error.log
Ubuntu / Debian 常见结构：
/etc/nginx/nginx.conf
/etc/nginx/conf.d/*.conf
/etc/nginx/sites-available/
/etc/nginx/sites-enabled/
列出启用站点：
ls -l /etc/nginx/sites-enabled/
常见问题：
sites-enabled里有坏的软链接；- 同一个
server_name写了多份； - 多个站点都监听同一端口但没有默认站点；
- 文件名加载顺序导致默认配置先匹配。
可以用：
sudo nginx -T | less
查看 Nginx 实际加载后的完整配置。
如果浏览器打开的是默认站点、旧站点或 404，先检查：
server {
listen 80;
server_name example.com www.example.com;
}
同时确认 DNS 指向当前 VPS：
dig +short example.com
如果还有 IPv6，别忘了 AAAA 记录。有时 A 记录对，AAAA 记录还指向旧机器，会导致部分用户访问异常。
静态站常见错误是 root / alias 路径拼接理解错。
推荐简单场景用 root：
location / {
root /var/www/site;
try_files $uri $uri/ =404;
}
alias 更适合把某个 URL 前缀映射到完全不同目录：
location /uploads/ {
alias /data/uploads/;
}
alias 末尾斜杠很重要，写错会导致 404 或路径拼接异常。
反向代理常见配置：
location / {
proxy_pass http://127.0.0.1:3000;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
排查后端：
curl -I http://127.0.0.1:3000
sudo ss -lntup | grep 3000
如果后端没监听，Nginx 配置再正确也会 502。
更详细的 502/504 排查可以看：
证书配置常见错误：
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
检查文件是否存在：
sudo ls -l /etc/letsencrypt/live/example.com/
检查续期：
sudo certbot renew --dry-run
如果证书路径错、域名不匹配、80 端口被拦截，都可能导致 HTTPS 配置不生效或 reload 失败。
确认 Nginx 是否监听：
sudo ss -lntup | egrep ':80|:443'
如果端口被 Apache、Caddy 或另一个 Nginx 占用，日志里通常会看到 bind() to 0.0.0.0:80 failed。
检查 UFW：
sudo ufw status verbose
放行 HTTP/HTTPS：
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
还要检查云厂商安全组，否则本机放行也可能外网不通。
每次改配置前先备份：
sudo cp /etc/nginx/sites-available/app.conf /etc/nginx/sites-available/app.conf.bak.$(date +%F-%H%M)
发布顺序：
sudo nginx -t
sudo systemctl reload nginx
curl -I https://example.com
如果失败，回滚：
sudo cp /etc/nginx/sites-available/app.conf.bak.时间戳 /etc/nginx/sites-available/app.conf
sudo nginx -t
sudo systemctl reload nginx
不要在生产机上边猜边改。把每次修改和回滚命令留在 shell history 或变更记录里，后续排障会快很多。
sudo nginx -t看文件和行号；journalctl -u nginx -n 100看 systemd 错误；tail /var/log/nginx/error.log看运行错误；nginx -T看最终加载配置；- 检查
sites-enabled软链接； - 检查
server_name和 DNS； - 检查
root/alias或proxy_pass； - 检查证书路径和 certbot；
- 检查 80/443 监听、防火墙、安全组；
- 必要时按备份回滚。
延伸阅读：
Nginx 配置错误最核心的原则是：先 nginx -t，再 reload，不要直接 restart。语法错误看行号，运行错误看 error.log，反代问题看后端监听，HTTPS 问题看证书路径和 80/443 可达性。把发布和回滚流程固定下来，比临时猜配置更可靠。