한국어 English 日本語简体中文繁體中文 Deutsch ไทย Tiếng Việt Русский Português (Brasil)Español Bahasa Indonesia

서버 conntrack 테이블 포화 conntrack table full

원인 ID so-conntrack · 주 담당 인프라팀·서버 인프라 · 함께 게임개발팀·서버 개발, 게임개발팀·클라이언트 개발

그림과 실험이 있는 원본 카드로 열기 →

리눅스 방화벽이 모든 연결을 기록하는 연결 추적(conntrack) 테이블이 한도에 닿으면 새 패킷을 버립니다.

왜 접속 폭주, 짧은 연결 반복으로 연결 기록 증가 → 그러면 테이블이 가득 차 새 연결과 일부 패킷 폐기 → 화면에서는 접속 불가, 원인 모를 손실로 순간이동

증상: 접속 불가·무한 로딩, 순간이동
요인: 손실
누가 겪나: 서버 전체
언제: 접속·점검 직후, 사람이 몰릴 때
담당: 주 담당 인프라팀·서버 인프라 · 함께 게임개발팀·서버 개발, 게임개발팀·클라이언트 개발
게임개발팀 할 일: 서버: 짧은 연결 줄이기(서버 간 호출은 연결 재사용). 클라이언트: 접속이 실패하거나 끊기면 재시도 간격을 늘려 가며 무작위로 분산.
인프라팀 할 일: 테이블 크기(nf_conntrack_max) 늘리기, 게임 포트는 추적 제외(raw 테이블의 NOTRACK), 사용량 경보.
수치 감각: 기본 한도는 서버 메모리에 따라 약 6만~26만 개입니다. 넘치면 커널 로그에 “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에서 평평해지고 그 시각부터 커널 로그에 table full이 찍힘
이러면 아님: 항목 수가 max에 한참 못 미치면 이 원인이 아님. AWS 인스턴스 자체의 연결 추적 한도는 “클라우드 PPS 한도 초과”의 conntrack_allowance_exceeded로 봄
확인 수단: 인프라 도구로 확인(게임 코드 불필요)

출처

Netfilter Conntrack Sysfs variables Linux kernel
nf_conntrack_max 기본값은 해시 버킷 수(nf_conntrack_buckets)와 같고, 버킷 수는 메모리 크기로 정해짐
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으로 연결 추적 제외

서버 conntrack 테이블 포화 conntrack table full

출처

함께 보면 좋은 원인

같은 층: L7 서버 OS (커널)

같은 증상(접속 불가·무한 로딩)의 다른 층 원인