Errori di timeout nel trasferimento: cause e soluzioni

Gli errori di timeout durante i trasferimenti di file provengono da uno di quattro posti: la richiesta HTTP del client ha aspettato troppo a lungo la risposta del server (tipicamente 30-120 secondi), il server ha aspettato troppo a lungo che il client inviasse dati (comune su upload lenti), un proxy intermedio o load balancer ha tagliato la connessione (il default AWS ALB è 60 secondi), oppure il sistema operativo ha ucciso una connessione TCP inattiva. 504 Gateway Timeout significa che il load balancer non riusciva a raggiungere l'origine. 408 Request Timeout significa che il server ha rinunciato ad aspettare i tuoi dati. ERR_CONNECTION_TIMED_OUT significa che l'handshake TCP non si è mai completato. Ognuno ha una soluzione distinta.

Leggi il tipo di timeout dall'errore

Timeout diversi richiedono soluzioni diverse:

• 504 Gateway Timeout: proxy intermedio o load balancer è andato in timeout. Problema lato servizio, di solito transitorio. Riprova o cambia regione.
• 408 Request Timeout: il server ha rinunciato ad aspettare i dati del client. Il tuo upload si è bloccato a metà richiesta.
• 524 (Cloudflare): l'origine non ha risposto entro 100 secondi. Problema lato servizio.
• 502 Bad Gateway: il proxy ha ricevuto una risposta non valida dall'origine. Interruzione del servizio o deploy in corso.
• ERR_CONNECTION_TIMED_OUT: la tua connessione TCP al server non si è mai completata. Rete o firewall.
• ERR_NETWORK_CHANGED: la tua rete è cambiata a metà connessione. Roaming Wi-Fi o disconnessione VPN.

La scheda Network di DevTools mostra la risposta esatta, i tempi e il codice di stato. Fai uno screenshot prima di chiudere qualsiasi cosa.

Il roaming Wi-Fi uccide gli upload di lunga durata

I chip Wi-Fi dei laptop cambiano bande e access point automaticamente. Ogni cambio interrompe la connessione TCP corrente. Gli upload single-stream muoiono immediatamente; gli upload a chunk sopravvivono se il servizio riprova per chunk.

