파일 전송 타임아웃 오류: 원인과 해결 가이드

파일 전송 중 타임아웃 오류는 네 가지 곳 중 하나에서 발생합니다: 클라이언트의 HTTP 요청이 서버 응답을 너무 오래 기다렸거나(일반적으로 30~120초), 서버가 클라이언트의 데이터 전송을 너무 오래 기다렸거나(느린 업로드에서 흔함), 중간 프록시나 로드 밸런서가 연결을 끊었거나(AWS ALB 기본값 60초), 또는 OS가 유휴 TCP 연결을 종료한 경우. 504 Gateway Timeout은 로드 밸런서가 오리진에 도달하지 못한 것입니다. 408 Request Timeout은 서버가 데이터를 기다리다 포기한 것입니다. ERR_CONNECTION_TIMED_OUT은 TCP 핸드셰이크가 완료되지 않은 것입니다. 각각 다른 해결책이 있습니다.

오류에서 타임아웃 유형을 읽으세요

타임아웃마다 다른 해결책이 필요합니다:

504 Gateway Timeout: 중간 프록시나 로드 밸런서가 타임아웃됨. 서비스 측 문제, 보통 일시적. 재시도 또는 지역 변경.
408 Request Timeout: 서버가 클라이언트 데이터를 기다리다 포기함. 업로드가 요청 중간에 멈춘 것.
524(Cloudflare): 오리진이 100초 내에 응답하지 않음. 서비스 측.
502 Bad Gateway: 프록시가 오리진으로부터 잘못된 응답을 받음. 서비스 장애 또는 배포 중.
ERR_CONNECTION_TIMED_OUT: 서버로의 TCP 연결이 완료되지 않음. 네트워크 또는 방화벽.
ERR_NETWORK_CHANGED: 연결 중간에 네트워크가 전환됨. Wi-Fi 로밍 또는 VPN 끊김.

DevTools의 Network 탭에서 정확한 응답, 타이밍, 상태 코드가 표시됩니다. 아무것도 닫기 전에 스크린샷을 저장하세요.

Wi-Fi 로밍이 장기 업로드를 죽입니다

노트북 Wi-Fi 칩은 자동으로 대역과 액세스 포인트 사이를 전환합니다. 각 전환은 현재 TCP 연결을 끊습니다. 단일 스트림 업로드는 즉시 죽고, 청크 업로드는 서비스가 청크별로 재시도한다면 살아납니다.

해결책: 2GB 이상 업로드에는 Ethernet으로 유선 연결하세요. 유선을 사용할 수 없다면, 라우터에서 밴드 스티어링을 비활성화하고(노트북 SSID를 "5GHz만"으로 전환) 한 방에 머무세요. macOS에서는 기본 SSID 외의 모든 SSID에서 "자동 연결"을 끄세요.

서비스 측 로드 밸런서 타임아웃

AWS Application Load Balancer는 유휴 타임아웃 기본값이 60초입니다. Nginx는 proxy_read_timeout이 기본 60초입니다. 이를 제대로 조정하지 않은 서비스는 잠깐 멈추는 업로드(암호화, 소스의 느린 디스크 읽기)를 60초 지점에서 끊습니다.

특정 서비스에서 504 타임아웃이 발생한다면 보통 그들의 로드 밸런서가 잘못 구성된 것입니다. 클라이언트 측에서 할 수 있는 것은 재시도 외에 없습니다. 청크 업로더는 실패한 청크를 재시도하여 이를 투명하게 처리하고, 단일 스트림 업로더는 완전히 실패하여 처음부터 다시 시작해야 합니다.

기업 프록시 타임아웃

Zscaler, Blue Coat, Palo Alto, 기타 기업 프록시는 자체 타임아웃을 적용합니다. 일반적으로 30초~5분의 유휴 상태. 업로드가 프록시가 유휴로 인식하는 작업(암호화 일시 정지, 청크 재시도 지연)을 수행하면 프록시가 연결을 끊습니다.

기업 네트워크 외부(휴대폰 핫스팟)에서 업로드하여 진단하세요. 타임아웃이 사라진다면 프록시가 원인입니다. IT에 전송 서비스 도메인을 허용 목록에 추가하고 해당 도메인에 대한 검사를 우회하도록 요청하세요. 대안은 개인 네트워크 또는 VPN 터널 홈.

