[Cloud NAT][운영] 새 Cloud NAT gateway의 TCP TIME_WAIT 기본값이 30초로 바뀌는 롤아웃 구간에서 무엇부터 점검하나

IT 리서치 노트

[Cloud NAT][운영] 새 Cloud NAT gateway의 TCP TIME_WAIT 기본값이 30초로 바뀌는 롤아웃 구간에서 무엇부터 점검하나

Cloud NAT 운영을 오래 했더라도 2026년 7월에는 한 가지를 새로 기억해야 한다. Google Cloud release notes는 2026년 3월 31일에 기본 TCP TIME_WAIT timeout이 120초에서 30초로 내려갈 예정이라고 공지했고, 6월 30일부터 9월 29일까지는 새 gateway 기본값이 지역 롤아웃 시점에 따라 120초일 수도 30초일 수도 있다고 설명한다. 이 글은 바로 이 롤아웃 구간에서 무엇부터 기록하고 점검해야 하는지 정리한 것이다.

목차

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

1. 개요

결론부터 말하면 이번 구간에서는 min ports, max ports, dynamic allocation부터 만지기 전에 새 Cloud NAT gateway가 언제 어떤 지역에서 만들어졌는지부터 확인해야 한다. 2026년 6월 30일부터 9월 29일까지는 지역별 롤아웃 때문에 새 gateway 기본 TIME_WAIT 값이 다를 수 있기 때문이다.

그다음은 port reuse 지연과 추가 30초 경고를 같이 읽는 일이다. TIME_WAIT를 30초로 이해했더라도 실제 재사용 체감은 앱 burst와 Cloud NAT의 추가 지연 메모까지 봐야 맞는다.

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

실무에서 흔한 실패는 세 가지다. 첫째, 새로 만든 gateway도 과거 gateway와 같은 기본값일 것이라고 본다. 둘째, TIME_WAIT 수치만 보고 실제 재사용 체감도 곧바로 줄어들 것이라 예상한다. 셋째, 앱 connection pattern과 destination fan-out을 기록하지 않은 채 NAT 설정만 원인으로 좁힌다.

Google Cloud 문서는 새 gateway 기본값 롤아웃 구간을 명시하고 있고, ports and addresses 문서는 TCP source port reuse 지연이 TIME_WAIT에 의해 제어된다고 설명한다. 또 tune NAT configuration 문서는 설정값과 별개로 추가 30초가 더 필요할 수 있다고 경고한다. 이 세 문서를 같이 읽어야 한다.

• 증상: 같은 템플릿인데 새 gateway의 포트 회복 감각이 다르다.
• 실패: 생성 시점과 지역을 운영 메모에 남기지 않는다.
• 막힘: TIME_WAIT 숫자만 보고 추가 재사용 지연을 잊는다.
• 누락: 앱 burst, destination fan-out, connection reuse 패턴을 같이 안 본다.

상황	먼저 확인할 것	이유
새 gateway를 오늘 생성했다	생성 날짜와 지역	롤아웃 기본값 차이가 있다
포트 압박은 줄었는데 회복 체감이 애매하다	추가 30초 경고	설정값만으로 즉시 재사용되지 않을 수 있다
Cloud Run burst가 잦다	앱 burst와 destination fan-out	체감은 앱 연결 패턴에 크게 좌우된다

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

실무 순서는 다섯 단계가 가장 안전하다. 먼저 gateway 생성 날짜와 region을 남긴다. 두 번째로 TIME_WAIT를 수동 override했는지 확인한다. 세 번째로 port reuse 지연과 추가 30초 메모를 함께 읽는다. 네 번째로 앱 burst와 destination fan-out을 기록한다. 마지막으로 그 뒤에야 min/max ports나 dynamic allocation을 손본다. 운영 표와 로그를 같은 화면에 두고 상태를 비교하면 생성 시점 차이와 설정 차이를 더 빨리 분리할 수 있다.

1. gateway 생성 날짜와 region을 메모한다.
2. TIME_WAIT override 여부를 확인한다.
3. 포트 재사용 지연과 추가 30초 메모를 같이 읽는다.
4. 앱 burst와 destination fan-out을 로그에 남긴다.
5. 그다음에 min/max ports와 dynamic allocation을 조정한다.

nat rollout memo

created_at=2026-07-16
region=us-west1
tcp_time_wait_override=unset
port_reuse_delay_checked=true
additional_delay_note_checked=true
burst_window=30s
fanout=high

핵심은 이번 변화가 설정값 하나의 문제가 아니라 운영 기준점의 문제라는 점이다. 새 gateway 생성 시점과 앱 연결 패턴을 남기지 않으면 다음 관찰이 왜 달라졌는지 설명할 수 없다.

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

첫 자료는 Cloud NAT release notes의 2026년 3월 31일 공지다. 이번 이슈는 일반론이 아니라 실제 기본값 롤아웃 일정이 이미 문서에 올라와 있다는 점이 중요하다.

Cloud NAT release notes는 2026년 3월 31일에 기본 TCP TIME_WAIT timeout이 120초에서 30초로 내려갈 예정이라고 공지했다.

