Upload fallisce? Correggi gli errori comuni di trasferimento

Un upload che fallisce rientra quasi sempre in una di cinque categorie: instabilità di rete (caduta del Wi-Fi, reindirizzamento dell'ISP), esaurimento della memoria del browser (Chrome che termina una scheda a 2 GB di RAM), limitazione della velocità lato servizio o quota raggiunta, file sorgente corrotto, o antivirus/firewall che blocca le richieste in uscita. Inizia controllando la scheda Network di DevTools per il codice di stato HTTP effettivo della richiesta fallita. Un 413 significa "payload troppo grande". Un 502 o 503 è il servizio. Un ERR_CONNECTION_RESET è la tua rete. Ognuno ha una correzione diversa.

Leggi l'errore reale, non il messaggio generico

La maggior parte delle UI di upload mostra "Upload fallito" e si ferma lì. Non è utile. Apri DevTools del browser (F12 o Cmd+Option+I), vai alla scheda Network e osserva la richiesta fallita. Il codice di stato ti dice dov'è il problema: serie 400 significa dalla tua parte (413 troppo grande, 401 autenticazione, 403 vietato), serie 500 significa dalla loro parte (502 bad gateway, 503 rallenta, 504 timeout). Errori di connessione come ERR_CONNECTION_RESET o net::ERR_NETWORK_CHANGED significano che la connessione TCP è morta durante il trasferimento.

Cattura uno screenshot della richiesta fallita e delle intestazioni di risposta prima di chiudere qualsiasi cosa. Se contatti il supporto, quelle intestazioni di solito identificano il problema.

Cadute Wi-Fi: il killer silenzioso

I chip Wi-Fi dei laptop si spostano tra punti di accesso e tra bande (2,4 GHz e 5 GHz). Ogni spostamento interrompe la connessione TCP per una frazione di secondo, il che uccide un upload a flusso singolo. I servizi di upload che implementano upload a blocchi ripristinabili (basati su tus.io, S3 multipart) sopravvivono; gli upload POST singoli no.

Se puoi collegare un cavo Ethernet, fallo. Ethernet non si sposta. Se non puoi, rimani almeno in una stanza e disabilita la "commutazione automatica SSID" o il band-steering mesh durante l'upload. Esegui un ping continuo a 1.1.1.1 in un altro terminale e osserva le interruzioni: sono quelle dove i tuoi upload muoiono.

Crash del browser ed espulsione delle schede

Chrome termina le schede quando superano una soglia di memoria, in genere intorno a 2-4 GB per scheda in base alla RAM disponibile. Caricare un file da 10 GB tramite un browser che carica tutto in memoria (implementazione scadente) supererà quel limite. Caricare tramite uno che trasmette blocchi (buona implementazione, usando il metodo slice() della File API) usa qualche centinaio di MB di RAM indipendentemente dalla dimensione del file.

Se il tuo browser continua a bloccarsi su upload grandi, prova Firefox, che storicamente gestisce upload File API di grandi dimensioni con meno pressione sulla memoria rispetto a Chromium. Assicurati che il servizio usi upload a blocchi; se un file da 5 GB viene caricato in un singolo Blob prima del POST, quello è il problema di progettazione.

Chiudi ogni altra scheda. Riavvia il browser prima di iniziare. Disabilita le estensioni (i blocchi di annunci, le estensioni per la privacy e i gestori di password a volte si inseriscono nei flussi di upload e li interrompono).

Firewall aziendali e proxy

Le reti aziendali spesso eseguono ispezione approfondita dei pacchetti, traffic shaping o server proxy che iniettano certificati. Sintomi: gli upload riescono per file piccoli ma falliscono a una dimensione specifica (spesso 100 MB o 1 GB), o l'errore recita "SSL handshake failed" o "certificate verification failed".

Verifica caricando dall'hotspot del telefono (fuori dalla rete aziendale). Se funziona lì, il problema è dalla tua parte. Opzioni: chiedi all'IT di aggiungere l'endpoint di upload del servizio alla lista di esclusione, usa una VPN (se consentito) per aggirare lo shaper, o passa a una rete personale.

Zscaler, Cisco Umbrella e gli appliance Palo Alto sono spesso i responsabili. Spesso ispezionano i file oltre una soglia di dimensione e vanno in timeout su flussi grandi.

Scansione dell'antivirus sul flusso in uscita

Windows Defender, Bitdefender, Norton e Kaspersky possono scansionare il traffico HTTPS in uscita intercettando TLS. Su upload grandi, la scansione stessa può ridurre il throughput del 40-60%, e su alcune versioni introduce timeout che interrompono la connessione.

Disabilita temporaneamente la protezione web in tempo reale (non l'intero antivirus, solo il componente di ispezione HTTPS) e riprova. Se l'upload riesce, aggiungi il dominio del servizio di trasferimento alla lista di esclusione dell'AV. Non lasciare la protezione web disabilitata in modo permanente.

Limiti di velocità lato servizio

Se stai ricevendo risposte 429 o 503, il servizio ti sta rallentando. Possibili ragioni: stai eseguendo troppi blocchi paralleli (riduci a 4 worker da 8), hai raggiunto una quota giornaliera del piano gratuito (WeTransfer free ha limiti impliciti di volume giornaliero), o sei su un IP condiviso che è stato segnalato (comune su Wi-Fi di hotel e bar che è stato abusato).

Aspetta 15 minuti e riprova. O cambia rete. O cambia servizio.

File sorgente corrotto

Raramente, il file stesso è il problema. La corruzione del filesystem (settore difettoso su un'unità esterna, copia interrotta) produce un file che si legge bene per i primi MB e restituisce errori I/O oltre quel punto. L'upload si blocca a una percentuale costante ad ogni tentativo.

Verifica copiando prima il file su un disco locale diverso. Se la copia fallisce alla stessa percentuale, è il sorgente. Esegui chkdsk su Windows o diskutil verifyDisk su macOS sull'unità sorgente. Per i file critici, recupera da una copia nota come buona prima di provare di nuovo a caricare.

Errori di data, ora e certificato TLS

Se l'orologio di sistema è sbagliato di più di qualche minuto, la convalida del certificato TLS fallisce e gli upload danno errore con "certificate not yet valid" o simili. Mac e Windows di solito si sincronizzano tramite NTP automaticamente, ma dopo un lungo periodo di sospensione o una batteria della scheda madre scarica, gli orologi si spostano.

Forza una sincronizzazione NTP: sntp -sS time.apple.com su macOS, o Impostazioni > Ora e lingua > Data e ora > Sincronizza ora su Windows.

VPN che falliscono silenziosamente

Alcuni client VPN (specialmente quelli gratuiti) interrompono le connessioni TCP di lunga durata dopo 5-10 minuti perché i loro token di sessione si rinnovano. Un upload da 2 GB che richiede 20 minuti muore al rinnovo del token, silenziosamente. Passa a una VPN a pagamento con una gestione migliore delle sessioni (Mullvad, ProtonVPN, IVPN), o disconnetti la VPN durante gli upload se il servizio è già crittografato end-to-end con TLS.

I servizi con crittografia end-to-end significano che non hai bisogno della VPN per la riservatezza durante il trasferimento. HexaTransfer, per esempio, crittografa con AES-256-GCM lato client prima che il file lasci il tuo browser, quindi aggiungere la crittografia VPN sopra è una precauzione doppia, non essenziale.

Usa un servizio che riprova i blocchi automaticamente

Se hai risolto i problemi locali ovvi e gli upload continuano a fallire, il servizio stesso potrebbe non gestire bene le interruzioni. Un servizio con ripetizione automatica per blocco e stato di sessione ripristinabile continua a funzionare attraverso il tipo di interruzioni (un'escursione Wi-Fi, un breve reindirizzamento dell'ISP) che uccidono i caricatori a flusso singolo. HexaTransfer esegue upload a blocchi paralleli con ripetizione per blocco e sopravvive alla maggior parte degli eventi di rete brevi senza alcun intervento manuale.

Provalo su hexatransfer.com — gratis, senza registrazione, fino a 10 GB.