Pourquoi votre VPN WireGuard peut être lent à l’étranger

Mise à jour : 2 novembre 2026

Introduction

De nombreux utilisateurs sont surpris de constater que, lorsqu’ils se connectent depuis un autre pays au serveur WireGuard de leur routeur GL.iNet, leur débit Internet est nettement inférieur au débit gigabit symétrique de leur domicile ou à la connexion tout aussi rapide de leur lieu de séjour à l’étranger, par exemple un Airbnb. Plusieurs facteurs peuvent expliquer cet écart : le routage et le peering du FAI, la congestion du réseau, la capacité de traitement du routeur et le comportement des applications qui communiquent à travers le tunnel VPN.

Qu’est-ce que la latence et pourquoi est-elle importante ?

La latence est le temps nécessaire aux données pour aller de votre appareil au serveur VPN et en revenir. Elle se mesure souvent en millisecondes (ms). Par exemple, si votre routeur GL.iNet au Vietnam se connecte à un serveur VPN au Texas, le temps aller-retour (RTT) peut facilement atteindre 250-300 ms.

Une latence élevée ne réduit pas intrinsèquement la capacité de transfert des paquets de WireGuard. Contrairement à TCP, le transport de données de WireGuard, fondé sur UDP, n’utilise ni accusés de réception ni fenêtres de congestion pour réguler l’envoi des paquets de données ordinaires. Par exemple, un tunnel WireGuard avec un RTT de 300 ms peut théoriquement maintenir le même débit de transfert de paquets qu’un tunnel avec un RTT de 3 ms, à bande passante disponible, pertes de paquets et capacités de traitement comparables.

Les applications communiquant à travers le tunnel VPN utilisent souvent TCP ou QUIC, qui dépendent des retours du point de terminaison récepteur. Faire passer le trafic par un serveur VPN éloigné peut augmenter le RTT subi par ces applications. Cela peut affecter leurs performances, sans pour autant établir si le goulot d’étranglement vient du comportement du transport, du chemin réseau ou du traitement par le routeur.

Le comportement des applications compte aussi. Ouvrir des fichiers dans un dossier partagé distant ou copier de nombreux petits fichiers peut nécessiter des requêtes et réponses répétées entre votre appareil et le serveur. Chaque aller-retour nécessaire ajoute un délai : ces tâches peuvent donc sembler lentes même si la connexion permet de télécharger rapidement un gros fichier. Agrandir la fenêtre de réception TCP ne supprime pas ces attentes au niveau applicatif.

Lien entre débit TCP et latence

Le produit bande passante-délai (BDP) est une relation utile pour comprendre le débit TCP sur les connexions à forte latence :

Produit bande passante-délai = Débit x RTT

Le BDP décrit la quantité de données qui doit rester en transit, c’est-à-dire envoyée mais pas encore acquittée, pour maintenir un débit donné sur une connexion ayant un RTT donné. Toutefois, cette relation ne permet pas à elle seule de déterminer le débit maximal atteignable ni d’identifier le facteur limitant d’une connexion réseau particulière.

Par exemple, maintenir un débit TCP de 100 Mbps avec un RTT de 288 ms nécessite environ 3.6 MB de données en transit non acquittées, à condition que le chemin réseau et les points de terminaison puissent par ailleurs supporter ce débit.

Voici quelques définitions importantes :

• Fenêtre de réception TCP (rwnd) : La quantité de données supplémentaires que l’appareil récepteur annonce pouvoir accepter, selon l’espace disponible dans son tampon de réception.
• Fenêtre de congestion TCP (cwnd) : La quantité de données non acquittées que l’émetteur est autorisé à maintenir selon son algorithme de contrôle de congestion et les conditions du réseau.
• Débit : La vitesse effective à laquelle les données sont transférées avec succès
• RTT (temps aller-retour) : Le temps nécessaire aux données pour circuler entre les points de terminaison et à une réponse pour revenir.

La limite effective des données TCP en attente côté émetteur dépend de la plus petite des fenêtres de réception et de congestion, ainsi que d’autres contraintes. Cette distinction est importante : une fenêtre de réception suffisamment grande ne garantit pas un débit élevé si le contrôle de congestion ou le chemin réseau empêche l’émetteur de maintenir suffisamment de données en attente.

Les pertes de paquets peuvent réduire le débit TCP en imposant des retransmissions et en amenant l’émetteur à réduire sa fenêtre de congestion. Sur une connexion à forte latence, les retours et la récupération peuvent prendre plus de temps ; une grande fenêtre de réception peut donc ne pas suffire à maintenir des transferts rapides.

Un exemple concret partagé sur le subreddit GL.iNet

