与FastCGI配合使用时try_files指令失效问题排查

你遇到的问题是try_files $uri =400没有按预期阻止不存在的PHP文件请求传递给PHP-FPM，反而返回了PHP的404错误，这大概率是location内的if指令干扰了try_files的执行逻辑，或者配置顺序/细节有问题。下面一步步帮你排查和修复：

核心问题原因 #

Nginx的if指令在location块内使用时，经常会导致意外的行为（社区常称它为"evil if"）。你在location ~ \.php$里加入的if ($http_x_forwarded_proto = 'https')块，可能打乱了try_files的执行顺序，使得Nginx没有正确触发=400的状态码返回，反而继续将请求传递给了PHP-FPM——而PHP-FPM在处理不存在的脚本时，自然返回了它自己的404错误。

修复方案 #

1. 用map指令替代location内的if #

把设置$fe_https变量的逻辑移到server块外部，使用map指令（这是Nginx官方推荐的方式，避免if的副作用）：

# 在server块之前添加
map $http_x_forwarded_proto $fe_https {
    default off;
    https on;
}

server {
    listen 80;
    root /var/www/html;
    index index.php;

    error_page 403 /error-403;
    error_page 404 /error-404;

    location ~ \.php$ {
        # 移除原来的if块
        try_files $uri =400;

        include fastcgi_params;
        fastcgi_split_path_info ^(.+\.php)(/.+)$;
        fastcgi_index index.php;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_param PATH_INFO $fastcgi_path_info;
        fastcgi_param HTTPS $fe_https;
        fastcgi_pass php:9000;
    }
}

2. 验证try_files的行为 #

修改后，重启Nginx再测试请求/no-file.php：

• 如果文件不存在，Nginx应该直接返回400状态码（默认的Nginx 400页面，或者你可以添加error_page 400 /error-400;自定义页面）。
• 如果文件存在，请求会正常传递给PHP-FPM处理。

3. 额外的验证步骤 #

如果还是有问题，可以检查以下几点：

• 确认Nginx容器内的/var/www/html路径下确实不存在no-file.php（毕竟Nginx是在自己的容器内判断文件是否存在，和PHP-FPM容器的路径无关）。
• 查看Nginx的错误日志（通常在/var/log/nginx/error.log），搜索请求记录，确认是否有try_files test: "/var/www/html/no-file.php" -> not found和try_files test: "=400" -> status code 400的日志条目，这能证明try_files正在正确工作。

为什么这样修复？ #

map指令是Nginx专门用来根据变量值设置新变量的方法，比if指令更可靠、更符合Nginx的配置逻辑。移除location内的if后，try_files会按照预期先检查文件是否存在，不存在则直接返回400，不会继续执行后续的fastcgi_pass指令，彻底阻断了不存在的PHP请求传递给PHP-FPM。

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