在 nginx 中，修改 include 子配置文件后实现平滑重载的标准做法是执行 nginx -s reload。该命令会触发主进程（master process）重新读取 nginx.conf 及其包含的所有子文件，验证配置语法无误后启动新的工作进程（worker process），并等待旧的工作进程处理完当前请求后优雅退出，从而实现零停机更新。
如何确保 include 的文件被正确加载
要确保 include 指令指向的文件被正确加载，必须保证路径准确且语法合法。Nginx 的主进程在收到重载信号时，会解析整个配置树，包括所有嵌套的 include 语句。如果子文件存在语法错误，重载将失败，Nginx 会回滚到旧的运行配置，因此建议在本地使用 nginx -t 进行预检查。
server {
listen 80;
server_name example.com;
# 引入外部配置片段
include /etc/nginx/conf.d/upstream.conf;
location / {
proxy_pass http://backend_pool;
}
}
上述配置中，include 引入了 /etc/nginx/conf.d/upstream.conf。当该文件内容变更时，执行 nginx -s reload 后，新启动的 Worker 进程将读取更新后的上游定义。若 upstream.conf 中存在无效指令，reload 操作会被拒绝，日志中会记录具体错误行号，此时需修正文件后重试。
如何处理多 worker 进程下的平滑过渡
在多 Worker 进程环境下，平滑重载依赖于 Master 进程的协调。Master 进程在生成新配置后，会 fork 出新的 Worker 进程，这些新进程立即开始监听端口并接受新连接。与此同时，旧的 Worker 进程不再接受新连接，但会继续处理已建立的长连接或正在进行的请求。只有当旧 Worker 进程完成所有任务并主动关闭连接后，它们才会退出，从而保证服务连续性。
# 模拟重载过程 $ nginx -s reload # 查看进程状态 $ ps aux | grep nginx master 12345 0.0 0.1 ... /usr/sbin/nginx -g daemon off; worker 12346 0.0 0.2 ... nginx: worker process worker 12347 0.0 0.2 ... nginx: worker process # 新进程启动后，旧进程逐渐变为 (exiting) worker 12346 0.0 0.2 ... nginx: worker process (exiting)
在实际操作中，可以通过观察进程列表来验证平滑重载的效果。新启动的 Worker 进程 PID 通常与旧进程不同，或者其内部状态标记为接收了新配置。在重载期间，客户端请求会被负载均衡到新 Worker 或继续由旧 Worker 处理，直到旧进程完全退出。这种机制确保了在高并发场景下，配置变更不会导致请求丢失或服务中断。
基于 include 路径变化的具体影响
当 include 指令中的路径本身发生变化，例如从 /etc/nginx/conf.d/a.conf 改为 /etc/nginx/conf.d/b.conf，Nginx 的重载行为依然遵循标准流程。Master 进程会解析新的路径，尝试打开 b.conf。如果 b.conf 不存在或权限不足，重载将失败；如果成功打开，新配置将生效。关键在于，Nginx 不会自动检测文件内容的哈希变化，而是依赖每次 reload 命令触发的完整配置重读。
为了验证这一行为，可以创建一个简单的测试环境。首先，创建两个不同的配置文件 a.conf 和 b.conf，分别定义不同的监听端口或服务器块。在主配置中使用 include 引用其中一个。执行 nginx -s reload 后，检查 Nginx 是否正在监听新文件中定义的端口。如果 b.conf 定义了端口 8080，而 a.conf 定义了 80，重载后应观察到 Nginx 仅在 8080 端口监听。这证明了 include 的路径和内容变更均通过 reload 机制生效，且整个过程是平滑的，不会影响现有连接。
