Błędy timeout transferu plików: przyczyny i rozwiązania

Błędy timeout podczas transferu plików mają jedno z czterech źródeł: żądanie HTTP klienta czekało zbyt długo na odpowiedź serwera (zwykle 30–120 sekund), serwer zbyt długo czekał na dane od klienta (częste przy wolnych przesyłaniach), pośredni serwer proxy lub load balancer przerwał połączenie (AWS ALB domyślnie 60 sekund), albo system operacyjny zakończył bezczynne połączenie TCP. Kod 504 Gateway Timeout oznacza, że load balancer nie mógł dotrzeć do serwera źródłowego. Kod 408 Request Timeout oznacza, że serwer przestał czekać na Twoje dane. ERR_CONNECTION_TIMED_OUT oznacza, że uzgadnianie TCP nigdy się nie zakończyło. Każdy z tych błędów wymaga innego podejścia.

Odczytaj typ timeoutu z komunikatu błędu

Różne timeouty wymagają różnych metod naprawy:

• 504 Gateway Timeout: Timeout pośredniego serwera proxy lub load balancera. Problem po stronie usługi, zwykle przejściowy. Ponów próbę lub zmień region.
• 408 Request Timeout: Serwer przestał czekać na dane od klienta. Przesyłanie zatrzymało się w połowie żądania.
• 524 (Cloudflare): Serwer źródłowy nie odpowiedział w ciągu 100 sekund. Problem po stronie usługi.
• 502 Bad Gateway: Serwer proxy otrzymał nieprawidłową odpowiedź od serwera źródłowego. Awaria usługi lub trwające wdrożenie.
• ERR_CONNECTION_TIMED_OUT: Połączenie TCP do serwera nigdy się nie nawiązało. Problem sieciowy lub zapora.
• ERR_NETWORK_CHANGED: Sieć zmieniła się podczas połączenia. Roaming Wi-Fi lub rozłączenie VPN.

Zakładka Network w DevTools pokazuje dokładną odpowiedź, czas i kod statusu. Zrób zrzut ekranu, zanim cokolwiek zamkniesz.

Roaming Wi-Fi przerywa długie przesyłania

Karty Wi-Fi w laptopach automatycznie przełączają się między pasmami i punktami dostępu. Każde takie przełączenie zrywa bieżące połączenie TCP. Przesyłanie jednopotokowe natychmiast się kończy; przesyłanie podzielone na fragmenty przeżywa, jeśli usługa ponawia próbę dla każdego fragmentu osobno.

