down标记不能单独永久下线节点，仅在upstream中静态生效，需修改配置并重载才启用或取消；它彻底禁用节点、不受健康检查影响，且不支持运行时动态设置。
在 Nginx 中，down 标记本身**不能单独“永久下线”后端节点**，它只在 upstream 块中生效，且仅对当前配置有效——修改配置后重载（nginx -s reload）才会生效。所谓“永久”，实际依赖的是配置文件的持久化和手动维护。
1. 在 upstream 中用 down 标记临时屏蔽节点
down 是 upstream 指令中 server 的一个参数，表示该服务器**永久不可用（不参与任何负载均衡和健康检查）**，直到你手动移除该标记并重载配置。
示例：
upstream backend {
server 10.0.1.10:8080;
server 10.0.1.11:8080 down; # 此节点被标记为下线，Nginx 完全跳过它
server 10.0.1.12:8080;
}注意：
– down 不受健康检查影响，即使健康检查开启，该节点也永远不会被恢复；
– 它不是运行时命令，无法通过 API 或信号动态设置；
– 必须修改配置 + 重载 Nginx 才能启用或取消。
2. 配合健康检查实现“自动感知+人工兜底”
若希望节点异常时自动摘除、恢复后自动加入，应启用 health_check（需 Nginx Plus）或开源版的 ngx_http_upstream_check_module（第三方模块）。但 down 仍可用于人工干预兜底：
- 当健康检查误判或需强制隔离时，直接加
down并重载，确保万无一失； - 故障修复后，删掉
down，再重载即可重新纳入流量； - 避免仅依赖健康检查，人工标记
down是最可靠的手动熔断方式。
3. 替代方案：运行时动态管理（无需 reload）
如果真需要不重启/不重载就下线节点，开源 Nginx 本身不支持，但有以下实用路径：
-
使用 Nginx Plus：提供
upstream_conf模块，可通过 HTTP API 动态增删/禁用 server（含down状态）； - 借助 Consul + nginx-upsync-module：将 upstream 列表从外部服务同步，下线节点只需更新 Consul KV，Nginx 自动拉取新配置；
-
用 Lua（OpenResty）：在
balancer_by_lua*中根据自定义逻辑（如 Redis 标记）跳过特定节点，实现软下线。
4. 注意事项与常见误区
down 不等于“暂停”或“维护中”，它是彻底剔除。容易混淆的点：
- ❌
down不是热更新指令，改完必须nginx -s reload； - ❌ 不要和
backup混用：backup 是备用节点，down 是完全禁用； - ❌ 日志里不会特别提示 “xxx is down”，只会表现为该 IP 从未被选中（可查
$upstream_addr日志确认）； - ✅ 若用变量或 map 动态构造 upstream，
down无效——它只支持静态 server 定义。
