try_files是网关容错第一道开关，配合error_page、proxy_pass、健康检查等实现静态优先→主代理→备集群→兜底页的多级降级；需用命名location、开启proxy_intercept_errors，并分离API与前端路由。
在企业级生产网关中，try_files 本身不代理、不负载均衡、不重试上游，但它能成为容错链路的“第一道开关”——决定请求是否该走静态、是否该进主代理、是否该降级兜底。真正高可用的网关，靠的是 try_files 与 error_page、proxy_pass、健康检查和 upstream 分层策略的协同。
静态优先 + 主代理 fallback 的标准链路
这是最常用也最稳健的起点：先查本地资源，命中即返回；未命中则交由主后端集群处理；主集群不可用时，自动切到备用服务或兜底页。
-
try_files $uri $uri/ @proxy_main;—— 最后一项必须是命名 location（以@开头），不能写proxy_pass或 URL -
location @proxy_main { proxy_pass http://backend_primary; proxy_intercept_errors on; }——proxy_intercept_errors on是关键，否则后端返回 502/503 不会触发error_page - 配合
error_page 502 503 504 = @fallback;，把上游异常导向备用逻辑
多级降级：从主集群 → 备集群 → 静态兜底页
当主后端整体失联，不能只返回错误码，而要提供可访问的最小功能面，比如维护页、简化版首页或离线提示。
- 定义两个 upstream：
backend_primary（主力）和backend_fallback（低配或只读节点） - 在
@fallback中使用proxy_pass http://backend_fallback;，而非直接返回 HTML，便于统一控制响应头、缓存和日志 - 再设一层兜底：
error_page 502 503 504 =503 /maintenance.html;，并确保/maintenance.html存在于root目录下，且该 location 不被 try_files 循环捕获
动静分离下的智能 fallback（含压缩优先）
对静态资源，按客户端支持能力自动匹配最优编码格式，既提升传输效率，又避免因缺失某一种压缩文件导致 404。
- 配置示例：
try_files $uri.gz $uri.br $uri =404; - 需开启
gzip_vary on;和add_header Vary Accept-Encoding;，让 CDN 或浏览器正确缓存不同变体 - 注意：若启用 Brotli（
.br），需确认 Nginx 编译时已加入--with-http_brotli_module，或使用 OpenResty 等增强版
SPA 路由 + API 接口的隔离式容错
Vue/React 前端 history 模式下，刷新子路径易 404；但若全部 try_files 到 /index.html，又可能把真实 API 请求也兜底，造成后端收不到请求。
- 明确分离路径：
location /api/ { proxy_pass http://backend_api; }—— 必须以/api/结尾，且proxy_pass后也带/，实现路径透传 - 前端静态路由兜底仅作用于非 API 路径：
location / { try_files $uri $uri/ /index.html; } - 加一层保护：
if ($request_uri ~ ^/api/) { break; }不推荐；更稳妥的是用location ^~ /api/保证前缀优先匹配，避免被通配 location 拦截
