Comment savoir si votre serveur VPN domestique est limité par le processeur, le chiffrement ou Internet ? Le test local qui m’a évité d’acheter un nouveau mini-PC

J’avais déjà ouvert la fiche d’un mini-PC plus puissant. Mon serveur VPN domestique plafonnait autour de 90 Mb/s lorsque je m’y connectais depuis l’extérieur, alors que mon ordinateur distant dépassait largement 400 Mb/s sans tunnel. Dans ma tête, le diagnostic était presque terminé : le petit processeur du serveur n’arrivait pas à chiffrer assez vite. J’allais donc remplacer une machine qui fonctionnait parfaitement. Avant de commander, j’ai fait un dernier test en restant à l’intérieur de mon réseau domestique. Le même serveur VPN a dépassé 700 Mb/s. En quelques secondes, toute ma théorie s’est effondrée.

Le chiffre de mon abonnement Internet m’avait envoyé dans la mauvaise direction

Il est devenu très facile de posséder à la maison une connexion plus rapide que certains équipements qui l’entourent.

En France, une offre comme la Freebox Ultra annonce aujourd’hui jusqu’à 8 Gbit/s en débit descendant et montant.

Face à des chiffres pareils, j’avais fini par considérer Internet comme un élément presque hors de cause.

Mon serveur était relié en Ethernet.
Le NAS aussi.
WireGuard fonctionnait.
Aucune perte spectaculaire.
Pourtant, à distance, mes transferts plafonnaient.

J’ai commencé comme beaucoup de gens commencent : en regardant la consommation CPU, puis en lisant des discussions sur les algorithmes de chiffrement, puis en touchant au MTU.

Le problème, c’est que le même symptôme — « mon VPN ne dépasse pas 90 Mb/s » — peut être produit par des causes complètement différentes.

Le chiffre final ne dit pas laquelle.

Il fallait donc arrêter de regarder uniquement le résultat et isoler les morceaux du trajet.

La première chose que j’ai retirée du test a été Internet.

Mon premier vrai test ne sortait même pas de chez moi

J’ai installé iperf3 sur une machine du réseau local et lancé un test normal, sans VPN.
Un peu moins d’un gigabit.
Rien d’anormal.

Puis j’ai connecté un autre appareil au serveur VPN en utilisant son adresse locale. Le trafic passait toujours dans le tunnel, avec le même chiffrement et le même processeur, mais il ne quittait plus la maison.

Le résultat a dépassé 700 Mb/s.

iperf3 sert précisément à mesurer ce qu’un chemin réseau peut réellement transporter entre deux points.

Et ce test venait de m’apprendre plus de choses que tous mes Speedtest précédents.

Si le processeur ou le chiffrement avait réellement été bloqué autour de 90 Mb/s, le même serveur n’aurait pas soudainement produit sept ou huit fois plus de débit simplement parce que les paquets restaient sur mon LAN.

Le serveur savait aller vite.
C’était ce qui se passait après lui qui créait le plafond.
À ce moment-là, le mini-PC dans mon panier avait déjà beaucoup moins de sens.

J’avais complètement oublié le sens du débit montant

J’ai alors regardé ma connexion domestique avec un peu moins d’optimisme.
Elle était rapide en téléchargement.
Son débit montant l’était beaucoup moins.

Et lorsque je récupérais un fichier de mon NAS depuis l’extérieur, ce fichier devait faire quelque chose de très banal :

partir de chez moi.

Mon « téléchargement » sur l’ordinateur distant était donc, vu depuis mon domicile, un upload.

Le serveur pouvait chiffrer plusieurs centaines de mégabits par seconde.
Le réseau local pouvait les transporter.
Mais la connexion domestique ne pouvait pas les envoyer vers Internet au même rythme.

J’avais passé une heure à soupçonner le processeur parce que je regardais la vitesse depuis le mauvais côté du tunnel.

Une discussion WireGuard de février 2026 illustre bien ce piège : un utilisateur disposant d’une connexion domestique annoncée à 10 Gb/s essayait de comprendre quel débit attendre depuis un iPhone en 5G. Très vite, la discussion revenait à l’ensemble du trajet, et pas seulement au gros chiffre inscrit sur l’abonnement fibre.

Une fois que mon plafond VPN s’est retrouvé presque au même niveau que le débit montant réellement disponible chez moi, acheter un processeur plus puissant est devenu une solution à un problème que je n’avais pas.

Si le test local avait été lent, le processeur serait redevenu suspect

Le test inverse reste tout aussi révélateur.
Imaginons que le réseau local transporte 1 Gb/s sans VPN.
Puis que le même trajet, à travers le tunnel, plafonne à 120 Mb/s.
Et qu’au même moment un cœur du serveur soit collé à 100 %.
Là, le processeur mérite immédiatement l’attention.

OpenVPN rappelle d’ailleurs que les capacités CPU influencent directement le débit et que les instructions d’accélération comme AES-NI peuvent améliorer fortement le traitement d’AES. Sa documentation recommande aussi des outils comme openssl speed pour mesurer la capacité cryptographique brute d’une machine.

Ce test est beaucoup plus utile que de conclure simplement :
« mon mini-PC est trop lent ».
Un processeur saturé pendant un transfert VPN raconte une histoire.

Un processeur à 20 % qui attend que la ligne montante accepte les prochains paquets en raconte une autre.

Et c’est là que j’ai arrêté de vouloir séparer artificiellement « processeur » et « chiffrement ».

Le chiffrement est justement l’une des tâches qui consomment ce processeur.

La vraie question devient :

est-ce que la machine manque de puissance, ou est-ce que la manière dont le tunnel traite les paquets lui demande trop de travail ?

Le protocole peut déplacer le plafond sans changer le matériel

C’est là que comparer les protocoles devient utile.

