Linux 磁盘满了 / 网络不通怎么排查？

2026年阅读约 9 分钟面试指南 · Linux/Docker面试

Linux 面试排查

Linux面试题：磁盘排查 df与du差异、inode耗尽、已删文件未释放、iostat指标；网络排查分层法、ss与netstat、tcpdump抓包、连接数统计，附实战口诀。

一句话总结

磁盘排查三板斧：df -h 看容量、df -i 看 inode（小文件占满）、lsof 找"已删除但未释放"的文件（日志被删但进程还握着句柄）。网络排查分层走：ping（三层可达）→ 端口（四层，ss/telnet）→ 应用（七层，curl），抓包用 tcpdump 兜底。

初级理解

df 显示磁盘满了，但 du 统计加起来很小——为什么？（经典题）两个原因：

# 原因一：已删除但未释放——文件被 rm 了，但进程还打开着句柄 lsof +L1 # 列出 link count 为 0 仍被占用的文件 # 解决：重启对应进程，或清空文件内容： echo '' > /var/log/huge.log # 不能 rm，要截断（truncate -s 0） # 原因二：df 与 du 统计口径不同 # df 看文件系统整体（含保留块、元数据），du 遍历文件累加 # 挂载点覆盖、硬链接重复计数也会造成差异

inode 是什么：文件的"身份证"（元数据 + 数据块指针），每个文件占一个。海量小文件会把 inode 耗尽——df -h 还有空间但写入报 "No space left on device"，用 df -i 确认。

中级深入

磁盘性能看 iostat -x 1：

%util：设备处理 IO 的时间占比，接近 100% 说明打满（SSD/并发队列下还要结合 await）
await：IO 平均响应时间（ms），SSD 应 < 1ms，机械盘正常 5~10ms，飙升即瓶颈
r/s w/s、rkB/s wkB/s：区分随机/顺序、读/写压力来源

找大文件/大目录：

du -h --max-depth=2 / 2>/dev/null | sort -rh | head -20 # 大目录 find / -type f -size +500M -exec ls -lh {} \; 2>/dev/null # 大文件 find / -size +100M -mtime -7 # 近 7 天新增大文件（排查日志疯涨）

网络排查四层法（面试标准答案）：

① 链路/三层：ping IP（通→基础网络 OK；不通→看路由/防火墙/ARP） ② 四层：telnet IP PORT 或 ss -tnl 确认端口在监听不通 → 服务挂了？防火墙（iptables/firewalld/安全组）？监听 127.0.0.1 而非 0.0.0.0？ ③ 七层：curl -v http://... 看状态码/证书/重定向 ④ 都通但业务异常 → tcpdump 抓包看实际交互

高级拓展

ss 优于 netstat（要说得出理由）：ss 直接读内核 netlink/内存数据，万级连接不卡；netstat 遍历 /proc 逐个读，连接多时极慢。高频用法：

ss -tnl # 监听中的 TCP 端口 ss -tnp | grep :8080 # 谁连着 8080（含进程名） ss -s # 连接状态总览（TIME_WAIT 多不多一眼看出） ss -tn state time-wait | wc -l # 统计 TIME_WAIT 数量

TIME_WAIT 过高的处置：TIME_WAIT 是主动关闭方的正常状态（等 2MSL），万级可接受；十万级+影响建连时：① 应用侧用连接池复用、尽量由客户端主动关闭；② 内核调优 tcp_tw_reuse=1（仅出站方向安全）。不要背"net.ipv4.tcp_tw_recycle=1"这种答案——它已在内核 4.12 移除且本身就是坑。

tcpdump 实战（面试让手写一条）：

tcpdump -i any host 10.0.0.5 and port 8080 -nn -c 100 -w /tmp/a.pcap # -i any 全网卡 host/port 过滤 -nn 不解析域名端口 # -c 100 抓满 100 包即停 -w 存文件（Wireshark 分析） # 只抓握手：'tcp[tcpflags] & (tcp-syn|tcp-ack) == tcp-syn'

抓包看什么：三次握手有没有 SYN 无 SYN-ACK（防火墙丢包/未监听）、RST 谁发的（服务拒绝/端口未监听）、重传多不多（网络质量）、HTTP 层看请求响应内容（配合 -A）。

实战场景

场景一：凌晨告警磁盘使用率 95%

1. df -h 定位满的分区；df -i 排除 inode 打满 2. du -h --max-depth=1 逐层下钻找大目录 3. 常见元凶：/var/log 日志疯涨（logrotate 没配）、应用 dump 文件、Docker 镜像/容器日志 Docker：docker system df；journalctl --disk-usage；清理 journalctl --vacuum-size=500M 4. 治本：logrotate 尺寸+保留策略、日志采集侧删本地、磁盘水位告警前置到 80%

场景二：服务间调用突然大量超时

# 按层走： ping 目标IP # 通 → 网络可达 telnet 目标IP 8080 # 通 → 四层 OK curl -v -m 5 http://... # 慢/挂 → 应用问题（看响应卡在哪） ss -s # TIME_WAIT/全连接队列是否异常 tcpdump -i any host 目标 port 8080 -nn # 观察是否有大量重传、RST、或 SYN 发出无响应 # 结合监控：目标机器负载/连接数/GC——八成是对方慢，不是网络断

场景三：容器里磁盘写满

# 容器可写层与挂载卷都要查 df -h # 看 overlay 满还是挂载卷满 docker ps -s # 看各容器可写层大小 du -sh /var/lib/docker/overlay2/* | sort -rh | head # 常见：容器 stdout 日志没轮转 → /etc/docker/daemon.json 配 log-driver max-size

面试模拟

Q：rm 掉一个 100G 日志文件，磁盘空间没释放，为什么？怎么办？

A：Linux 删除只减 link count，进程还持有文件句柄时 inode 不会释放。用 lsof +L1 能看到 deleted 状态的大文件。处置：优雅方案是让进程重开日志（logrotate 的 copytruncate / 发 USR1 信号）；紧急方案是 truncate -s 0 文件名截断释放空间——直接 rm 是无效的，重启进程才彻底。

Q：服务器能 ping 通但端口连不上，列出可能原因。

A：按概率排：① 服务没启动或崩了（ss -tnl 看监听）；② 监听地址是 127.0.0.1 而非 0.0.0.0（容器/配置常见）；③ 防火墙：iptables/firewalld 规则、云平台安全组没放行；④ 端口被占用导致服务起不来；⑤ 中间网络设备 ACL。排查命令链：ss -tnl → telnet → iptables -L -n → 抓包看 SYN 有没有回 SYN-ACK。

Q：怎么统计一个服务的实时连接数和来源 IP 分布？

A：ss -tn state established '( sport = :8080 )' 列出 established 连接；配 awk 统计来源：ss -tn | awk 'NR>1 {split($4,a,":"); print a[1]}' | sort | uniq -c | sort -rn | head（按需取 $4 对端或本端）。对比 netstat：ss 读内核态数据更快，连接数上万时是唯一可行选择。关注点：ESTABLISHED 总量、TIME_WAIT 趋势、单一来源 IP 是否异常（可能是爬虫或连接泄漏）。