伺服器 conntrack 表飽和 conntrack table full

原因 ID so-conntrack · 主要負責 基礎設施團隊（伺服器基礎設施） · 協同遊戲開發團隊（伺服器開發）, 遊戲開發團隊（用戶端開發）

Linux 防火牆會把每條連線記錄在連線追蹤（conntrack）表中，這個表碰到上限時就會丟棄新封包。

為什麼 連線暴增或反覆建立短連線，讓連線紀錄增加 → 於是表已滿，新連線與部分封包被丟棄 → 畫面上 連不上，或因原因不明的遺失出現瞬移

症狀: 連不上／無限讀取, 瞬移
因素: 遺失
誰會遇到: 整個伺服器
何時: 剛登入／維護剛結束, 人潮湧入時
負責單位: 主要負責 基礎設施團隊（伺服器基礎設施） · 協同遊戲開發團隊（伺服器開發）, 遊戲開發團隊（用戶端開發）
遊戲開發團隊要做的事: 伺服器：減少短連線（伺服器之間的呼叫重複使用連線）。用戶端：連線失敗或中斷時，逐步拉長重試間隔並加上隨機值分散。
基礎設施團隊要做的事: 加大表的大小（nf_conntrack_max）、讓遊戲 port 不做追蹤（raw 表的 NOTRACK）、設定用量警示。
數值參考: 預設上限依伺服器記憶體約為 6 萬～26 萬筆。溢位時 kernel log 會出現「nf_conntrack: table full, dropping packet」。
圖表上: 碰到上限後持平 · conntrack 項目數（nf_conntrack_count）
查看位置: 把 sysctl 的 net.netfilter.nf_conntrack_count（目前項目數）與 nf_conntrack_max 放在同一張圖表上，並在 dmesg 中找「nf_conntrack: table full, dropping packet」
符合的跡象: nf_conntrack_count 在 max 持平，從那個時間點起 kernel log 出現 table full
不符合的跡象: 項目數遠低於 max 就不是這個原因。AWS 執行個體本身的連線追蹤上限，要看「超過雲端 PPS 上限」中提到的 conntrack_allowance_exceeded
確認方式: 用基礎設施工具確認（不需要遊戲程式碼）

出處

Netfilter Conntrack Sysfs variables Linux kernel
nf_conntrack_max 預設值等於雜湊 bucket 數（nf_conntrack_buckets），bucket 數由記憶體大小決定
net/netfilter/nf_conntrack_core.c (Linux v6.12) Linux kernel
預設大小在記憶體超過 1GB 時為 65,536，超過 4GB（64 位元）時為 262,144；表滿時會記錄「nf_conntrack: table full, dropping packet」並丟棄封包
iptables-extensions(8) — Linux manual page netfilter
以 raw 表的 CT --notrack 排除連線追蹤