原生 upstream 不支持动态发现，必须依赖外部机制：一是 Nginx 主动拉取（如 nginx-upsync-module+Consul，零 reload、worker 级同步）；二是外部程序生成配置后热重载（如 nacos-nginx-template 或 consul-template）。
原生 upstream 块不支持动态发现——它在 Nginx 启动或 nginx -s reload 时固化为内存结构，既不轮询、也不监听后端变化，更无运行时 API。所谓“动态”，必须靠外部机制驱动，核心就两条路：要么让 Nginx 自己拉（如 nginx-upsync-module），要么靠外部程序生成配置再热重载（如 consul-template 或 nacos-nginx-template）。
为什么直接改 upstream 配置 + reload 不算真动态
每次增删后端都要手动改 nginx.conf、nginx -t、nginx -s reload，看似能用，但存在三个硬伤：
- reload 会中断长连接（TCP 连接重置，HTTP/2 流失效），对 gRPC 或 WebSocket 类业务影响明显
- 高并发下频繁 reload 可能导致 worker 进程卡顿甚至配置加载失败
- 没有健康检查联动——宕机节点仍留在配置里，直到你人工发现并删掉
nginx-upsync-module + Consul：零 reload 的 worker 级同步
这是目前最轻量、平滑性最好的方案，适合对连接中断零容忍的场景。关键点不是“连上 Consul”，而是模块把服务列表直接写进共享内存，每个 worker 进程自己读取，完全绕过 reload。
- 编译 Nginx 时必须显式加入
nginx-upsync-module，官方源码包不含该模块 -
upsync指令必须指向 Consul 服务目录 API，例如：upsync 127.0.0.1:8500/v1/health/service/backend upsync_type=consul（注意是/health/service/{name}，不是/catalog/services，否则拿不到健康状态） -
upsync_dump_path必须设，比如/var/nginx/upstream_backend.conf，Nginx 启动时会从该文件恢复上次有效节点，避免 Consul 临时不可用导致 upstream 为空 - Consul 中注册的服务名（
service.name）必须和upstream块名一致，且每个实例需带Check.Status: "passing"
nacos-nginx-template + Nacos：配置驱动型热更新
如果你已在用 Nacos，这个 Agent 方案侵入最小——不改 Nginx，不编译模块，纯靠模板渲染 + reload。但它本质仍是 reload，只是自动化了。
- Agent 的
config.toml中每个discover_config对应一个upstream名，路径指向独立的 conf 片段（如/etc/nginx/conf.d/backend.upstream.conf），避免多服务互相污染 -
reload_interval别设太短（建议 5–10 秒），否则 Nginx master 进程频繁 fork 新 worker，CPU 和内存抖动明显 - 务必确认
nginx_cmd路径正确（如/usr/sbin/nginx），且 Agent 运行用户有执行nginx -s reload的权限（通常要加到nginx组或配 sudo 免密） - 启用
subscribe模式后，Nacos 实例变更会触发即时回调，比轮询快得多；但首次启动时仍依赖轮询兜底
consul-template：通用但 reload 风险更高
它不止能刷 upstream，还能动态生成整个 server 块、SSL 配置、限流规则等，适合复杂网关场景。但每改一次就全量 reload，风险比前两者高。
- 模板中必须用
{{range service "backend" "passing"}}...{{end}}显式过滤健康实例，否则会把critical或warning节点也写进去 - reload 前建议加
nginx -t校验，consul-template 的command字段可写成：nginx -t && nginx -s reload - 不要把所有 upstream 写在一个模板里——单个模板出错会导致整站配置失效；按服务拆分，各自独立 reload
- Consul ACL 开启后，
consul-template必须配-token=xxx，否则监听失败且无明确错误日志
真正容易被忽略的点是健康检查闭环：无论选哪种方案，都得确保后端注册时带的是真实健康状态（不是只注册不探活），且 Nginx 层要么用 nginx_upstream_check_module 主动探测，要么依赖注册中心的最终一致性。否则“动态”只是列表变来变去，流量照样打到已死的机器上。
