Nginx容器代理启动异常：如何配置降级回退策略？

问题核心 #

Nginx启动时会预解析所有proxy_pass中的上游地址，若目标容器未运行（DNS解析失败），会导致整个Nginx服务启动失败。我们需要实现两种层级的容错：尽可能保留所有代理规则，若无法实现则仅保留核心容器的代理规则。

方案一：延迟解析上游地址（推荐） #

通过变量+resolver让Nginx在请求到达时才解析上游容器地址，而非启动时预解析，这样即使部分容器未运行，Nginx也能正常启动，仅在对应路径有请求时返回错误。

配置示例 #

1. 先在http或当前server块中配置Docker内置DNS（适用于Docker环境）：

resolver 127.0.0.11 valid=30s; # Docker内置DNS服务器，缓存解析结果30秒

2. 修改代理规则，用变量包裹上游地址：

server {
  listen 443;
  server_name example.com;

  # 核心容器代理规则
  location /app1/ {
    set $upstream_core1 http://container1:8080/;
    proxy_pass $upstream_core1;
    # 容器不可达时尝试重试或返回错误
    proxy_next_upstream error timeout invalid_header http_500 http_502 http_503 http_504;
  }

  location /app2/ {
    set $upstream_core2 http://container2:8080/;
    proxy_pass $upstream_core2;
    proxy_next_upstream error timeout invalid_header http_500 http_502 http_503 http_504;
  }

  # 非核心容器代理规则
  location /app3/ {
    set $upstream_noncore3 http://container3:8080/;
    proxy_pass $upstream_noncore3;
    # 可选：自定义错误页面
    error_page 502 503 504 /fallback.html;
  }

  # 自定义错误页面（可选）
  location = /fallback.html {
    root /usr/share/nginx/html;
    internal;
  }
}

原理 #

使用变量后，Nginx不会在启动阶段解析上游地址，而是在每次请求到来时才通过指定的resolver解析，避免了启动时因容器未运行导致的失败。

方案二：动态生成配置文件 #

若要求启动时仅加载运行中容器的代理规则，可通过启动脚本预先检查容器状态，动态生成Nginx配置。

脚本示例（Docker环境） #

#!/bin/bash

# 初始化配置文件，写入核心容器规则
cat > /etc/nginx/conf.d/default.conf <<EOF
server {
  listen 443;
  server_name example.com;

  location /app1/ {
    proxy_pass http://container1:8080/;
  }

  location /app2/ {
    proxy_pass http://container2:8080/;
  }
EOF

# 检查非核心容器状态，运行则添加对应规则
if docker inspect container3 &>/dev/null; then
  cat >> /etc/nginx/conf.d/default.conf <<EOF

  location /app3/ {
    proxy_pass http://container3:8080/;
  }
EOF
fi

# 可添加更多容器检查逻辑...

# 闭合server块
echo "}" >> /etc/nginx/conf.d/default.conf

# 启动Nginx
nginx -g "daemon off;"

原理 #

脚本在Nginx启动前，通过docker inspect检查容器是否运行，仅将运行中容器的代理规则写入配置文件，确保Nginx启动时所有上游地址都有效。

方案对比 #

• 方案一：无需修改启动流程，保留所有代理规则，仅在容器不可达时返回错误，适合大多数场景。
• 方案二：严格控制加载的规则，仅保留运行中容器的代理，适合对无效规则零容忍的场景。

内容的提问来源于stack exchange，提问作者Kamil Kos