确认conntrack表满导致连接失败：查conntrack -c是否接近/proc/sys/net/netfilter/nf_conntrack_max；dmesg或/var/log/messages是否有"table full, dropping packet"；ss -s显示estab远少于nf_conntrack_count。
Workerman 拒绝新连接，日志里没报错但客户端连不上，systemctl status workerman 看进程正常，dmesg 或 /var/log/messages 却刷屏 nf_conntrack: table full, dropping packet —— 这不是 Workerman 的问题，是内核 conntrack 表被耗尽，新 TCP 握手包直接被丢弃，根本到不了 Workerman 的监听 socket。
怎么确认真是 conntrack 表满导致的连接失败
别猜，直接查内核状态和实时连接分布：
- 看是否真满：
conntrack -C输出数字接近或等于cat /proc/sys/net/netfilter/nf_conntrack_max就是瓶颈 - 查丢包证据：
dmesg -T | grep "table full"或grep "nf_conntrack: table full" /var/log/messages - 观察连接堆积特征：短连接密集（如 HTTP API、WebSocket 心跳）时，
conntrack -L | awk '{print $4}' | sort | uniq -c | sort -nr | head -5很可能显示大量TIME_WAIT或UNREPLIED - 排除 Workerman 自身限制：用
cat /proc/$(pgrep -f "workerman start")/limits | grep "Max open files"确认 fd 限制没卡住；ss -s看 ESTAB 数量远低于nf_conntrack_count，说明连接压根没建立成功
临时救急：立刻释放资源恢复业务
线上挂了先止血，但注意操作有副作用：
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 只删无效条目（推荐）：
conntrack -D --state INVALID,UNREPLIED—— 不中断现有 ESTABLISHED 连接，适合生产环境 - 清空整个表（慎用）：
conntrack -F—— 所有 NAT、FTP、已有连接状态丢失，可能导致客户端重连风暴或服务短暂不可用 - 临时扩容上限：
sysctl -w net.netfilter.nf_conntrack_max=131072，同时调哈希桶数避免冲突：sysctl -w net.netfilter.nf_conntrack_buckets=32768 - 快速定位攻击源：
conntrack -L | awk '{print $7}' | cut -d= -f2 | sort | uniq -c | sort -nr | head -10，对异常高频 IP 用iptables限流
长期调优：适配 Workerman 的连接模型
Workerman 多为短连接或长连接心跳，但默认 conntrack 超时（如 nf_conntrack_tcp_timeout_established=432000）远超业务实际存活时间，导致条目滞留：
- 大幅缩短 established 超时：
sysctl -w net.netfilter.nf_conntrack_tcp_timeout_established=3600（1小时），高并发 API 可压到600（10分钟） - 收紧 TIME_WAIT 回收：
sysctl -w net.netfilter.nf_conntrack_tcp_timeout_time_wait=60（原值常为 120） - 禁用无关 ALG 模块：
modprobe -r nf_conntrack_ftp nf_conntrack_sip，并在/etc/modprobe.d/blacklist.conf加blacklist nf_conntrack_ftp - 若 Workerman 节点纯作 L4 转发且不依赖 stateful 防火墙，考虑在
iptables -t raw -A PREROUTING中对业务端口加-j NOTRACK，彻底绕过跟踪
Workerman 场景下容易被忽略的点
很多人调了 nf_conntrack_max 就以为完事，但实际还有两个硬约束经常被漏掉：
-
nf_conntrack_buckets必须同步调整，否则哈希桶太少会引发严重冲突，导致插入失败或性能陡降；它通常应设为nf_conntrack_max的 1/4 到 1/8 - Workerman 启动时继承的是 shell 的 ulimit，而 conntrack 表满后系统级丢包，
ulimit -n再大也无济于事——必须盯死/proc/sys/net/netfilter/nf_conntrack_count和dmesg输出，而不是只看 Workerman 日志 - 容器环境（如 Docker/K8s）中，若使用 Cilium 或 eBPF 替代 iptables，conntrack 可能被绕过；但若仍用 kube-proxy iptables 模式，则宿主机 conntrack 参数仍起决定性作用
