Nginx服务器PHP服务故障时防止PHP文件被下载的最佳实践咨询

Great question—this is a critical security gap that often flies under the radar until a service outage exposes sensitive code. Let’s walk through the best practices to lock down your Nginx setup so PHP files never get served as raw downloads when your PHP handler (usually PHP-FPM) goes down.

1. Core Nginx Config to Block Raw PHP Downloads #

The first line of defense is ensuring Nginx only forwards PHP requests to your PHP service, and rejects them outright if the service is unavailable.

Add this location block to your server configuration:

location ~ \.php$ {
    # First, check if the file exists—if not, return 404 immediately
    try_files $uri =404;
    # Forward to your PHP-FPM instance (adjust the path to match your setup)
    fastcgi_pass unix:/run/php/php8.2-fpm.sock;
    fastcgi_index index.php;
    include fastcgi_params;
}

The try_files $uri =404 directive is key here: if Nginx can’t pass the request to PHP-FPM (e.g., the service is down), it won’t fall back to serving the raw file—it’ll return a 404 instead.

For extra safety, add a global block to deny access to all PHP-related files by default (place this before the PHP processing block above):

location ~* \.(php|phar|phtml|php3|php4|php5)$ {
    deny all;
}

This acts as a fail-safe: if the PHP processing block ever misbehaves, this rule will block direct access to any PHP file.

2. Fallback to Custom Error Pages Instead of Raw Files #

When your PHP service fails, Nginx might return a 502 Bad Gateway or 503 Service Unavailable. Instead of letting the default error page show up (or worse, serving the file), configure a static error page that’s safe to display:

location ~ \.php$ {
    try_files $uri =404;
    fastcgi_pass unix:/run/php/php8.2-fpm.sock;
    include fastcgi_params;
    # Redirect PHP service failures to a static error page
    error_page 502 503 /php-service-down.html;
}

# Restrict access to the error page so it can only be accessed via internal Nginx redirects
location = /php-service-down.html {
    root /var/www/your-static-files-directory;
    internal;
}

The internal directive ensures users can’t directly navigate to the error page—only Nginx itself can serve it during a failure.

3. Use Nginx Health Checks for PHP-FPM #

If you’re running Nginx 1.16 or later, you can set up health checks to automatically detect when PHP-FPM is down and stop sending requests to it. This prevents Nginx from even attempting to process PHP requests when the service is unavailable:

# Define an upstream block for PHP-FPM with health checks
upstream php-fpm-pool {
    server unix:/run/php/php8.2-fpm.sock;
    # Check health every 5 seconds; mark as down after 3 failed checks
    health_check interval=5s fails=3 passes=2;
}

location ~ \.php$ {
    try_files $uri =404;
    fastcgi_pass php-fpm-pool;
    include fastcgi_params;
    error_page 502 503 /php-service-down.html;
}

When PHP-FPM is marked as unhealthy, Nginx will immediately return a 503 error instead of trying to process the request.

4. Additional Hardening Steps #

• Set proper file permissions: Ensure PHP files have permissions of 644 (owner read/write, others read-only) and directories have 755. This prevents Nginx from accidentally modifying files, and limits exposure if a breach occurs.
• Disable autoindex: Add autoindex off; to your server block to prevent directory listing—if an attacker finds a directory without an index file, they won’t see a list of your PHP files.
• Block sensitive PHP files: Explicitly deny access to configuration files or other sensitive PHP scripts:

  location ~* /(config|database|credentials)\.php$ {
      deny all;
  }
  

All these practices work together to create a robust defense against PHP file downloads during service outages.

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