Nginx反向代理随机抛出“已监听80&443端口”错误的排查求助

看起来你遇到的这个随机端口占用问题确实挺闹心的，尤其是还要手动重启才能恢复。给你整理了几个靠谱的排查方向，你可以挨个试试：

• 先抓准端口占用的真凶：下次再弹出错误提示时，先别着急重启Nginx，立刻以root身份跑这两个命令，看看到底是哪个进程占着80/443端口：

  lsof -i :80
  lsof -i :443
  

  重点留意是不是Nginx的残留子进程没正常退出，或者Certbot的临时续约进程出了岔子——虽说Certbot一般用临时端口干活，但极端情况下也可能抢占80/443。

• 深挖日志找线索：

  • 翻一翻Nginx的错误日志（默认路径是/var/log/nginx/error.log），定位崩溃前后的日志条目，说不定能找到进程异常退出、配置重载失败的具体原因；
  • 再检查系统日志（比如/var/log/syslog或/var/log/messages），看看崩溃时段有没有内存不足（被OOM Killer干掉）、系统资源耗尽的记录，这些情况也可能导致Nginx进程残留占着端口。

• 排查Certbot自动续约的锅：

  • 先确认证书续约的定时任务：切换到root用户执行crontab -l，或者用systemctl list-timers certbot.timer，看看任务的执行时间是不是和Nginx崩溃的时间点对上了；
  • 手动模拟一次续约流程，跑certbot renew --dry-run，全程盯着Nginx的状态，看看会不会触发端口冲突；
  • 检查Certbot的续约配置，是不是用了--nginx插件自动重载Nginx配置？重载过程中如果出问题，也可能导致端口占用冲突。

• 检查你的Nginx重启逻辑：
  你提到用service nginx restart-all来恢复，这个命令不是标准Nginx服务的默认命令，是不是你自己自定义的重启脚本？如果是，得确认脚本里有没有彻底清理Nginx残留进程的逻辑——比如重启前有没有先执行pkill -9 nginx或者killall nginx，把所有老进程都杀掉，避免它们占着端口不放。

• 临时应急小技巧：
  要是暂时找不到根源，先整个自动恢复的方案减少手动操作：编辑/lib/systemd/system/nginx.service，把Restart=on-failure改成Restart=always，然后执行systemctl daemon-reload，这样Nginx崩溃后会自动重启，先解决燃眉之急，再慢慢挖根源。

备注：内容来源于stack exchange，提问作者Lambda killed App