windows查看80端口被占用

线上故障实录：服务启动异常，一大早就陷入忙碌？

一个宁静的周末早晨，尚未从睡梦中完全清醒的我接到了来自另一团队的紧急电话，app 出现故障，所有数据显示异常，似乎整个服务都陷入了瘫痪。睡意全无，立刻投入到紧张的故障排查中。经过一系列的努力，最终定位到一个关键链路的 nginx 配置错误，导致 nginx 无法正常启动。下面我将详细记录这个周末的不寻常早晨。

一、项目背景

这个项目是我之前参与过的，现在由其他小伙伴负责。它采用 nginx 作为反向代理，为了应对某些业务上的挑战，我们还专门设置了香港和之间的专线，并使用了另一层 nginx 进行业务请求的转发。后端服务基于 SpringCloud 微服务构建，通过统一网关提供基础业务服务。但也有部分服务不通过网关，直接由 nginx 转发。整体结构相对复杂，具体细节在此不再赘述。

二、问题描述

故障表现为运营团队首先接收到反馈，app 上的所有数据都无法显示，有一种业务服务崩溃的直观感受。初步怀疑可能的原因有两个：一是业务服务确实出现了问题；二是过期。值得注意的是，我们的域名使用 let's encrypt 进行颁发，有效期仅三个月，因此过期也是一个可能的原因。

三、问题追踪

我先通过 app 查看具体情况，确认数据确实无法加载，初步判断是服务端出了问题。首先验证了运营团队的疑虑之一——是否过期。尝试直接通过浏览器访问 app 对应的接口域名，发现被重定向到一个过期的页面，但这个一级域名并非直接问题所在。接着尝试访问二级域名（根据用户地域随机生成），发现无法直接访问。需要通过抓包来确定具体域名。假设二级域名为 xxx.，直接访问提示网络无法访问，无法确定其是否过期。域名能够 ping 通，说明域名解析没有问题。在排除域名问题后，进一步检查服务是否在线。登录服务器查看当前进程，发现没有 zuul 网关进程，这是否意味着网关出现了问题？查看日志发现有心跳日志，但进程实际存在且是以 root 权限启动的，所以普通账号无法看到。为避免此类情况，建议小伙伴们在服务器上操作时尽量避免使用 root 用户。

在确认服务还在线后，通过 curl 命令发出请求测试服务响应，结果显示正常。于是将目光转向上层 nginx 服务器，查看访问日志和错误日志，发现一些之前的 ssl 验证失败的记录，但这似乎不是导致问题的主要原因。进一步深入排查时，发现某一台 nginx 服务器的域名 ping 无响应，查看 nginx 配置文件未发现异常改动。此时意识到可能是 nginx 进程出现问题。

四、问题解决方案

既然问题集中在 nginx 进程上，那就优先解决它。尝试启动 nginx 时遇到端口 80 被占用的错误。通过 netstat 命令未找到占用该端口的进程。在寻求网络上的解决方案时，尝试使用 fuser 命令杀掉占用端口 80 的进程，但问题仍未解决。此时只能选择重启服务器作为临时解决方案，先恢复服务可用性。重启后尝试再次启动 nginx 仍然失败。这时开始深入分析为何 nginx 起不来。

经过排查发现，nginx 配置中的某个配置文件导致端口冲突。原来是 conf.d 目录下的某个配置文件与最外层的配置产生了冲突。调整配置后，nginx 成功启动。至于为何 nginx 进程会挂掉，这可能是由一些未知的原因导致的，需要进一步深入调查。

五、小结

回顾这次故障处理过程，虽然最终找到了问题的根源并解决了故障，但也出一些问题和需要改进的地方。首先是单点问题，某个单点的 nginx 故障导致了整个服务的瘫痪；其次是监控缺失，对于核心链路的进程监控不够充分；最后是信息沟通不及时，虽然阿里云已经发出了警告，但相关信息的传递存在延误。这次故障给我们敲响了警钟，需要在这些方面加强管理和改进。