改 Nginx 配置的正确流程：-t 检查再 reload

配置改完顺手 systemctl restart nginx，很多人这么干了很多年没出过事，直到某个业务高峰瞬间断连才回头补课。改 Nginx 配置的标准流程是三步：nginx -t 检查、nginx -s reload 平滑加载、看 error.log 确认。restart 是备选，不是日常。 一、为什么 -t 不能省 nginx -t 会完整解析配置并做一次启动级校验，路径不存在、指令拼写错、证书缺失都在这一步暴露，而且只读不改，随便跑。没有 -t 就 reload 等于闭眼过马路：配置有语法错误时 reload 会失败，master 还跑着旧配置，你以为生效了其实没有——这种静默不生效比直接报错更坑。习惯写法是一条命令： ``` nginx -t && nginx -s reload ``` 检查通过才加载，不通过就停在原地。 二、reload 的平滑原理 收到 reload 信号后，master 进程重新读配置，新起一批 worker 用新配置干活；旧 worker 把手头已接受的连接处理完再自行退出。整个过程监听端口不关闭，已建立的连接不断，新连接立刻由新 worker 接管，用户无感。新旧 worker 有几秒到几十秒的共存期，用 ps 能看到不同启动时间的两批 worker。 三、restart 重在哪 restart 是完整停掉再启动：master 退出时所有连接被掐断，正在传输的下载、长轮询、WebSocket 全部断线，服务出现秒级空窗。真正需要它的场景是少数：升级 Nginx 二进制、增减监听端口这类 reload 处理不了的变动。日常改 location、加站点、调超时，reload 就够。 四、两个补充动作 一是 reload 后验证生效：ps -eo pid,lstart,cmd | grep "nginx: worker"，worker 的启动时间应刷新为刚才那一刻。二是留好退路：改前先备份 cp nginx.conf nginx.conf.bak.$(date +%m%d%H%M)，reload 出问题立即恢复旧文件再 reload，半分钟内回到可用状态。配置目录进 git 管理的团队，回退就是一条 git checkout。 流程不复杂，难在形成肌肉记忆。把 nginx -t && nginx -s reload 定为团队改配置的唯一姿势，无解释、无例外，线上事故率会实打实降下来。补一句边界：reload 也并非零成本，worker 重建有轻微开销，脚本循环里一分钟 reload 几十次同样是坏实践，配置变更理应有节奏、有记录。