套接字资源不足需通过dmesg查内核警告、/proc/net/sockstat和/proc/sys/net/ipv4/ip_local_port_range查系统级用量、/proc/pid/limits查进程限制，并用ss -s或lsof定位高socket占用进程。
套接字资源不足（如 socket: too many open files 或 Cannot assign requested address）通常不会直接写入常规日志文件，而是触发内核行为或被应用层捕获为错误。Linux 本身不记录“套接字回收”过程的日志，但你可以通过三类线索交叉定位：内核警告、进程资源限制、以及连接异常时的上下文痕迹。
查内核是否因套接字耗尽触发警告
当系统级套接字资源（如 sockets: used 接近上限）或文件描述符耗尽时，内核可能在 ring buffer 中输出警告，但默认不落盘到 /var/log/。必须用 dmesg 实时抓取：
-
dmesg -l err,warn | grep -i "socket\|oom\|fd"—— 查最近的内核级报错，重点关注sock_alloc失败、nf_conntrack溢出、或Too many open files相关提示 -
dmesg -T | tail -30—— 带时间戳查看最近 30 条，比journalctl更早捕获内核瞬间事件 - 注意：这些日志是环形缓冲区，重启后丢失；若需持久化，要配置
sysctl net.netfilter.nf_conntrack_log_invalid=1或启用kmsg日志服务
确认当前套接字和文件描述符使用量
资源不足一定是“已用数接近上限”，而非凭空报错。必须同时检查三层指标：
Linux Security Scanner
下载
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
- 系统级套接字总量：
cat /proc/net/sockstat→ 看sockets: used和各协议inuse是否逼近alloc值（例如 TCPalloc 41但inuse 39就很紧张） - 端口范围限制：
cat /proc/sys/net/ipv4/ip_local_port_range→ 若值是32768 61000，则仅约 28K 临时端口可用；高并发短连接容易耗尽，引发Cannot assign requested address - 进程级 fd 限额：
cat /proc/<pid>/limits | grep "Max open files"</pid>→ 单个进程若被限制为1024，而实际打开 1020+ socket，就会报too many open files；注意软限制（soft limit）才是生效值
排查哪些进程在疯狂创建 socket
资源不是均匀消耗的，往往由某个异常进程导致。用 ss 或 lsof 定位“高 socket 持有者”：
-
ss -s→ 快速汇总：显示total: 12345、TCP: 8765 (estab 123, closed 456, orphaned 7)等全局统计，比netstat更快更准 -
lsof -i -n -P | awk '{print $1,$2}' | sort | uniq -c | sort -nr | head -10→ 列出打开 socket 最多的前 10 个进程名+PID -
ss -tunap | grep ":<port>"</port>→ 若已知某端口异常（如大量TIME-WAIT），可精准过滤该端口的连接归属进程 - 陷阱：
ss -peanut需要 root 权限才能显示users:(...)，否则看不到进程名，只显示-
为什么找不到“回收日志”？关键点在这里
Linux 不记录 socket 回收动作本身——它只是关闭 fd、释放内存、从哈希表中删节点，全程静默。你看到的“回收”现象，其实是以下任一环节失败后的副作用：
- 应用层未调用
close()或shutdown()，导致 fd 泄漏 → 查/proc/<pid>/fd/</pid>目录数量持续增长 - TIME-WAIT 过多卡住端口 →
ss -tan state time-wait | wc -l超过几千就可能阻塞新连接 - conntrack 表满（尤其 NAT 场景）→
cat /proc/sys/net/netfilter/nf_conntrack_count对比nf_conntrack_max - 真正要盯的不是“回收日志”，而是
ss -s输出里orphan（孤儿 socket）和tw（TIME-WAIT）数字是否异常升高
