Nginx静态资源404主因是root/alias路径拼接逻辑错误：root会拼接完整URL路径，alias则替换location前缀；务必注意alias末尾斜杠、检查实际解析路径、验证文件存在性与权限。
Nginx 访问静态资源报 404，绝大多数不是文件真丢了，而是路径拼接逻辑没理清——尤其在 root 和 alias 混用或配置不当时，Nginx 找错了地方。
下面直奔关键点，分四类快速定位：
一、先确认到底是 root 还是 alias 该用
- 用
root：适合“URL 路径 = 磁盘路径”的场景，比如访问/css/app.css就该对应/var/www/html/css/app.css - 用
alias：适合“URL 前缀要被完全替换”的场景，比如访问/assets/js/实际想读/opt/app/public/js/
常见错配：
- 在带路径前缀的 location（如
/images/）里写root /data/files;→ Nginx 会去找/data/files/images/logo.png - 正确做法是改用
alias /data/files/;→ 才会去找/data/files/logo.png
二、检查路径末尾斜杠是否规范
这个细节极容易漏，但直接导致路径粘连：
-
alias /var/www/static（缺/）→ 请求/static/a.js会去查/var/www/statica.js（自动拼接，没空格！） -
alias /var/www/static/（带/）→ 才正确映射到/var/www/static/a.js - 同样，location 也建议写成
/static/而非/static，避免匹配歧义
三、验证 Nginx 实际解析出的文件路径
别猜，让 Nginx 自己“说出来”：
- 在对应 location 块里临时加一行：
return 200 "real path: $request_filename"; - 用 curl 请求那个 404 资源，比如
curl http://localhost/static/test.js - 返回内容就是 Nginx 当前打算打开的完整路径，一眼看出它找的是不是你预期的位置
四、排除系统级干扰项
路径看着对，还是 404？继续往下查：
- 文件是否存在且大小写一致（Linux 区分
Style.css和style.css） - Nginx 进程用户（通常是
nginx或www-data）是否有读取权限：ls -l /var/www/static/test.js - SELinux 是否拦截（CentOS/RHEL）：
getenforce查状态，若为Enforcing，试运行：chcon -Rt httpd_sys_content_t /var/www/static - 配置是否生效：改完务必执行
nginx -t && nginx -s reload，别只改没 reload
不复杂但容易忽略。