OS 수준 TCP keepalive

Linux는 기본적으로 2시간의 유휴 후에만 TCP keepalive 패킷을 보내는데, 파일 전송에는 쓸모없습니다. macOS와 Windows도 유사한 기본값을 가집니다. 불안정한 네트워크에서 매우 긴 업로드의 경우, 일부 서비스는 WebSocket ping 프레임이나 주기적 빈 청크를 통해 애플리케이션 수준 keepalive를 구현합니다. 서비스가 이를 하지 않는다면, NAT 방화벽을 통한 긴 업로드(대부분의 가정용 라우터에서 기본 5분 UDP 세션 타임아웃)는 NAT 항목이 만료될 때 끊어질 수 있습니다.

VPN 세션 토큰 갱신

일부 VPN 클라이언트는 5~15분마다 세션 토큰을 갱신합니다. 버그가 있는 클라이언트에서 갱신은 기본 TCP 터널을 0.5초 동안 끊습니다. 긴 업로드는 그 순간에 죽습니다.

유료 VPN(Mullvad, ProtonVPN Plus, IVPN)은 이를 깔끔하게 처리합니다. 무료 VPN은 대부분 그렇지 않습니다. 10분 지점에서 일관된 타임아웃이 발생한다면 VPN 갱신을 의심하세요. 전송 서비스가 이미 TLS 1.3 엔드투엔드 암호화를 사용한다면 업로드 중 VPN을 끊으세요.

셀룰러 핸드오프

셀룰러 데이터는 이동 시 셀을 전환합니다. 각 핸드오프는 (a) 이동성 관리를 통해 IP를 유지하거나(투명), (b) 새 IP를 할당합니다(연결 끊김). LTE에서 대부분의 핸드오프는 투명합니다. 5G, 특히 mmWave에서 sub-6 또는 LTE 폴백으로의 핸드오프는 IP를 바꾸고 연결을 끊을 수 있습니다.

이동 중인 차량에서 셀룰러로 업로드한다면 끊김을 예상하세요. 청크-재개 가능 업로더는 이를 잘 처리하고, 단일 스트림 업로더는 그렇지 않습니다.

WAF 타임아웃

서비스가 WAF(Cloudflare WAF, AWS WAF, ModSecurity) 뒤에 있다면 WAF가 장기 업로드를 의심스럽게 여기고 끊을 수 있습니다. 증상: 소용량에서는 업로드가 성공하지만 특정 임계값(WAF 구성에 따라 종종 1GB 또는 10GB)에서 실패하며 403 또는 502 응답이 옵니다.

클라이언트 측에서 고칠 수 있는 것이 없습니다. 서비스에 보고하세요. 잘 조정된 WAF는 청크 업로드를 플래그 없이 허용합니다.

재시도 로직과 지수 백오프

잘 구축된 전송 클라이언트는 지수 백오프로 실패한 청크를 재시도합니다: 1초, 그다음 2초, 4초, 8초. 짧은 네트워크 중단은 투명하게 복구됩니다. 재시도 로직이 없는 클라이언트는 첫 오류에서 실패합니다.

자동 재시도가 없는 서비스를 사용하고 있다면 타임아웃으로 인한 실패가 더 많이 발생합니다. 재시도를 처리해 주는 클라이언트나 서비스를 선택하세요.

청크 재시도가 있는 서비스를 선택하세요

불안정한 네트워크에서 대용량 파일의 경우, 청크별 재시도, 재개 가능한 세션 상태, 공격적이지 않은 서버 측 타임아웃이 있는 서비스가 필요합니다. HexaTransfer는 청크별 재시도와 클라이언트 측 AES-256-GCM 암호화로 병렬 청크 업로드를 실행하므로, 불안정한 연결에서 10GB 업로드는 단일 네트워크 중단으로 전체 전송을 실패시키지 않고 영향받은 청크만 재시도합니다.

hexatransfer.com에서 사용해 보세요 — 무료, 계정 불필요, 최대 10GB.