在 nginx 中，`try_files` 配合 `proxy_pass` 实现后端降级的核心做法是：将 `try_files` 的最后一个参数（即 fallback 目标）指向一个内部重定向或错误处理 location，在该 location 中配置备用后端的 `proxy_pass`。当主后端不可用（如连接超时、502/504 错误）时，nginx 不会直接返回错误页面，而是通过内部跳转将请求转发给备用服务，从而实现透明降级。
如何配置 try_files 触发后端故障转移
要实现这一机制，需要在主 location 块中定义 `try_files`，但其最后一个值不能是文件路径，而必须是一个以 @ 开头的内部命名 location。这个命名 location 负责处理“找不到资源”或“上游失败”的情况，并在其中设置备用后端的代理地址。关键在于，`try_files` 本身只检查文件系统，要让它感知后端状态，通常需要结合 `error_page` 指令捕获来自主后端的 HTTP 错误码，并将其重定向到同一个 fallback location。
server {
listen 80;
server_name example.com;
# 主业务逻辑
location /api/ {
# 尝试访问静态文件，如果不存在，则交给 @backend_fallback
# 注意：这里主要依赖 error_page 来触发 fallback
proxy_pass http://primary_backend;
# 关键：当主后端返回 502, 503, 504 时，内部重定向到 @fallback
error_page 502 503 504 = @fallback;
}
# 降级处理逻辑
location @fallback {
# 重新设置 proxy_pass 指向备用后端
proxy_pass http://backup_backend;
# 可选：重置一些头部信息，避免混淆
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
}
上述配置中，`@fallback` 是一个内部 location，客户端无法直接访问它。当 `primary_backend` 返回 502、503 或 504 时，`error_page` 指令会拦截这些响应，并执行内部重定向到 `@fallback`。此时，Nginx 会使用 `@fallback` 中定义的 `proxy_pass` 将请求发送给 `backup_backend`。这种组合确保了在主服务宕机或过载时，用户能无缝切换到备用服务。
try_files 在静态资源与 API 混合场景下的具体应用
在包含静态资源和动态 API 的混合场景中，`try_files` 的作用更加直观。我们可以利用它先检查本地是否有缓存的静态版本或预生成的 HTML，如果没有，再尝试代理到主后端。如果主后端也失败了，再通过 `error_page` 跳转到备用后端。这种方式常用于单页应用（SPA）或文档站点，其中大部分流量是静态的，只有少数请求需要后端处理。
server {
listen 80;
server_name docs.example.com;
root /var/www/html;
location / {
# 1. 尝试精确匹配的文件
# 2. 尝试目录索引
# 3. 如果都不存在，尝试代理到主后端
# 4. 如果主后端失败（由 error_page 处理），进入 @api_fallback
try_files $uri $uri/ @main_api;
}
location @main_api {
proxy_pass http://main_api_server;
error_page 502 503 504 = @static_fallback;
}
location @static_fallback {
# 最终降级：返回一个通用的静态错误页或静态备份内容
return 200 "Service temporarily unavailable. Please check back later.";
add_header Content-Type text/plain;
}
}
在这个例子中，`try_files` 首先检查 `$uri` 和 `$uri/`，这适用于静态文件。如果文件不存在，请求被传递给 `@main_api`。在 `@main_api` 中，我们设置了主后端的代理，并再次使用 `error_page` 来捕获主后端的错误。如果主后端也挂了，请求会被重定向到 `@static_fallback`，后者直接返回一个静态文本响应。这种多层降级策略确保了即使在所有后端都不可用的情况下，用户也能看到一个友好的提示，而不是浏览器默认的丑陋错误页。
当主后端返回 504 Gateway Timeout 时降级流程是怎样的
当主后端返回 504 Gateway Timeout 时，Nginx 会根据 `error_page` 的配置，立即中断与主后端的当前连接处理，并将请求内部重定向到指定的 fallback location。在这个过程中，Nginx 会丢弃从主后端接收到的部分或全部响应数据，然后建立一个新的连接到备用后端。对于客户端而言，这个过程几乎是透明的，因为 Nginx 会在备用后端返回结果后，将最终的响应状态码和内容发送回客户端，客户端通常只会看到备用后端的成功响应，而不会感知到中间的 504 错误。
