nginx 官方不支持 njs 动态修改 upstream，因其仅运行于请求上下文，无法访问 upstream 共享内存结构及配置api；可行方案为 upstream_conf、dyups 或 upsync。
目前 Nginx 官方并不支持通过 njs 直接动态修改 upstream 配置。njs 是 Nginx 的嵌入式 JavaScript 引擎，能力聚焦于请求处理阶段的逻辑控制（如重写、鉴权、Header 修改、变量计算等），**无法读写 upstream 的共享内存结构，也不具备管理 server 列表、权重、健康状态等运行时配置的能力**。
为什么 njs 不能替代 dyups 或 upstream_conf
njs 运行在 request context 中，属于“每请求执行”模型；而 upstream 状态存储在进程共享内存（zone）中，由 master/worker 协同维护。两者不在同一抽象层级：
- njs 没有 API 访问
ngx_http_upstream_srv_conf_t或其 servers 数组 - 无法触发 upstream 的 reload 逻辑、健康检查重置或一致性哈希重建
- 不支持原子性增删 server、设置
down标志或更新max_fails等核心字段
真正可行的免 Reload 动态 upstream 方案
生产环境高并发集群应选择已验证、低开销、与 Nginx 内核深度集成的方案：
-
官方 upstream_conf 模块（推荐首选）：Nginx ≥ 1.9.11 内置，HTTP 接口直改 zone，零额外依赖。需提前定义
zone backend 64k，通过POST /upstream_conf?add=10.0.1.12:8080等操作实时生效 -
dyups 模块：成熟稳定，支持 RESTful 全量/增量更新（
POST /upstream/myapp提交 server 列表），可配合脚本或调度系统自动同步 - upsync + Consul/Etcd：适合微服务架构，Nginx 主动轮询注册中心，自动拉取并热加载节点列表，天然支持服务发现与健康上下线
若坚持用 njs，仅能做的辅助动作
njs 可作为“策略增强层”，配合上述方案使用，但不能独立完成 upstream 修改：
- 根据请求特征（如 header、cookie、地域）动态选择已有 upstream 名称：
proxy_pass http://$upstream_name - 结合
map和 njs 函数实现灰度路由，把流量导向不同预定义的 upstream 分组 - 调用外部 HTTP 接口（如 dyups 或 upstream_conf 管理端点），间接触发变更（注意超时与幂等性）
高频 Reload 的根本问题不在工具，而在设计
频繁 reload 往往暴露了架构缺陷：
- 将服务实例 IP 直接硬编码进配置 → 应改用服务发现机制（Consul、Nacos、K8s Endpoints）
- 靠人工或定时脚本修改配置 → 应接入 CI/CD 流水线，对接配置中心自动下发
- 健康检测粒度粗（如只靠 passive 检测）→ 应启用
nginx_upstream_check_module主动探测，避免故障扩散