즉 새 gateway의 포트 재사용 감각이 과거와 다를 수 있다는 뜻이다. 특히 운영팀이 기존 경험치만 믿고 새 환경을 만들면 초기 추론이 틀어질 수 있다.

두 번째 자료는 롤아웃 구간 설명이다. 2026년 6월 30일부터 9월 29일까지는 지역 배포 시점에 따라 새 gateway 기본값이 120초일 수도 있고 30초일 수도 있다.

Google Cloud는 2026년 6월 30일~9월 29일 사이 새 Cloud NAT gateway의 기본 TIME_WAIT 값이 지역별 롤아웃에 따라 달라질 수 있다고 설명한다.

이 구간에서는 같은 템플릿으로 gateway를 다시 만들어도 결과가 같다고 가정하면 안 된다. 날짜와 지역을 운영 메모에 반드시 남겨야 한다.

세 번째 자료는 ports and addresses 문서의 port reuse 설명이다. TIME_WAIT는 단순 설정값이 아니라 같은 source IP와 port tuple 재사용 지연과 직접 연결된다.

Cloud NAT 문서는 TCP source port reuse 지연이 TIME_WAIT timeout 설정에 의해 제어된다고 설명한다.

따라서 새 기본값 변화는 포트 압박, 짧은 burst 후 회복 속도, destination fan-out 관찰 방식까지 함께 바꿀 수 있다. 설정 문구만 읽고 끝낼 문제가 아니다.

네 번째 자료는 tune NAT configuration 문서의 추가 지연 경고다. TIME_WAIT를 줄였더라도 실제 재사용에는 추가 30초가 더 걸릴 수 있다.

Cloud NAT 문서는 TIME_WAIT 값을 낮춰도 새 연결 처리 전 추가 30초가 더 필요할 수 있다고 경고한다.

즉 30초 기본값이라는 한 줄만 보고 포트 재사용이 즉시 반영된다고 기대하면 안 된다. dynamic port allocation과 합쳐 보면 여전히 시간축 기록이 중요하다.

실무에서는 새 gateway와 기존 gateway를 따로 기록해야 한다. 이번 변화는 설정 오차보다 생성 시점 차이에서 먼저 갈리는 경우가 생기기 때문이다.

TIME_WAIT 기본값 롤아웃 구간에서 운영팀이 먼저 기록해야 할 체크포인트를 정리한 표다.

이미 connection reuse와 앱 동시성 글과 destination fan-out 로그 글을 읽었다면, 이번 표는 그 앞단의 gateway 생성 시점 차이를 운영 메모에 묶는 역할을 한다.

마지막 자료는 운영 메모 예시다. 생성 시점, 지역, timeout override, port 사용 관찰을 같이 남겨야 나중에 증상이 왜 달랐는지 설명할 수 있다.

새 Cloud NAT gateway 생성 시점과 TIME_WAIT 관련 메모를 같이 남기는 운영 예시다.

이렇게 기록해 두면 min/max ports 조정 글과 burst 시간축 비교 글로 자연스럽게 이어 붙일 수 있다.

5. 주의사항과 리스크

가장 큰 리스크는 롤아웃 구간인데도 기본값이 모두 동일하다고 가정하는 것이다. 그러면 새 gateway와 기존 gateway 차이를 앱 코드 변화로 오해하기 쉽다.

또 TIME_WAIT가 30초라는 한 줄만 보고 재사용이 바로 빨라질 것이라고 기대하는 것도 위험하다. Cloud NAT 문서는 추가 지연 가능성을 따로 적고 있고, dynamic port allocation 사용 시 최소 15초 이상을 권장한다.

• 주의: 2026년 6월 30일~9월 29일 새 gateway 기본값은 지역별로 다를 수 있다.
• 주의: TIME_WAIT 값을 낮춰도 추가 재사용 지연이 남을 수 있다.
• 주의: NAT 설정보다 먼저 앱 burst와 destination fan-out 기록이 필요하다.

6. 결론

새 Cloud NAT gateway의 기본 TIME_WAIT가 30초로 내려가는 롤아웃 구간에서는 생성 날짜와 지역, override 여부, 포트 재사용 지연 메모를 먼저 확인하는 편이 맞다. 그 뒤에야 port 수나 dynamic allocation을 조정해야 증상과 원인을 덜 섞는다.

운영 중에 새 gateway와 기존 gateway가 함께 남아 있어 기본 TIME_WAIT 기대값이 더 헷갈린다면 후속 글인 mixed gateway 비교 글로 이어서 생성 시점과 override, port_usage를 같은 창에서 비교하는 순서를 보는 편이 낫다.

관련 흐름으로는 connection reuse와 앱 동시성 글, destination fan-out 로그 글, min/max ports 조정 글, burst 시간축 비교 글을 같이 보면 설정 변경과 관찰 기준이 한 줄로 이어진다.

7. 참고 링크

1. https://docs.cloud.google.com/nat/docs/release-notes
2. https://docs.cloud.google.com/nat/docs/ports-and-addresses
3. https://docs.cloud.google.com/nat/docs/tune-nat-configuration
4. https://docs.cloud.google.com/run/docs/configuring/vpc-direct-vpc