WireGuard utilise notamment ChaCha20-Poly1305 et a été conçu pour un traitement efficace sur les processeurs généralistes.

OpenVPN peut de son côté profiter de l’accélération AES et de Data Channel Offload. DCO déplace une partie du traitement du trafic dans le noyau, ce qui réduit les passages coûteux entre différentes couches du système.

La traduction pratique tient en une phrase :

le même matériel peut aller nettement plus vite si on lui demande de traiter le tunnel de manière plus efficace.

Si mon test local plafonne avec une configuration puis gagne brutalement plusieurs centaines de mégabits avec un autre protocole ou avec DCO, je ne vais pas commander un nouveau serveur tout de suite.

Le processeur vient de prouver qu’il peut faire mieux.

C’est le chemin de traitement qui le retenait.

Cette méthode me paraît beaucoup plus utile que les raccourcis du type « OpenVPN est lent » ou « WireGuard est toujours rapide ».

Ce qui compte, c’est ce que mon serveur fait réellement avec la configuration que j’utilise.

Mon serveur domestique avait finalement trois plafonds différents

Après quelques essais, ma configuration est devenue beaucoup plus simple à lire.

Sans VPN sur le LAN, je voyais la capacité du réseau local.

Avec VPN sur le LAN, je voyais ce que le serveur, son processeur et son protocole pouvaient réellement traiter.

Avec VPN depuis l’extérieur, j’ajoutais enfin les connexions Internet, le routage, la latence et les éventuelles pertes.

Je n’avais donc pas un unique « débit VPN ».
J’avais plusieurs plafonds empilés.
Et le débit final ne pouvait dépasser le plus bas.
C’était presque embarrassant de simplicité.

Avant ce test, je regardais uniquement le dernier chiffre et j’essayais de deviner lequel des dix composants du trajet en était responsable.

Maintenant, je pouvais les éliminer un par un.

Mon diagnostic était réglé, mais ma connexion restait lente

Le test local avait sauvé le mini-PC.
Il n’avait pas augmenté le débit montant de ma connexion domestique.
Et j’étais toujours loin de chez moi avec du travail à terminer.

J’utilisais mon serveur maison comme tunnel complet. Même lorsque je voulais simplement consulter le Web ou envoyer un gros fichier vers un service cloud, mon trafic partait jusqu’à mon domicile avant de repartir vers Internet.

Pour atteindre mon NAS, ce détour était nécessaire.
Pour envoyer un fichier à un service public, beaucoup moins.
C’est à ce moment-là que OnlydogVPN^↗ est entré dans le test.

Je voulais surtout savoir si mon ordinateur distant et le réseau sur lequel je me trouvais étaient eux-mêmes capables de beaucoup mieux.

J’ai coupé le tunnel domestique, activé le mode de connexion rapide et relancé le même type de trafic.

Le débit a immédiatement dépassé le plafond que j’observais en passant par chez moi.
Même ordinateur.
Même Wi-Fi.
Ce qui avait disparu, c’était le détour par ma ligne domestique.

Cette comparaison m’a donné la réponse que j’attendais : mon serveur maison n’était pas le problème principal. Je lui demandais simplement de servir de sortie Internet universelle à travers un lien montant beaucoup plus étroit que le reste du trajet.

J’ai arrêté de faire revenir tout mon Internet par mon salon

C’est finalement ce changement qui m’a été le plus utile.

Lorsque j’ai besoin d’entrer sur mon réseau domestique pour récupérer un fichier ou administrer une machine, j’utilise toujours mon tunnel maison.

C’est exactement son rôle.

Mais lorsque j’ai simplement besoin d’une connexion VPN pour naviguer, télécharger ou travailler depuis un réseau extérieur, je n’envoie plus automatiquement tout le trafic jusqu’à mon domicile.

Avec le petit service, je lance le mode adapté et je laisse l’application choisir la route.

Je ne demande plus à mon serveur maison de devenir à la fois porte d’entrée vers mon LAN et sortie Internet générale.

Cette séparation paraît évidente après coup.

Elle ne l’était pas lorsque j’étais sur le point d’acheter une machine plus puissante pour compenser une limite située ailleurs.

Le service possède moins de régions et moins d’historique public qu’un grand fournisseur établi. Et il ne remplace pas mon serveur domestique lorsqu’il s’agit d’atteindre les machines privées chez moi.

Mais il n’a justement pas besoin de le remplacer.

Il me permet de réserver mon serveur domestique au travail qu’il est le seul à pouvoir faire.

Le test que je ferais désormais avant de toucher au chiffrement

Si mon serveur VPN domestique devient lent, je ne commence plus par modifier le protocole ou acheter du matériel.

Je regarde d’abord où le plafond apparaît.
Le réseau local est-il rapide sans tunnel ?
Le tunnel reste-t-il rapide lorsqu’il ne quitte pas la maison ?
Le processeur sature-t-il pendant ce test ?

Un changement de protocole ou une accélération comme DCO modifie-t-il fortement le résultat ?

Et seulement ensuite, je regarde ce qui se passe lorsque les mêmes données traversent Internet.

Si le VPN est déjà lent sur le LAN et que le CPU est saturé, je regarde le matériel et le traitement cryptographique.

S’il devient beaucoup plus rapide après un changement de protocole, la limite se trouvait davantage dans la façon de traiter le tunnel.

S’il est rapide à la maison mais s’effondre uniquement à distance, je regarde d’abord les deux accès Internet — surtout le débit dans le sens où les données doivent réellement quitter chaque site.

Je pensais que 90 Mb/s était la preuve qu’un petit processeur n’arrivait plus à suivre.

Le test qui m’a évité de le remplacer a simplement consisté à lui demander de faire exactement le même chiffrement sans laisser les paquets sortir de la maison.