问题现象

有个项目现场同事说他修改了nginx的配置，也执行了reload命令，但是就是不生效，而且能够正常访问nginx，不清楚为什么。

怎么办，什么年代了，当然是让他问问AI看怎么肥事。他说问了几个AI，也照着试了，把配置文件都给AI看了，都说没啥问题，AI让重启，让检查网络问题，让查看日志输出。很好，他都照做了，可是依然是不行。

那不可能吧，我倒是要看看哦。

排查处理

其实他的诉求很简单，线上有一台机子要停机维护，临时下线，他手动设置了down，然后想着reload就行了，结果客户反馈偶尔慢的一批，他查看error发现竟然还会路由到那个节点。

而且我看他给http节点新加了access日志，也没生效。

server 192.168.5.56:8889 max_fails=3 fail_timeout=30s down;

• 检查了配置文件没问题，使用nginx -t输出successful说明配置无误。
• 因为window系统，我还专门使用管理员在命令行执行了nginx -s reload。发现确实不起作用
• error日志没有错误
• 查看进程，有两个17个nginx进程（因为配置了16个worker_processes再加上一个主进程就是17个）
• 那就直接干掉重新启动nginx（当然解决他的问题很简单，注释掉哪一行就行了，我们只是研究下为什么不起作用）。**使用nginx -s stop停掉了NG，然后查看任务管理器的进程发现确实没有了，之后再次nginx.exe运行，发现配置竟然仍然不起作用
  **

发现问题并解决

这就很诡异了，不报错，配置也不生效。突然想到会不会NG并没有死掉，再次nginx -s stop，任务管理器的“进程”里面确实没有我先netstat -ano|findstr 80查看了竟然还存在很多进程占用80端口：

又切换到任务管理器的“详细信息” 页签，发现有一批nginx在运行（进程页签是看不到的）。而且尝试访问了一下，80端口当然是通的，可以访问！

也就是说，nginx -s stop并没有停止掉进程吗? 并不是,它只是停停止自己当前从nginx.pid文件中识别出来的进程（以及子进程），那为什么会出现和pid文件不一致的进程仍然存活呢？进过排查发现，他至少两次启动过NG，也就是多次点击启动nginx.exe 最后一次启动的进程号写入到nginx.pid中覆盖之前的进程号，但之前的进程仍然存在并监听对应的端口。执行-s stop只是停止了最后的这个进程相关，导致之前的进程仍然存在，仍然可用。那些请求都被之前的进程所监听，刷新配置文件的操作只是对当前pid起作用，所以就出现了开头的那种情况，看起来命令无误、配置无误，也不报错，就是不生效。
可能会想那我再次执行nginx -s stop多执行几次，是否能停掉之前的。当然不行，pid只记录一条。停止掉这个文件就删了。《不嫌麻烦可以把主进程号找到写入这个文件，在执行stop，没必要，直接按照下面的命令全部kill掉》

# 命令行执行kill，干掉所有nginx进程
taskkill /F /IM nginx.exe

然后重新启动即可！！