CentOS 7上Laravel应用Nginx 403错误及多域名异常求助

Hey there, let’s tackle these two Nginx issues on your CentOS 7 VPS one by one—they’re super common, so we’ll get to the bottom of them.

A 403 error almost always boils down to permissions, config missteps, or SELinux blocking access. Here’s what to check first:

• File & directory permissions: Nginx runs as a specific user (usually nginx on CentOS 7). First confirm which user it’s using with:

  ps aux | grep nginx
  

  Then check the permissions on your zargold.com root directory and files:

  ls -l /path/to/your/zargold/root/folder
  

  Make sure the nginx user has read access to files and read+execute access to directories. If not, fix it with:

  chown -R nginx:nginx /path/to/your/zargold/root/folder
  chmod -R 755 /path/to/your/zargold/root/folder
  

• Nginx server block config: Double-check your zargold.com server block (usually in /etc/nginx/conf.d/ or /etc/nginx/sites-available/). Ensure:
  • The root directive points to the correct folder
  • The index line includes your actual homepage file (e.g., index.html, index.php)
  • There are no accidental deny all or restrictive allow rules blocking access
• SELinux context issues: CentOS 7 has SELinux enabled by default, which can block Nginx from accessing web files. Check the SELinux context of your root folder:

  ls -Z /path/to/your/zargold/root/folder
  

  You should see httpd_sys_content_t in the output. If not, fix it with:

  restorecon -Rv /path/to/your/zargold/root/folder
  

  You can also temporarily disable SELinux (for testing only!) with setenforce 0 to rule it out.
• Missing index file: Make sure the index file you specified in Nginx actually exists in the root directory. If you’re using PHP, confirm the file is there and Nginx is configured to pass PHP requests to PHP-FPM.

A 502 means Nginx can’t reach the backend service it’s supposed to proxy to (like PHP-FPM, Node.js, or another server). Here’s how to debug:

• Check if your backend service is running: If zar7.com uses PHP-FPM, run:

  systemctl status php-fpm
  

  If it’s inactive, start it with systemctl start php-fpm and enable it on boot with systemctl enable php-fpm. For other backends (like Node.js), use systemctl status your-service-name or ps aux | grep your-service.
• Verify backend connection settings: Look at your zar7.com server block. If it’s a PHP site, check the fastcgi_pass line—it should point to 127.0.0.1:9000 (default PHP-FPM port) or a Unix socket path (like /run/php-fpm/www.sock). If it’s a reverse proxy, confirm proxy_pass points to the correct backend IP/port.
• Dig into Nginx error logs: This is the most helpful step. Check the global Nginx error log or zar7.com’s specific log (usually in /var/log/nginx/):

  tail -f /var/log/nginx/error.log
  

  Look for lines like connect() failed (111: Connection refused) while connecting to upstream—this tells you exactly why Nginx can’t reach the backend (port closed, service down, etc.).
• Check VPS resource limits: If your VPS is low on memory, the backend service might crash unexpectedly. Check memory usage with:

  free -h
  

  If memory is tight, consider upgrading your VPS or optimizing backend settings (like reducing the number of PHP-FPM processes).

If you’ve gone through all these steps and still have issues, share snippets of your Nginx config files for both domains and the relevant error log lines—I’ll help you parse them further.

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