Nginx 下 PHP 文件被浏览器下载而非执行的完整排查与修复指南-php教程-PHP中文网

Nginx 下 PHP 文件被浏览器下载而非执行的完整排查与修复指南

当 Nginx 将 index.php 等 PHP 文件直接作为二进制流下载，而非交由 PHP-FPM 解析执行，本质是 FastCGI 请求转发链断裂——常见于 try_files 误拦截、SCRIPT_FILENAME 路径错误、PHP-FPM 未就绪或权限不匹配。本文提供系统化诊断路径与生产级修复方案。

当 nginx 将 index.php 等 php 文件直接作为二进制流下载，而非交由 php-fpm 解析执行，本质是 fastcgi 请求转发链断裂——常见于 try_files 误拦截、script_filename 路径错误、php-fpm 未就绪或权限不匹配。本文提供系统化诊断路径与生产级修复方案。

? 根本原因：请求未进入 PHP 处理流程

浏览器下载 .php 文件，绝非 PHP 版本或代码问题，而是 Nginx 配置中请求在到达 location ~ \.php$ 块前已被其他规则“截胡”并作为静态文件返回。典型诱因包括：

location / 中 try_files 指令错误地将 /index.php 解析为可直接提供的静态文件（如示例中 try_files $uri /public/$uri /index.php$is_args$args =404）；
fastcgi_param SCRIPT_FILENAME 路径拼接失败，导致 PHP-FPM 收到空或非法路径，拒绝处理并返回原始文件内容；
fastcgi_pass 指向的 PHP-FPM socket 或端口未监听，或 Nginx 进程无权访问该 socket；
include fastcgi_params 缺失或被重复包含，造成关键 CGI 变量（如 QUERY_STRING、REQUEST_METHOD）为空。

✅ 关键验证点：访问 https://rss.getty.nz/index.php 时，Nginx 是否真正将请求交给 location ~ \.php$？可通过 nginx -T | grep -A 10 "location ~ \.php" 检查配置生效顺序。

?️ 快速修复：修正 `try_files` 与 PHP 块配置

您配置中的核心问题在于 location / 的 try_files 规则：

location / {
    try_files $uri  /public/$uri /index.php$is_args$args =404;
}

该行末尾的 =404 会强制将 /index.php 视为一个需返回的静态资源路径（而非触发 PHP 处理），一旦 /index.php 文件存在，Nginx 就直接读取并下载其原始内容 —— 完全绕过 location ~ \.php$ 块。

✅ 正确写法（推荐 Laravel/ThinkPHP 类框架风格）：

location / {
    try_files $uri $uri/ /index.php?$query_string;
}

同时，精简并加固 PHP 处理块（删除冗余 include，确保路径准确）：

Nginx Config Linter

对 Nginx 配置文件进行语法检查、验证和安全、性能审计。

下载

location ~ \.php$ {
    # 严格限制仅处理真实存在的 PHP 文件
    try_files $fastcgi_script_name =404;

    # 指向正确的 PHP-FPM 实例（Raspberry Pi 1B 上通常为 Unix socket）
    fastcgi_pass unix:/run/php/php7.4-fpm.sock;

    # ⚠️ 关键：SCRIPT_FILENAME 必须基于 $document_root 动态拼接
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

    # 包含标准 FastCGI 参数（无需重复 include fastcgi_params）
    include snippets/fastcgi-php.conf;

    # 确保 index.php 为默认入口
    fastcgi_index index.php;
}

? 提示：snippets/fastcgi-php.conf 已内置 fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; 和 include fastcgi.conf;，因此无需额外 include fastcgi_params，避免参数冲突。

✅ 必做验证清单（5 步闭环）

执行以下检查，确保每一步均通过：

步骤	命令/操作	预期结果
1. PHP-FPM 是否运行？	`sudo systemctl status php7.4-fpm`	`Active: active (running)`
2. Socket 是否监听？	`sudo ss -tlnp \\| grep php7.4`	显示 `u_str LISTEN ... /run/php/php7.4-fpm.sock`
3. 权限是否允许？	`ls -l /run/php/php7.4-fpm.sock`	属主为 `www-data:www-data`（Debian/RPi 默认），权限 `srw-rw----`
4. Nginx 配置语法？	`sudo nginx -t`	`syntax is ok`, `test is successful`
5. 重载服务	`sudo systemctl reload nginx && sudo systemctl restart php7.4-fpm`	无报错，日志中无 `connect() to ... failed`

? 针对 Raspberry Pi 1B 的特别注意事项

性能敏感：Pi 1B 内存仅 512MB，建议在 /etc/php/7.4/fpm/pool.d/www.conf 中调低 PHP-FPM 进程数：
```
pm = static
pm.max_children = 4    # 默认可能为 5，建议降至 3–4
pm.start_servers = 2
```
Socket 路径一致性：确认 /etc/php/7.4/fpm/pool.d/www.conf 中 listen = /run/php/php7.4-fpm.sock 与 Nginx fastcgi_pass 完全一致（注意路径大小写与版本号）。
日志定位问题：若仍异常，检查 tail -f /var/www/rss.getty/rss.error.log 与 /var/log/php7.4-fpm.log，重点关注 No input file specified（路径错误）或 Connection refused（PHP-FPM 未启动）。