虚拟机里的404，本质是请求已经走到了Web服务，但服务端在它认为”对”的目录里没找到对应文件绝大多数情况是root、location、context path这几处路径没对齐，或者前端路由与后端转发规则打架，按”日志→配置→权限→路由”顺序排查，通常十几分钟就能锁定位置。
404到底是什么：先分清”找不到”和”连不上”
浏览器甩出一个404页面，很多人第一反应是”服务器挂了”，其实不是，服务器活得好好的，只是它翻遍了指定目录,没找到你要的那个东西。
这在HTTP语义里很明确：404是资源不存在，502是网关拿不到后端响应，403是文件在但你没权限看，500是程序自己跑挂了。判断错了方向,排查会越走越偏。
| 状态码 | 谁在报错 | 典型场景 |
|---|---|---|
| 404 | Web服务或应用层 | 路径写错、文件没上传、路由未配置 |
| 403 | Web服务 | 目录权限不足、SELinux拦截、IP限制 |
| 500 | 应用代码 | 程序异常、依赖缺失、配置报错 |
| 502 | 反向代理 | 后端进程没起、端口不通、超时 |
虚拟机环境里还有一类特殊404：不是你的网站404，而是云平台控制台、管理页面自己报404，前者查你自己的配置，后者查访问地址、API版本和反向代理的子路径，两类问题的处置路径完全不同,动手前先看清楚报错页面是谁的。
虚拟机里网站返回404的常见原因排查
根目录配错了：Nginx和Apache的root最容易踩坑
改完配置忘了reload，是高频事故，文件已经传到/var/www/new-site，配置里还写着/var/www/html,请求自然落空。
先确认生效配置：
nginx -T | grep -n "root\|server_name"
注意两点：server_name没匹配上的请求会落到默认站点，返回的是默认站点目录下的404；location里的root和alias行为不同，alias结尾斜杠不配对就会拼出奇怪路径。
Apache同理，看DocumentRoot和<Directory>，改完systemctl reload httpd。
权限与SELinux：文件明明在，服务却读不到
ls能看到文件，不代表Nginx能读，目录缺x权限，遍历就断了；文件缺r权限，读取失败。目录至少要755，文件至少644，属主要让Web进程能访问。
CentOS系还要过SELinux这一关,临时验证：
getenforce # 看是否Enforcing setenforce 0 # 临时关掉测试
如果关掉后404变200，说明是安全上下文问题，用chcon -R -t httpd_sys_content_t /var/www/your-site修正，别长期关闭SELinux,Ubuntu系对应的是AppArmor。
前端路由history模式，刷新就404
Vue Router的createWebHistory、React Router的BrowserRouter，靠浏览器History API切页面，首屏能进，按F5刷新就404因为刷新时浏览器真的向服务器要/user/123这个路径,而服务器上根本没有这个文件。
修法是在Nginx里兜底：
location / {
try_files $uri $uri/ /index.html;
}
意思是依次找文件、找目录，都没有就交给index.html，让前端路由自己接管。这是单页应用部署最常见的404来源，也是新手最容易误判成”后端接口挂了”的地方。
反向代理：proxy_pass尾部斜杠改变了路径
proxy_pass http://127.0.0.1:8080/;带斜杠，会把location匹配到的前缀剥掉；不带斜杠则原样透传，两边差一个字符，后端收到的请求路径就不同，404随之而来，改完用curl -I打一下后端直连地址,先确认后端自己能返回200。
虚拟机Nginx配置后访问404怎么解决：一份能照着敲的流程
按下面顺序走,基本不会绕弯路：
- 看访问日志。
tail -f /var/log/nginx/access.log，确认请求有没有到Nginx，请求的URI是什么，状态码是不是404，日志里没有这条请求，说明问题在更前面DNS、安全组、负载均衡。 - 看错误日志。
tail -50 /var/log/nginx/error.log，权限拒绝、文件不存在会写得很清楚。 - 本机直连测试。
curl -I http://127.0.0.1/，本机通而外网不通，问题在网络层,不在配置层。 - 核对生效配置。
nginx -T输出完整配置树，重点看root、location、try_files、proxy_pass。 - 确认文件真的在。
ls -l /var/www/xxx，别只看本地开发机,虚拟机里的目录结构经常和想象的不一样。 - 查权限与安全上下文。
ls -lZ看SELinux标签，namei -l /var/www/xxx/index.html逐级看权限。 - 重载并复测。
nginx -t && systemctl reload nginx，再curl -I验证。
七步里八成的404会停在第1步或第4步。
虚拟机Tomcat项目404的单独处理
Java项目不走Nginx那套逻辑,重点看三处：
- war包名就是context path，丢进去的是
demo.war，访问地址就是http://ip:8080/demo,直接访问根路径当然404。 server.xml里的Host appBase和Context path配置是否和部署方式一致。autoDeploy是否开启,热部署失败时日志里会有明确提示。
日志看logs/localhost..log，路径问题会写”requested resource is not available”。
云服务器上部署网站提示404错误是什么原因
把同样的站点从本地虚拟机搬到云上，配置一字不改却404,问题往往出在云平台这一层。
本地虚拟机和云服务器404有什么区别
| 排查项 | 本地虚拟机 | 云服务器 |
|---|---|---|
| 网络入口 | 桥接/NAT，直接访问IP | 安全组、负载均衡、CDN多层转发 |
| 路径改写 | 一般不涉及 | SLB路径转发、CDN回源路径可能改变URI |
| 拦截行为 | 无 | WAF、备案拦截可能返回自定义页面 |
| 缓存 | 基本无 | CDN缓存旧规则，改配置后仍返回旧404 |
安全组不通通常表现为超时而非404，所以看到404先别急着改安全组，真正要查的是负载均衡的转发规则、CDN的回源路径，以及WAF是否把请求改写或拦截了，修改后记得刷新CDN缓存,否则新配置要等缓存过期才生效。
平台层404：控制台和管理页面打不开
登录入口地址拼错、API版本号对不上、反向代理把子路径吃掉，都会让云平台管理页返回404，业内专家指出，这类问题优先核对官方文档给出的完整访问地址，再确认本地hosts和代理软件没有做额外改写，浏览器无痕模式复测一次,能排除大部分缓存干扰。
修复之后：把404挡在复发之前
定位到原因只是第一步，想让同样的坑不再踩第二次,做三件事就够：
- 配置纳入版本管理，Nginx、Apache的站点配置放Git,改之前先看diff。
- 加一条健康检查，定时
curl -I关键页面，非200就告警,比等用户投诉快得多。 - 日志留存至少7天，404的URI分布能直接告诉你哪些链接失效、哪些爬虫在乱扫。
行业共识认为，Web层故障里路径配置类问题占比一直不低,而这类问题恰恰是最容易通过流程规范避免的。
虚拟机404错误常见问题解答
虚拟机404和500有什么区别，怎么快速判断
404是”东西不在”，500是”东西在但程序崩了”，快速判断方法：看错误日志，Nginx的error.log里出现”open() failed (2: No such file or directory)”就是404路径问题；出现”upstream prematurely closed”或应用堆栈，就是500，两者处置方向相反，404改路径,500查代码和依赖。
虚拟机404修复大概多少钱
看复杂度，单纯改一处root或补一条try_files，属于配置类小修，市面按次收费通常几十元到一两百元，涉及云上负载均衡、CDN回源、多级反向代理的链路排查，一般按工时计，几百到上千元一天的区间都有。报价前把访问日志、nginx -T输出、拓扑结构准备好，能显著缩短排查时间，费用也更可控。
重启虚拟机能不能解决404
不能，404是资源路径问题，不是进程崩溃，重启只会让服务重新加载配置。唯一可能”碰巧”生效的情况，是之前改了配置但没执行reload，重启时顺带加载了新配置。这种运气不可依赖，正确做法是改完配置执行nginx -t校验语法，再systemctl reload nginx平滑生效，然后用curl -I验证状态码。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/772564.html
