Perché la tua VPN WireGuard può essere lenta quando viaggi all’estero

Aggiornato: 2 novembre 2026

Introduzione

Molti utenti si sorprendono quando si collegano da un altro paese al server WireGuard del proprio router GL.iNet e scoprono che la velocità Internet è nettamente inferiore alla connessione gigabit simmetrica di casa o a quella altrettanto veloce del soggiorno all’estero, per esempio un Airbnb. Questa differenza di prestazioni può dipendere da diversi fattori, tra cui instradamento e peering degli ISP, congestione di rete, capacità di elaborazione del router e comportamento delle applicazioni che comunicano attraverso il tunnel VPN.

Che cos'è la latenza e perché conta?

La latenza è il tempo impiegato dai dati per andare dal tuo dispositivo al server VPN e tornare. Si misura spesso in millisecondi (ms). Per esempio, se il tuo router GL.iNet in Vietnam si collega a un server VPN in Texas, il tempo di andata e ritorno (RTT) può raggiungere facilmente 250-300 ms.

Una latenza elevata non riduce intrinsecamente la capacità di inoltro dei pacchetti di WireGuard. A differenza di TCP, il trasporto dati di WireGuard basato su UDP non usa conferme di ricezione o finestre di congestione per regolare la trasmissione dei normali pacchetti dati. Per esempio, un tunnel WireGuard con RTT di 300 ms può teoricamente mantenere lo stesso throughput di inoltro di uno con RTT di 3 ms, a parità di banda disponibile, perdita di pacchetti e capacità di elaborazione.

Le applicazioni che comunicano attraverso il tunnel VPN usano spesso TCP o QUIC, che dipendono dal riscontro dell’endpoint ricevente. Instradare il traffico attraverso un server VPN lontano può aumentare l’RTT percepito da queste applicazioni. Ciò può influenzarne le prestazioni, ma non stabilisce se il collo di bottiglia sia il comportamento del trasporto, il percorso di rete o l’elaborazione del router.

Conta anche il comportamento delle applicazioni. Aprire file da una cartella condivisa remota o copiare molti file piccoli può comportare richieste e risposte ripetute tra il dispositivo e il server. Ogni scambio necessario aggiunge ritardo, quindi queste attività possono sembrare lente anche quando la connessione consente di scaricare velocemente un unico file grande. Aumentare la finestra di ricezione TCP non elimina queste attese a livello applicativo.

Come il throughput TCP è legato alla latenza

Una relazione utile per comprendere il throughput TCP sulle connessioni ad alta latenza è il prodotto banda-ritardo (BDP):

Prodotto banda-ritardo = Throughput x RTT

Il BDP descrive la quantità di dati che deve rimanere in transito, cioè inviata ma non ancora confermata, per mantenere un determinato throughput su una connessione con un dato RTT. Tuttavia, questa relazione da sola non stabilisce il throughput massimo raggiungibile né identifica il fattore limitante di una specifica connessione di rete.

Per esempio, mantenere 100 Mbps di throughput TCP con un RTT di 288 ms richiede circa 3.6 MB di dati in transito non confermati, supponendo che il percorso di rete e gli endpoint possano altrimenti sostenere tale velocità.

Ecco alcune definizioni importanti:

• Finestra di ricezione TCP (rwnd): La quantità di dati aggiuntivi che il dispositivo ricevente annuncia di poter accettare in base allo spazio disponibile nel buffer di ricezione.
• Finestra di congestione TCP (cwnd): La quantità di dati non confermati che il mittente può mantenere in base al proprio algoritmo di controllo della congestione e alle condizioni di rete.
• Throughput: La velocità effettiva con cui i dati vengono trasferiti correttamente
• RTT (tempo di andata e ritorno): Il tempo necessario ai dati per viaggiare tra gli endpoint e a una risposta per tornare.

Il limite effettivo dei dati TCP in attesa di conferma per il mittente dipende dalla minore tra finestra di ricezione e finestra di congestione, oltre che da altri vincoli. La distinzione è importante: una finestra di ricezione sufficientemente ampia non garantisce un throughput elevato se il controllo della congestione o il percorso di rete impediscono al mittente di mantenere abbastanza dati in attesa di conferma.

La perdita di pacchetti può ridurre il throughput TCP richiedendo ritrasmissioni e inducendo il mittente a ridurre la finestra di congestione. Su una connessione ad alta latenza, il riscontro e il recupero possono richiedere più tempo, quindi una finestra di ricezione ampia può non bastare a mantenere trasferimenti veloci.

Un esempio reale da un membro del subreddit GL.iNet

