前言
站长们估计或多或少都遇到过这个问题：明明在服务器里改好了Nginx的配置文件，但是刷新网站发现配置没生效。再比如：新加的域名访问不了、改的防盗链规则不生效…
我每次折腾程序的时候也会遇到这个问题，在宝塔面板配置好之后刷新页面，却发现配置没生效，反复检查没找到问题，忙叨半天最后才发现，原来是忘了让Nginx生效新配置。
为什么Nginx修改配置后不会实时生效？修改配置后，到底该用重启还是重新加载？这两个操作有什么区别？哪些修改必须重启，哪些只需要重载就够？
为了便于理解，以宝塔面板来举例，用这篇文章一次性解释完，以供后来者参考。
为什么Nginx修改配置后不会实时生效
这和Nginx的设计机制问题，这类服务软件的逻辑都是这样，为了保证服务稳定的设计，全部遵循一次读取，长期驻留的原则
Nginx在启动时会将配置文件解析并固化到内存中，后续的请求处理直接读取内存数据，以保证高性能，而不会每次都去读取磁盘上的文件。
所以，仅仅修改文件是不够的，必须通过命令通知主进程重新读取配置文件、验证语法、创建新的工作进程来加载新配置，从而实现平滑更新。
为什么要这么设计
包括我在内，很多站长会问：为什么不能设计成配置自动生效，这样多方便。答案也很简单：为了服务器的绝对稳定和高性能。分三点说明：
- 如果Nginx实时监听配置文件，每一次请求都要去读硬盘的配置文件，服务器的IO开销会暴增，网站访问速度变慢、性能大幅下降，这对高访问量的站点是致命的；
- 配置文件的修改可能不完整、有语法错误，如果实时生效，会直接导致Nginx运行出错、网站崩溃，风险极高！对新手来说更是如此；
- 一次性加载到内存，是所有高性能服务软件的标配，内存的读取速度非常快，能最大程度保证Nginx的运行效率。
重启（restart） / 重载（reload）
以宝塔为例，有两种方式让新配置生效。
方法一：重载配置（推荐）
宝塔面板上的重载配置按钮，对应到Linux命令行就是：nginx -s reload
这是日常修改配置的首选操作，也是最推荐的！它的作用是：通知正在运行的Nginx，去重读硬盘上的配置文件，把新的配置加载到内存中，平滑生效。
这个操作的核心优点：不中断服务、不影响用户访问。通过reload命令，进程会先验证新配置的正确性，仅在语法无误时启动新的工作进程来接管新请求，同时让旧的工作进程继续处理完现存连接后再优雅退出，从而在零停机的情况下完成配置更新，既保证了高可用性，又具备了出错回滚的安全机制。
方法二：重启Nginx服务
宝塔面板上的Nginx重启按钮，对应到Linux命令行就是：systemctl restart nginx
作用：先完全停止当前正在运行的所有Nginx进程，然后再重新启动Nginx，启动的同时加载新配置。
这个操作的核心特点：短暂中断服务。重启的瞬间，Nginx的所有进程都被关闭了，此时如果有用户访问网站，会出现访问失败、页面报错、加载超时的情况，直到Nginx重启完成。虽然重启的时间很短（一般毫秒级），但对有大量访问的站点来说，依然有影响，所以非必要不建议重启。
哪些修改，用重载就够？哪些修改，必须重启？
只需要重载 ：仅修改业务规则类配置，比如：新增/修改 反向代理、新增/修改 防盗链、新增/修改 缓存策略、转发规则、后端服务地址gzip压缩、页面跳转/重定向。这些不涉及 Nginx 核心运行的进程、端口、模块。
必须重启 ：修改核心运行相关配置， 比如：新增/删除 监听端口、新增/删除 核心模块、修改 工作进程数、进程绑定CPU、修改 用户权限、运行身份、修改 pid文件路径、日志文件的根路径。凡是涉及 Nginx 的进程、端口、加载的模块，这些配置都无法通过重载生效，只能重启。