在 nginx 中，`server_name` 结合 `upstream` 实现动态后端分发的核心做法是：利用 `map` 指令根据请求头（如 host）映射到不同的上游组名称，然后在 `location` 块中使用该变量作为 `proxy_pass` 的目标。这样无需为每个域名编写独立的 `server` 块，即可将流量分发到对应的后端集群。
如何通过 map 指令实现基于域名的路由选择
要实现这一功能，首先需要定义一个变量，该变量的值取决于请求的 Host 头部。Nginx 提供了 map 指令来完成这个映射过程。当客户端发起请求时，Nginx 会根据配置的规则匹配 Host，并将结果赋值给自定义变量。随后，在 location 配置中，直接将该变量传递给 proxy_pass，Nginx 就会解析该变量指向的 upstream 块并进行负载均衡。
http {
# 定义变量 $backend_pool，默认值为 default_pool
map $host $backend_pool {
default default_pool;
api.example.com api_backend;
www.example.com web_backend;
}
upstream default_pool {
server 127.0.0.1:8080;
}
upstream api_backend {
server 192.168.1.10:3000;
server 192.168.1.11:3000;
}
upstream web_backend {
server 192.168.1.20:80;
server 192.168.1.21:80;
}
server {
listen 80;
server_name _;
location / {
proxy_pass http://$backend_pool;
}
}
}
上述配置中，如果请求的 Host 是 api.example.com，$backend_pool 将被赋值为 api_backend，请求将被转发到 192.168.1.10 和 192.168.1.11。如果 Host 不匹配任何特定规则，则使用默认的 default_pool。这种方式的优点是配置集中，新增域名只需在 map 块中添加一行映射即可。
如何处理不同后端服务的健康检查与故障转移
在动态分发场景下，确保后端服务的可用性至关重要。Nginx 本身不提供主动健康检查，但可以通过 max_fails 和 fail_timeout 参数实现被动故障转移。当某个后端节点连续失败次数达到 max_fails 设定的阈值时，Nginx 会在 fail_timeout 指定的时间内将该节点标记为不可用，不再向其发送请求。时间过后，Nginx 会尝试再次向该节点发送请求以检测其是否恢复。
upstream api_backend {
server 192.168.1.10:3000 max_fails=3 fail_timeout=30s;
server 192.168.1.11:3000 max_fails=3 fail_timeout=30s;
}
upstream web_backend {
server 192.168.1.20:80 max_fails=5 fail_timeout=60s;
server 192.168.1.21:80 max_fails=5 fail_timeout=60s;
}
在实际运行中，如果 192.168.1.10 连续三次响应错误或超时，Nginx 将在接下来的 30 秒内忽略该节点，所有针对 api_backend 的请求将仅由 192.168.1.11 处理。这种机制保证了在高可用架构中，单点故障不会导致服务中断。开发者应监控 Nginx 的错误日志，确认故障转移是否按预期触发，并根据业务需求调整 max_fails 和 fail_timeout 的值。
当 upstream 中所有节点均不可用时 Nginx 的行为是什么
当通过 map 动态选择的 upstream 组中所有服务器节点都被标记为不可用（即都达到了 max_fails 限制且处于 fail_timeout 冷却期内），Nginx 将无法建立到后端的连接。此时，Nginx 会返回 502 Bad Gateway 错误给客户端。这是因为 proxy_pass 无法找到可用的目标地址。
# 模拟所有节点故障后的行为 # 客户端收到 HTTP 502 响应 # Nginx error.log 中记录类似如下信息： # *1 no live upstreams while connecting to upstream, client: 127.0.0.1, server: _, request: "GET / HTTP/1.1", upstream: "http://api_backend", host: "api.example.com"
为了改善用户体验，可以配置 error_page 指令来捕获 502 错误，并重定向到一个维护页面或提供降级服务。例如，可以添加 error_page 502 /maintenance.html;，并在本地提供一个静态的维护页面。此外，引入主动健康检查模块（如 njs 或第三方模块）可以在节点真正不可用前将其从池中移除，从而减少 502 错误的出现频率。