Un membre du subreddit GL.iNet situé au Vietnam a rapporté les résultats suivants en se connectant à son serveur WireGuard domestique au Texas, hébergé sur un routeur GL.iNet Flint 2.

• Emplacement du serveur : Texas, États-Unis
  
  • Débits locaux (fibre symétrique) 700 Mbps en téléchargement / 940 Mbps en envoi
• Emplacement du client : Vietnam
  
  • Débits locaux (sans VPN) : 455 Mbps en téléchargement / 634 Mbps en envoi
    
  • Débits locaux (avec le client VPN WireGuard activé) : 47.3 Mbps en téléchargement / 12.1 Mbps en envoi, ping de 288 ms

N’oubliez pas que, lorsque vous téléchargez via un serveur VPN à domicile, votre débit descendant maximal dépend aussi du débit montant de la connexion Internet de ce domicile.

Ces mesures montrent un écart important entre les performances Internet locales et celles obtenues via la connexion WireGuard internationale. Cependant, ces tests ne mesurent pas nécessairement des chemins réseau équivalents. Un test local au Vietnam peut utiliser un serveur de test proche, alors que le trafic acheminé via le VPN doit d’abord traverser la liaison internationale vers le Texas. Cela implique d’autres réseaux de transit de FAI, accords de peering et points de congestion potentiels. Deux connexions internationales présentant une latence similaire peuvent offrir des débits très différents selon la qualité de leurs itinéraires. Bien que la connexion VPN ait affiché un RTT d’environ 288 ms, cette seule mesure ne prouve pas que la latence était la cause principale de la baisse de débit. Des pertes de paquets, un routage international inefficace, la congestion ou d’autres facteurs ont pu contribuer.

Identifions d’abord quelques facteurs courants pouvant affecter le débit réseau :

1. Variations des performances du FAI et congestion dans votre quartier : Le débit peut varier considérablement selon la congestion et la charge du réseau.
2. Performances Wi-Fi : Très variables selon l’environnement physique, les interférences d’autres appareils sans fil, les capacités de l’appareil client et la nature intrinsèquement semi-duplex du Wi-Fi, contrairement à l’Ethernet en duplex intégral
   • Pour une explication détaillée des débits Wi-Fi réellement possibles, consultez : https://www.wiisfi.com/
3. Routage des FAI et peering international : Le trafic entre pays peut traverser plusieurs réseaux exploités indépendamment. Des liens de peering saturés, des itinéraires inefficaces ou des pertes de paquets peuvent fortement réduire le débit, même si les deux extrémités disposent de connexions Internet locales rapides. Deux itinéraires internationaux présentant des RTT similaires peuvent offrir des débits très différents.

La congestion du FAI local et les conditions du routage international échappent généralement au contrôle direct de l’utilisateur, mais tester d’autres FAI ou itinéraires réseau peut révéler des différences de performances. Un mauvais routage international ou un peering saturé est souvent suspect lorsque les deux extrémités disposent d’un Internet local rapide mais que la liaison longue distance est lente. Un test via un autre FAI, par exemple dans un café, ou un point d’accès mobile peut aider à savoir si le ralentissement se situe sur le trajet. Les limites du Wi-Fi peuvent souvent être atténuées en utilisant Ethernet filaire dès que possible. Les limites de traitement du routeur et les problèmes de MTU méritent aussi d’être examinés lors du diagnostic du débit VPN.

En définitive, déterminer pourquoi une connexion VPN internationale est lente nécessite de distinguer les limites du chemin réseau, du routeur VPN et des applications communiquant à travers le tunnel.

Mise à l’échelle de la fenêtre TCP pour améliorer les performances

À l’origine, la fenêtre de réception TCP était limitée à environ 64 KB. La mise à l’échelle des fenêtres (RFC 7323) porte cette limite à environ 1 GiB, et les systèmes d’exploitation modernes ajustent automatiquement la fenêtre. Par exemple, le réglage d’ajustement automatique Normal documenté par Microsoft peut représenter des fenêtres de réception d’environ 16.8 MB. Les connexions TCP modernes ne sont donc pas intrinsèquement limitées à 64 KB.

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

Interaction entre les limites de fenêtre TCP et le RTT

Pour une connexion TCP avec une limite fixe de données en attente, le plafond approximatif de débit lié à la fenêtre est :

Débit en bits par seconde ≈ Limite de fenêtre en octets × 8 ÷ RTT en secondes

À limite de fenêtre constante, un RTT plus élevé produit un plafond lié à la fenêtre plus bas. Les exemples suivants illustrent cette relation ; ils ne prédisent pas le débit VPN réel.

Plafonds théoriques liés à la fenêtre (fenêtre ÷ RTT), avec 1 MB = 1,000,000 octets. Il s’agit d’illustrations, pas de prévisions du débit VPN réel.