Un membro del subreddit GL.iNet in Vietnam ha riportato i seguenti risultati collegandosi al proprio server WireGuard domestico in Texas, in esecuzione su un router GL.iNet Flint 2.

• Posizione del server: Texas, USA
  
  • Velocità locali (fibra simmetrica) 700 Mbps download / 940 Mbps upload
• Posizione client: Vietnam
  
  • Velocità locali, senza VPN: 455 Mbps in download / 634 Mbps in upload
    
  • Velocità locali (con client WireGuard VPN attivo): 47.3 Mbps download / 12.1 Mbps upload, ping 288 ms

Ricorda che, quando scarichi tramite un server VPN a casa, il throughput massimo in download dipende anche dalla velocità di upload della connessione Internet domestica.

Queste misurazioni mostrano una differenza notevole tra le prestazioni Internet locali e quelle della connessione WireGuard internazionale. Tuttavia, i test non misurano necessariamente percorsi di rete equivalenti. Un test locale in Vietnam può collegarsi a un server vicino, mentre il traffico instradato tramite VPN deve prima attraversare il collegamento internazionale fino al Texas. Questo comporta reti di transito degli ISP, accordi di peering e possibili punti di congestione diversi. Due connessioni internazionali con latenza simile possono offrire velocità molto diverse a seconda della qualità dei percorsi. Benché la connessione VPN riportasse circa 288 ms di RTT, questo dato da solo non dimostra che la latenza fosse la causa principale del throughput ridotto. Potrebbero aver contribuito perdita di pacchetti, instradamento internazionale inefficiente, congestione o altri fattori.

Identifichiamo prima alcuni fattori comuni che possono influire sul throughput di rete:

1. Variazioni delle prestazioni dell’ISP e congestione nel quartiere: Il throughput può variare sensibilmente in base alla congestione e al carico della rete.
2. Prestazioni Wi-Fi: Molto variabili in base all’ambiente fisico, alle interferenze di altri dispositivi wireless, alle capacità del dispositivo client e alla natura intrinsecamente half-duplex del Wi-Fi, a differenza di Ethernet full-duplex
   • Per una spiegazione approfondita delle prestazioni Wi-Fi realistiche, leggi qui: https://www.wiisfi.com/
3. Instradamento degli ISP e peering internazionale: Il traffico tra paesi può attraversare più reti gestite in modo indipendente. Collegamenti di peering congestionati, percorsi inefficienti o perdita di pacchetti possono ridurre notevolmente il throughput anche se entrambi gli endpoint hanno connessioni Internet locali veloci. Due percorsi internazionali con RTT simili possono offrire velocità molto diverse.

La congestione dell’ISP locale e le condizioni dell’instradamento internazionale sono generalmente fuori dal controllo diretto dell’utente, anche se provare ISP o percorsi alternativi può aiutare a rilevare differenze di prestazioni. Un instradamento internazionale inefficiente o un peering congestionato sono cause spesso sospettate quando entrambi gli endpoint hanno Internet locale veloce ma il percorso a lunga distanza è lento. Un test tramite un altro ISP, per esempio da un bar, o un hotspot può aiutare a capire se il rallentamento si trova sul percorso. I limiti del Wi-Fi possono spesso essere ridotti usando Ethernet cablata dove possibile. Vale la pena indagare anche i limiti di elaborazione del router e i problemi di MTU durante la diagnosi del throughput VPN.

In definitiva, per capire perché una connessione VPN internazionale è lenta bisogna distinguere tra i limiti del percorso di rete, del router VPN e delle applicazioni che comunicano nel tunnel.

Scalatura della finestra TCP per prestazioni migliori

In origine, la finestra di ricezione TCP era limitata a circa 64 KB. Il Window Scaling (RFC 7323) porta il limite a circa 1 GiB e i sistemi operativi moderni regolano automaticamente la finestra. Per esempio, l’impostazione di regolazione automatica Normal documentata da Microsoft può rappresentare finestre di ricezione di circa 16.8 MB. Le connessioni TCP moderne non sono quindi intrinsecamente limitate a 64 KB.

Fonte: duckware.com/blog/how-windows-is-killing-internet-download-speeds

Come i limiti della finestra TCP interagiscono con l’RTT

Per una connessione TCP con un limite fisso di dati in attesa di conferma, il tetto approssimativo di throughput legato alla finestra è:

Throughput in bit al secondo ≈ Limite della finestra in byte × 8 ÷ RTT in secondi

Mantenendo costante il limite della finestra, un RTT maggiore produce un tetto più basso legato alla finestra. Gli esempi seguenti illustrano questa relazione; non prevedono il throughput VPN effettivo.

