부하가 몰리면 connect: cannot assign requested address 같은 에러가 뜨고, ss로 보면 TIME_WAIT 소켓이 수만 개 쌓여 있습니다. TIME_WAIT는 TCP가 연결을 깔끔하게 닫기 위한 정상 상태지만, **연결을 능동으로 닫는 쪽(주로 클라이언트나 프록시)**에 과하게 쌓이면 로컬 포트가 고갈돼 새 연결을 못 맺습니다.
진단 — 얼마나 쌓였나
상태별 소켓 개수를 셉니다.
ss -tan state time-wait | wc -l # TIME_WAIT 소켓 개수
ss -s # 상태별 요약
TCP: 52310 (estab 210, closed 51800, timewait 51020/0), ports 0
timewait이 수만 단위이고 ip_local_port_range로 잡힌 가용 포트(보통 약 28000개)에 근접하면 포트 고갈 구간입니다. 가용 포트 범위도 확인합니다.
cat /proc/sys/net/ipv4/ip_local_port_range
개념 — 왜 생기고 누구에게 쌓이나
TIME_WAIT는 연결을 먼저 닫은 쪽에서 약 60초(2*MSL) 유지됩니다. 지연 도착한 패킷이 다음 연결을 오염시키는 걸 막는 안전장치라 함부로 없애면 안 됩니다. 핵심은 누가 먼저 닫느냐입니다. 서버가 Connection: close로 매 요청 후 끊으면 TIME_WAIT는 클라이언트가 아니라 서버 쪽에 쌓입니다.
| 패턴 | TIME_WAIT 누적 위치 | 1순위 대처 |
|---|---|---|
| 매 요청마다 새 연결(단명 커넥션) | 능동으로 닫는 쪽 | keep-alive·커넥션 풀 |
| 백엔드로 짧은 연결 폭주(프록시) | 프록시 | 업스트림 keep-alive |
| 동일 목적지로 대량 아웃바운드 | 발신 서버 | tcp_tw_reuse |
대처 — 근본부터, 커널은 보조
1. 애플리케이션: 연결 재사용이 정답
가장 확실한 해결은 연결을 재사용하는 것입니다. HTTP keep-alive를 켜고 커넥션 풀을 쓰면 매 요청마다 새 소켓을 만들고 닫지 않으므로 TIME_WAIT 자체가 거의 생기지 않습니다. nginx 업스트림이라면 keepalive 지시자를 추가합니다.
2. 커널 튜닝 (발신 측에 한해)
같은 목적지로 나가는 아웃바운드가 많아도 tcp_tw_reuse는 마지막 수단입니다. 현재 Linux 문서에서 값은 0(끔), 1(전역), 2(loopback만)이며 기본값도 커널 버전·배포판에 따라 다를 수 있습니다. 커널 문서는 전문가 검토 없이 바꾸지 말라고 경고합니다.
sysctl net.ipv4.tcp_tw_reuse # 현재 값과 커널 문서를 먼저 확인
sysctl net.ipv4.ip_local_port_range # 현재 임시 포트 범위 확인
# 변경이 필요하면 테스트 환경에서 부하·NAT·지연 패킷 영향을 검증하고
# 변경 승인과 되돌릴 기존 값을 기록한 뒤 단계적으로 적용합니다.
tcp_tw_reuse는 TIME_WAIT 재사용 조건과 범위가 커널 버전에 따라 달라집니다. 단순히 TIME_WAIT 개수가 많다는 이유로 1을 적용하지 말고, 연결 재사용과 포트 범위를 먼저 개선하세요. tcp_tw_recycle은 NAT 뒤 연결을 깨뜨려 오래전 커널에서 제거된 옵션이므로 사용하면 안 됩니다.
체크리스트
ss -tan state time-wait | wc -l # 규모 확인
ss -s # 상태 분포
cat /proc/sys/net/ipv4/ip_local_port_range # 가용 포트
# 1순위: keep-alive·커넥션 풀 적용
# 커널 값 변경은 공식 문서·부하 시험·롤백 계획을 갖춘 뒤에만 검토
TIME_WAIT는 "줄이는" 문제가 아니라 "연결을 재사용해서 안 만드는" 문제입니다.
TCP 상태 머신과 소켓 진단을 직접 패킷 단위로 따라가 보고 싶다면 회원가입 없이 무료로 네트워크 트랙에서 익힐 수 있습니다.