Nginx收到SIGHUP后执行平滑重载：先校验配置语法，成功则解析新配置、启动新worker、通知旧worker优雅退出；监听socket由新旧进程共享，确保连接不中断；kill -9会破坏该机制，导致服务中断和数据丢失。
当向Nginx主进程发送 SIGHUP 信号时，它并不会终止当前服务，而是启动一次“平滑重载”（graceful reload）：新旧工作进程交替切换，配置生效的同时连接不中断。
主进程收到HUP后做了什么
主进程接收到 SIGHUP 后，首先校验新配置文件语法是否正确（nginx -t 的逻辑）。若失败，直接报错退出重载流程；若成功，则按顺序执行：
- 重新解析配置文件，生成新的配置结构体
- 启动一批新的工作进程（worker processes），使用新配置
- 通知旧工作进程“准备退出”，但不立即杀死它们
- 旧工作进程完成当前正在处理的请求后，自动退出
工作进程如何实现“不中断服务”
关键在于监听套接字（listen socket）的继承与共享：
- 主进程在 fork 新工作进程前，已打开并保持所有监听 socket（如 0.0.0.0:80）
- 新旧工作进程都持有这些 socket 的文件描述符，可同时 accept 新连接
- 主进程通过信号（如 QUIT）通知旧进程停止 accept 新连接，只处理完已有连接
- 客户端无感知——新连接由新进程处理，老连接由旧进程善终
为什么不能直接 kill -9 主进程
kill -9 会强制终止主进程，导致：
- 所有工作进程失去管理，可能被内核回收或残留为僵尸进程
- 监听 socket 关闭，新连接被拒绝（Connection refused）
- 正在进行的请求被粗暴中断，造成数据不完整或客户端超时
- 无法触发优雅退出逻辑，日志、缓存刷新等清理动作丢失
实际操作中的注意事项
执行 kill -HUP `cat /var/run/nginx.pid` 或 nginx -s reload 前建议确认：
- 配置文件路径是否正确（尤其使用 include 时，相对路径易出错）
- 磁盘空间充足（重载期间可能写临时文件或日志）
- 权限未变更（新进程仍以原用户身份运行，需确保对证书、日志目录等有读写权限）
- 第三方模块兼容性（部分动态模块未正确处理重载，可能导致新进程启动失败）
整个过程本质是主进程驱动的一次“配置热更新+进程冷替换”，核心设计目标就是零停机运维。不复杂但容易忽略细节。
