[Cloud NAT][운영] custom TIME_WAIT override 제거 전후 추가 재사용 지연을 어떤 시간축으로 먼저 비교하나

IT 리서치 노트

[Cloud NAT][운영] custom TIME_WAIT override 제거 전후 추가 재사용 지연을 어떤 시간축으로 먼저 비교하나

Cloud NAT에서 custom TCP TIME_WAIT override를 지운 뒤 포트 재사용이 언제부터 실제로 빨라지는지 헷갈리는 경우가 많다. 2026년 7월 20일 기준 Google Cloud 공식 문서를 다시 보면 2026년 rollout 기간에는 gateway 기본값 자체가 region과 생성 시점에 따라 다를 수 있고, TIME_WAIT 값과 별도로 tuple 재사용까지 최대 30초 추가 지연이 더 붙을 수 있다. 이 글은 custom override 제거 전후를 어떤 시간축으로 비교해야 운영 판단이 덜 꼬이는지 정리한 것이다.

목차

1. 개요
2. 어디서 실제로 막히는가
3. 실무에서 적용하는 순서
4. 공식 문서와 예시 화면으로 확인하기
5. 주의사항과 리스크
6. 결론
7. 참고 링크

1. 개요

결론부터 말하면 custom TIME_WAIT override를 지운 뒤에는 TIME_WAIT 값과 실제 tuple 재사용 회복 시점을 따로 기록해야 한다. Google Cloud는 TIME_WAIT timeout과 별도로 최대 30초의 추가 재사용 지연이 있을 수 있다고 설명하므로, override를 default로 돌렸다고 해서 곧바로 같은 폭으로 포트 회복 시간이 줄어들지는 않는다.

또 2026년 7월 20일 현재는 rollout 구간이라 gateway 기본값 자체가 120초 또는 30초일 수 있다. 따라서 override 제거 전후 비교는 gateway 생성 시점, regional rollout 상태, current drops 또는 port exhaustion 신호를 같이 붙여야 의미가 있다.

2. 어디서 실제로 막히는가

현장에서 흔한 실수는 세 가지다. 첫째, custom TIME_WAIT을 지우면 모든 gateway가 바로 30초 기본값으로 내려갈 것이라고 본다. 둘째, TIME_WAIT 값을 낮췄으니 port reuse 회복도 정확히 같은 폭으로 빨라질 것이라고 기대한다. 셋째, packet drops와 port usage를 안 보고 timeout 값만 비교한다.

하지만 release notes는 2026년 6월 30일부터 9월 29일까지 새 gateway만 region별 배포 시점에 따라 120초 또는 30초 기본값을 쓸 수 있다고 말한다. 기존 gateway는 120초 기본값을 유지할 수 있고, custom TIME_WAIT 값을 가진 gateway는 이 rollout의 직접 영향을 받지 않는다.

• 증상: override를 지웠는데 port exhaustion 완화 시점이 기대보다 늦다.
• 실패: gateway 기본값과 configured override를 같은 값으로 취급한다.
• 막힘: TIME_WAIT 값만 보고 추가 30초 재사용 지연을 빼먹는다.
• 누락: reset 시각과 packet drop 회복 시각을 같은 로그에 남기지 않는다.

질문	먼저 볼 것	이유
default가 무엇인가	gateway 생성 시점과 rollout 상태	existing와 new gateway가 다를 수 있다
실제 reuse가 언제 빨라지나	TIME_WAIT + 추가 30초 지연	설정값과 관측값이 일치하지 않을 수 있다
운영상 도움이 됐는가	port usage, packet drops, recovery timestamp	증상 개선 여부를 timeout 외 지표로 확인해야 한다

3. 실무에서 적용하는 순서

실무 비교는 다섯 단계면 충분하다. 먼저 gateway가 new인지 existing인지, rollout 구간인지 적는다. 두 번째로 현재 configured TIME_WAIT 값과 reset 시각을 남긴다. 세 번째로 reset 뒤 tuple 재사용 회복 시점을 packet drop 또는 port usage와 함께 기록한다. 네 번째로 최대 30초 추가 지연을 감안해 기대 회복 시각을 계산한다. 마지막으로 dynamic port allocation 사용 여부와 min ports 설정도 같이 적어 둔다.

1. gateway 세대와 rollout 상태를 먼저 적는다.
2. configured TIME_WAIT 값과 reset 시각을 기록한다.
3. packet drops, port usage, first recovery 시각을 저장한다.
4. TIME_WAIT와 추가 30초 지연을 합쳐 기대 회복 범위를 잡는다.
5. dynamic port allocation과 min/max ports 상태를 함께 남긴다.

• Cloud NAT 페이지를 연다.
• 해당 gateway를 클릭한다.
• Advanced configurations를 열고 TIME_WAIT 값을 확인하거나 지운다.
• Save 또는 --clear-tcp-time-wait-timeout 실행 직후 시각을 적는다.
• Monitoring에서 port usage와 packet drops를 같은 축에 비교한다.

핵심은 설정값 하나만 보지 않는 것이다. 튜닝 문서는 timeout 값을 줄이면 포트 재사용이 빨라질 수 있다고 설명하면서도, 별도 추가 지연이 있을 수 있다고 명시한다. 따라서 운영판정은 설정이 적용됐는가와 실제 증상이 줄었는가를 따로 읽어야 한다.

