Correggere velocità lenta: diagnosticare problemi di upload
Diagnostica e correggi velocità di trasferimento lente. Risoluzione passo passo per problemi di rete, browser e colli di bottiglia del servizio.
Per correggere un upload lento, diagnostica nell'ordine: misura la connessione grezza con speedtest-cli, confronta la velocità effettiva del servizio di trasferimento con quella rilevata in DevTools, verifica se le sincronizzazioni in background stanno consumando banda, controlla se il servizio limita la velocità per singolo trasferimento e assicurati di essere sull'endpoint regionale più vicino. Una linea da 500 Mbps che consegna solo 40 Mbps a un servizio di trasferimento indica uno dei quattro problemi: contesa di banda, mismatch di regione CDN, throttling lato server o collo di bottiglia single-stream. Ognuno ha una soluzione diversa, e tutti emergono dalla scheda Network di DevTools prima che tu faccia qualsiasi altra cosa.
Misura prima la connessione
Prima di dare la colpa al servizio di trasferimento, verifica che la tua connessione stia davvero erogando quello che pensi. Esegui speedtest-cli --json da terminale, oppure speedtest.net dal browser. Annota gli Mbps in upload, la latenza e il jitter. Questo è il tuo tetto massimo. Se la tua connessione "500 Mbps" consegna solo 80 Mbps in upload sullo speedtest, nessun servizio di trasferimento farà meglio.
Esegui il test due volte: una su Wi-Fi e una su Ethernet se possibile. Il divario ti dice quanto ti sta costando il Wi-Fi. Su Wi-Fi 5 in un ambiente domestico medio, aspettati di perdere dal 30 al 50 percento rispetto al tetto cablato.
Confronta lo speedtest con la velocità di trasferimento reale
Apri il servizio di trasferimento, avvia l'upload e apri DevTools > scheda Network. Osserva la velocità effettiva delle singole richieste. Se lo speedtest dice 500 Mbps e il trasferimento consegna 150 Mbps, il divario ha quattro cause probabili: il servizio usa un singolo stream (non riesce a saturare una pipe ad alta latenza), l'endpoint CDN del servizio è lontano da te, i consumatori di banda in background stanno rubando traffico, oppure il servizio applica un rate limit per trasferimento.
I client di upload con chunking parallelo (servizi basati su tus.io, S3 multipart, HexaTransfer) dovrebbero eseguire da 4 a 8 richieste concorrenti. Contale nel waterfall. Meno di queste su una linea veloce significa che il servizio sta sprecando banda disponibile.
Elimina le sincronizzazioni in background
Activity Monitor di macOS (scheda Network, ordina per "Sent Bytes per sec") e Resource Monitor di Windows (scheda Network) mostrano la banda usata da ogni processo. I principali responsabili: Dropbox, Google Drive, OneDrive, iCloud Photos, Backblaze, Time Machine su rete, Adobe Creative Cloud sync. Chiudili del tutto — non mettere solo in pausa, perché la pausa a volte mantiene aperte le connessioni TCP.
Una videochiamata Zoom in HD usa 2,5 Mbps in upstream. Un upload 4K su YouTube in un altro tab può consumare 20 Mbps. Anche i file preview di Slack spingono qualche centinaio di KB/s. Su connessioni asimmetriche (100 Mbps down, 10 Mbps up è un piano cable comune), questi si sommano velocemente.
Verifica l'endpoint regionale
Molti servizi di trasferimento instradano tramite edge CDN. Se il tuo DNS o GeoIP è obsoleto, potresti stare caricando su un edge di Francoforte da Sydney, aggiungendo 300 ms di round-trip e distruggendo la velocità single-stream. Controlla l'IP dell'endpoint con il pannello Network di DevTools (clic destro sulla richiesta > Copia > Copia URL, poi nslookup), quindi esegui il ping per vedere la latenza.
Latenza ideale verso l'ingest del servizio di trasferimento: sotto i 20 ms per la stessa città, sotto i 50 ms per lo stesso continente, sotto i 100 ms per l'intercontinentale. Se sei a 250 ms e sei sullo stesso continente del servizio, qualcosa sta instradando attraverso un edge lontano.
Cambia DNS per escludere un GeoIP obsoleto
Se usi ancora il DNS predefinito del tuo ISP, prova temporaneamente Cloudflare (1.1.1.1), Google (8.8.8.8) o Quad9 (9.9.9.9). Resolver diversi restituiscono edge CDN diversi perché rispondono in modo differente alle query ECS (EDNS Client Subnet). Un cambio può ridurre la latenza in upload di 50 ms e aumentare la velocità del 20 percento senza toccare altro.
Bufferbloat del router
Il bufferbloat è invisibile ai normali speedtest ma distrugge le connessioni a uso misto. Esegui il test bufferbloat di Waveform su waveform.com/tools/bufferbloat. Un voto A+ significa che il tuo router gestisce le code correttamente. Un voto F significa che il tuo router sta introducendo da 200 a 2000 ms di latenza sotto carico, il che non solo penalizza il traffico interattivo ma fa sì che il controllo di congestione TCP ceda ripetutamente, dimezzando la velocità di upload.
Soluzione: abilita SQM (Smart Queue Management) su OpenWrt o pfSense, attiva QoS su Asus/Netgear/Ubiquiti, oppure acquista un router che lo fa per impostazione predefinita (eero recenti, Google Nest Wifi Pro).
Disabilita la VPN quando non è necessaria
Una VPN aggiunge da 20 a 80 ms di latenza e tipicamente limita la velocità all'upstream del server VPN. Una linea da 1 Gbps attraverso un endpoint PIA o NordVPN congestionato può scendere a 50 Mbps. I provider di qualità (Mullvad, ProtonVPN Plus) reggono meglio; le VPN gratuite quasi sempre strozzano gli upload.
Se il servizio di trasferimento usa già TLS 1.3 e crittografia end-to-end, la VPN è ridondante per la riservatezza in transito. Disattivala durante gli upload e riattivala dopo.
Scelta del browser e protocollo
Chrome, Edge, Brave e Firefox supportano tutti HTTP/3 (QUIC) nativamente. Safari pure, ma usa HTTP/2 per impostazione predefinita con alcuni host. HTTP/3 su UDP tollera la perdita di pacchetti molto meglio di HTTP/2 su TCP su connessioni cellulari, Wi-Fi di hotel o last-mile con perdite.
Controlla la colonna Protocol in DevTools > Network. Se dice h2, sei su HTTP/2. Se dice h3, sei su HTTP/3. I servizi che gestiscono gli upload su HTTP/3 vedono guadagni di velocità del 15-30 percento su link con perdite.
Prova un'altra rete per isolare il problema
La diagnosi più rapida: aggancia il tuo telefono per un minuto e carica un chunk di test. Se il tethering del telefono è più veloce del tuo Wi-Fi domestico, il problema è nella tua rete locale (router, ISP o dispositivo). Se il tethering del telefono ha la stessa velocità, il collo di bottiglia è più a monte (congestione di transito, limite lato servizio).
Questo singolo test elimina metà delle cause possibili in meno di due minuti.
Quando il servizio è il collo di bottiglia
Alcuni servizi di trasferimento limitano semplicemente la velocità per singolo trasferimento. I livelli gratuiti di certi strumenti applicano throttling sopra i 10 MB/s indipendentemente dalla tua connessione. I livelli a pagamento spesso rimuovono il limite.
Se hai eliminato tutto il resto e la tua linea da 500 Mbps consegna ancora solo 30 Mbps a un servizio specifico, il servizio è il limite. Cambia. HexaTransfer non applica throttling per trasferimento e usa upload con chunking parallelo che saturano qualunque velocità la tua pipe possa spingere, fino al tetto di 10 GB per trasferimento.
Provalo su hexatransfer.com — gratis, senza registrazione, fino a 10 GB.
Invia file di grandi dimensioni in modo sicuro con crittografia end-to-end
Trasferisci file fino a 10 GB gratuitamente con crittografia end-to-end. Nessun account necessario. I tuoi file vengono crittografati nel browser prima del caricamento — nessun altro può leggerli.
Invia un file