nginx -s reload 能不中断连接是因为其采用 master-worker 架构，主进程收到 sighup 后先校验语法，再 fork 新 worker 加载新配置，旧 worker 持有已有 socket、仅拒绝新连接，直至处理完存量请求后退出。
nginx -s reload 是唯一推荐的平滑重载配置方式，它能确保正在处理的连接不中断，新连接由新 worker 进程接管。
为什么 nginx -s reload 能做到不中断连接
因为 Nginx 采用 master-worker 架构，reload 不是 kill + restart，而是信号驱动的协作式切换：主进程收到 SIGHUP 后，先校验语法，再 fork 新 worker 加载新配置；旧 worker 仍持有已建立的 socket 连接，只拒绝新 accept，直到当前请求完成或超时退出。
nginx -s reload 执行前必须检查的三件事
常见错误现象：nginx: [error] invalid PID number、nginx: configuration file /etc/nginx/nginx.conf test failed、reload 后服务无响应。
- 确认主进程正在运行且
pid文件路径正确——默认是/usr/local/nginx/logs/nginx.pid，若自定义过，需在配置中显式声明：pid /var/run/nginx.pid; - 必须先执行
nginx -t（或nginx -t -c /path/to/nginx.conf）验证语法；reload会隐式调用该检查，失败则直接中止，旧配置继续生效 - 确保运行用户对配置文件、日志目录、SSL 证书路径有读取权限；worker 进程常因证书路径不可读而静默失败
reload 后怎么确认是否真正生效
不能只看 ps aux | grep nginx 是否有新进程，要验证配置行为是否更新。
- 查看
error.log最后几行：成功 reload 会记录reloading configuration，失败则有具体报错位置 - 用
curl -I http://localhost或访问真实业务路径，观察响应头（如Server、X-Upstream等自定义 header）是否反映新配置 - 检查监听状态：
ss -tlnp | grep :80应同时看到旧、新 worker 的监听套接字（PID 不同），说明交接正在进行中
别把 systemctl reload nginx 当万能解药
它底层仍是调用 nginx -s reload，但 systemd 封装可能掩盖细节：
- 某些发行版（如 CentOS 7）的 nginx.service 单元未正确定义
PIDFile=，导致systemctl reload实际发送信号失败，看似成功实则没 reload - systemd 默认超时 90 秒，若旧 worker 因长连接（如 WebSocket、流式响应）迟迟不退出，可能触发 timeout 并报错，但此时 reload 已部分生效——容易误判失败
- 调试优先用原生命令：
nginx -s reload+ 查error.log，比依赖 systemctl 更可控
keepalive_timeout 或强制 reset_timedout_connection on，反而可能打断本该保持的连接。这点常被忽略。
