PHP-FPM返回的File not found.”的本质

你已经修正了SCRIPT_FILENAME的参数，但仍然显示“File not found.”，这说明问题不仅是配置参数的问题，还涉及PHP文件的路径匹配、权限、PHP-FPM的访问权限或Nginx的root指令作用域等问题。我会逐一分析并给出可落地的排查和修复步骤。

一、先明确“File not found.”的本质

这个错误是PHP-FPM返回的，而非Nginx直接返回。意味着Nginx已经把请求转发给了PHP-FPM，但PHP-FPM在$document_root$fastcgi_script_name对应的路径下，找不到对应的PHP文件，或者没有权限访问该文件。

二、分步排查与修复（按优先级排序）

步骤1：给PHP解析块添加root指令（关键遗漏项）

你的location ~ \.php$块中缺少root /app/code/zbx;指令，这会导致$document_root在PHP解析块中可能无法正确获取到项目根目录（Nginx的root指令有作用域，不同location块需要显式声明）。

修改这部分配置：

location ~ \.php$ { root /app/code/zbx; # 必须添加！和location /中的root保持一致 try_files $uri =404; # 新增：先检查文件是否存在，不存在直接返回404，避免无效请求 fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; }

• try_files $uri =404：这一步能提前过滤掉不存在的PHP文件请求，避免PHP-FPM返回错误，同时也能防止某些安全漏洞。

步骤2：验证PHP文件的实际路径是否存在

执行以下命令，确认你访问的PHP文件（比如index.php）确实在/app/code/zbx目录下：

# 检查根目录下的index.php是否存在ls-l /app/code/zbx/index.php# 如果你访问的是其他PHP文件（比如test.php），替换为对应文件名ls-l /app/code/zbx/test.php

• 如果输出“No such file or directory”，说明文件不存在，需要将PHP文件放到该目录下。

步骤3：检查PHP-FPM用户是否有权限访问文件

PHP-FPM默认以apache或nginx（部分系统是php-fpm、www-data）用户运行，该用户需要有读取PHP文件和遍历目录的权限。

1. 查看PHP-FPM的运行用户：

   # 编辑PHP-FPM的配置文件（不同版本路径可能不同，比如php74-php-fpm的配置在/etc/opt/remi/php74/php-fpm.d/www.conf）cat/etc/php-fpm.d/www.conf|grep-E'user|group'

   输出示例（通常是user = apache，group = apache）：

   user = apache group = apache

2. 修改文件和目录的权限：

   # 给目录添加遍历权限（755），给文件添加读取权限（644）chmod-R755/app/code/zbxchmod-R644/app/code/zbx/*.php# 将目录和文件的所有者改为PHP-FPM的运行用户（比如apache，根据上面的输出调整）chown-R apache:apache /app/code/zbx

   • 如果你不确定PHP-FPM的用户，也可以临时设置文件的其他用户可读：chmod -R o+r /app/code/zbx（测试用，生产环境建议严格控制权限）。

步骤4：检查SELinux是否阻止了访问（CentOS/RHEL系统常见）

SELinux的强制模式会阻止PHP-FPM访问非默认目录的文件，这是很多人容易忽略的点。

1. 临时关闭SELinux测试：

   setenforce0

   然后重新访问PHP文件，如果能正常显示，说明是SELinux的问题。

2. 永久解决SELinux问题（推荐，而非一直关闭）：

   # 给目录添加SELinux上下文，允许Web服务访问chcon -R -t httpd_sys_content_t /app/code/zbx# 若需要PHP写入文件（比如上传目录），再添加可写上下文chcon -R -t httpd_sys_rw_content_t /app/code/zbx

步骤5：查看Nginx和PHP-FPM的日志，定位具体错误

如果以上步骤都没解决，查看日志能直接找到问题：

# 查看Nginx的错误日志tail-f /var/log/nginx/error.log# 查看PHP-FPM的错误日志（路径可能不同，比如/var/log/php-fpm/error.log、/var/log/opt/remi/php74/php-fpm/error.log）tail-f /var/log/php-fpm/error.log

• 日志中如果出现“Permission denied”，说明是权限问题；如果出现“No such file or directory”，说明路径问题。

三、修复后的完整配置（汇总所有修正项）

server { listen 80; server_name localhost www.zbx888.com; location / { root /app/code/zbx; index index.php index.htm; # 把index.php放前面，优先解析 try_files $uri $uri/ /index.php$is_args$args; # 处理PHP项目路由 } error_page 500 502 503 504 /50x.html; location = /50x.html { root /usr/share/nginx/html; } location ~ \.php$ { root /app/code/zbx; # 显式声明根目录 try_files $uri =404; # 提前检查文件是否存在 fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; } # 禁止访问隐藏文件，提升安全性 location ~ /\.ht { deny all; } }

修改后记得执行nginx -t检查语法，再执行systemctl restart nginx重启Nginx。

总结

1. 核心遗漏问题是PHP解析块缺少root指令，导致$document_root无法正确指向项目目录。
2. 其次需要验证文件存在性、PHP-FPM用户权限、SELinux限制这三个常见触发“File not found.”的因素。
3. 日志是定位剩余问题的关键，若仍有报错，可通过Nginx和PHP-FPM的错误日志进一步分析。