Soluzione: collega via Ethernet per upload sopra i 2 GB. Se non puoi, disabilita il band-steering sul router (impostalo su "solo 5 GHz" per l'SSID del laptop) e rimani in una stanza. Per macOS, disattiva "Auto-Join" per tutti tranne il tuo SSID primario per evitare di cercare segnali più forti a metà upload.

Timeout del load balancer lato servizio

L'Application Load Balancer di AWS ha un idle timeout predefinito di 60 secondi. Nginx ha proxy_read_timeout predefinito a 60 secondi. I servizi che non hanno ottimizzato correttamente questi parametri tagliano gli upload che si mettono in pausa brevemente (per crittografia, per una lettura disco lenta sulla sorgente) al segno dei 60 secondi.

Se vedi timeout 504 su un servizio specifico, di solito è il loro load balancer mal configurato. Non c'è nulla che puoi fare lato client oltre a riprovare. I client di upload a chunk gestiscono questo in modo trasparente riprovando il chunk fallito; i client single-stream falliscono completamente e devi ricominciare.

Timeout del proxy aziendale

Zscaler, Blue Coat, Palo Alto e altri proxy aziendali applicano i propri timeout, di solito da 30 secondi a 5 minuti di inattività. Se il tuo upload sta facendo qualcosa che il proxy percepisce come inattivo (pausa di crittografia, ritardo di ripetizione chunk), il proxy uccide la connessione.

Diagnostica caricando fuori dalla rete aziendale (hotspot del telefono). Se i timeout scompaiono, il proxy è la causa. Chiedi all'IT di inserire nella whitelist il dominio del servizio di trasferimento e bypassare l'ispezione per quei domini. L'alternativa è la rete personale o il tunnel VPN verso casa.

TCP keepalive a livello di sistema operativo

Linux invia pacchetti TCP keepalive per impostazione predefinita solo dopo 2 ore di inattività, il che è inutile per il trasferimento di file. macOS e Windows hanno valori predefiniti simili. Per upload molto lunghi su reti instabili, alcuni servizi implementano il keepalive a livello applicazione tramite ping frame WebSocket o chunk vuoti periodici. Se il servizio non lo fa, gli upload lunghi attraverso un firewall NAT (timeout di sessione UDP predefinito di 5 minuti sulla maggior parte dei router domestici) possono interrompersi quando la voce NAT scade.

Rinnovo del token di sessione VPN

Alcuni client VPN rinnovano i token di sessione ogni 5-15 minuti. Su client con bug, il rinnovo interrompe il tunnel TCP sottostante per mezzo secondo. Gli upload lunghi muoiono allora.

Le VPN a pagamento (Mullvad, ProtonVPN Plus, IVPN) gestiscono questo in modo pulito. Le VPN gratuite spesso no. Se vedi timeout consistenti al segno dei 10 minuti, sospetta il rinnovo VPN. Disconnetti la VPN per l'upload se il servizio di trasferimento usa già crittografia TLS 1.3 end-to-end.

Handoff cellulare

I dati cellulari cambiano celle mentre ti sposti. Ogni handoff o (a) mantiene l'IP tramite mobility management (trasparente) o (b) assegna un nuovo IP (la connessione cade). Su LTE, la maggior parte degli handoff è trasparente. Su 5G, specialmente mmWave, gli handoff verso sub-6 o fallback LTE possono cambiare IP e uccidere le connessioni.

Se stai caricando da un veicolo in movimento su connessione cellulare, aspettati interruzioni. I client di upload riprendibili a chunk gestiscono questo bene; i client single-stream no.

Timeout WAF e mod_security

Se un servizio è dietro un Web Application Firewall (Cloudflare WAF, AWS WAF, ModSecurity), il WAF potrebbe contrassegnare un upload di lunga durata come sospetto e tagliarlo. Sintomi: gli upload riescono a dimensioni piccole, falliscono a una soglia specifica (spesso 1 GB o 10 GB a seconda della configurazione WAF), con risposte 403 o 502.

Non c'è nulla che puoi correggere lato client. Segnala al servizio. Un WAF ben ottimizzato consente gli upload a chunk senza contrassegnare nulla.

Timeout predefiniti del browser

Anche i browser hanno timeout delle richieste, anche se di solito sono generosi per gli upload. Chrome e Firefox danno alle richieste XHR e fetch tempo illimitato per impostazione predefinita, ma interrompono le connessioni inattive dopo 5 minuti in alcune configurazioni. I Service Worker possono intercettare ed estendere i timeout.

Se il JavaScript del servizio imposta xhr.timeout = 30000 (30 secondi) per chunk, i chunk lenti falliscono. Questo è un bug lato servizio; segnalalo.

Antivirus che ispeziona il traffico HTTPS

Windows Defender con "ispezione HTTPS" abilitata, Norton, Bitdefender e simili tutti eseguono un MITM delle connessioni HTTPS per scansionare il contenuto. Su upload grandi, la scansione stessa aggiunge latenza che può spingere i chunk oltre i timeout lato server.

Disabilita temporaneamente l'ispezione HTTPS (non l'AV completo, solo la scansione HTTPS) durante gli upload grandi. Se gli upload hanno successo, aggiungi il dominio del servizio di trasferimento alla lista di esclusione dell'AV in modo permanente.

Logica di ripetizione e backoff esponenziale

I client di trasferimento ben costruiti riprovano i chunk falliti con backoff esponenziale: 1 secondo, poi 2, poi 4, poi 8. Un breve problema di rete si risolve in modo trasparente. I client senza logica di ripetizione falliscono al primo errore.

Se stai usando un servizio che non riprova automaticamente, vedrai più fallimenti indotti da timeout. Scegli un client o un servizio che gestisce i tentativi per te.

Riprova dopo 15 minuti

Alcuni timeout sono transitori: un problema su un edge Cloudflare, un deploy del servizio, un link di transito congestionato. Riprova dopo 15 minuti prima di escalare. Se fallisce di nuovo, passa a una rete diversa per isolare se il problema è tuo o loro.

Scegli un servizio con ripetizione efficace

Per file grandi su reti inaffidabili, vuoi un servizio con ripetizione per chunk, stato di sessione riprendibile e nessun timeout aggressivo lato server. HexaTransfer esegue upload a chunk paralleli con ripetizione per chunk e crittografia AES-256-GCM lato client, in modo che un upload da 10 GB su una connessione instabile riprovi i chunk interessati in modo trasparente piuttosto che fallire l'intero trasferimento a un singolo problema di rete.

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