现象与初步诊断
1. 常见表现与影响
在网站开发与运维的日常场景中，PHP 文件被下载而非执行往往意味着服务器没有把 .php 请求转发给 PHP 解释器，而是将其视为普通文件下载。这种现象直接影响网站的动态功能，导致表单提交、数据库查询、会话管理等后端逻辑失效。核心症状通常包括 浏览器弹出下载对话框、返回的内容为代码文本而非执行结果，以及 响应头中缺少正确的 PHP 解释器标识。
从安全与稳定性角度出发，快速定位原因要关注 处理器（PHP-FPM、mod_php、CGI）是否正常工作，以及 MIME 类型和处理器映射是否被覆盖或误改。若能在初步诊断阶段确认这些关键环节，将大幅缩短定位时间。
# 快速自检方法（示例，替换为实际域名）
curl -I https://your-site.test/phpinfo.php
通过上述命令可以查看响应头信息；若 Content-Type 显示为 text/plain、application/octet-stream，或 Content-Disposition 指定为 attachment，且页面内容不是预期的 HTML/PHP 结果，则很可能存在下载而非执行的问题。
2. 快速验证与横向排查要点
除了单点测试，对比同域名下的其他 .php 文件、以及对比静态资源的响应行为，可以快速确认是否是局部配置导致的问题。若只有某些目录或某些文件出现下载，那么问题更可能出在 目录权限、.htaccess 重写规则、或特定虚拟主机的配置继承上。
在排查过程中，请留意是否存在 错误日志中的提示，如“未找到处理程序”、“无法加载 PHP 模块”、“No input file specified”等信息，这些都能给出进一步线索。
环境与配置排查要点
1. 服务器端处理器与入口点的可用性
确保 PHP 解释器可用且正在运行，以及服务器能够将 .php 请求正确地交给它处理。若使用 PHP-FPM，需确认 fastcgi 连接可用，监听端口或 socket 配置正确。若使用 mod_php，需确认 相应的 Apache 模块已加载。
常见排查方向包括：PHP-FPM 是否启动、监听地址与端口是否一致、进程权限与 SELinux 策略是否阻止执行。
# 查看 PHP-FPM 服务状态
systemctl status php7.4-fpm# 查看 Apache/Nginx 与 PHP-FPM 的通信端口或 socket
ss -tulnp | grep php-fpm
2. MIME 类型与处理器映射
下载行为往往与 MIME 类型映射和处理器映射直接相关。请确认服务器对 .php 的处理规则未被覆盖，且 AddHandler、SetHandler、以及 location / ~ 等指令未误将 .php 作为静态资源处理。
在 Apache 与 Nginx 环境中，正确的映射是将 .php 请求转发到 PHP 解释器，而不是直接输出源代码。若出现错误，需要在相应的配置文件中显式声明处理逻辑。
3. 站点根目录与虚拟主机的继承关系
许多网站是在多虚拟主机共用同一服务器时出现“下载”，往往是由于某个虚拟主机的配置未正确继承父级的处理规则，或某些目录被覆盖 Override 了默认设置。请检查 虚拟主机块、目录块以及 .htaccess 文件，确保没有错误覆盖导致 .php 被识别为静态资源。
从应用层与代码层的排查要点
1. 应用层的处理链路是否完整
PHP 解释器是否能被 Web 服务器正确调用，是判断“下载”现象的关键。请确认 请求先经过 Web 服务器，然后进入 PHP-FPM/CGI/ mod_php，再由 PHP 解释器输出执行结果。若途中断裂，浏览器可能直接接收到未处理的文件。
需要重点检查：入口脚本路径正确性、auto_prepend_file/auto_append_file 等自动加载配置是否有异常、以及是否存在 短路导致直接输出源码 的自定义中间件。
2. 常见代码与配置导致的问题点
某些框架或自定义中间件在未正确配置输出缓冲、或在权限不足时回退静态资源，会造成误判为“下载”。请关注：响应头的 Content-Type 与 Content-Disposition、输出前的缓冲区状态、以及 日志中关于权限和路径的错误信息。
快速修复方法与实施步骤
1. 修复清单（分阶段落地）
第一阶段目标是恢复 .php 文件的执行能力、并确保之后不会再次回落到下载行为。请对照以下清单执行逐项修复：检查并修复处理器映射、校正 MIME 类型、以及 修复目录权限与 SELinux/AppArmor 规则。
在执行阶段，务必记录每一步的变更，并在完成后执行 端到端的功能验证，确保动态页能够正确渲染。
# 示例：修复 Apache 的 .php 处理
a2enmod php7.4
systemctl restart apache2# 示例：Nginx 配置指向 PHP-FPM
# 在 https 配置块中绑定 fastcgi
2. 服务器配置的具体修复示例
以下示例展示了在常见环境中需要确认或调整的要点。请根据实际服务器版本与路径进行替换：确保 PHP 处理器生效，以及不要把 .php 直接作为下载资源。
# Apache（示例，适用于 mod_php）
AddHandler application/x-httpd-php .phpAddType application/x-httpd-php .php
# 确保未覆盖 .php 的 MIME 类型AddType application/x-httpd-php .php
# Nginx + PHP-FPM（示例）
location ~ \.php$ {include snippets/fastcgi-php.conf;fastcgi_pass unix:/var/run/php/php7.4-fpm.sock;
}
如果你使用的是 CDN、反向代理或多层缓存，务必在边缘节点也进行等效的处理器映射检查，避免在分发层产生下载现象。
3. 关系到权限与安全的修复要点
对文件与目录权限、SELinux/AppArmor 限制也可能导致“下载”现象，尤其是在上传目录、缓存目录、或日志目录上。请确保 网站根目录及子目录的权限可执行，并在必要时为执行用户赋予所需访问权限。
# 常用权限修复示例
chown -R www-data:www-data /var/www/html
find /var/www/html -type d -exec chmod 755 {} \;
find /var/www/html -type f -exec chmod 644 {} \;
典型场景与环境适配
1) 场景：Apache + mod_php / PHP-FPM
在这种场景下，确保 mod_php 已启用且与 PHP 版本匹配，或确保 FastCGI 连接可用。若使用 PHP-FPM，检查监听方式（socket 或 端口）以及 pool 配置。通过对比 日志文件 /var/log/apache2/error.log 以及 /var/log/php-fpm/error.log，可以快速定位问题根源。
要点回顾：正确的处理链路、正确的响应头、以及目录继承关系，避免单点配置导致全站“下载”现象。
# 查看 Apache 错误日志
tail -n 100 /var/log/apache2/error.log# 查看 PHP-FPM 错误日志
tail -n 100 /var/log/php7.4-fpm.log
2) 场景：Nginx + PHP-FPM
在 Nginx + PHP-FPM 的部署中，Ensuring fastcgi_pass 指向正确的 PHP-FPM 实例是关键。若 fastcgi 配置不正确，Nginx 可能直接返回文件内容而非通过 PHP 解释器执行。请重点检查 socket/端口、fastcgi_param 设置、以及 try_files 的顺序。
验证路径示例： curl -I 检查响应头，确保 Content-Type 为 text/html 或 text/php 而不是应用/octet-stream。
# 典型的 Nginx + PHP-FPM 片段
location ~ \.php$ {include fastcgi_params;fastcgi_pass unix:/var/run/php/php7.4-fpm.sock;
}
验证与回归要点
1. 验证步骤与回归测试
完成修复后，进行端到端的验证测试：单点请求测试、跨目录测试、以及 动态功能的页面渲染测试。确保测试覆盖常见入口点（如登录、注册、数据查询等）。
记录测试结果与变更点，便于后续回滚与审计。若仍存在问题，请对照最近的变更，回退最近一次修改并重新执行验证。
# 简单端到端测试示例
curl -I https://your-site.test/login.php
curl -s https://your-site.test/login.php | head -n 5
2. 回滚与变更管理要点
在高风险变更阶段，建议先在测试环境完成全部验证后再推送到生产环境。请确保有版本控制记录、变更单和回滚方案，并与运维态势监控系统对接，确保变更可追溯。