Le débit réel dépend aussi du contrôle de congestion, des pertes de paquets, de la bande passante disponible et des limites de traitement. Plusieurs connexions TCP peuvent parfois atteindre un débit cumulé plus élevé, mais il n’existe pas de seuil universel de RTT au-delà duquel elles ne pourraient plus exploiter toute la bande passante disponible.

Dans l’exemple Vietnam-Texas, une connexion TCP unique hypothétique limitée à 2 MB de données en attente avec un RTT de 288 ms aurait un plafond lié à la fenêtre d’environ 55.6 Mbps. La ligne 300 ms du tableau est légèrement inférieure en raison de son RTT plus élevé. Cela n’établit toutefois pas pourquoi l’utilisateur a mesuré 47.3 Mbps.

Sans connaître le nombre de connexions du test, les fenêtres TCP réelles et les conditions du réseau, nous ne pouvons pas déterminer si le goulot d’étranglement était une limite de fenêtre, la congestion, les pertes de paquets, le routage du FAI ou autre chose.

Qu’est-ce qui détermine la taille de votre fenêtre TCP ?

Les tailles de fenêtre TCP sont propres à chaque connexion et peuvent évoluer pendant le transfert. Les valeurs des exemples ci-dessus ne doivent donc pas être considérées comme des réglages fixes s’appliquant à toutes les connexions de votre appareil.

Le système d’exploitation de l’appareil récepteur gère sa fenêtre de réception. Sa taille dépend notamment de l’espace disponible dans le tampon de réception, de l’ajustement automatique et des limites du système, des réglages de l’application et de la vitesse à laquelle celle-ci traite les données entrantes. Lorsque vous téléchargez un fichier sur votre ordinateur portable, celui-ci annonce sa fenêtre de réception au serveur émetteur. Lors d’un envoi, le serveur récepteur annonce sa fenêtre à votre ordinateur.

L’émetteur gère séparément sa fenêtre de congestion selon son algorithme de contrôle de congestion et les retours du réseau. Cela peut limiter la quantité de données en attente même lorsque le récepteur annonce une grande fenêtre. Dans une configuration WireGuard classique entre routeurs, ces fenêtres TCP appartiennent aux ordinateurs et serveurs qui communiquent ; elles ne correspondent pas à un réglage unique de taille de fenêtre sur les routeurs VPN.

Comment vérifier une connexion réelle ?

Si vous maîtrisez l’analyse de paquets, Wireshark peut afficher la fenêtre de réception TCP annoncée. Dans une configuration entre routeurs, capturez le trafic sur l’ordinateur qui effectue le transfert. Lancez la capture avant d’établir une nouvelle connexion TCP afin que Wireshark enregistre la négociation initiale et celle de la mise à l’échelle des fenêtres. Pendant un téléchargement, examinez un accusé de réception TCP émis par votre ordinateur pour ce transfert, développez la section Transmission Control Protocol et recherchez Calculated window size. Cette valeur indique la fenêtre de réception annoncée par votre ordinateur à cet instant, avec mise à l’échelle lorsque Wireshark connaît le facteur négocié.

Cette valeur peut changer durant le transfert. Elle ne révèle pas directement la fenêtre de congestion de l’émetteur et ne prouve pas que la fenêtre de réception limite les performances. Vérifier le réglage d’ajustement automatique du système d’exploitation ne permet pas non plus de connaître la fenêtre réelle actuellement annoncée par une connexion donnée.

Un autre exemple concret : un débit supérieur sans baisse du ping

Dans un autre cas d’assistance, j’ai étudié une connexion VPN Tailscale lente. Tailscale utilise le chiffrement WireGuard, mais ses options de relais peuvent transporter différemment les paquets chiffrés : les relais DERP utilisent des connexions TCP, tandis que les Tailscale Peer Relays utilisent UDP. Cela diffère d’une connexion WireGuard autonome, qui envoie normalement ses paquets chiffrés directement via UDP. Dans ce cas, les deux relais étaient auto-hébergés sur la même instance AWS Lightsail : la comparaison portait donc sur deux méthodes de relais hébergées à titre privé, et non sur les serveurs DERP publics de Tailscale.

La connexion Internet du client atteignait environ 83 Mbps lors du test, tandis que celle du serveur VPN présentait un débit montant mesuré d’environ 40.6 Mbps. Les débits descendants suivants ont été observés :

SQM signifie Smart Queue Management, une fonction du routeur servant à gérer les files de paquets et à réduire les délais excessifs sous charge. Dans cette comparaison, SQM était activé ou désactivé sur le routeur de voyage côté client.

