Upload ciągle się nie udaje? Napraw typowe błędy transferu

Nieudany upload niemal zawsze należy do jednej z pięciu kategorii: niestabilność sieci (zanik Wi-Fi, reroutowanie ISP), wyczerpanie pamięci przeglądarki (Chrome zabijający zakładkę przy 2 GB RAM), ograniczenia po stronie usługi lub przekroczenie limitu, uszkodzony plik źródłowy albo blokada przez antywirus lub firewall. Pierwszym krokiem jest sprawdzenie zakładki Sieć w DevTools i odczytanie rzeczywistego kodu HTTP nieudanego żądania. Kod 413 to „payload too large". Kody 502 lub 503 wskazują na problem po stronie usługi. ERR_CONNECTION_RESET oznacza problem z siecią. Każdy z tych przypadków ma inne rozwiązanie.

Odczytaj rzeczywisty błąd, a nie komunikat ogólny

Większość interfejsów uploadowych wyświetla „Upload failed" i na tym kończy. To bezużyteczna informacja. Należy otworzyć DevTools przeglądarki (F12 lub Cmd+Option+I), przejść do zakładki Sieć i obserwować nieudane żądanie. Kod statusu wskazuje, gdzie leży problem: kody 400 dotyczą strony użytkownika (413 — za duże, 401 — brak autoryzacji, 403 — brak dostępu), kody 500 dotyczą strony usługi (502 bad gateway, 503 — zwolnij, 504 — timeout). Błędy połączenia, takie jak ERR_CONNECTION_RESET lub net::ERR_NETWORK_CHANGED, oznaczają, że połączenie TCP zerwało się w trakcie transferu.

Warto zrobić zrzut ekranu nieudanego żądania i nagłówków odpowiedzi przed zamknięciem okna. Przy eskalacji do działu wsparcia te nagłówki zazwyczaj od razu wskazują przyczynę problemu.

Wi-Fi: cichy morderca uploadów

Karty Wi-Fi w laptopach przełączają się między punktami dostępowymi i pasmami (2,4 GHz oraz 5 GHz). Każde takie przełączenie zrywa połączenie TCP na ułamek sekundy, co uśmierca upload jednopotokowy. Usługi transferowe implementujące fragmentowane, wznawialne uploady (oparte na tus.io, S3 multipart) przeżywają to — pojedyncze żądania POST nie.

Jeśli jest możliwość użycia kabla, zdecydowanie warto. Ethernet nie roamuje. Jeśli nie, warto przynajmniej pozostać w jednym miejscu i wyłączyć „Auto-switch SSID" lub band steering siatki mesh podczas uploadu. Ciągły ping do 1.1.1.1 w osobnym terminalu pokazuje przerwy — to właśnie w tych momentach giną uploady.

Awarie przeglądarki i eksmisja zakładek

Chrome zabija zakładki przekraczające próg pamięci, typowo 2–4 GB na zakładkę w zależności od dostępnego RAM. Upload pliku 10 GB przez przeglądarkę buforującą całą zawartość w pamięci (złe rozwiązanie) zakończy się awarią. Upload przez usługę strumieniującą w fragmentach (dobre rozwiązanie, używające metody slice() File API) zużywa kilkaset MB RAM niezależnie od rozmiaru pliku.

Jeśli przeglądarka regularnie się zawiesza przy dużych uploadach, warto spróbować Firefox, który historycznie obsługuje duże uploady przez File API z mniejszym zużyciem pamięci niż Chromium. Należy upewnić się, że usługa używa fragmentowanych uploadów; jeśli plik 5 GB jest ładowany do jednego obiektu Blob przed POST-em, to jest błąd projektowy.

Przed uploadem należy zamknąć wszystkie inne zakładki, zrestartować przeglądarkę i wyłączyć rozszerzenia (blokery reklam, rozszerzenia prywatności i menedżery haseł czasami wstrzykują się w strumienie uploadowe i je psują).

Korporacyjne firewalle i proxy

Sieci korporacyjne często używają głębokiej inspekcji pakietów, kształtowania ruchu lub serwerów proxy wstrzykujących certyfikaty. Objawy: uploady kończą się sukcesem dla małych plików, ale padają przy określonym rozmiarze (często 100 MB lub 1 GB), albo błąd brzmi „SSL handshake failed" lub „certificate verification failed".

Warto sprawdzić, wgrywając plik przez hotspot telefonu (poza siecią korporacyjną). Jeśli tam działa, problem leży po stronie użytkownika. Opcje: poprosić IT o dodanie endpointu uploadowego usługi do listy wyjątków, użyć VPN (jeśli dozwolony) do obejścia mechanizmu kształtowania ruchu lub przenieść się na sieć prywatną.