Tetti teorici legati alla finestra (finestra ÷ RTT), usando 1 MB = 1,000,000 byte. Sono esempi illustrativi, non previsioni del throughput VPN effettivo.

Il throughput effettivo dipende anche dal controllo della congestione, dalla perdita di pacchetti, dalla banda disponibile e dai limiti di elaborazione. Più connessioni TCP possono talvolta ottenere un throughput aggregato maggiore, ma non esiste una soglia universale di RTT oltre la quale non possano sfruttare tutta la banda disponibile.

Nell’esempio Vietnam-Texas, un’ipotetica singola connessione TCP limitata a 2 MB di dati in attesa di conferma con RTT di 288 ms avrebbe un tetto legato alla finestra di circa 55.6 Mbps. La riga da 300 ms nella tabella è leggermente inferiore per via dell’RTT maggiore. Questo, però, non stabilisce perché l’utente abbia misurato 47.3 Mbps.

Senza conoscere il numero di connessioni del test, le finestre TCP effettive e le condizioni di rete, non possiamo determinare se il collo di bottiglia fosse un limite della finestra, congestione, perdita di pacchetti, instradamento dell’ISP o altro.

Cosa determina la dimensione della tua finestra TCP?

Le dimensioni delle finestre TCP appartengono alle singole connessioni e possono cambiare durante il trasferimento. I valori degli esempi precedenti non vanno quindi considerati impostazioni fisse valide per tutte le connessioni del dispositivo.

Il sistema operativo del dispositivo ricevente gestisce la finestra di ricezione. La dimensione dipende da fattori come lo spazio disponibile nel buffer, la regolazione automatica e i limiti del sistema operativo, le impostazioni dell’applicazione e la rapidità con cui questa consuma i dati in arrivo. Quando scarichi un file sul portatile, il portatile annuncia la propria finestra di ricezione al server mittente. Quando carichi un file, è il server ricevente ad annunciare la propria finestra al portatile.

Il mittente gestisce separatamente la propria finestra di congestione secondo l’algoritmo di controllo della congestione e i riscontri della rete. Questo può limitare i dati in attesa di conferma anche se il ricevente annuncia una finestra ampia. In una tipica configurazione WireGuard tra router, queste finestre TCP appartengono ai computer e ai server che comunicano; non sono un’unica impostazione della dimensione della finestra sui router VPN.

Come puoi verificare una connessione reale?

Se hai familiarità con l’analisi dei pacchetti, Wireshark può mostrare la finestra di ricezione TCP annunciata. In una configurazione tra router, acquisisci il traffico sul computer che esegue il trasferimento. Avvia l’acquisizione prima di stabilire una nuova connessione TCP, così che Wireshark registri l’handshake iniziale e la negoziazione del window scaling. Durante un download, esamina una conferma TCP in uscita dal computer per quel trasferimento, espandi la sezione Transmission Control Protocol e cerca Calculated window size. Il valore mostra la finestra di ricezione annunciata dal computer in quel momento, con il ridimensionamento applicato quando Wireshark conosce il fattore di scala negoziato.

Questo valore può cambiare durante il trasferimento. Non rivela direttamente la finestra di congestione del mittente né dimostra che la finestra di ricezione limiti le prestazioni. Anche controllare l’impostazione di regolazione automatica del sistema operativo non indica la finestra effettiva annunciata in quel momento da una specifica connessione.

Un altro esempio reale: velocità maggiori senza ridurre il ping

In un altro caso di assistenza ho esaminato una connessione VPN Tailscale lenta. Tailscale usa la crittografia WireGuard, ma le sue opzioni di relay possono trasportare i pacchetti cifrati in modi diversi: i relay DERP usano connessioni TCP, mentre i Tailscale Peer Relay usano UDP. Questo differisce da una connessione WireGuard autonoma, che normalmente invia i pacchetti cifrati direttamente via UDP. In questo caso, entrambi i relay erano ospitati autonomamente sulla stessa istanza AWS Lightsail; il confronto riguardava quindi due metodi di relay ospitati privatamente, non i server DERP pubblici di Tailscale.

La connessione Internet del client raggiungeva circa 83 Mbps nel test, mentre quella del server VPN aveva una velocità di upload misurata di circa 40.6 Mbps. Sono state osservate le seguenti velocità di download:

SQM significa Smart Queue Management, una funzione del router che gestisce le code dei pacchetti e riduce i ritardi eccessivi sotto carico. In questo confronto SQM era abilitato o disabilitato sul router da viaggio lato client.

