Linux怎么查看异常连接半开统计

用ss快速识别半开连接需精准过滤状态：ss -ton state fin-wait-1、ss -ton state close-wait、ss -tan state syn-recv；其中orphaned非零即确认内核级socket泄漏，CLOSE-WAIT和FIN-WAIT-2卡住表明应用未主动关闭。

怎么用 ss 快速识别半开连接

半开连接（如 FIN-WAIT-1、CLOSE-WAIT、SYN-RECV）并不只是“暂时还没彻底断开”这么简单，本质上是连接生命周期卡在了中间状态，通常说明要么对端出了异常，要么本端在关闭流程上没有处理到位。排查时也别直接用 ss -t | grep CLOSE 这类模糊匹配——状态字段的位置并不固定，很容易出现漏判，甚至误判。

• ss -ton state fin-wait-1：只输出 FIN-WAIT-1 状态，加 -o 可看超时剩余时间，判断是否已超时却未回收
• ss -ton state close-wait：CLOSE-WAIT 大量堆积，说明本端收到 FIN 后没调 close()，常见于应用 read() 返回 0 后忘记 shutdown
• ss -tan state syn-recv：SYN-RECV 是真正的半连接（三次握手未完成），持续 >100 基本可判定是 SYN Flood 或 net.core.somaxconn 设置过小

为什么 ss -s 的 orphaned 值非零就是硬泄漏

ss -s 第一行的 orphaned 数值是内核级指标：进程已退出，但 socket 还挂在内核里没释放。它和用户态可见的 Total 不重叠，也不受 TIME-WAIT 影响。一旦 orphaned > 0，基本等于确认泄漏，不是配置问题，是代码缺陷。

• 常见原因：子进程继承了父进程的 socket fd 但没显式 close；信号中断导致 cleanup 跳过；使用了 fork() 但没在子进程中关闭监听 socket
• 验证方式：cat /proc/net/sockstat 查 sockets: used 和 orphan 行，对比是否随时间增长
• 注意：net.ipv4.tcp_max_orphans 是保护阈值，设太高只会延迟 OOM，不能解决根本问题

如何区分半开连接是攻击还是程序 bug

SYN-RECV 高 ≠ 一定被攻击。得结合来源 IP 分布和连接持续时间看：

• 如果 ss -tan state syn-recv 输出里源 IP 高度离散（几十上百个不同 C 段），且每个连接存在时间接近 60–120 秒（内核默认 tcp_synack_retries 超时周期），大概率是 SYN Flood
• 如果源 IP 集中在 1–2 个内网段，且连接存在时间极短（<5 秒）又反复出现，更可能是客户端异常断连 + 服务端未设置 SO_LINGER 或未处理 read() == 0
• 用 ss -tan state syn-recv -i 看 rto 和 retrans：若重传次数 >3 且 RTO 持续拉长，说明网络层丢包严重，不是纯协议栈问题

排查时最容易忽略的两个点

先看两点很容易被忽略的细节：其一，ss -t 默认只看 TCP，不会把 UDP 带出来，而不少“半开”现象恰恰更容易藏在 UDP 场景里，比如 DNS 查询发出去后迟迟没响应，既不重试，也不做清理；其二，所有状态过滤的写法必须严格使用小写加连字符，state time-wait 才是正确写法，像 state TIME_WAIT 或 state timewait 这类写法都会直接静默失败，既不报错，也没有任何输出。

真正卡住的半开连接，往往藏在 CLOSE-WAIT 和 FIN-WAIT-2 里——前者代表你收了 FIN 却没发 FIN，后者代表你发了 FIN 却没等到 ACK，这两个状态不会自动超时清理，全靠应用主动干预。