nginx 404 根本原因在于其实际查找路径与预期不符，需先确认生效的 root 路径、验证物理文件存在性及权限，并区分静态资源与 spa 刷新场景；location 中 root 拼接逻辑易错，alias 更适合前缀映射，spa 必须用 try_files $uri $uri/ /index.html 回退。
看到 404，别急着改代码或重启——大多数时候，Nginx 根本没去你认为的路径找文件。关键不是“文件在哪”，而是“Nginx 认为它该去哪找”。
先确认 Nginx 实际生效的 root 路径
location 块里的 root 会覆盖 server 级配置，且拼接逻辑容易出错。用以下命令直接看最终生效配置：
- nginx -T | grep -A 2 "location /your-path" —— 找到对应 location，确认里面写的 root 是什么
- 特别注意带前缀的 location（如 location /static/），如果配了 root /var/www，Nginx 会拼成 /var/www/static/xxx，而不是你预期的 /var/www/xxx
- 若需精确映射，优先考虑用 alias 替代 root，比如 location /static/ { alias /var/www/assets/; }，这样访问 /static/logo.png 就直接找 /var/www/assets/logo.png
手动还原并验证物理路径
从 access.log 中取出一条 404 请求的 URI（如 /css/app.css），再结合该 location 的 root 值，拼出完整路径：
- 例如 root 是 /var/www/html → 拼出 /var/www/html/css/app.css
- 执行 ls -l /var/www/html/css/app.css，检查文件是否存在、大小写是否一致（Linux 区分大小写）
- 前端打包后常带哈希名（如 app.a1b2c3.js），但 HTML 中引用的仍是旧名，也会导致 404
检查权限与 SELinux 上下文
路径对、文件在，还 404？可能是 Nginx 进程“看得见，读不了”：
- 查 worker 进程用户：ps aux | grep nginx（通常是 www-data 或 nginx）
- 模拟该用户访问：sudo -u www-data ls -l /var/www/html/css/app.css，若报 permission denied，说明权限不足
- 补上必要权限：chmod 755 /var/www/html/css（目录需 x 权限）、chmod 644 /var/www/html/css/app.css
- CentOS/RHEL 启用 SELinux 时，用 ls -Z /var/www/html 查上下文，应为 httpd_sys_content_t；否则运行 chcon -R -t httpd_sys_content_t /var/www/html
区分静态资源和 SPA 刷新 404
单页应用（Vue/React）在 history 模式下刷新出现 404，本质是 Nginx 在找物理文件，而路由该由前端接管：
- 错误配置：location / { root /var/www/html; try_files $uri =404; } —— 找不到就真返回 404
- 正确做法：location / { root /var/www/html; try_files $uri $uri/ /index.html; } —— 所有未匹配路径都 fallback 到 index.html，交由前端路由处理
- 注意：不能对根 location 用 alias，会导致 index 指令失效
