504错误本质是Nginx等代理无法在超时时间内收到上游响应，常见于后端慢、网络延迟或conntrack表满导致连接被丢弃；需结合日志、curl测试、conntrack状态及系统资源综合排查，优先调优proxy_read_timeout等参数并根治conntrack瓶颈。
504 错误本身不直接由 conntrack 溢出引起，但当 conntrack 表满时，新连接被内核丢弃（nf_conntrack: table full, dropping packet），导致上游代理（如 Nginx、HAProxy 或 Kubernetes Ingress Controller）无法建立到后端服务的连接——此时超时后即返回 504 Gateway Timeout。本质是“连不上”，而非“后端慢”。解决需从连接跟踪资源瓶颈切入，而非仅调长 proxy_read_timeout。
快速确认是否为 conntrack 溢出
登录出现 504 的节点（通常是网关或负载均衡器所在宿主机），执行：
- 查丢包日志：
dmesg -t | grep "table full"—— 若有输出，基本坐实 - 看当前用量：
cat /proc/sys/net/netfilter/nf_conntrack_count和上限cat /proc/sys/net/netfilter/nf_conntrack_max，比值 >90% 即高危 - 统计连接分布：
conntrack -L | awk '{print $3}' | sort | uniq -c | sort -nr | head -5，重点关注tcp、udp或异常协议（如大量invalid状态）
立即恢复业务：清空 + 临时扩容
生产环境优先保通，不建议直接 conntrack -F 全清（会中断所有 NAT 和 stateful 规则），推荐分步操作：
- 清理无效连接：
sudo conntrack -D --state INVALID（通常能释放 20–50% 空间） - 按端口清理堆积连接（如网关常用 80/443）：
sudo conntrack -D -p tcp --dport 80 - 临时扩大上限（按内存估算）：
sudo sysctl -w net.netfilter.nf_conntrack_max=1048576（1GB 内存 ≈ 200 万条） - 验证生效：
conntrack -C查当前数，确保未再飙升
精准定位连接堆积源头
单纯扩容只是掩耳盗铃。重点排查三类典型场景：
-
短连接风暴：HTTP API 高频请求但未复用连接，
TIME_WAIT大量堆积 → 查conntrack -L -p tcp | grep TIME_WAIT | wc -l -
后端失联连接滞留：Pod 崩溃或网络断开后，客户端仍发包，conntrack 保持
ESTABLISHED直至超时（默认 5 天）→ 查conntrack -L | grep "src=.*dst=.*port" | head -10看源/目标 IP 是否含已下线节点 -
ALG 干扰：启用了
nf_conntrack_sip或nf_conntrack_ftp，但业务根本不用这些协议 → 执行lsmod | grep nf_conntrack_确认模块加载情况
长效稳定调优：缩、禁、绕
真正降低 conntrack 压力，靠三类协同动作：
-
缩超时：写入
/etc/sysctl.conf后sysctl -pnet.netfilter.nf_conntrack_tcp_timeout_established = 3600（1 小时，非 5 天）net.netfilter.nf_conntrack_tcp_timeout_time_wait = 60（60 秒） -
禁 ALG：若无 SIP/FTP/TFTP 业务，卸载并黑名单：
sudo modprobe -r nf_conntrack_sip nf_conntrack_ftp
在/etc/modprobe.d/blacklist.conf加：blacklist nf_conntrack_sip -
绕跟踪：对纯转发流量（如 kube-proxy ipvs 模式、Cilium eBPF 节点），用 raw 表跳过：
iptables -t raw -A PREROUTING -d 10.96.0.0/12 -j NOTRACK（跳过 ClusterIP 流量）
