php在服务器上运行找不到怎么回事，是什么原因导致的？

Nginx或Apache没有把PHP文件交给PHP解释器处理,这是九成以上“PHP上传服务器后找不到文件”问题的根源，并非你的PHP代码写错了，而是Web服务器根本不认识这个文件，压根没执行它。

php文件上传服务器后打不开404是什么原因

很多朋友在本地用集成环境（比如phpstudy、XAMPP）调试代码一切正常，一旦把文件传到云服务器上，访问路径就报“404 Not Found”或者“找不到文件”，这背后最常见的原因，是你的服务器压根没有配置PHP的解析规则，本地集成环境把Apache/Nginx跟PHP的“联姻”安排得明明白白，但服务器上的纯净环境必须由你手动指定：哪个路径下的PHP文件需要交给php-fpm进程来处理。

加载中

搞笑呢！新建的网站竟然无法访问 php建站打不开 你有问题我来回答

写代码的猫叔

749452-

原视频地址

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 + 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，和你服务器上的真实路径做对比，一级一级目录地去比对，基本五分钟内就能锁到问题所在。