nginx 配置改了 nginx -t 也过了，reload 却不生效：先分清 reload 和 restart，再看是不是多实例

改完 nginx 配置，nginx -t 提示 syntax is ok，然后 nginx -s reload 也没报错，但访问网站发现改动根本没生效（比如改的 upstream 还是老的、加的 location 没出现）。"配置校验过了、reload 也执行了、就是不生效"，按下面几个方向查。

1. 确认 reload 真的发给对的进程了。 nginx -s reload 是通过信号通知正在跑的 nginx master 进程重载。如果机器上有多套 nginx（比如系统包的和编译安装的、或 docker 里的），nginx -s reload 可能发给的不是你改配置的那套。判断：

ps aux | grep nginx
nginx -V                      # 看用的是哪个二进制/prefix
cat /etc/nginx/nginx.conf     # 确认改的是不是这套实际加载的配置

如果 nginx 是 docker 跑的，reload 要进容器 docker exec nginx nginx -s reload，宿主机上的 nginx -s reload 根本影响不到它。

2. 检查是不是真的 reload 了还是配置被覆盖。 有些部署方式（比如 nginx 官方镜像 + 配置文件是模板渲染的）每次容器重启会重新生成配置覆盖你的修改，改了不持久。看配置文件的修改时间和内容是不是你改的版本。

3. 语法 ok 不代表逻辑对。 nginx -t 只校验语法，不校验配置是否符合预期。常见的"校验通过但不生效"：

• 你改了 A server 块，但流量实际走到的是 B（比如 default_server 是另一个、server_name 匹配了别的块）。加 server_name 精确匹配，或用 curl -H "Host: 你的域名" 指定 Host 测，确认命中哪个 server。
• upstream 改了但客户端有连接缓存（keepalive 长连接还挂在旧 worker 上），reload 后旧连接等自然断，短时间看起来"没生效"。长连接场景 reload 后可能要等旧 worker 的 keepalive 超时，或直接 restart 立刻干净。

4. reload 失败但没被注意。 虽然 nginx -t 过了，但 reload 时如果配置在 reload 瞬间校验失败（比如有人同时在改、文件权限问题导致读不了），nginx 会保留旧配置并打日志。看：

journalctl -u nginx --no-pager | tail
/var/log/nginx/error.log | tail

reload 和 restart 的区别要想清楚： reload 平滑，不中断连接，适合 upstream/常规配置修改；restart 会短暂中断所有连接但一定彻底生效。如果"改了什么不生效且急着验证"，reload 完查日志没报错但确实没变，直接 restart 一次排除"旧连接/旧进程"因素。

完整排查顺序： 确认改的是实际加载的那套配置（多实例/docker 别搞错）→ 确认命中正确的 server/upstream 块 → 看 error.log 有没有 reload 失败 → 长连接等 keepalive 或 restart 兜底 → 模板渲染的配置要确认持久化。

总结：reload 不生效 = 发错进程（多套 nginx/docker）、改错配置块、reload 静默失败、或长连接缓存。先 ps + nginx -V 确认操作对象，再 error.log 看有没有真 reload，必要时 restart 排除旧连接因素。