在容器化部署中，nginx 的 server_name 无法在运行时直接修改，必须通过构建时注入或启动时替换配置文件的方式实现。具体做法是利用 envsubst 命令将环境变量中的占位符替换为实际值，或者使用 docker 卷挂载动态生成的配置文件。这样做可以在不重新构建镜像的情况下，根据运行环境（如开发、测试、生产）自动调整域名绑定。
如何通过环境变量动态生成 Nginx 配置
利用 envsubst 工具可以将模板文件中的变量替换为当前容器的环境变量值。这种方法允许你在构建镜像时保留一个通用的配置模板，而在容器启动时根据传入的 SERVER_NAME 变量生成最终的 nginx.conf。你需要创建一个包含 ${SERVER_NAME} 占位符的模板文件，并在入口脚本中执行替换操作，最后启动 Nginx 服务。
FROM nginx:alpine # 安装 envsubst 工具 RUN apk add --no-cache gettext # 创建配置模板目录 RUN mkdir -p /etc/nginx/templates # 复制模板文件 COPY nginx.conf.template /etc/nginx/templates/default.conf.template # 设置默认环境变量 ENV SERVER_NAME=example.com # 覆盖入口点以执行变量替换 CMD ["sh", "-c", "envsubst '$(printenv | sed -n "s/^/\$$&/p" | tr "\n" " ") /etc/nginx/conf.d/default.conf && exec nginx -g 'daemon off;'"]
上述代码定义了一个基于 Alpine 的 Nginx 镜像。它安装了 gettext 包以提供 envsubst 命令。模板文件 default.conf.template 中包含 server_name ${SERVER_NAME};。启动时，Shell 脚本提取所有环境变量，传递给 envsubst，将模板渲染为标准 Nginx 配置，然后启动 Nginx。这种方式确保了每次容器启动时，server_name 都会根据传入的环境变量动态更新。
如何验证动态配置是否生效及处理冲突
验证动态配置的关键在于检查容器内部实际加载的配置文件内容。你可以通过进入正在运行的容器并查看 /etc/nginx/conf.d/default.conf 来确认 server_name 是否已被正确替换。如果未生效，通常是因为环境变量未正确传递或 envsubst 命令执行失败。此外，若多个容器共享同一主机端口，需确保不同容器的 SERVER_NAME 不冲突，或通过反向代理区分流量。
# 在宿主机或 CI/CD 环境中执行以下命令验证
docker run -d --name test-nginx \
-e SERVER_NAME=test.example.com \
-p 80:80 \
my-nginx-image
# 进入容器检查生成的配置
docker exec test-nginx cat /etc/nginx/conf.d/default.conf
# 预期输出应包含：
# server {
# listen 80;
# server_name test.example.com;
# ...
# }
该验证步骤展示了如何启动容器并检查其内部状态。通过 docker exec 命令查看生成的配置文件，可以直观地看到 server_name 已从模板中的 ${SERVER_NAME} 变为 test.example.com。这证明了环境变量注入和文本替换机制工作正常。若输出仍为占位符，则需检查环境变量是否在启动命令中正确指定，以及 envsubst 语法是否符合当前系统版本要求。
当 SERVER_NAME 为空字符串时 Nginx 的行为是什么
当 SERVER_NAME 环境变量为空字符串时，envsubst 会将模板中的 ${SERVER_NAME} 替换为空值，导致生成的 Nginx 配置中出现 server_name ; 或 server_name;。在这种情况下，Nginx 会接受任何主机头的请求，即匹配所有域名。这在某些场景下可能带来安全风险，因为服务器将无法区分合法请求与恶意泛解析请求。为避免此问题，应在启动脚本中添加默认值保护逻辑，例如使用 ${SERVER_NAME:-default.com} 语法确保变量不为空。