SQM n’est pas une solution universelle aux faibles vitesses VPN. Lorsqu’il ne voit qu’un seul flux de tunnel chiffré, il ne peut pas attribuer de priorités distinctes aux connexions applicatives masquées à l’intérieur. Il peut toujours gérer la file de paquets partagée, mais cela ne réduit le délai d’attente que si l’accumulation excessive de paquets est un problème auquel il peut remédier. En l’absence d’une accumulation excessive de paquets que SQM peut contrôler utilement, des paramètres de bande passante inutilement restrictifs ou une charge de traitement supplémentaire peuvent réduire le débit sans améliorer la réactivité.

La latence est restée à peu près identique, mais le relais utilisant UDP a fourni un débit nettement supérieur avec SQM activé comme désactivé. La plus forte amélioration a accompagné le changement de méthode de relais, et non une baisse du ping ou la suppression de SQM.

Le transport TCP de DERP est un facteur possible. Chaque appareil Tailscale se connecte au relais DERP via TCP : les paquets chiffrés passent donc par des connexions TCP distinctes de part et d’autre du relais. Plusieurs connexions applicatives à l’intérieur du tunnel peuvent partager ces connexions TCP externes. Si des données sont perdues sur une connexion TCP externe, les données suivantes peuvent devoir attendre leur retransmission avant d’être livrées, ce qui risque de retarder plusieurs applications simultanément. Un Peer Relay utilisant UDP évite cette couche supplémentaire de transport TCP ordonné, même si les applications TCP dans le tunnel conservent leurs propres accusés de réception et leur propre contrôle de congestion.

Les deux relais fonctionnant sur la même instance, l’hôte et l’emplacement du relais étaient constants. Cela renforce l’idée que le transport ou l’implémentation du relais a contribué à l’amélioration, plutôt qu’un simple rapprochement du relais vers les utilisateurs. Toutefois, le même hôte ne garantit pas des chemins ou conditions réseau identiques : cette comparaison n’isole donc pas TCP contre UDP comme cause unique.

Ces observations proviennent d’un seul cas d’assistance et ne constituent pas des performances garanties. Elles montrent néanmoins pourquoi la latence seule ne suffit pas à prédire le débit d’un VPN.

Conclusion

J’espère que cet article vous a aidé à mieux comprendre pourquoi les débits descendants et montants d’une connexion VPN WireGuard longue distance peuvent être nettement inférieurs aux débits Internet disponibles à chaque extrémité. La distinction essentielle est que WireGuard lui-même n’impose aucun plafond de débit dépendant du RTT. Son transport de données fondé sur UDP n’implémente pas de fenêtres de congestion, d’accusés de réception ni de retransmissions de type TCP pour les paquets de données ordinaires.

Toutefois, les applications TCP et QUIC communiquant dans le tunnel restent soumises à leurs propres mécanismes de contrôle de congestion et de fiabilité. Un RTT plus élevé augmente la quantité de données en attente nécessaire pour maintenir un débit donné. Plusieurs connexions peuvent améliorer les performances cumulées, mais ni le RTT ni leur nombre ne détermine à lui seul la vitesse atteignable. Les performances réelles dépendent aussi des pertes de paquets, de la congestion, du routage et du peering des FAI, de la bande passante disponible, de la configuration MTU et de la capacité de traitement du routeur VPN.

Dans une configuration WireGuard classique entre routeurs GL.iNet, les connexions TCP sont établies entre les appareils terminaux et leurs serveurs de destination. Les routeurs VPN chiffrent, déchiffrent et transfèrent les paquets sans contrôler directement les fenêtres de réception TCP de ces connexions de bout en bout. Les limites matérielles du routeur peuvent affecter le débit des paquets chiffrés, mais ne doivent pas être confondues avec les limites de fenêtre de réception TCP.

Pour diagnostiquer une connexion WireGuard internationale lente, commencez par tester la connexion Internet à chaque endroit, avec Ethernet filaire si possible. Vérifiez si les performances du VPN changent selon l’heure ou lorsque vous utilisez une autre connexion Internet, par exemple un point d’accès mobile. Ces comparaisons peuvent aider à localiser le ralentissement, même si des tests plus détaillés peuvent être nécessaires pour en identifier la cause. Une forte latence peut ralentir les applications, mais ne doit pas être automatiquement considérée comme la seule explication d’un VPN lent.

À l’avenir, j’espère tester des relais UDP placés stratégiquement pour voir si d’autres itinéraires peuvent améliorer les performances du VPN WireGuard entre les États-Unis et l’Asie.

Pour mieux comprendre votre configuration VPN WireGuard et résoudre d’éventuels problèmes, consultez cet article du forum GL.iNet : https://forum.gl-inet.com/t/how-to-troubleshoot-wireguard/42502