Nginx多虚拟主机故障：新增配置后所有站点无法访问

Let’s walk through how to diagnose and fix this issue—since a failed nginx reload taking down all your sites almost always traces back to invalid syntax or conflicts in the two new config files you added.

Step 1: Validate Nginx Config Syntax Immediately #

The first thing you should do is run the built-in config checker. This will tell you exactly where the problem is, instead of guessing:

nginx -t

Pay close attention to the output—it will point to the specific file and line number causing the failure (e.g., syntax error on line 15 of /etc/nginx/sites-enabled/new-site.conf). This is the fastest way to narrow down the issue.

Step 2: Dig Into the Error Log Details #

You mentioned the error.log has relevant info—let’s parse it for common red flags:

• Port conflicts: Look for errors like address already in use—this happens if two configs try to listen on the same port (80/443) without proper server_name differentiation, or if a default_server directive is duplicated.
• SSL issues: Errors like no such file or directory for ssl_certificate mean your certificate path is wrong, or Nginx doesn’t have permission to read the cert files (check ownership with ls -l /path/to/certs—they should be readable by the Nginx user, usually www-data or nginx).
• Syntax mistakes: Missing semicolons (;), unclosed curly braces (}), or misspelled directives (e.g., listen 443 ssL instead of ssl) will break the entire config parse.
• File permissions: If the new config files in sites-enabled have restrictive permissions (e.g., 600 owned by root), Nginx might not be able to read them—fix this with chmod 644 /etc/nginx/sites-enabled/new-site.conf.

Step 3: Isolate the Problem Configs #

To confirm the new files are the culprit, temporarily disable them by moving them out of sites-enabled (back to sites-available is a safe spot):

mv /etc/nginx/sites-enabled/new-site1.conf /etc/nginx/sites-available/
mv /etc/nginx/sites-enabled/new-site2.conf /etc/nginx/sites-available/

Then run nginx reload again. If your sites come back online, you know the issue is definitely in one (or both) of those two files.

Step 4: Debug the New Config Files One by One #

Now take each config file and validate it individually, checking for these common issues:

• Listen directives: For HTTP sites, ensure listen 80; is set correctly—if multiple sites use port 80, make sure each has a unique server_name (or use server_name _; for catch-alls only if needed). For HTTPS sites, double-check listen 443 ssl; and that SSL cert paths are absolute (not relative).
• Server name conflicts: If you reused a server_name that’s already in another config, Nginx will throw an error—each domain should map to exactly one server block (unless using wildcards intentionally).
• Unclosed blocks: A missing } at the end of a location or server block will cause the entire config to fail parsing. Use a text editor with syntax highlighting (like VS Code or nano with syntax enabled) to spot this easily.

Step 5: Test and Reload #

Once you’ve fixed the issues, re-run nginx -t to confirm the config is valid. If you get the message test is successful, you can safely run:

nginx reload

Your sites should now be accessible again.

内容的提问来源于stack exchange，提问作者Markus