404 是 Web 服务器找不到文件路径所致,非 PHP 报错;需依次验证 PHP 解析是否生效、检查 .htaccess 重写规则是否误拦截真实 PHP 文件、确认上传路径与虚拟主机文档根目录一致,并排除大小写及隐藏字符问题。
404 不是 PHP 报错,而是 Web 服务器(如 Apache 或 Nginx)说“我根本没找到你要的这个文件路径”。在虚拟主机环境下,你没有 root 权限改全局配置,排查必须聚焦在你能控制的层面:文件位置、URL 路径、.htaccess、以及服务商是否真支持 PHP 解析。
这是虚拟主机最隐蔽的坑:有些廉价主机默认不解析 .php 文件,而是把它当普通文本下载或拒之门外,浏览器一请求就 404(甚至不报错,只空白)。
快速验证:
info.php,内容只有
public_html 或 www)http://你的域名/info.php —— 如果看到 PHP 信息页,说明解析正常;如果下载文件、显示源码、或直接 404,那问题出在服务器未启用 PHP 处理application/x-httpd-php 还是 CGI/FastCGI)。.htaccess 是否偷偷劫持了所有请求很多虚拟主机默认允许 .htaccess,而 CMS(如 WordPress、Typecho)或手动加的伪静态规则常包含兜底重写:
RewriteEngine On这类规则本意是把所有“找不到的真实文件”转给
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php [QSA,L]
index.php,但它有个漏洞:如果 about.php 真实存在,按理应跳过重写——但某些虚拟主机的 Apache 模块版本或 AllowOverride 配置异常,会导致 !-f 判断失效,结果连真实 PHP 文件也被转发,而 index.php 又没处理它,最终 404。.htaccess 重命名为 .htaccess.bak
/about.php,能打开就坐实是它的问题RewriteEngine On
# 显式放行真实存在的 .php 文件
RewriteCond %{REQUEST_FILENAME} -f
RewriteCond %{REQUEST_FILENAME} \.php$
RewriteRule ^ - [L]
# 其余路由逻辑保持不变
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php [QSA,L]
虚拟主机控制面板(如 cPanel)里写的“网站根目录”未必是你直觉认为的那个路径。例如:
blog.abc.com,它的根目录可能是 public_html/blog/,而不是 public_html/
public/ 或 htdocs/,而你传到了上级文件夹index.php 就在这个路径下,且 URL 中的路径层级完全匹配(http://blog.abc.com/test.php 对应的就是 public_html/blog/test.php)Linux 虚拟主机严格区分大小写,About.php 和 about.php 是两个文件。
更难发现的是不可见字符:复制粘贴 URL 时可能混入全角斜杠 /、中文顿号、零宽空格(尤其从微信、Word 里复制过来),浏览器地址栏看着一样,服务器却完全识别不了。
务必:
contact .php)ls -la 确认文件名原貌虚拟主机的限制决定了你无法像本地环境那样改 httpd.conf 或重启服务,所有排查必须落在“上传了什么”“写了什么规则”“路径对不对”这三件事上。最容易被跳过的其实是第一步:先确认 PHP 解析本身是否生效——很多所谓“404”,本质是服务器压根没跑 PHP 引擎。