CSS文件404主因是Nginx未代理.css请求，需添加location ~.(js|css)$规则并确保proxy_pass末尾带/或不带路径，避免拼接错误，同时检查Content-Type是否为text/css。
CSS 文件 404 或加载但无样式，基本就是静态资源路径没被正确代理，不是后端问题，而是 Nginx 没把 .css 请求转发到对应服务。
为什么 location / 不能代理 CSS？
反向代理的 location / 只负责匹配以 / 开头的请求，但浏览器实际请求的 CSS 路径可能是：/static/css/app.css、/assets/main.css，甚至带版本号的 /css/style.v2.css。如果后端服务（比如 Tomcat、Spring Boot）把静态资源放在子路径下（如 /video/），而 Nginx 的 proxy_pass http://127.0.0.1:8083/video 又没做路径剥离或补充，那么请求 /static/css/app.css 就会变成去 http://127.0.0.1:8083/video/static/css/app.css 找——而这个路径在后端根本不存在。
常见表现：curl -I http://yourdomain.com/style.css 返回 404；Chrome DevTools 的 Network 面板里 CSS 请求状态码是 404；页面 HTML 能加载，但样式全丢。
- 根本原因不是文件缺失，而是 Nginx 没把这类请求“选中”并交给后端处理
-
location /不匹配.css后缀优先级低，会被更具体的location ~ \.css$覆盖——但如果你没配，它就走默认 root 或 404 - 尤其当后端用 context path（如
/video）部署时，CSS 的相对路径引用可能指向根路径，但代理没覆盖到
必须加 location ~ \.(js|css)$ 规则
这是最直接有效的解法：显式声明所有 .js 和 .css 请求都走反向代理，且不带额外前缀（避免路径拼接错误）。
在 server 块内添加：
location ~ \.(js|css)$ {
proxy_pass http://127.0.0.1:8083;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
-
proxy_pass后面的地址**不能带路径**（如http://127.0.0.1:8083/可以，但http://127.0.0.1:8083/video不行），否则请求路径会被拼接，导致 404 - 如果后端静态资源本就放在
/video/static/下，那应让后端暴露根路径静态服务（比如 Spring Boot 的spring.web.resources.static-locations），而不是靠 Nginx 拼路径 - 可顺手加上
expires 12h;提升缓存效率，但非必需
proxy_pass 末尾斜杠决定路径是否保留
这是最容易踩坑的地方。假设你写成：
location /video/ {
proxy_pass http://127.0.0.1:8083/video/;
}
那么请求 /video/style.css 会被转发为 http://127.0.0.1:8083/video/style.css —— 看似合理，但如果后端没在 /video/ 下提供静态资源，还是 404。
更稳妥的做法是：让后端服务直接响应根路径下的静态资源，Nginx 则统一代理所有 .css 请求到后端根地址：
- ✅ 正确：
proxy_pass http://127.0.0.1:8083;（无路径，保留原始 URI） - ❌ 错误：
proxy_pass http://127.0.0.1:8083/video;（少斜杠 → 路径被替换为/video） - ⚠️ 易混淆：
proxy_pass http://127.0.0.1:8083/video/;（有斜杠 → 剥离/video/后再拼接，适合 API 前缀，不适合静态资源泛匹配）
简单记：静态资源规则（~ \.(js|css)）里，proxy_pass **结尾必须有斜杠或完全不带路径**，否则行为不可控。
还要检查 Content-Type 是否正确
即使 CSS 文件能返回 200，如果响应头里 Content-Type 是 text/plain 或空，浏览器也不会解析为样式表。
排查方法：curl -I http://yourdomain.com/style.css 看响应头；或者在 Chrome Network 面板里点开 CSS 请求，看 Response Headers 中的 Content-Type。
- 如果值不是
text/css，先确认后端是否设置了正确的 MIME 类型（例如 Spring Boot 默认支持，Tomcat 需检查web.xml或容器配置） - Nginx 自身一般不会改
Content-Type，除非你手动加了add_header Content-Type ...或用了错误的types配置 - 确保
mime.types已在http块中引入：include mime.types;；没有这行，Nginx 可能无法识别.css后缀
真正麻烦的从来不是加一行配置，而是加完忘了 reload，或者 reload 了但某处语法错误导致配置没生效——每次改完务必执行 nginx -t && nginx -s reload，并盯一眼 error.log。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