Zscaler, Cisco Umbrella i urządzenia Palo Alto to częste winowajcy. Często inspekcjonują pliki powyżej określonego rozmiaru i generują timeout przy dużych strumieniach.

Antywirus skanujący strumień wychodzący

Windows Defender, Bitdefender, Norton i Kaspersky mogą skanować wychodzący ruch HTTPS, przechwytując TLS. Przy dużych uploadach samo skanowanie może obniżyć przepustowość o 40–60 procent, a w niektórych wersjach wprowadza timeout zrywający połączenie.

Należy chwilowo wyłączyć ochronę internetową w czasie rzeczywistym — nie cały antywirus, tylko komponent inspekcji HTTPS — i spróbować ponownie. Jeśli upload się powiedzie, warto dodać domenę usługi transferowej do listy wyjątków antywirusa. Nie należy pozostawiać wyłączonej ochrony na stałe.

Limity przepustowości po stronie usługi

Kody odpowiedzi 429 lub 503 oznaczają, że usługa ogranicza ruch. Możliwe przyczyny: zbyt wiele równoległych fragmentów (należy zmniejszyć z 8 do 4 workerów), przekroczenie dziennego limitu darmowego planu (darmowy WeTransfer ma limit 2 GB na transfer, ale też niejawne limity dziennego wolumenu) lub wspólny adres IP oznaczony jako nadużywany (częste w hotelach i kawiarniach).

Warto poczekać 15 minut i spróbować ponownie, zmienić sieć albo przejść na inną usługę.

Uszkodzony plik źródłowy

Rzadko, ale zdarza się, że problemem jest sam plik. Uszkodzenie systemu plików (zły sektor na dysku zewnętrznym, przerwane kopiowanie) generuje plik, który normalnie odczytuje się przez pierwsze kilka MB, a potem zwraca błędy I/O. Upload zatrzymuje się przy tym samym procencie przy każdej próbie.

Warto sprawdzić, kopiując plik na inny lokalny dysk. Jeśli kopiowanie zawiedzie przy tym samym procencie, problem tkwi w źródle. Należy uruchomić chkdsk na Windows lub diskutil verifyDisk na macOS na dysku źródłowym. W przypadku krytycznych plików trzeba przywrócić je z pewnej kopii przed kolejną próbą uploadu.

Błędy daty, czasu i certyfikatu TLS

Jeśli zegar systemowy jest ustawiony z kilkuminutowym odchyleniem, walidacja certyfikatu TLS zawodzi, a uploady kończą się błędem „certificate not yet valid" lub podobnym. Komputery Mac i Windows zwykle synchronizują się automatycznie przez NTP, ale po długim uśpieniu lub wyczerpaniu baterii CMOS zegar potrafi się rozjechać.

Należy wymusić synchronizację NTP: sntp -sS time.apple.com na macOS lub Ustawienia > Czas i język > Data i godzina > Synchronizuj teraz na Windows.

VPN, który cicho zawodzi

Niektóre klienty VPN (szczególnie bezpłatne) zrywają długotrwałe połączenia TCP po 5–10 minutach, bo tokeny sesji się odświeżają. Upload 2 GB trwający 20 minut ginie przy odnowieniu tokenu — bez żadnego ostrzeżenia. Rozwiązaniem jest przejście na płatny VPN z lepszą obsługą sesji (Mullvad, ProtonVPN, IVPN) albo odłączenie VPN podczas uploadu, jeśli usługa i tak szyfruje ruch end-to-end przez TLS.

Usługi z szyfrowaniem end-to-end oznaczają, że VPN nie jest potrzebny dla zachowania poufności podczas samego transferu. HexaTransfer szyfruje pliki po stronie klienta przez AES-256-GCM przed opuszczeniem przeglądarki, więc dodanie szyfrowania VPN to „szelki i pasek", a nie konieczność.

Usługa, która sama ponawia fragmenty

Jeśli oczywiste problemy lokalne zostały wyeliminowane, a upload nadal zawodzi, sama usługa może nie obsługiwać dobrze przerw. Usługa z automatycznym ponawianiem per fragment i wznawianiem stanu sesji działa przez typowe zakłócenia — chwilowy zanik Wi-Fi, krótki reroutowanie ISP — które uśmiercają uploady jednopotokowe. HexaTransfer uruchamia równoległe, fragmentowane uploady z ponawianiem per fragment i przeżywa większość krótkich awarii sieciowych bez żadnej ręcznej interwencji.

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