我真的很烦那种一上来就让人把Apache或者Nginx卸载了重装的教程。

明明是个配置问题非要把整个服务器折腾一遍，不仅慢还容易出新bug。最近有个朋友找我，说他在Ubuntu上折腾了一下午，linux建设网站php打开提示404，最后发现其实只是多打了两个斜杠的事。

气人不？

今天我就把我在生产环境里踩过的坑全抖落出来。如果你也遇到了这个问题，先看这几点，别去翻那些几百页的官方文档。

首先，检查你的文档根目录对不对。

这是最基础也是最容易错的地方。很多人习惯在/var/www/html下放文件，但在CentOS或者Debian的最新版本里，默认路径可能不一样。比如Nginx在CentOS下往往是/html或者/usr/share/nginx/html，而在Ubuntu下才是/var/www/html。

如果你的站点文件在/data/web/app下，但配置里写的是/root/www，那服务器当然找不到文件，自然给你甩个404。别怀疑人生，去ls一下你的目录，再cat一下你的配置文件（比如/etc/nginx/sites-available/your_site）。确保root指向的路径下确实有index.php或者你访问的文件。

其次，看看你的虚拟主机Host头设置。

很多人忽略这点。Nginx配置里，server_name后面写的是域名，但本地测试时你用的是IP地址或者localhost。虽然Nginx通常会把第一个定义的server块作为默认，但如果你开了多个vhost，顺序没排好，或者IP没加到server_name里，请求就会匹配到默认的那个80端口服务器，而那个服务器往往没配你的站点逻辑。

试一下，把访问的IP地址或者域名明确加进server_name，保存，重载配置。很多时候问题就解了。

第三步，也是最坑人的：SELinux。

如果你用的是CentOS或者RHEL系的服务器，SELinux默认是Enforcing模式。它像个大管家，管得特别严。哪怕你的用户权限是755，Nginx worker进程跑的是nginx用户，它也可能觉得这个目录“不安全”，直接拒绝读取，表现出来就是404，而不是403。这反直觉吗？太反直觉了。很多新手会以为权限不对去chown，改半天没用。

这时候你需要运行audit2allow -a，或者直接临时设为Permissive测试。如果是生产环境，建议给Nginx的tcontext打上标签：chcon -R -t httpd_sys_content_t /data/web/app。这一步不做，后面怎么调代码都白搭。

我见过太多人在这一步耗时间，以为是自己PHP代码写错了，结果日志里全是Permission denied。

还有一个小细节，检查PHP-FPM的sock文件路径。

虽然sock不通通常报502，但如果路径配置得极其离谱，或者FastCGI超时被Nginx当成404处理（虽然很少见，但逻辑混乱的配置下会发生），也得排查。去/etc/nginx/conf.d目录下看fastcgi_pass是指向unix:/tmp/php-fpm.sock还是unix:/var/run/php-fpm/php-fpm.sock。两边不一致的话，Nginx找不到后端进程，虽然报错码可能不对，但也会表现得很诡异。

最后，别忘了清空浏览器缓存。

我知道这句废话，但真有20%的人是卡在这里的。你后台改好了配置，前台还在读旧的资源。强制刷新一下，或者换个无痕窗口访问。

说了这么多，其实就是几个点：路径、Host匹配、系统安全策略、后端连接。

linux建设网站php打开提示404这个现象，90%都是配置文件里的某个绝对路径写错了，或者系统级的安全拦截。别被那个404吓住，它不一定代表文件不存在，只代表服务器“不敢”给你看。

如果你还是没解决，把你nginx -t的输出和access.log的最后三行贴出来，大概率一眼就能看出问题。别再盲目重启服务了，那样只会让你的日志文件越来越大，掩盖真正有用的报错信息。

技术这东西，不怕难，就怕闷头撞墙。遇到坑记下来，下次再遇到linux建设网站php打开提示404的问题，你笑一下就好，因为你知道该怎么破了。