用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 分布和连接持续时间看：
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 如果
ss -tan state syn-recv输出里源 IP 高度离散（几十上百个不同 C 段），且每个连接存在时间接近 60–120 秒（内核默认tcp_synack_retries超时周期），大概率是 SYN Flood - 如果源 IP 集中在 1–2 个内网段，且连接存在时间极短（SO_LINGER 或未处理
read() == 0 - 用
ss -tan state syn-recv -i看rto和retrans：若重传次数 >3 且 RTO 持续拉长，说明网络层丢包严重，不是纯协议栈问题
排查时最容易忽略的两个点
一是 ss -t 默认不显示 UDP，而很多半开行为其实在 UDP 场景下更隐蔽（比如 DNS 查询无响应后不重试也不清理）；二是所有状态过滤必须用小写+连字符，state time-wait 对，state TIME_WAIT 或 state timewait 都会静默失败，不报错也不输出。
真正卡住的半开连接，往往藏在 CLOSE-WAIT 和 FIN-WAIT-2 里——前者代表你收了 FIN 却没发 FIN，后者代表你发了 FIN 却没等到 ACK，这两个状态不会自动超时清理，全靠应用主动干预。
