使用 nginx 监听已被监听的端口, reload 不会失败, 但会导致其他配置不生效.

[vincentWdp]

先叠甲: 我是业余运维.

昨天, 在宝塔上对线上服务 A 修改 proxy_pass, 端口从 7511 改成 7501:

location / { 
    proxy_pass http://localhost:7501; 
}

更新配置后, 错误日志显示 upstream 依旧是 127.0.0.1:7511, 询问 AI, 反复折腾后, 依旧没能解决. 但在此期间, 没有任何报错, 包括在宝塔上保存配置, 在服务器上 nginx -t, nginx -s reload, nginx -T 等.

推测配置被缓存了, 但为什么被缓存, 不清楚. 只能先重启 nginx 把服务搞上线.

重启之前就隐隐觉得这次重启肯定不顺利, 毕竟 nginx -s reload 没有生效, 有些地方肯定有问题. 果然报错: 7503 端口被占用, nginx 无法启动.

我瞬间就慌了, 在做了两次无效重复后, 理智回来了: nginx -T 查出 7503 在服务 B 的配置文件, 果断注释那一行然后成功启动 nginx, 线上服务恢复, 服务 A 也正常了.

7503 端口本身就被一个 next.js 项目占用, 但不知道为什么还要写到 nginx 配置文件, 只能认为不会 nginx. 问了前端负责人, 到现在也没回我~~

nginx version: nginx/1.20.2

[seansong]

nginx -t && nginx -s reload

[busier]

@seansong -t 只是測試配置文件。又不能檢測端口已占用！

[julyclyde]

reload 并不会重新 listen
我觉得你还是先仔细检查一下再说

[julyclyde]

哦。明白了
你是期望-t 失败或者-s reload 失败？

[vincentWdp]

@julyclyde 是的, 如果 -t 或 reload 失败那就可以查到错误. 但 -t 并没有.
listen 7503 这条配置我事先并不知情

[julyclyde]

@vincentWdp 你这个需求掉在夹缝里了
想让它失败，那应该是一个 restart 操作。但是这个操作是有损的

建议还是先管理好服务器上的程序吧。

[BreadKiller]

完整配置贴出来 把敏感信息打码

[coderzhangsan]

nginx -t 可以检测 nginx 下所有配置文件 listen 端口冲突，因为这是基于当前 nginx 服务而言的，反向代理端口，是远程服务器端口，这是检测不到远程端口冲突的。

[duzhuo]

只能说你无法阻止有人比你还业余

[strobber16]

7503 那一行谁加的，谁的锅。如果没有堡垒机日志那就只能和稀泥

[yinmin]

nginx -s reload 配置有问题会报出错误信息的。改配置后必须先 nginx -s reload 不出错才敢 service nginx restart ，否则就凉凉了。

OP 用 nginx -s reload 看不到报错信息吗？

[realpg]

@yinmin #11
@coderzhangsan #8

你俩到现在都没看明白 OP 这个环境是发生了什么问题

nginx 的配置没有问题

是 nginx 新监听的端口在外部被别人占用了

因为占用 所以 nginx -s reload 是不生效的


其实 OP 的吐槽是对的,这是 nginx reload 的一个问题 只是不太业余的运维大概率不会把自己弄到这个场景, 然后就没踩过这个坑

nginx reload 确实应该在这里给一个 warning 或者 error 出来

[coderzhangsan]

@realpg 业余人员，多谢指点

[leconio]

不同的 app 绑定同一个地址，同一个端口，同一种协议只会有一个 accept ，其他情况内核都能自动区分处理。

[julyclyde]

@realpg 其实 @coderzhangsan 看出来问题了啊。

[SenLief]

你说你是业务运维，那估计就是有另外一个业余运维自己部署了反代 7503 ，没有和你说而已。