Rozwiązanie: dla przesyłań powyżej 2 GB podłącz komputer kablem Ethernet. Jeśli to niemożliwe, wyłącz band-steering na routerze (przełącz go na „tylko 5 GHz" dla identyfikatora SSID laptopa) i zostań w jednym pomieszczeniu. W systemie macOS wyłącz „Auto-Join" dla wszystkich sieci oprócz głównej, aby zapobiec przełączaniu się na silniejsze sygnały w trakcie przesyłania.

Timeouty load balancera po stronie usługi

AWS Application Load Balancer domyślnie ustawia timeout bezczynności na 60 sekund. Nginx domyślnie ustawia proxy_read_timeout na 60 sekund. Usługi, które nie dostroiły tych parametrów, przerywają przesyłania, które na chwilę się zatrzymują — z powodu szyfrowania lub wolnego odczytu dysku źródłowego — dokładnie gdy mija 60 sekund.

Jeśli widzisz timeouty 504 w określonej usłudze, zwykle jest to błędnie skonfigurowany load balancer po ich stronie. Po stronie klienta nie możesz nic zrobić poza ponowieniem próby. Programy do przesyłania podzielonego na fragmenty obsługują to transparentnie, ponawiając próbę dla nieudanego fragmentu; programy jednopotokowe całkowicie zawodzą i musisz zaczynać od nowa.

Timeouty firmowego serwera proxy

Zscaler, Blue Coat, Palo Alto i inne firmowe serwery proxy narzucają własne limity czasu — zazwyczaj od 30 sekund do 5 minut bezczynności. Jeśli przesyłanie wykonuje coś, co proxy uznaje za bezczynność (pauza szyfrowania, opóźnienie ponowienia fragmentu), proxy przerywa połączenie.

Zdiagnozuj problem, przesyłając poza siecią firmową (hotspot telefonu). Jeśli timeouty znikną, winowajcą jest proxy. Poproś dział IT o dodanie domeny usługi transferu do listy dozwolonych i wyłączenie inspekcji dla tych domen. Alternatywą jest sieć osobista lub tunel VPN.

TCP keepalive na poziomie systemu operacyjnego

Linux domyślnie wysyła pakiety TCP keepalive dopiero po 2 godzinach bezczynności, co jest bezużyteczne przy transferze plików. macOS i Windows mają podobne ustawienia domyślne. Przy bardzo długich przesyłaniach w niestabilnych sieciach niektóre usługi implementują keepalive na poziomie aplikacji za pomocą ramek ping WebSocket lub okresowych pustych fragmentów. Jeśli usługa tego nie robi, długie przesyłania przez NAT (domyślny 5-minutowy timeout sesji UDP na większości routerów domowych) mogą się zerwać po wygaśnięciu wpisu NAT.

Odnowienie tokenu sesji VPN

Niektórzy klienci VPN odnawiają tokeny sesji co 5–15 minut. W wadliwych klientach odnowienie zrywa na pół sekundy bazowy tunel TCP. Długie przesyłania wówczas się kończą niepowodzeniem.

Płatne sieci VPN (Mullvad, ProtonVPN Plus, IVPN) obsługują to prawidłowo. Darmowe VPN często nie. Jeśli widzisz stałe timeouty po upływie około 10 minut, podejrzewaj odnowienie sesji VPN. Rozłącz VPN podczas przesyłania, jeśli usługa transferu już stosuje szyfrowanie end-to-end przez TLS 1.3.

Przełączenia w sieci komórkowej

Dane komórkowe przełączają stacje bazowe podczas przemieszczania się. Każde przełączenie albo (a) zachowuje IP przez zarządzanie mobilnością (transparentnie) albo (b) przypisuje nowe IP, co zrywa połączenie. W sieci LTE większość przełączeń jest transparentna. W sieci 5G, szczególnie mmWave, przełączenia do pasma sub-6 lub LTE mogą zmienić IP i zerwać aktywne transfery.

Jeśli przesyłasz pliki z pojazdu w ruchu przez sieć komórkową, spodziewaj się przerw. Programy do przesyłania z możliwością wznowienia dobrze sobie z tym radzą; programy jednopotokowe — nie.

Timeouty WAF i mod_security

Jeśli usługa działa za Web Application Firewall (Cloudflare WAF, AWS WAF, ModSecurity), WAF może oznaczyć długotrwałe przesyłanie jako podejrzane i je przerwać. Objawy: przesyłanie udaje się przy małych rozmiarach, kończy się niepowodzeniem przy określonym progu (często 1 GB lub 10 GB w zależności od konfiguracji WAF), z odpowiedziami 403 lub 502.

Po stronie klienta nie możesz nic naprawić. Zgłoś to do dostawcy usługi. Prawidłowo skonfigurowany WAF pozwala na przesyłanie podzielone na fragmenty bez flagowania.

Domyślne timeouty przeglądarki

Przeglądarki też mają limity czasu żądań, choć zwykle są liberalne przy przesyłaniu. Chrome i Firefox dają żądaniom XHR i fetch nieograniczony czas domyślnie, ale przerywają bezczynne połączenia po 5 minutach w niektórych konfiguracjach. Service Workers mogą przechwytywać żądania i przedłużać timeouty.

Jeśli JavaScript usługi ustawia xhr.timeout = 30000 (30 sekund) na fragment, wolne fragmenty kończą się niepowodzeniem. To błąd po stronie usługi — zgłoś go.

Oprogramowanie antywirusowe sprawdzające ruch HTTPS

Windows Defender z włączoną „inspekcją HTTPS", Norton, Bitdefender i podobne oprogramowanie przechwytuje połączenia HTTPS w celu skanowania zawartości. Przy dużych przesyłaniach samo skanowanie dodaje opóźnienie, które może przekraczać timeouty po stronie serwera.

Tymczasowo wyłącz inspekcję HTTPS (nie całego AV, tylko skanowania HTTPS) podczas dużych przesyłań. Jeśli przesyłania się powiodą, dodaj usługę transferu do listy wyjątków antywirusa na stałe.

Logika ponowień i wykładnicze opóźnienie

Dobrze zbudowane klienty transferu ponawiają nieudane fragmenty z wykładniczym opóźnieniem: 1 sekunda, potem 2, potem 4, potem 8. Krótka usterka sieci naprawia się transparentnie. Klienty bez logiki ponowień zawodzą przy pierwszym błędzie.

Jeśli korzystasz z usługi, która nie ponawia prób automatycznie, zobaczysz więcej błędów spowodowanych timeoutem. Wybierz klienta lub usługę, która obsługuje ponowienia bez Twojej ingerencji.

Poczekaj 15 minut i spróbuj ponownie

Niektóre timeouty są przejściowe: chwilowa przerwa na krawędzi Cloudflare, wdrożenie usługi, przeciążone łącze tranzytowe. Ponów próbę po 15 minutach, zanim zaczniesz eskalować problem. Jeśli znowu się nie powiedzie, przełącz się na inną sieć, aby sprawdzić, czy problem leży po Twojej stronie, czy po stronie usługi.

Wybierz usługę z niezawodnym ponawianiem prób

Przy dużych plikach przesyłanych przez niestabilne sieci potrzebujesz usługi z ponawianiem prób dla każdego fragmentu, możliwością wznawiania sesji i bez agresywnego timeoutu po stronie serwera. HexaTransfer uruchamia równoległe przesyłanie podzielone na fragmenty z ponowieniami dla każdego z nich i szyfrowaniem AES-256-GCM po stronie klienta — przesyłanie 10 GB przez niestabilne połączenie transparentnie ponawia próbę dla dotkniętych fragmentów, zamiast kończyć niepowodzeniem cały transfer z powodu jednej usterki sieci.

Wypróbuj na hexatransfer.com — bezpłatnie, bez konta, do 10 GB.