文件未真正迁移或路径配置错误是404最直接原因，需检查DocumentRoot、DirectoryIndex、.htaccess/Nginx重写规则、文件权限及大小写敏感性，并清缓存验证真实响应。
检查文件是否真正在目标服务器目录中
迁移后404最直接的原因是文件没拷全，或上传时被跳过。别只看FTP客户端的“传输完成”提示——它不校验内容一致性。
登录服务器（SSH 或 FTP），执行 ls -la 确认 HTML 文件（如 index.html）确实存在于你配置的 DocumentRoot 目录下，且权限允许读取（通常 644 即可）。特别注意：
- 隐藏文件（如
.htaccess）可能未启用显示，需手动确认是否一并迁移 - Windows 本地打包的 ZIP 解压到 Linux 服务器后，可能因换行符或编码导致文件名乱码，用
ls | od -c查看真实字节 - 某些 CMS（如 WordPress）会把实际 HTML 页面存在数据库里，迁移时只传了空壳文件夹，这时
index.php存在但内容返回 404，本质是 PHP 或 rewrite 规则没生效
验证 DocumentRoot 和 DirectoryIndex 配置是否匹配新路径
Apache 的 httpd.conf 或 Nginx 的 nginx.conf 里写的根目录，必须和你实际放文件的位置完全一致。常见错配场景：
比如你把网站移到 /var/www/my-site/，但 Apache 的 DocumentRoot 还指向旧的 /var/www/html/；或者 Nginx 的 root 指令少写了一个层级，变成 /var/www 而不是 /var/www/my-site。
立即学习“前端免费学习笔记（深入）”；
同时检查默认索引文件设置：
- Apache：确认
DirectoryIndex包含你实际使用的入口文件名，例如DirectoryIndex index.html index.php—— 如果你用的是home.html却没加进去，访问根路径就会 404 - Nginx：对应的是
index指令，语法为index index.html index.php; - 改完配置必须重启服务：
sudo systemctl restart apache2或sudo systemctl restart nginx
排查 .htaccess 或 Nginx rewrite 规则失效
静态 HTML 网站一般不依赖重写，但若原站有 SEO 友好链接（如 /about 而非 /about.html），迁移后规则没同步就会 404。
Apache 用户重点查 .htaccess 是否随文件一起上传，并确认主配置中 AllowOverride All 已开启（否则 .htaccess 被忽略）；Nginx 用户则要确认 server 块里是否复制了 location + try_files 规则，例如：
location / {<br> try_files $uri $uri/ /index.html;<br>}
漏掉这句，所有无扩展名路径都会 404。另外注意迁移后 PHP 版本变化可能导致 .htaccess 中某些指令（如 php_flag）报 500 而非 404，间接让页面不可达。
用浏览器 Network 面板确认 404 请求的真实路径
打开开发者工具 → Network → 刷新页面，点击任意标红的 404 请求，看 Headers 里的 Request URL。这个地址就是浏览器真正去哪找文件——它往往暴露真实问题：
- 显示
http://example.com/css/style.css但你实际把 CSS 放在/assets/css/下 → 改<link href="assets/css/style.css"> - 显示
http://example.com//img/logo.png（双斜杠）→ 源码里拼接路径时多写了/，比如"/" + path遇到path = "/img/logo.png" - 显示
https://old-domain.com/js/app.js→ 迁移时忘了替换硬编码的绝对 URL，尤其常见于内联 script 或 JSON 配置中
这个步骤不能跳过：很多“以为修好了”的情况，其实是浏览器缓存了旧的 404 响应，清缓存或用隐身窗口重试才能看到真实结果。
迁移后的 404 往往不是单一原因，而是路径、配置、缓存、编码四层叠加。最容易被忽略的是大小写敏感性（本地 Windows 测试正常，上线 Linux 就崩）和 .htaccess 权限开关——这两点不查日志根本看不出异常。
