Nginx无法正常提供Docker托管的Angular应用静态资源服务

一、路径映射与重写类（最高概率踩坑点） #

• 检查proxy_pass的尾部斜杠配置差异：
  宿主机location /v2/块中，如果proxy_pass http://localhost:7021;（无尾部斜杠），NGINX会将完整请求路径（含/v2/前缀）透传给容器内NGINX，即容器收到的请求为/v2/xxx.js；但Angular打包产物默认无/v2/子目录，文件直接存放在容器/usr/share/nginx/html根目录，此时容器内NGINX会因找不到/v2/xxx.js触发fallback返回index.html。
  正确配置应为proxy_pass http://localhost:7021/;（带尾部斜杠），此时NGINX会替换匹配的/v2/前缀为空，将请求转为/xxx.js传给容器，匹配根目录下的实际资源文件。
• 核对Angular打包产物的实际目录结构：
  --base-href="/v2/"仅修改index.html内的资源引用前缀为/v2/，不会创建/v2/子目录，需确认Dockerfile中拷贝产物的路径是否正确：比如如果angular.json中outputPath配置为dist/v2，需将dist/v2/*而非dist/*拷贝到容器/usr/share/nginx/html/，避免错误生成嵌套的v2子目录。

二、容器内NGINX配置排查（易被忽略的本地配置覆盖） #

• 直接在宿主机用curl测试容器服务，绕开宿主机代理：
  执行curl -I http://localhost:7021/main.js，确认容器内NGINX能否直接返回main.js的200状态与application/javascript类型；再执行curl -I http://localhost:7021/v2/main.js，对比两个请求的返回结果，快速定位是否为路径透传导致的404 fallback。
• 检查容器内NGINX的默认配置是否被意外覆盖：
  进入容器执行cat /etc/nginx/conf.d/default.conf，确认：
  • root路径是否为/usr/share/nginx/html
  • 是否正确include /etc/nginx/mime.types（Alpine镜像的mime.types路径与Ubuntu宿主机不同，若Dockerfile中手动复制了自定义配置文件，可能遗漏该引入）
  • try_files规则是否为try_files $uri $uri/ /index.html;，确认静态资源请求不会被错误fallback。
• 核对容器内NGINX的监听端口：
  Alpine版NGINX默认监听80端口，若Docker端口映射为-p 7021:80才会将容器80端口映射到宿主机7021；若端口映射写反为-p 80:7021，容器内NGINX未监听7021端口，会导致代理异常。

三、宿主机NGINX配置冲突排查 #

• 检查location块的匹配优先级：
  若宿主机存在全局正则匹配块（如location ~ \.js$ { ... }或location ~ \.css$ { ... }），其优先级会高于普通前缀匹配的location /v2/，可能导致JS/CSS请求被其他块处理，触发错误fallback。可在/v2/块前加修饰符^~（如location ^~ /v2/），强制优先匹配该前缀块。
• 确认宿主机NGINX是否开启了不必要的sub_filter或重写规则：
  若全局配置中存在sub_filter / /v2/ /index.html;这类资源替换规则，可能会修改静态资源的返回内容或类型，导致浏览器解析异常。

内容的提问来源于stack exchange，提问作者JadedEric