PHP页面被浏览器直接下载，本质是Nginx未将.php请求转发给PHP-FPM处理，核心原因包括：location ~ .php$配置未生效、fastcgi_pass指向失效的端口或socket、SCRIPT_FILENAME参数拼接错误（如硬编码路径或漏$document_root）、root与$document_root不一致，以及PHP-FPM服务未运行。
PHP页面被浏览器直接下载，本质是Nginx没把请求转给PHP处理，而是当成纯文本文件发给了浏览器。核心原因往往不是“完全没配”，而是关键FastCGI参数缺失或错位——尤其是SCRIPT_FILENAME拼接错误、fastcgi_pass指向失效、或location ~ \.php$根本没生效。
确认 location ~ \.php$ 块是否真实生效
很多人复制了配置，但实际没起作用。常见情况包括：
- 该 location 写在了未被 include 的独立文件里，或者被注释掉（哪怕只多一个空格或中文字符）
- 它不在当前启用的 server 块中，比如写在
/etc/nginx/nginx.conf全局段，却没放进具体站点的server{}里 - root 路径和 $document_root 不一致：例如 server 块中 root 是
/var/www/html，但 SCRIPT_FILENAME 却硬写成/usr/share/nginx/html/$fastcgi_script_name
检查 fastcgi_pass 是否连得上 PHP-FPM
端口或 socket 必须真实存在且可通信：
- Windows 下 phpEnv 多用
127.0.0.1:9000，不能填 unix socket 路径 - Linux 下常用
unix:/run/php/php8.2-fpm.sock，先运行ls /run/php/确认文件存在 - 用
sudo netstat -tulpn | grep :9000或ss -tlnp | grep php查监听状态；若无输出，说明 PHP-FPM 没启动或监听配置不对
SCRIPT_FILENAME 必须动态拼接，不能硬编码
这是最易出错的一环。必须写成：
立即学习“PHP免费学习笔记（深入）”；
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
而不是：
-
fastcgi_param SCRIPT_FILENAME /var/www/html/$fastcgi_script_name;（硬路径易错位） -
fastcgi_param SCRIPT_FILENAME $fastcgi_script_name;（漏 $document_root，PHP 找不到文件） -
include snippets/fastcgi-php.conf;单独使用时，仍依赖 $document_root 正确——它不自动修复路径
验证与重启的关键动作
改完别急着 reload，按顺序操作：
- 运行
nginx -t确保语法无误 - 检查 PHP-FPM 状态：
systemctl status php8.2-fpm（Linux）或任务管理器确认php-cgi.exe进程在跑（Windows） - 执行
sudo nginx -s reload；如仍异常，某些旧环境需完整 restart，甚至重启 php-fpm 服务 - 临时加一行
error_log /var/log/nginx/php_debug.log notice;到 location 块内，看日志是否报 “No input file specified” 或 “connect() failed”
