sudo systemctl status nginx --no-pager
sudo nginx -t

If nginx -t reports an error, it usually gives the file and line number, for example:

nginx: [emerg] invalid number of arguments in "proxy_pass" directive in /etc/nginx/sites-enabled/app.conf:18

At this point, don't guess—open the corresponding file and line directly.

Recommended release process:

sudo nginx -t
sudo systemctl reload nginx

Not recommended to start with:

sudo systemctl restart nginx

When reload fails, the old workers are usually still running, so the online service may not be interrupted; when restart fails, there may be no Nginx process serving at all.

Check the logs:

sudo journalctl -u nginx -n 100 --no-pager
sudo tail -n 100 /var/log/nginx/error.log

Common Ubuntu / Debian structure:

/etc/nginx/nginx.conf
/etc/nginx/conf.d/*.conf
/etc/nginx/sites-available/
/etc/nginx/sites-enabled/

List enabled sites:

ls -l /etc/nginx/sites-enabled/

Common problems:

• There is a broken symlink in sites-enabled;
• The same server_name is written multiple times;
• Multiple sites listen on the same port but there is no default site;
• File name load order causes the default configuration to match first.

You can use:

sudo nginx -T | less

To view the complete configuration after Nginx actually loads it.

If the browser opens the default site, an old site, or a 404, first check:

server {
    listen 80;
    server_name example.com www.example.com;
}

Also confirm DNS points to the current VPS:

dig +short example.com

If you also have IPv6, don't forget the AAAA record. Sometimes the A record is correct but the AAAA record still points to the old machine, causing access problems for some users.

A common static site mistake is misunderstanding how root / alias paths are concatenated.

For simple scenarios, use root:

location / {
    root /var/www/site;
    try_files $uri $uri/ =404;
}

alias is better for mapping a URL prefix to a completely different directory:

location /uploads/ {
    alias /data/uploads/;
}

The trailing slash in alias matters; getting it wrong causes 404 or abnormal path concatenation.

Common reverse proxy configuration:

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;
}

Troubleshoot the backend:

curl -I http://127.0.0.1:3000
sudo ss -lntup | grep 3000

If the backend isn't listening, Nginx will return 502 no matter how correct its configuration is.

For more detailed 502/504 troubleshooting, see:

• What to Do About VPS 502 / 504 Bad Gateway (2026): Nginx, PHP-FPM, Gunicorn, upstream timeout troubleshooting checklist

Common certificate configuration errors:

ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

Check whether the files exist:

sudo ls -l /etc/letsencrypt/live/example.com/

Check renewal:

sudo certbot renew --dry-run

Wrong certificate paths, domain mismatch, or port 80 being blocked can all cause HTTPS configuration not to take effect or reload to fail.

Confirm whether Nginx is listening:

sudo ss -lntup | egrep ':80|:443'

If the port is occupied by Apache, Caddy, or another Nginx, the logs usually show bind() to 0.0.0.0:80 failed.

Check UFW:

sudo ufw status verbose

Allow HTTP/HTTPS:

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

Also check the cloud provider security group, otherwise even if the local machine allows it, external access may still fail.

Back up before every configuration change:

sudo cp /etc/nginx/sites-available/app.conf /etc/nginx/sites-available/app.conf.bak.$(date +%F-%H%M)

Release order:

sudo nginx -t
sudo systemctl reload nginx
curl -I https://example.com

If it fails, roll back:

sudo cp /etc/nginx/sites-available/app.conf.bak.时间戳 /etc/nginx/sites-available/app.conf
sudo nginx -t
sudo systemctl reload nginx

Don't guess and change things on the production machine. Keep every change and rollback command in shell history or a change log; future troubleshooting will be much faster.

1. sudo nginx -t to see the file and line number;
2. journalctl -u nginx -n 100 to see systemd errors;
3. tail /var/log/nginx/error.log to see runtime errors;
4. nginx -T to see the final loaded configuration;
5. Check sites-enabled symlinks;
6. Check server_name and DNS;
7. Check root/alias or proxy_pass;
8. Check certificate paths and certbot;
9. Check 80/443 listening, firewall, security group;
10. Roll back from backup if necessary.

Further reading:

• VPS Service Started but Not Accessible from the Internet (2026): How to Troubleshoot Ports, Firewall, Security Group, and Listen Address
• What to Do When Let's Encrypt Certificate Renewal Fails on a VPS (2026): certbot, Cloudflare, DNS-01, port 80 troubleshooting checklist

The core principle for Nginx configuration errors is: first nginx -t, then reload, don't restart directly. For syntax errors, look at the line number; for runtime errors, look at error.log; for reverse proxy issues, look at backend listening; for HTTPS issues, look at certificate paths and 80/443 reachability. Fixing your release and rollback process is more reliable than guessing at configuration on the fly.