做运维或者自己管网站服务器的，改Nginx配置是家常便饭：加个跳转、改个缓存、调个超时……可每次改完要生效的时候，心里都得咯噔一下：是用reload还是restart？会不会把正在访问的用户给掐了？我就见过有人图省事直接restart，结果线上几百人在线，服务断了几秒，投诉电话立马打爆。其实Nginx改配置有一套安全的标准姿势，学会了，改配置就跟喝水一样平常，全程不断线。
先搞明白 reload 和 restart 的区别
这俩词看着像，差别大了去了。restart是重启服务，先把老进程干掉再启新的，中间必然有断档，在线用户会瞬间掉线重连，运气不好还会看到报错页面。reload是平滑重载，Nginx会优雅地加载新配置：老的worker进程继续处理完手上的请求，然后自然退出，新的worker进程按新配置接棒。整个切换过程用户无感知，这才是改配置该用的方式。
动手之前，先检查配置对不对
改完配置文件，千万别直接reload，先检查语法：nginx -t。这条命令会检查所有配置文件的语法，有问题会明确告诉你在哪个文件哪一行。语法错了还硬reload，Nginx会拒绝加载，甚至可能导致服务异常，到时候线上直接出问题，你还得手忙脚乱地回滚。所以规矩就是：改完配置先nginx -t，显示syntax is ok再reload，一步都不能省。
nginx -t输出ok之后，执行nginx -s reload平滑重载，配置文件就生效了。想确认新配置真的加载上了，用nginx -T能看到最终生效的完整配置，或者看进程的启动时间：ps aux | grep nginx，新worker进程的时间应该是刚刚。这套流程走熟了，改配置就是几秒钟的事。
什么时候才需要 restart
话又说回来，有些改动reload是搞不定的，必须restart：比如改了监听端口、改了进程数worker_processes这种主配置，或者装了新的模块需要重新加载。这种时候restart不可避免，那就挑业务低峰期操作，比如凌晨，把影响降到最低。要是实在没法停机，可以考虑先改完配置，用nginx -t验证，然后找凌晨窗口快速restart，总比白天高峰期硬来强。
改配置的几个好习惯
说几个我自己的习惯，都是血泪换来的：第一，改配置前先复制一份备份，cp conf文件带个日期后缀，改坏了秒回滚；第二，改完先nginx -t再reload，前面说了，这是铁律；第三，一次只改一个逻辑，别同时改好几个地方，出问题了都不知道是哪处引起的；第四，重要改动先在测试环境验证，测试环境跟线上配置保持一致，验证过了再上生产。这四条看着啰嗦，真出事的时候能救你一命。
多站点服务器，改配置更要小心
如果一台服务器上跑着好几个网站（虚拟主机那种），改配置的风险就更高了，因为你改的是公共的nginx.conf，影响的是一大票站点。这种环境更要谨慎：先看清楚你改的是公共配置还是某个站点的server块，公共配置的改动要评估对全部站点的影响；改完nginx -t是必须的，最好再curl检查几个不同站点的页面都正常，别只盯着自己那个站。我给朋友托管过服务器，最怕的就是他改公共配置把别的站搞挂了，还一脸无辜地说我就改了一行。
还有个相关的小知识：用include把你的站点配置拆成一个个独立文件放好，比如conf.d目录下每个站一个文件，改的时候只动自己那个文件，出问题也只影响自己，不会连累别人。配置文件模块化，是多人共用服务器时的基本礼仪，也是保护自己的好办法。
reload之后，记得验证线上效果
reload完别以为就完事了，花几秒钟验证一下：访问一下网站看正常不正常，curl一下刚改的那个配置涉及的页面，确认新规则生效了。要是改了跳转，就curl -I看状态码和Location对不对。验证这步花不了半分钟，但能让你安心，不用提心吊胆地等用户来报告问题。Nginx配置管理做到这个份上，基本就稳了，改配置再也不是什么让人紧张的事了。
【版权声明】：本站所有内容均来自网络，若无意侵犯到您的权利，请及时与我们联系将尽快删除相关内容!
