偶发不可用主因是中间设备RST、OOM Killer杀进程、systemd重启退避、TIME_WAIT端口耗尽；应优先用dmesg、ss、tcpdump定位系统与网络层问题。
看连接是否被中间设备重置
公网服务偶发不可用，第一反应常是服务进程挂了，但更常见的是连接在传输路径中被意外中断。典型表现是客户端 tcpdump 抓到 SYN 发出后没收到 SYN-ACK，或收到 RST 包；服务端 netstat -s | grep -i "reset" 显示大量 segments reset。这往往不是服务本身的问题，而是防火墙、云厂商安全组、NAT 网关或运营商设备因会话超时、连接数限制或策略变更主动发 RST。
实操建议：
- 在服务端和客户端分别用
tcpdump -i any port抓包，比对三次握手是否完整PORT-w conn.pcap - 检查云平台控制台的安全组/网络 ACL 日志（如 AWS VPC Flow Logs、阿里云流日志），确认是否有
REJECT或DROP记录 - 临时关闭本地防火墙（
systemctl stop firewalld或ufw disable）排除干扰，再复现问题 - 若使用 NAT 网关，确认其连接数配额（如 AWS NAT Gateway 默认 5.5 万并发连接）是否被打满
查服务进程是否被 OOM Killer 杀掉
偶发不可用持续几秒到几十秒，且无明显错误日志，dmesg -T | grep -i "killed process" 却输出类似 Killed process 12345 (nginx) total-vm:2048000kB, anon-rss:1800000kB, file-rss:0kB 的记录——这就是 OOM Killer 在后台动的手。Linux 内核发现内存严重不足时，会按 oom_score_adj 选一个“最该杀”的进程干掉，不通知应用层，也不写服务日志。
实操建议：
- 立即执行
dmesg -T --level=err，过滤带时间戳的内核错误，重点找Killed process - 检查服务进程的内存限制：
cat /proc/（值越大越容易被杀），默认为 0，容器中可能被设为 1000PID/oom_score_adj - 给关键服务设置抗杀优先级：
echo -999 > /proc/（需 root；容器启动时加PID/oom_score_adj--oom-score-adj=-999） - 监控
free -h和cat /sys/fs/cgroup/memory/memory.usage_in_bytes（cgroup v1）趋势，提前预警内存压力
验 systemd 服务是否被 RestartSec 拖慢恢复
用 systemctl status 看到状态是 SERVICEactivating (auto-restart) 或反复在 failed → activating → failed 循环，但服务二进制本身没问题——问题常出在 systemd 的重启退避机制。默认配置下，如果服务连续失败，RestartSec 会指数级增长（如 100ms → 200ms → 400ms…），导致看似“偶发不可用”，实则是服务刚崩就立刻重启，却被 systemd 卡着不让起。
