故障

博客原来运行正常，但尝试通过htps://117.72.192.68 访问时，浏览器显示ERR_CONNRCTION_TIMED_OUT(响应超时)。尝试在系统内重启Nginx服务时，也遭遇了启动失败。本文记录了完整的排查思路、使用的命令以及最终解决过程。

排障过程与核心命令

排障思路#

在排障中，我遵循了网络 ➡ 端口 ➡ 服务 ➡ 配置 ➡ 日志 ➡ 进程

一、 确认云平台安全组与防火墙#

首先确认京东云控制台的安全组，已放行 80 和 443 端口。接着检查系统内部防火墙状态，确保没有拦截

sudo ufw status

🔍 命令解析
sudo:临时借用最高管理员（root）权限。
ufw:Ubuntu系统的防火墙管理工具
status:查看当前防火墙规则，确保没有拦截端口。

二、检查端口监听状态

端口时网络服务的“大门”
检查 443 端口：

sudo ss -tlnp | grep ':443'

检查 80 端口

sudo ss -tlnp | grep ':80'

🔍 命令解析
ss:Socket Statistics，查看端口和连接
-tlnp:-t看TCP:-l看监听：-n看显示数字：-p显示进程名。
|：管道符，把前面的结果交给后面处理
grep ‘:443’:过滤出包含443的行。
⚠️ 排查结果
查443无任何输出，说明443没启动：
查80发现被多个 nginx 进程占用。

三、检查服务运行状态

发现异常后，查看系统管家记录的服务状态。

sudo systemctl status nginx

尝试启动：

sudo systemctl start nginx

🔍 命令解析

systemctl：系统的服务管家。

status：查状态（显示 dead 表示没运行）。

start：尝试启动服务。
⚠️ 排查结果
启动报错 Job for nginx.service failed…

四、 检查 Nginx 配置语法

启动失败最常见的原因是配置文件写错。

sudo nginx -t

🔍 命令解析
-t 代表 test，让 Nginx 自己检查配置。

✅ 排查结果
显示 syntax is ok 和 test is successful，说明代码没问题。

五、 查看系统底层日志#

配置没问题，去看看系统底层发生了什么。

sudo journalctl -xe -u nginx --no-pager | tail -n 20

🔍 命令解析

journalctl：查看系统日志。

-xe：显示详细错误。

-u nginx：只看 nginx 的。

–no-pager：不分页显示。

tail -n 20：只看最后 20 行。

六、 找出真凶与清理

结合前面发现 80 端口被占，真相大白：有一个“野生”的旧 Nginx 进程卡死了，占着 80 端口，导致新服务起不来。

强制杀掉旧进程：

sudo pkill -9 nginx

清理后重新启动并检查：

sudo systemctl start nginx
sudo systemctl status nginx

🔍 命令解析
pkill -9 nginx 意思是强制（-9 信号）杀掉所有叫 nginx 的进程。把旧钉子拔掉，系统管家就能成功把 Nginx 重新拉起来了。

✅ 解决成功
再次检查状态，显示绿色的 active (running)，浏览器访问恢复正常！

（在这里插入 status 变绿色的截图）

七、 运维核心知识点总结

知识点	说明
端口排他性	一个 IP 的特定端口（如 80），同一时间只能被一个服务监听。
多端口支持	一个 Nginx 服务可以同时监听 80 和 443 等多个端口。
Nginx 进程结构	查 80 端口看到好几个 nginx 是一家人：1 个 Master 主进程负责占端口，多个 Worker 负责干活。
黄金排障思路	网络 → 端口 → 服务 → 配置 → 日志 → 杀进程重启。