排查 try_files 兜底行为需主动验证路径存在性、变量展开及兜底目标可达性；重点检查 $uri/$uri/ 匹配、构建与引用一致性、root/alias 配置、静态资源独立拦截、子路径 base 适配及 error_page 链式降级。
排查 try_files 在静态资源丢失时的兜底行为，关键不是等 404 出现后再“捕获”，而是主动验证每一步是否按预期命中或跳转。重点看三个环节：路径是否存在、变量是否展开正确、兜底目标是否可访问。
检查 $uri 和 $uri/ 是否真被尝试
Nginx 不会自动补扩展名或猜测哈希文件，$uri 就是原始请求路径（如 /js/app.js），$uri/ 表示同名目录（如 /js/app.js/）。若资源实际是 /js/app.a1b2c3.js，而 HTML 中误引了 /js/app.js，那么 $uri 必然失败——这不是配置问题，而是构建与引用不一致。
- 用
curl -I http://your.site/js/app.js确认返回状态码，再对比ls /var/www/html/js/app*看文件真实存在形式 - 开启 Nginx debug 日志（
error_log /var/log/nginx/error.log debug;），搜索try_files相关行，能看到它依次检查了哪些路径 - 临时把
try_files改为try_files $uri =404;，确认是否真因文件不存在触发 404，排除 location 匹配错位等问题
验证兜底路径是否被正确解析
最后一个参数必须是内部重写目标：/index.html 是相对于 root 的路径，@fallback 是命名 location。常见错误是写成 index.html（缺斜杠）或 /dist/index.html（但 root 并未指向 /dist）。
- 确保
root指向构建产物根目录，且/index.html文件真实存在于该目录下 - 若用
alias（如location /admin/ { alias /var/www/admin-dist/; }），兜底必须写成/admin/index.html，不能写/index.html，否则路径拼接错误 - 用
nginx -t检查语法，再用nginx -T输出完整生效配置，确认try_files所在 location 块的root或alias定义无冲突
区分静态资源和动态路由，避免兜底误伤
如果 JS、CSS 请求也被 fallback 到 /index.html，页面会白屏或报语法错误——说明 try_files 被放在了过于宽泛的 location 中，没做前置静态资源拦截。
- 把高频静态资源用独立
location ~* \.(js|css|png|woff2)$提前声明，并在里面禁用try_files，只设缓存头和expires - API 接口（如
/api/）必须放在主location /之前，用proxy_pass显式处理，防止被try_files错误兜底 - 对子路径部署（如
/app/），前端要配base="/app/"，Nginx 要用location /app/ { alias /path/to/dist/; }，且try_files的兜底路径需匹配实际结构（如/app/index.html）
用 error_page 做更细粒度的容灾控制
当需要多级降级（本地缺失 → 回源备用站 → 返回降级页），单靠 try_files 不够，得结合 error_page 链式处理。
- 在静态资源 location 中写
try_files $uri =404;，确保只在文件不存在时触发错误 - 同一 location 内配
error_page 404 = @fallback;，注意等号表示内部重定向，保持状态码可控 -
@fallback中用proxy_pass转发，再在其内部配error_page 404 = /degrade.html;，形成闭环 - 确认
proxy_intercept_errors on;已启用，否则后端返回的 404 不会被捕获
