Nginx平滑重载不丢请求的核心是master-worker架构与SIGHUP信号协作：旧worker处理完已有连接，新worker接管新请求；必须先nginx -t校验语法，再用nginx -s reload等正确方式触发，确保upstream keepalive、proxy_http_version 1.1及后端长连接支持到位。
修改 Nginx 配置后实现平滑重载、不丢请求，核心在于利用其 master-worker 架构和信号机制——旧 worker 继续处理已有连接，新 worker 接管后续请求，整个过程无服务中断。
必须先验证配置语法
语法错误会导致 reload 失败，甚至意外回退到无配置状态：
- 运行 nginx -t 检查默认路径配置；若用自定义路径（如
/etc/nginx/conf.d/app.conf），加-c /etc/nginx/nginx.conf显式指定 - 常见报错如
Address already in use表示端口被占，open() "/path" failed (13: Permission denied)表示权限不足，需提前修复 - 不要跳过这步直接 reload，否则可能看似成功，实则新 worker 启动失败，旧进程最终退出后服务中断
用正确方式触发 reload
推荐使用以下任一方式，本质都是向 master 进程发送 SIGHUP 信号：
Linux Security Scanner
下载
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
-
sudo nginx -s reload —— 最直接，要求当前用户对 pid 文件（默认
/usr/local/nginx/logs/nginx.pid或配置中pid指定路径）有读取权限 - sudo systemctl reload nginx —— 若由 systemd 管理（主流发行版默认），该命令会调用预设的 ExecReload 指令，自动关联日志与依赖检查
- 手动发信号：sudo kill -HUP $(cat /var/run/nginx.pid) —— 适用于定制化部署或 pid 路径非标场景
确认重载真正生效
不能只看命令返回“success”，要验证行为是否更新：
- 查进程：
ps aux | grep nginx应看到新旧 worker 共存，新 worker 的启动时间接近 reload 时间 - 看日志：
tail -f /var/log/nginx/error.log出现reloading configuration行，且无 syntax 错误或 bind 失败记录 - 测效果：比如改了某个
server_name或rewrite规则，用curl -H "Host: test.example.com" http://127.0.0.1验证路由是否按新规则响应
特别注意 upstream 变更的连接复用
增删后端节点、调权重等操作本身不会中断长连接，但需确保连接能复用：
- upstream 块中必须加 keepalive N（建议 16–64），且后端地址用 HTTP（如
server 10.0.0.20:8080），避免直连 HTTPS 绕过连接池 - 对应 location 中设 proxy_http_version 1.1 和 proxy_set_header Connection ''，清空客户端传来的 Connection 头，防止后端误关连接
- 后端服务（如 Spring Boot、Tomcat）需支持长连接，且其 keepAliveTimeout > Nginx 的
proxy_read_timeout
