nf_conntrack_max过小会导致syn包被静默丢弃；tcp_timeout_established设太短会误杀长连接；time_wait超时过长易占满表项；需协同调优三者并监控使用率。
nf_conntrack_max 设置太小会直接丢包
连接跟踪表满时，Linux 会静默丢弃新连接的首包（SYN），不回复 RST，客户端超时重传后可能误判为服务不可达。这不是防火墙规则问题，而是内核 conntrack 子系统主动拒绝登记新连接。
查当前使用量：cat /proc/sys/net/netfilter/nf_conntrack_count；查上限：cat /proc/sys/net/netfilter/nf_conntrack_max。生产环境建议两者比值长期低于 60%，否则容易在流量毛刺时触顶。
- 估算公式：每台服务器
nf_conntrack_max≈预期并发连接数 × 1.5（留余量防短连接爆发） - 临时调大：
sysctl -w net.netfilter.nf_conntrack_max=65536 - 永久生效：写入
/etc/sysctl.conf，但注意该值受RAM限制——每条 conntrack 条目约占用 320 字节，64K 条目 ≈ 20MB 内存 - 容器环境要特别小心：
dockerd或kube-proxy默认共享宿主机 conntrack 表，Pod 网络密集场景极易打满
nf_conntrack_tcp_timeout_established 调得太短会导致长连接被误杀
这个值控制 ESTABLISHED 状态 TCP 连接在 conntrack 表中的存活时间，默认是 5 天（432000 秒）。如果设成 300 秒，所有空闲但未断开的 HTTP 长连接、数据库连接池连接、SSH 会话都会在 5 分钟后被强制从表中清除——后续数据包因无对应连接记录，直接被 DROP。
现象典型：用户反馈“连接用着用着就断”，conntrack -L | grep :80 看不到活跃连接，但 ss -tn 显示 socket 仍 ESTABLISHED。
- Web 服务（Nginx/HTTP）建议设为 1200–3600 秒（20–60 分钟），兼顾资源回收与用户体验
- 数据库连接池（如 PgBouncer、MySQL 连接池）必须 ≥ 应用端最大空闲连接超时时间，否则池里“健康”的连接在内核侧已失效
- 不要全局统一设为 300 秒来“优化性能”——conntrack 查表是哈希 O(1)，耗时微乎其微，真正瓶颈是内存和表满后的丢包
修改后不生效？检查 conntrack 模块是否已加载及 sysctl 是否被覆盖
sysctl 值写入后看似成功，但 conntrack -L 里连接超时时间没变，大概率是模块参数未正确传递，或被更高优先级配置覆盖。
- 确认模块已加载：
lsmod | grep nf_conntrack；若未加载，需先modprobe nf_conntrack - 模块参数优先级高于 sysctl：检查
/etc/modprobe.d/*.conf中是否有options nf_conntrack nf_conntrack_tcp_timeout_established=300类似行，它会覆盖 sysctl 设置 - 某些发行版（如 RHEL/CentOS 7+）默认启用
systemd-sysctl，但若/etc/sysctl.conf里有语法错误（如多空格、注释符错位），整行会被跳过且无提示 - 验证是否生效：改完运行
sysctl net.netfilter.nf_conntrack_tcp_timeout_established，输出应与你设置值一致；再看conntrack -L | head -1的 timeout 字段是否更新
高并发短连接场景下，光调参数不够，得配合连接复用与状态清理
电商秒杀、API 网关等场景，每秒数千 SYN，即使 nf_conntrack_max 足够，也会因大量 TIME_WAIT 连接占满表项——它们默认超时 120 秒，远长于 ESTABLISHED。
- 启用快速回收（慎用）：
net.ipv4.tcp_tw_reuse = 1，仅对 client 端有效，且要求 timestamps 开启；服务端不推荐开启tcp_tw_recycle（已废弃，NAT 下必出问题） - 缩短 TIME_WAIT 超时：
net.netfilter.nf_conntrack_tcp_timeout_time_wait = 30（默认 120），比调nf_conntrack_max更治本 - 定期清理无效连接：
conntrack -D --dst-port 80 --proto tcp --state INVALID可清异常条目，但别放进 cron 频繁跑——conntrack -D是全表扫描，高负载时加重 CPU - 更彻底的解法：用 eBPF 替代 conntrack 做连接跟踪（如 Cilium），或改用无状态代理（如 Envoy 的 original_dst 配合 iptables TPROXY）绕过 conntrack
真正卡住人的从来不是参数名记不牢，而是查到 nf_conntrack_count 接近 nf_conntrack_max 时，顺手把后者翻倍，却忘了 nf_conntrack_tcp_timeout_time_wait 还钉在 120 秒——结果半小时后表又满了。
