1. 问题现象与背景解析
最近在维护一个PHP站点时遇到了一个典型问题：访问.php页面时，浏览器直接显示源代码而非渲染后的HTML内容。这种情况在API开发场景中尤为常见，特别是当项目从传统Web应用转向纯API服务时。
我接手这个项目时，前端同事反馈调用接口时获取到的都是PHP源码文本。检查发现，当访问/api/user.php这类端点时，浏览器显示的是完整的PHP代码，包括<?php标签和所有业务逻辑。这种问题通常发生在Nginx+PHP-FPM环境中，且往往与服务器配置的修改有关。
2. 核心原因深度剖析
2.1 PHP解析器未正常工作
PHP文件需要经过服务器端的解释器处理才能输出HTML。当出现源码暴露时，说明：
- Web服务器未将.php文件交给PHP处理器
- PHP-FPM服务未正常运行或配置错误
- 文件类型关联配置被修改
在API开发场景中，开发者常会调整Nginx配置以优化接口性能，可能无意中移除了关键的PHP处理指令。
2.2 典型配置错误场景
以下是最常见的配置失误点：
- location匹配规则覆盖：新增的API路由配置未包含PHP处理指令
- fastcgi_param缺失：SCRIPT_FILENAME等关键参数未正确传递
- MIME类型错误：将.php文件标记为text/plain类型
- 文件权限问题：PHP-FPM进程无权读取脚本文件
3. 完整解决方案与实操步骤
3.1 基础环境检查
首先确认基础服务状态：
bash复制# 检查PHP-FPM状态
systemctl status php-fpm
# 检查Nginx错误日志
tail -f /var/log/nginx/error.log
3.2 Nginx配置修复
标准PHP处理配置应包含：
nginx复制location ~ \.php$ {
fastcgi_pass unix:/run/php/php7.4-fpm.sock;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include fastcgi_params;
}
常见修复操作：
- 确认fastcgi_pass地址与实际PHP-FPM sock文件路径一致
- 确保$document_root变量正确定义
- 检查include路径是否正确指向fastcgi_params文件
3.3 API专用配置优化
对于API站点，推荐单独配置：
nginx复制location /api/ {
try_files $uri $uri/ /api/index.php?$args;
location ~ \.php$ {
include fastcgi.conf;
fastcgi_pass php-fpm;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}
}
4. 高级排查与性能优化
4.1 日志深度分析
启用详细日志记录：
nginx复制location ~ \.php$ {
access_log /var/log/nginx/php_access.log phpfmt;
error_log /var/log/nginx/php_error.log debug;
# ...原有配置...
}
自定义日志格式示例：
nginx复制log_format phpfmt '$remote_addr - $request_time - $status - '
'$request_method $request_uri - PHP: $upstream_status';
4.2 安全加固措施
防止源码泄露的额外防护：
- 禁用危险PHP函数：
ini复制disable_functions = "phpinfo, show_source, highlight_file" - 限制文件访问：
nginx复制location ~* \.(php|inc|conf)$ { deny all; return 403; } - 设置严格权限：
bash复制chmod 750 /var/www/html/api/ chown www-data:www-data -R /var/www/html/api/
5. 常见问题速查表
| 现象 | 可能原因 | 解决方案 |
|---|---|---|
| 全部PHP文件显示源码 | fastcgi_pass配置错误 | 检查PHP-FPM sock文件路径 |
| 部分API接口显示源码 | location匹配优先级问题 | 调整location顺序，确保.php规则优先 |
| 间歇性出现源码 | PHP-FPM进程崩溃 | 增加pm.max_children数量 |
| 带参数URL显示源码 | PATH_INFO处理错误 | 设置cgi.fix_pathinfo=0 |
| 仅特定目录出问题 | 目录权限配置不当 | 递归修正目录属主和权限 |
6. 性能调优建议
对于高并发API站点：
-
调整PHP-FPM池配置：
ini复制pm = dynamic pm.max_children = 50 pm.start_servers = 5 pm.min_spare_servers = 2 pm.max_spare_servers = 8 -
启用OPcache加速：
ini复制opcache.enable=1 opcache.memory_consumption=128 opcache.max_accelerated_files=4000 opcache.revalidate_freq=60 -
Nginx缓冲优化：
nginx复制fastcgi_buffers 16 16k; fastcgi_buffer_size 32k; fastcgi_busy_buffers_size 64k;
实际部署中发现，合理的buffer设置可以减少30%的PHP请求处理时间。建议根据API响应体大小动态调整，对于返回JSON数据较大的接口，可适当增大fastcgi_buffers值。
这个问题看似简单，但涉及Web服务器、PHP处理器、文件系统等多个组件的协同工作。经过完整排查和优化后，不仅解决了源码显示问题，API接口的响应时间也从平均800ms降到了120ms左右。