Nginx配置文件已经改了服务仍按旧规则转发，怎样证明reload真正生效

磁盘配置已经改变，不证明运行中的worker加载成功。先执行配置检查，再观察独立master的reload日志与新连接响应标记；reload失败时Nginx可以继续使用旧配置，因此服务仍可访问也不能说明新规则生效。

建立可见且非敏感的配置版本标记

常见误判是编辑文件以后刷新一次页面，看到200就认为发布成功。旧配置本来就可能返回200，失败的HUP不会必然把服务停掉。应给待验证配置安排可识别的无敏感版本标记，并确保测试请求经过目标监听、目标Host和目标路径。

先用-t检查目标前缀与配置文件

隔离实验先返回v1，随后写入无效指令并检查失败；仅向本实验Popen得到的master PID发HUP，新连接仍返回v1，错误日志记录unknown directive。修正为合法v2、检查通过并再HUP后，新连接返回v2。原始日志包含重新配置与worker启动退出记录，可继续核对运行阶段。

有效配置检查需要使用与运行实例相同的二进制、prefix和config路径，否则检查通过的可能是另一份文件。本文将这些参数集中在新实例对象中，坏配置与好配置都走同一组参数；HUP的目标则直接来自Popen返回PID，避免通过模糊进程名匹配到生产master。

说明旧长连接短期留在旧worker

平滑reload期间旧worker可以继续处理既有长连接，所以不能要求所有在途请求瞬间切换。本文每次新建连接，验证的是新请求路径；SSE或其他长连接需要另行观察。程序不使用全局nginx -s reload，也不向任何现有master发信号，避免把实验变成生产变更。

适用范围：独立高端口Nginx实例，绝不向现有master发HUP；语法成功不独自证明实际请求已走新配置。

配套样本与复核入口

• run.py：独立运行程序，包含合成输入、操作和正反例断言。
• case.json：输入说明、预期任务与适用范围，便于保存和交接。
• observed.json：本次实际执行输出；临时路径、进程号和计时可能随运行变化。

运行前只需提供实验Nginx路径，脚本自己保存master PID。结果应依次看到v1、坏配置后仍v1、修复后v2；bad_test_returncode非零、good_test_returncode为零，日志还保留重配过程。不要把脚本改为全局nginx -s reload，后者可能控制已有服务，且不能证明测试响应来自本实验的新worker。

Linux、Python3.8以上与Nginx1.28.0，设置NGINX_BIN为可执行文件绝对路径；鉴权题还需编译启用http_auth_request_module。程序显式指定新建prefix、配置、pid和日志，所有监听均为回环高端口，绝不向已有master发送控制命令。

python3 -B run.py

阅读输出时，先按case.json中的任务逐项核对Nginx网关reload配置未生效，再与observed.json比较。非零退出表示依赖或断言需要处理，应保留实际错误。

一手依据1（HUP尝试应用配置失败时继续用旧配置；新worker与旧长连接可能短期并存。）。

继续阅读：API路径被静态资源正则接走了，怎样核对Nginx的location选择顺序；网关上游域名换了IP仍连旧地址，怎样在Nginx核对动态DNS解析；限流规则热更新时，怎样避免同一请求混读两个配置版本。