Nginx或Apache没有把PHP文件交给PHP解释器处理,这是九成以上“PHP上传服务器后找不到文件”问题的根源，并非你的PHP代码写错了，而是Web服务器根本不认识这个文件，压根没执行它。
php文件上传服务器后打不开404是什么原因
很多朋友在本地用集成环境（比如phpstudy、XAMPP）调试代码一切正常，一旦把文件传到云服务器上，访问路径就报“404 Not Found”或者“找不到文件”，这背后最常见的原因，是你的服务器压根没有配置PHP的解析规则，本地集成环境把Apache/Nginx跟PHP的“联姻”安排得明明白白，但服务器上的纯净环境必须由你手动指定：哪个路径下的PHP文件需要交给php-fpm进程来处理。
Nginx环境下,网站配置文件的location区块如果只写了静态文件支持，没有添加对.php结尾请求的处理规则，那么所有PHP文件都会被Nginx当作不存在的资源直接返回404，判断方法很简单：在网站根目录下创建一个info.php写<?php phpinfo(); ?>，然后访问你的域名/info.php，如果浏览器显示“File not found”或直接404，那就是Web服务器根本没有把请求转给PHP处理器。
Apache环境下则更隐蔽一些,因为Apache默认能“看见”文件，但如果httpd.conf里没有加载libphp.so模块（或者PHP-FPM的代理配置），服务器不会执行PHP代码，而是把源码直接输出到浏览器，或者提示“服务器不支持此文件类型”。
除了配置缺失,还有一类常见情况是路径写错了，文件根本没在它该在的位置，云服务器默认站点根目录通常是/usr/share/nginx/html或/var/www/html，而很多人把文件传到了/root或者用户主目录下，更头疼的是，有些面板（比如宝塔）创建站点时默认根目录绑定在www/wwwroot/你的域名下，如果你上传到了旧目录，自然怎么找都找不到。
nginx不解析php直接下载了怎么办
这个现象同样高频出现,你在地址栏输入xxx.com/xx.php，结果浏览器没有显示网页，反而弹出了文件下载框，或者页面满屏都是PHP源代码。这说明Nginx完全没把PHP请求交给php-fpm，而是把它当成了普通文本文件直接返回了，用curl命令测试更直观：curl -I http://你的域名/info.php，返回的Content-Type如果是application/octet-stream，就坐实了问题服务器没有执行PHP。
解决办法是在Nginx的site配置里,为server块添加如下解析规则：
location ~ .php$ {
root /你的站点根目录;
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include fastcgi_params;
}
这里最容易犯的错是把fastcgi_param SCRIPT_FILENAME的值写成$document_root$fastcgi_script_name，但实际上$document_root在部分Nginx版本里为空值，导致PHP解释器找不到文件路径，最终同样返回“File not found”，稳妥的做法是硬编码你的绝对路径：
fastcgi_param SCRIPT_FILENAME /var/www/html$fastcgi_script_name;改完配置后执行nginx -t测试语法，然后systemctl reload nginx，如果依然不行，检查php-fpm是否真的在运行，执行ps aux | grep php-fpm，如果没有任何进程输出，说明PHP-FPM服务压根没启动，你要用systemctl start php-fpm把它拉起来。
PHP运行在Windows服务器上找不到与Linux的区别
不少中小企业或个人站长还在用Windows Server + IIS跑PHP站点，这块的排查思路稍有不同，Windows服务器上最常见的问题是IIS的处理器映射缺失，IIS默认只认asp/aspx，你需要在IIS管理器里给PHP单独添加一个处理程序映射，把.php请求交给php-cgi.exe去执行，具体路径是：IIS管理器 → 站点 → 处理程序映射 → 添加模块映射，请求路径填.php，模块选FastCgiModule，可执行文件填PHP安装目录下的php-cgi.exe。
Linux服务器和Windows服务器在PHP运行方式上的核心区别如下表：
| 对比项 | Linux服务器 | Windows服务器 |
|---|---|---|
| PHP运行形式 | PHP-FPM（独立进程池） | FastCGI（配合IIS） |
| 配置文件位置 | /etc/php/或/usr/local/php/etc/ |
PHP安装目录下的php.ini |
| 常见Web服务器 | Nginx/Apache | IIS |
| 重写规则支持 | 需要手动配置伪静态 | 需要导入URL Rewrite规则 |
行业共识认为,Linux + Nginx + PHP-FPM是当前最高效稳定的部署组合，但Windows+IIS对新手更友好，不需要碰命令行，如果你在Windows上部署PHP站遇到“找不到文件”，第一反应应该去IIS的“错误页”设置里看具体是404还是500，如果是404，几乎可以断定是处理程序映射没匹配上。
排查PHP版本与解析器本身的故障
排除网站配置问题后,还有相当一部分场景是PHP解析器自己出问题了，你安装了PHP 8.2，但网站代码是用PHP 5.6语法写的，用了大量mysql_函数，那PHP解释器会直接报“Fatal error: Call to undefined function”，这类报错经常被运维人员误判为“文件找不到”，因为看起来是白屏或500。
还有一类容易忽略的是php-fpm.sock权限问题，在Ubuntu/Debian系统上，php-fpm默认监听Unix socket（文件路径类似
/run/php/php8.2-fpm.sock），Nginx配置里需要指定fastcgi_pass unix:/run/php/php8.2-fpm.sock;，如果这个sock文件的权限是www-data用户没有权限访问的，Nginx会交给php-fpm一个“Access denied”的请求，显示出来的效果也是找不到文件。
如果你使用的是宝塔面板这类可视化运维工具,PHP文件打不开还有一个很隐蔽的原因PHP版本被切换了，但你没有重载PHP-FPM服务，面板上安装了多个PHP版本时，站点绑定的PHP版本与实际运行的进程不一致，就会出现诡异的间歇性404。
查看错误日志快速定位问题
手工排查的效率太低,正确的姿势是直接看日志，Nginx的错误日志路径通常在/var/log/nginx/error.log，执行tail -50 /var/log/nginx/error.log，如果你看到类似Primary script unknown或FastCGI sent in stderr: "Access to the script ... has been denied的报错，那就已经把问题范围锁定在了Nginx到PHP-FPM这一步。
再看PHP-FPM的日志，路径一般在/var/log/php8.x-fpm.log，执行tail -50 /var/log/php8.x-fpm.log，如果里面有WARNING: [pool www] seems busy或ERROR: unable to bind listening socket，说明PHP-FPM没有正常对外提供解析服务。
绝大多数情况下,配置错误造成的“找不到文件”只涉及两个文件：Nginx的站点配置文件和php.ini，跟你的业务代码毫无关系，在Linux服务器上用一条命令组合拳可以快速验证链路是否打通：
curl -I http://localhost:8080/info.php如果返回200且Content-Type为text/html，说明PHP解析已经正常工作；如果返回404，直接检查Nginx的location匹配规则中的root路径是否跟文件实际存放路径完全一致，这是最容易踩坑的点，很多运维同学把root写在了server级别，而location级又写了另一条root，两个路径不一致时，PHP请求会被路由到错误的目录去查找文件。
网站源码传到服务器php找不到文件怎么处理
有部分情况是文件上传不完整导致的,用FTP工具（比如FileZilla）传输PHP文件时，如果中途断开重连，文件可能只有部分字节被写入服务器，当你用浏览器访问时，PHP解释器解析到一半就报“unexpected end of file”，但这种情况下报错的是Parse error，不是“找不到文件”，所以判断标准依然清晰。
比较诡异的属于简米云、酷番云服务器安全组和宝塔防火墙双重拦截，有些服务商默认只放行80和443端口，如果你用非标准端口（比如8080）跑PHP开发服务器，外部访问自然连接不上，那个体验也类似于“找不到文件”，宝塔面板的防火墙里如果未放行对应端口，你用
http://公网IP:8080/phpinfo.php访问，浏览器会直接显示“无法访问此网站”。
还有一条冷门路径：如果你是用Gzip压缩包上传的PHP代码，上传后在服务器上解压时出现了中文文件名乱码或目录层级错乱，也会导致访问路径不匹配，比如压缩包内目录是/www/，解压后文件被放到了/www/www/下，浏览器访问的还是/www/info.php，自然404，用命令find /你的站点根目录 -name "info.php"可以快速确定文件究竟在哪。
最后补一条实用的建议：给站点根目录设置正确的用户权限，在Linux下运行chown -R www-data:www-data /你的站点根目录，然后chmod -R 755 /你的站点根目录，权限不对会导致PHP-FPM进程没有读取文件的权限，表现同样是“找不到文件”，很多新站长把文件上传到服务器后，文件属主是root，而Nginx的worker进程是以www-data用户运行的，没有读权限，访问时就会出现诡异的“No such file or directory”偏偏文件就在那里，用ls看得到，浏览器却死活打不开。
PHP文件在服务器上执行不了的常见问答
问：Nginx配置了fastcgi_pass后还是报Primary script unknown，怎么排查？
先执行php -v确认环境里有没有装PHP解释器，然后打开Nginx站点配置文件，检查root指令是否指向了包含PHP文件的真实目录，重点检查fastcgi_param SCRIPT_FILENAME参数，命令行执行nginx -T | grep fastcgi_param，看它解析出的路径是否符合预期，另外检查php-fpm进程是否以监听TCP端口的方式运行，如果是sock模式，确认sock文件是否存在且权限正确。
问：本地测试正常，一上传到服务器就白屏，是哪里出了问题？
白屏大概率是PHP解析错误被隐藏了,在PHP文件顶部加两行代码：ini_set('display_errors', 1); error_reporting(E_ALL);，刷新页面后就会看到具体报错信息，这类问题绝大多数是PHP版本差异造成的，老代码用了新版本废弃的函数，或者新代码用了老版本不支持的语法，建议检查一下服务器上安装的是哪个PHP版本，跟本地开发环境是否对齐。
问：Linux服务器上php-fpm进程在跑，但访问PHP文件还是404，这是什么原因？
如果你确认php-fpm活着且Nginx配置正确，那问题基本出在root指向的目录不存在，或者站点根目录下根本没有这个PHP文件，用命令ls -la /你的站点根目录 | grep php确认文件属性，再看Nginx访问日志tail -20 /var/log/nginx/access.log中实际请求的完整URI，和你服务器上的真实路径做对比，一级一级目录地去比对，基本五分钟内就能锁到问题所在。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/php%e5%9c%a8%e6%9c%8d%e5%8a%a1%e5%99%a8%e4%b8%8a%e8%bf%90%e8%a1%8c%e6%89%be%e4%b8%8d%e5%88%b0%e6%80%8e%e4%b9%88%e5%9b%9e%e4%ba%8b%ef%bc%8c%e6%98%af%e4%bb%80%e4%b9%88%e5%8e%9f%e5%9b%a0%e5%af%bc/
