업로드가 계속 실패? 일반적인 전송 오류 해결

업로드 실패는 거의 항상 다섯 가지 범주 중 하나에 해당합니다: 네트워크 불안정(Wi-Fi 끊김, ISP 경로 변경), 브라우저 메모리 부족(Chrome이 RAM 2GB에서 탭 종료), 서비스 측 속도 제한 또는 할당량 초과, 소스 파일 손상, 또는 안티바이러스/방화벽의 아웃바운드 요청 차단. 먼저 DevTools의 Network 탭에서 실패한 요청의 실제 HTTP 상태 코드를 확인하세요. 413은 "페이로드 너무 큼"입니다. 502 또는 503은 서비스 문제입니다. "ERR_CONNECTION_RESET"은 네트워크 문제입니다. 각각 다른 해결 방법이 있습니다.

실제 오류 코드를 읽으세요

대부분의 업로드 UI는 "업로드 실패"라고만 표시합니다. 이는 쓸모없는 정보입니다. 브라우저 DevTools(F12 또는 Cmd+Option+I)를 열고 Network 탭으로 전환한 뒤 실패한 요청을 확인하세요. 상태 코드가 문제의 위치를 알려줍니다: 400번대는 클라이언트 측 문제(413 너무 큼, 401 인증, 403 금지), 500번대는 서버 측 문제(502 불량 게이트웨이, 503 느린 응답, 504 타임아웃). ERR_CONNECTION_RESET이나 net::ERR_NETWORK_CHANGED 같은 연결 오류는 전송 도중 TCP 연결이 끊긴 것입니다.

아무것도 닫기 전에 실패한 요청과 응답 헤더를 스크린샷으로 저장하세요. 지원팀에 에스컬레이션할 경우 해당 헤더가 문제를 정확히 짚어줍니다.

Wi-Fi 끊김: 보이지 않는 적

노트북 Wi-Fi 칩은 때때로 액세스 포인트 간, 대역(2.4GHz와 5GHz) 간을 로밍합니다. 각 로밍은 TCP 연결을 순간적으로 끊어버리며, 단일 스트림 업로드는 죽어버립니다. 청크 기반 재개 업로드(tus.io 기반, S3 멀티파트)를 구현한 서비스는 이를 견디지만, 단일 POST 업로드는 그렇지 않습니다.

유선 Ethernet을 사용할 수 있다면 사용하세요. Ethernet은 로밍하지 않습니다. 유선을 사용할 수 없다면, 업로드 중에는 한 방에 있고 "자동 SSID 전환"이나 메시 밴드 스티어링을 비활성화하세요. 다른 터미널에서 1.1.1.1로 연속 ping을 실행하며 끊김을 확인하세요. 그 끊김 지점에서 업로드가 실패합니다.

브라우저 충돌 및 탭 강제 종료

Chrome은 탭이 메모리 임계값(일반적으로 탭당 2~4GB)을 초과하면 강제 종료합니다. 메모리에 파일 전체를 버퍼링하는 서비스(잘못된 구현)에서 10GB 파일을 업로드하면 충돌이 발생합니다. File API의 slice() 메서드로 청크를 스트리밍하는 서비스(올바른 구현)는 파일 크기에 관계없이 수백 MB의 RAM만 사용합니다.

대용량 업로드에서 브라우저가 계속 충돌한다면 Firefox를 시도해 보세요. Firefox는 역사적으로 대용량 File API 업로드를 Chromium보다 메모리 압력이 적게 처리합니다. 서비스가 청크 업로드를 사용하는지 확인하세요. 5GB 파일이 POST 전에 단일 Blob으로 로드되고 있다면 설계 문제입니다.

모든 다른 탭을 닫고, 업로드 시작 전에 브라우저를 재시작하세요. 확장 프로그램을 비활성화하세요(광고 차단기, 개인정보 보호 확장, 비밀번호 관리자는 업로드 스트림에 개입해 중단시킬 수 있습니다).

기업 방화벽 및 프록시

기업 네트워크는 종종 딥 패킷 검사, 트래픽 쉐이핑, 또는 인증서를 삽입하는 프록시 서버를 운용합니다. 증상: 소용량 파일은 업로드되지만 특정 크기(종종 100MB 또는 1GB)에서 실패하거나, "SSL handshake failed" 또는 "certificate verification failed" 오류가 발생합니다.

