在 nginx 中，`try_files` 指令仅存在于 `http` 和 `server` 上下文中，专门用于处理 http/https 七层请求，无法直接用于 `stream` 模块的四层 tcp/udp 代理。要实现四层服务降级（例如后端数据库或 redis 连接失败时切换至备用节点），必须使用 `stream` 模块原生的 `proxy_next_upstream` 指令配合多个 `upstream` 组来实现。
为什么 try_files 不能用于 stream 模块
`try_files` 是 Nginx 的 HTTP 核心模块功能，它依赖于解析 HTTP 请求头、URI 路径以及文件系统状态。而 `stream` 模块工作在传输层，直接转发二进制数据流，不解析应用层协议，因此不具备执行 `try_files` 所需的上下文环境。如果在 `stream` 块中尝试配置 `try_files`，Nginx 启动时会报错提示该指令无效。
stream 模块实现四层服务降级的正确配置
正确的做法是利用 `stream` 模块的负载均衡与故障转移机制。通过定义两个独立的 `upstream` 块，分别指向主用服务和备用服务，然后在 `listen` 指令所在的 `server` 块中启用 `proxy_next_upstream`。当主用连接建立失败或超时，Nginx 会自动将流量切换到备用 `upstream`。
stream {
upstream primary_backend {
server 192.168.1.10:3306;
}
fallback_backend {
server 192.168.1.20:3306;
}
server {
listen 3306;
proxy_pass primary_backend;
proxy_next_upstream on;
proxy_next_upstream_timeout 10s;
proxy_connect_timeout 5s;
}
}
上述配置中，`proxy_next_upstream on` 启用了默认的故障转移条件，包括连接失败、超时等。`proxy_next_upstream_timeout` 限制了尝试切换的总时间，防止无限重试。当 `primary_backend` 不可用时，客户端会被重定向到 `fallback_backend`，从而实现四层服务的自动降级。
基于 proxy_next_upstream 条件的具体行为分析
在实际运行中，`proxy_next_upstream` 的行为取决于具体的错误类型。默认情况下，只有当连接建立失败或读取响应超时时才会触发切换。如果主用服务器返回了正常的 TCP 握手但后续数据传输异常，Nginx 可能不会立即切换，除非配置了更细致的错误匹配。开发者可以通过设置 `proxy_next_upstream error timeout invalid_header` 来扩展触发条件，确保在各种网络不稳定场景下都能有效降级。
