主要解决问题思路
排查服务器访问缓慢时，可按以下步骤逐步定位：
先用 htop 监控进程资源占用，重点观察 CPU 使用率。若 CPU 仅略高于日常（无异常进程占用），属正常现象 —— 因网络拥堵可能导致 CPU 处理开销略有增加，此时需转向网络排查。
运行 iftop 查看实时网络连接的上下行流量。若发现服务器带宽被占满（如大量异常连接持续占用带宽），则网络拥堵为主要瓶颈。
若流量处于较低水平（排除网络因素），可进一步通过 iostat 或 iotop 排查磁盘 IO 性能，确认是否因磁盘读写缓慢（如 IO 等待过高）导致访问延迟。
这次故障是iftop找到了有问题的链接，但是 lsof -i @121.199.62.135:443 找不到 PID，但 iftop 仍显示有连接时，可通过以下方法进一步定位：
1. 利用 ss 结合 nsenter 排查（容器/命名空间场景）
如果系统有容器或使用了网络命名空间，进程可能隔离在其他命名空间，lsof 无法直接看到。
# 先找相关连接的 inode
ss -i | grep 121.199.62.135:443 | awk '{print $10}'
# 输出类似 ino:12345
# 遍历进程找 inode 对应的 PID
for pid in $(ls -d /proc/[0-9]*); do
grep -q 12345 $pid/fdinfo/* 2>/dev/null && echo $pid
done
# 若找到 PID，进入进程命名空间查看（需 root）
nsenter -t <PID> -n lsof -i @121.199.62.135:443
2. 抓包分析 SYN 包（半连接/未完成握手）
如果是大量 SYN 包（半连接），lsof 不会显示进程，因为连接未建立。
# 抓包看是否有大量 SYN 包
tcpdump -i eth0 'tcp SYN and host 121.199.62.135' -c 100
# 若有，可能是 SYN 洪水攻击，用 iptables 防护：
iptables -A INPUT -p tcp --syn --dport 443 -m connlimit --connlimit-above 10 -j DROP
3. 检查内核模块/隐藏进程（高权限恶意程序）
恶意程序可能隐藏进程（如 rootkit），需检测：
# 安装 rkhunter
yum install rkhunter -y # 或 apt install rkhunter
rkhunter --check
# 检查可疑内核模块
lsmod | grep -Ev '^Module|nfs|ext4' # 找未知模块
4. 对比 netstat 和 ps 找差异
# 列出所有网络连接的 PID
netstat -anp | grep 121.199.62.135:443 | awk '{print $7}' | cut -d/ -f1 | sort -u > net_pids
# 列出所有存在的 PID
ps -eopid | sort -u > all_pids
# 找不在正常 PID 列表的连接
comm -23 net_pids all_pids
5. 直接阻断（应急）
若无法定位，先阻断 IP 止损：
# iptables 封禁
iptables -I INPUT -s 121.199.62.135 -j DROP
iptables -I OUTPUT -d 121.199.62.135 -j DROP
# 或用路由丢弃
route add -host 121.199.62.135 reject
6. 容器环境特殊处理
如果是 Docker 环境，检查容器网络：
# 列出所有容器网络命名空间
docker ps -q | xargs -n1 docker inspect --format '{{.State.Pid}} {{.Name}}' | while read pid name; do
echo "Container: $name (PID: $pid)"
nsenter -t $pid -n lsof -i @121.199.62.135:443
done
通过定位容器网络访问的IP，最终找到有问题的容器，中止对应的容器。整体恢复正常，问题得到解决。
关键结论
- 若
ss/netstat也看不到 PID，可能是半连接（SYN 洪水）或内核级隐藏进程。 - 优先用
iptables封禁 IP 止损，再逐步排查是否有 rootkit 或容器隔离问题。 - 若在容器环境，必须进入容器命名空间才能看到进程。