nginx 使用 include 将 upstream 按业务/环境/域名拆分为独立 .conf 文件,在 http 块中统一引入,使主配置简洁、可维护、易协作;每个 upstream 文件职责单一,server 块精准引用,配合权限控制与 nginx -t 校验,提升部署效率与稳定性。

Nginx 使用 include 管理多条 upstream,核心是把不同业务、环境或域名的后端分组拆到独立文件里,让主配置干净、可维护、易协作。不靠堆代码,靠结构化组织。
upstream 配置单独抽离到外部文件
在 http 块中用 include 引入多个 .conf 文件,每个文件专注一类服务:
http {
# 公共基础设置(超时、header、日志等)
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
# 分类引入 upstream 定义
include /etc/nginx/upstreams/*.conf;
# server 块保持简洁,只管路由逻辑
include /etc/nginx/sites-enabled/*.conf;
}
按业务/环境/域名命名 upstream 文件
推荐命名规范,一眼识别用途,例如:
-
/etc/nginx/upstreams/api.conf→ 所有 API 后端(含 weight、health check) -
/etc/nginx/upstreams/admin.conf→ 运维后台服务(启用ip_hash保会话) -
/etc/nginx/upstreams/cdn.conf→ 静态资源节点(加backup和max_fails) -
/etc/nginx/upstreams/staging.conf→ 预发环境专用组(带注释说明用途)
每个 upstream 文件保持最小职责
例如 /etc/nginx/upstreams/api.conf 内容示例:
# api.conf —— 生产 API 服务集群(轮询 + 权重 + 健康探测)
upstream api_backend {
server 10.0.1.10:3000 weight=3 max_fails=2 fail_timeout=30s;
server 10.0.1.11:3000 weight=2 max_fails=2 fail_timeout=30s;
server 10.0.1.12:3000 backup; # 故障兜底
}
# 可选:定义另一个策略用于灰度发布
upstream api_canary {
server 10.0.1.20:3000 weight=1;
}
server 块中精准引用对应 upstream
避免硬编码或混淆,直接按语义调用:
server {
listen 443 ssl;
server_name api.example.com;
location / {
proxy_pass http://api_backend; # 清晰指向文件中定义的组
proxy_next_upstream error timeout http_502 http_503;
}
}
server {
listen 443 ssl;
server_name admin.example.com;
location / {
proxy_pass http://admin_backend;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
权限与校验不可跳过
- 确保
include路径下所有.conf文件对nginx用户可读(chmod 644,chown root:root) - 每次修改任一 upstream 文件后,都需执行
nginx -t全局检查——Nginx 不会自动检测子文件变更 - 推荐用
systemctl reload nginx而非restart,避免连接中断
这样组织,新增一个微服务只需新建一个 upstream 文件 + 一个 server 配置,主 nginx.conf 几乎不再动,上线快、回滚稳、多人协同不冲突。











