业务无法访问？用这7条命令快速定位网络故障

对运维工程师而言，业务故障在所难免，熟练掌握故障排查技能是运维人员的必备能力。一套清晰的排查思路能帮助我们准确定位问题所在。

今天分享一下业务无法访问的排查方法。

运维工作中总会遇到各种突发故障，但掌握系统的排查方法就能沉着应对。下面我结合个人经验，从5个方向展开说明，希望能为你提供参考。

1. 确认问题范围

开始排查前不要急着敲命令，先问清楚这几个关键点：

影响范围：是单个用户无法访问？某个地区的用户集体报错？还是整体业务完全不可用？业务范围：是整个服务中断？还是某个功能模块或接口异常？时间规律：问题持续存在还是间歇性出现？排查技巧：越早锁定问题范围，定位效率越高。

2. 分层排查思路

主要排查点：网络策略 → 系统资源 → 应用服务 → 数据库 → 外部依赖 → 安全设备

逐层深入排查，才能避免遗漏。

(1) 网络层：先看“通不通”

主要使用ping，traceroute，telnet，curl等命令。

# 测试服务器是否连通，ping域名或IPping -c 4 10.0.0.110ping www.ligelinux.com# 路由追踪，查看卡在哪一跳traceroute 10.0.0.110# 测试端口连通性telnet 10.0.0.110 8089# HTTP接口连通性curl -I http://www.ligelinux.com

常见问题：网络策略变动、路由抖动、运营商网络波动、防火墙规则更新。

(2) 系统层：资源够不够

# 查看CPU、内存、负载情况，资源是否充足topuptimefree -h# 查看磁盘使用情况df -hdu -sh /data/*# 系统日志journalctl -xetail -n 200 /var/log/messages

常见问题：CPU跑满、内存不足、磁盘写满导致服务无响应。

(3) 应用层：服务是否正常

服务异常一般会出现503错误。

可以通过检查服务进程、端口状态和日志信息来定位。

# 查看服务状态，比如nginx，排查时替换成你的服务就行systemctl status nginxps -ef | grep 服务名字# 检查端口监听ss -tulnp | grep 端口# 查看应用日志tail -f /var/log/xxx.log# 本地检查应用是否正常curl -v http://localhost:your-port/health

常见问题：进程挂掉、端口没监听、依赖服务未启动。

(4) 数据层：库和缓存撑不撑得住

主要检查数据库是否正常。连接不上一般会在日志里报错。

主要排查数据库是否正常：

# MySQL是否能连mysql -uroot -p# MySQL是否卡锁mysql -e "show full processlist;"# Redis连通性redis-cli -h redis-host ping# Redis慢日志redis-cli -h redis-host slowlog get 10

常见问题：数据库连接数爆满、慢查询、Redis阻塞。

(5) 外部依赖

有些系统会调用外部接口，也有可能是外部应用出问题了。

# 测试外部API健康性curl -I https://xxx.com/health# DNS解析nslookup xxx.comdig xxx.com# CDN是否正常curl -v https://xxx.com | grep -i "cache"

常见问题：第三方接口超时、DNS劫持、CDN缓存异常。

(6) 安全设备层：别忽略“拦路虎”

很多时候，业务并不是挂了，而是被安全设备拦截，一般会出现403字样。

这种情况一般是触发了安全设备拦截规则，这时就要找安全团队查看安全设备是否有拦截记录。

WAF（Web应用防火墙）：拦截了特定请求，比如带有敏感参数或 SQL 关键字。防火墙/安全组：有时候策略更新导致流量被拦截。

iptables -L -n -v firewall-cmd --list-all

IDS/IPS（入侵检测/防御系统）：突然发现请求量大，被判定为攻击流量。建议与安全团队对接，确认是否有误拦。

常见问题：安全策略过于严格、误拦合法流量、规则变更未通知。可以通过加白名单解决。

3. 排查信息收集清单

排查时必须收集以下信息：

用户报错截图及相关服务日志系统指标：CPU、内存、磁盘、网络应用指标：进程，端口，日志外部依赖状态安全设备：WAF拦截，FW策略，IPS日志

信息齐全，排查效率提升3倍以上。

4. 复盘与预防

排查只是第一步，问题解决后一般会做下面的事情：

原因复盘：是配置问题、流量激增、资源不足，还是安全设备触发？监控优化：关键指标全链路监控，异常提前预警。自动化排查：脚本化常用检测命令，一键定位问题。知识沉淀：把排查经验写成 SOP，让团队少踩坑。

业务无法访问时，真正考验的不是你会多少命令，而是有没有完整的排查思路。

只要照着网络 → 系统 → 应用 → 数据 → 外部依赖 → 安全设备这条链路去排查，信息收集全面，就能快速找到根因。