휴대폰 핫스팟(기업 네트워크 외부)에서 업로드해 보세요. 거기서 작동한다면 문제는 내부에 있습니다. 옵션: IT에 서비스 업로드 엔드포인트 허용 목록 추가 요청, VPN(허용된 경우)을 사용해 쉐이퍼 우회, 또는 개인 네트워크 사용.

Zscaler, Cisco Umbrella, Palo Alto 어플라이언스가 흔한 원인입니다. 이들은 특정 크기 이상의 파일을 검사하며 대용량 스트림에서 타임아웃이 발생하는 경우가 많습니다.

안티바이러스의 아웃바운드 스트림 스캔

Windows Defender, Bitdefender, Norton, Kaspersky는 TLS를 가로채어 아웃바운드 HTTPS 트래픽을 스캔할 수 있습니다. 대용량 업로드의 경우 스캔 자체가 처리량을 40~60% 감소시킬 수 있으며, 일부 버전에서는 연결을 끊는 타임아웃을 유발합니다.

실시간 웹 보호(전체 안티바이러스가 아닌 HTTPS 검사 구성 요소만)를 일시적으로 비활성화하고 재시도하세요. 업로드가 성공하면 전송 서비스 도메인을 AV 제외 목록에 추가하세요. 웹 보호를 영구적으로 비활성화하지는 마세요.

서비스 측 속도 제한

429 또는 503 응답을 받고 있다면 서비스가 속도를 제한하고 있는 것입니다. 가능한 이유: 병렬 청크가 너무 많음(8개에서 4개로 줄이기), 무료 티어 일일 할당량 초과(WeTransfer 무료는 전송당 2GB이지만 일일 볼륨 한도도 있음), 또는 공유 IP가 차단됨(호텔이나 카페 Wi-Fi에서 흔함).

15분 대기 후 재시도하세요. 또는 네트워크를 바꾸거나 서비스를 바꾸세요.

소스 파일 손상

드물게 파일 자체가 문제인 경우가 있습니다. 파일시스템 손상(외장 드라이브의 불량 섹터, 복사 중단)은 처음 몇 MB는 정상적으로 읽히지만 그 이후부터 I/O 오류를 반환하는 파일을 만들어냅니다. 업로드가 재시도할 때마다 일정 비율에서 멈춥니다.

먼저 파일을 다른 로컬 디스크에 복사해 보세요. 같은 비율에서 복사가 실패한다면 소스 문제입니다. Windows에서는 chkdsk, macOS에서는 diskutil verifyDisk로 소스 드라이브를 확인하세요. 중요한 파일이라면 다시 업로드하기 전에 알려진 정상 복사본에서 복구하세요.

VPN이 조용히 실패하는 경우

일부 VPN 클라이언트(특히 무료)는 세션 토큰이 5~10분마다 갱신되기 때문에 오래 지속된 TCP 연결을 끊습니다. 20분이 걸리는 2GB 업로드는 토큰 갱신 시 조용히 중단됩니다. 더 나은 세션 처리를 지원하는 유료 VPN(Mullvad, ProtonVPN, IVPN)으로 전환하거나, 서비스가 이미 TLS 엔드투엔드 암호화를 사용한다면 업로드 중 VPN을 연결 해제하세요.

엔드투엔드 암호화 서비스는 전송 중 기밀성을 위해 VPN이 필요하지 않습니다. 예를 들어, HexaTransfer는 파일이 브라우저를 떠나기 전에 클라이언트 측에서 AES-256-GCM으로 암호화하므로 VPN 암호화를 추가하는 것은 이중 안전장치이지 필수가 아닙니다.

청크 자동 재시도 서비스를 사용하세요

명백한 로컬 문제를 해결했음에도 업로드가 계속 실패한다면 서비스 자체가 중단을 잘 처리하지 못하는 것일 수 있습니다. 청크별 자동 재시도와 재개 가능한 세션 상태를 갖춘 서비스는 단일 스트림 업로더를 죽이는 종류의 끊김(Wi-Fi 로밍, 짧은 ISP 경로 변경)을 견뎌냅니다. HexaTransfer는 청크별 재시도가 있는 병렬 청크 업로드를 실행하며 수동 개입 없이 대부분의 짧은 네트워크 이벤트를 견딥니다.

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