nginx reload 通过重载配置实现 upstream 动态更新，启动新 worker 并平滑关闭旧进程，不影响已有连接；需确保 upstream 在 http 块内、语法正确、路径可读、无 BOM，且 reload 前必须 nginx -t 验证。
nginx reload 不等于重启，但必须重载配置才能生效
动态添加服务器本质是更新反向代理的 upstream 列表，nginx 本身不支持运行时增删节点，但可以通过「修改配置 + nginx -s reload」实现无缝更新。reload 会启动新 worker 进程、平滑关闭旧进程，已有连接不受影响，用户几乎无感。
常见错误现象：nginx: [emerg] unknown directive "upstream"（配置未放在 http 块内）、nginx: [warn] conflicting server name（重复 server_name）、reload 后请求 502（新 upstream 里加了未启动的服务）。
- 配置必须写在
http块中，不能放在server或location内 -
upstream块名要全局唯一，且被proxy_pass http://your_upstream_name;正确引用 - 每个
server指令后必须跟分号，漏掉会导致语法错误，nginx -t会报错 - reload 前务必先
nginx -t验证，否则可能直接中断服务
用 include 分离 upstream 配置，避免主配置文件频繁变更
把动态服务器列表单独抽成文件（如 /etc/nginx/conf.d/upstreams.conf），再用 include 引入，能降低主配置出错风险，也方便脚本批量更新。
使用场景：CI/CD 自动部署新实例、运维脚本根据 Consul 或 Etcd 发现服务并写入 upstream、手动快速扩容。
-
include路径必须是绝对路径，相对路径行为不可靠 - 被 include 的文件不能有 BOM，Windows 编辑保存时容易带 BOM，导致
nginx -t报语法错误 - 如果 upstream 文件为空或只含注释，
nginx -t仍能通过，但 reload 后 proxy_pass 会 502 - 建议在 include 文件末尾加一行
# auto-generated at $(date +%s)，便于追踪更新时间
upstream 中的 weight、max_fails 和 fail_timeout 怎么配才不翻车
这些参数决定流量如何分配和故障如何判定，配错会导致新机器刚加进去就被踢出、或故障节点持续接收请求。
性能影响明显：weight 过高会让单节点过载；max_fails=1 + fail_timeout=10s 可能让偶发超时直接摘除节点；而 max_fails=0 则完全关闭健康检查。
-
weight默认为 1，数值越大分到的请求越多；新机器建议从weight=1起步，观察负载后再调 -
max_fails是连续失败次数，不是总失败数；设为 0 表示禁用失败计数（慎用） -
fail_timeout既是失败窗口期，也是恢复等待时间；设太短（如 1s）易误判，太长（如 60s）故障恢复慢 - 新加服务器时，可临时加
down标志，验证通后再删掉，避免上线即故障
reload 失败时怎么快速定位是配置问题还是权限问题
执行 nginx -s reload 返回失败，90% 是配置语法或路径权限问题，不是 nginx 本身挂了。
错误信息里最关键的是 nginx: [emerg] 开头那行，它指明具体哪一行、哪个指令出错；而 nginx: [alert] 多半是文件权限或磁盘满等系统级问题。
- 先跑
nginx -t -c /etc/nginx/nginx.conf，确认配置语法和路径是否都 OK - 检查
include的文件是否被nginx用户（通常是www-data或nginx）可读：ls -l /etc/nginx/conf.d/upstreams.conf - 查看
error_log路径是否可写，df -h看磁盘是否满了（尤其/var/log或/tmp） - 不要直接 kill 主进程再启——那是真重启，不是 reload；要用
nginx -s reload或systemctl reload nginx
真正难处理的是 upstream 后端服务监听了 IPv6 地址但 nginx 编译时没开 IPv6 支持，此时 nginx -t 不报错，但 reload 后日志里狂刷 connect() failed (97: Address family not supported by protocol) ——这种得查编译参数或换地址格式。