gateway_type=existing
regional_rollout_window=true
configured_time_wait_before=120
configured_time_wait_after=default
expected_reuse_window_seconds=default_time_wait + up_to_30
packet_drop_reason=out_of_resources
first_recovery_seen_at=2026-07-20T20:40+09:00

이미 gateway generation과 TIME_WAIT rollout governance 글이 세대 차이를 정리했다면, 이번 글은 그 위에 custom override reset 사건을 올려서 실제 회복 시점을 비교하는 후속편이라고 보면 된다.

4. 공식 문서와 예시 화면으로 확인하기

첫 화면은 2026년 rollout 조건이다. Google Cloud는 Cloud NAT의 기본 TCP TIME_WAIT timeout이 120초에서 30초로 내려가는 일정을 공지했고, 새 gateway와 기존 gateway, custom value 적용 gateway를 서로 다르게 취급한다고 적고 있다.

Cloud NAT release notes는 2026년 TIME_WAIT 기본값 변경 일정과 custom 값 예외를 설명한다.

즉 override를 지우기 전후 비교에서는 먼저 이 gateway가 어떤 기본값 구간에 속하는지 적어야 한다. 기본값이 여전히 120초인 기존 gateway인데 30초처럼 기대하면 시간축이 처음부터 틀어진다.

두 번째 자료는 TIME_WAIT 자체보다 더 중요한 문장이다. Google Cloud 문서는 TIME_WAIT 값을 어떻게 설정하든, source IP와 source port tuple 재사용까지는 추가로 최대 30초가 더 걸릴 수 있다고 적고 있다.

Tune NAT configuration 문서는 TIME_WAIT 값과 별도로 최대 30초의 추가 재사용 지연이 있을 수 있다고 설명한다.

그래서 override를 120초에서 30초로 줄였는데 재사용이 바로 90초 짧아지지 않는다고 해서 곧바로 설정 실패로 보면 안 된다. 비교 기준을 TIME_WAIT 값과 추가 재사용 지연으로 나눠 봐야 한다.

세 번째 자료는 실제 증상 쪽 근거다. troubleshooting 문서는 port exhaustion이 보일 때 five-tuple이 TIME_WAIT 동안 재사용되지 못한다는 점을 직접 짚는다.

Cloud NAT troubleshooting 문서는 port exhaustion과 TIME_WAIT 재사용 제한을 연결해 설명한다.

즉 override 제거 전후 비교는 단순 설정 diff가 아니라 실제 port exhaustion 신호와 연결돼야 한다. packet drops나 port usage가 비슷한데 재사용 회복 시점만 달라지는지 같이 봐야 운영 판단이 맞는다.

override 제거 전후에는 시간축을 네 칸으로 나누는 표가 필요하다. gateway 기본값, configured TIME_WAIT, 추가 재사용 지연, packet drop 시각을 한 줄에 붙여야 기대값이 맞는다.

TIME_WAIT override 제거 전후를 기본값과 추가 재사용 지연까지 포함해 비교하는 표다.

이미 mixed gateway와 TCP TIME_WAIT 30초 rollout 글이 rollout 구간 비교를 다뤘다면, 이번 표는 custom override를 지우는 순간을 그 시간축 안에 끼워 넣는 운영판이다.

마지막 자료는 reset 예시와 로그 포맷이다. override 제거는 단순 UI 클릭이 아니라 어떤 값을 지웠고 어느 시각부터 기본값으로 돌아갔는지를 남겨야 다음 packet drop과 비교가 가능하다.

TIME_WAIT override reset과 비교 로그를 함께 남기는 예시다.

이 메모가 있으면 설정 reset과 실제 port reuse 개선 사이의 시차를 계산하기 쉬워진다. 또 TIME_WAIT rollout governance 글과도 직접 이어진다.

5. 주의사항과 리스크

첫 번째 리스크는 custom override를 지운 뒤 gateway default가 무조건 30초라고 단정하는 것이다. 두 번째는 TIME_WAIT 값과 tuple reuse 회복 사이의 추가 지연을 무시하는 것이다. 세 번째는 packet drop 이유가 진짜 TIME_WAIT인지, min ports나 endpoint-independent mapping 같은 다른 원인인지 분리하지 않는 것이다.

운영 문서에는 gateway 생성 시점, rollout 상태, configured timeout, reset 시각, first recovery 시각을 한 줄로 남기는 편이 좋다. 그래야 mixed gateway 비교 글과 이번 reset 글을 같은 타임라인에서 합칠 수 있다.

6. 결론

Cloud NAT custom TIME_WAIT override 제거 전후 비교의 핵심은 설정값이 아니라 시간축이다. gateway 기본값, configured TIME_WAIT, 최대 30초 추가 재사용 지연, packet drop 회복 시각을 같은 표로 놓아야 실제 개선 여부를 올바르게 읽을 수 있다.

같은 가지의 선행 글로는 gateway generation과 rollout governance 글, mixed gateway TIME_WAIT 30초 비교 글을 같이 보면 좋다.

그런데 mixed gateway와 TIME_WAIT 축까지 봤는데도 port_usage가 비슷해 설명이 막힌다면 destination fan-out persistence를 어떤 표로 남길지 정리한 후속 글로 넘어가는 편이 빠르다. 새 글은 destination 3-tuple 집중도와 shared source tuple 흔적을 같은 표에 묶어 남기는 분기다.

7. 참고 링크

1. https://docs.cloud.google.com/nat/docs/release-notes
2. https://docs.cloud.google.com/nat/docs/tune-nat-configuration
3. https://docs.cloud.google.com/nat/docs/troubleshooting