SQM non è una soluzione universale per le basse velocità VPN. Quando rileva un solo flusso di tunnel cifrato, non può assegnare priorità separate alle connessioni delle applicazioni nascoste al suo interno. Può comunque gestire la coda di pacchetti condivisa, ma ciò riduce il ritardo in coda solo quando l’accodamento eccessivo è un problema che può risolvere. Se non c’è un accodamento eccessivo che SQM possa controllare in modo utile, impostazioni di larghezza di banda inutilmente restrittive o un ulteriore carico di elaborazione possono ridurre il throughput senza migliorare la reattività.

La latenza è rimasta pressoché invariata, ma il relay basato su UDP ha fornito un throughput nettamente superiore sia con SQM abilitato sia disabilitato. Il miglioramento maggiore ha accompagnato il cambio di metodo di relay, non una riduzione del ping o la rimozione di SQM.

Un possibile fattore è il trasporto TCP di DERP. Ogni dispositivo Tailscale si collega al relay DERP via TCP, quindi i pacchetti cifrati attraversano connessioni TCP separate sui due lati del relay. Più connessioni applicative dentro il tunnel possono condividere queste connessioni TCP esterne. Se si perdono dati su una connessione TCP esterna, i dati successivi possono dover attendere la ritrasmissione prima di essere consegnati, ritardando potenzialmente più applicazioni insieme. Un Peer Relay basato su UDP evita questo ulteriore livello di trasporto TCP ordinato, sebbene le applicazioni TCP nel tunnel continuino a usare le proprie conferme e il proprio controllo della congestione.

Poiché entrambi i relay erano sulla stessa istanza, host e posizione sono rimasti costanti. Questo rafforza l’interpretazione secondo cui il trasporto o l’implementazione del relay abbiano contribuito al miglioramento, invece del semplice avvicinamento del relay agli utenti. Tuttavia, lo stesso host non garantisce percorsi o condizioni di rete identici, quindi il confronto non isola TCP rispetto a UDP come unica causa.

Sono osservazioni di un singolo caso di assistenza, non valori di prestazioni garantiti. Dimostrano però perché la sola latenza non basta a prevedere la velocità di una VPN.

Conclusione

Spero che questo articolo abbia chiarito perché le velocità di download e upload sulle connessioni VPN WireGuard a lunga distanza possano essere molto inferiori alle velocità Internet disponibili ai due estremi. La distinzione più importante è che WireGuard stesso non impone un tetto al throughput dipendente dall’RTT. Il suo trasporto dati basato su UDP non implementa finestre di congestione, conferme o ritrasmissioni di tipo TCP per i normali pacchetti dati.

Tuttavia, le applicazioni TCP e QUIC che comunicano nel tunnel restano soggette ai propri meccanismi di controllo della congestione e affidabilità. Un RTT maggiore aumenta i dati in attesa di conferma necessari a sostenere un dato throughput. Più connessioni possono migliorare le prestazioni aggregate, ma né l’RTT né il numero di connessioni determinano da soli la velocità raggiungibile. Le prestazioni effettive dipendono anche da perdita di pacchetti, congestione, instradamento e peering degli ISP, banda disponibile, configurazione MTU e capacità di elaborazione del router VPN.

In una tipica configurazione WireGuard tra router GL.iNet, le connessioni TCP vengono stabilite tra i dispositivi finali e i server di destinazione. I router VPN cifrano, decifrano e inoltrano i pacchetti senza controllare direttamente le finestre di ricezione TCP di queste connessioni end-to-end. I limiti hardware del router possono influenzare il throughput dei pacchetti cifrati, ma non vanno confusi con i limiti della finestra di ricezione TCP.

Per diagnosticare una connessione WireGuard internazionale lenta, inizia provando la connessione Internet in ogni sede, usando Ethernet cablata dove possibile. Controlla se le prestazioni VPN cambiano in diversi momenti della giornata o usando un’altra connessione, per esempio un hotspot mobile. Questi confronti possono aiutare a individuare dove avviene il rallentamento, anche se per identificare la causa potrebbero servire test più dettagliati. Una latenza elevata può rallentare le applicazioni, ma non va automaticamente considerata l’unica spiegazione di una VPN lenta.

In futuro spero di sperimentare relay UDP collocati strategicamente per verificare se percorsi alternativi possano migliorare le prestazioni VPN WireGuard tra Stati Uniti e Asia.

Per informazioni e consigli sulla configurazione WireGuard VPN e diagnosi, vedi il post GL.iNet: https://forum.gl-inet.com/t/how-to-troubleshoot-wireguard/42502