Guide
Comment vérifier que votre VPN fonctionne
Six vérifications pour savoir si le tunnel transporte votre trafic, dans l'ordre qui permet de trouver d'abord les défaillances courantes. Aucune ne nécessite de logiciel autre qu'un navigateur, et chacune prouve une seule chose, rien de plus. Rédigé pour les clients de fin 2026.
Ce que cela permet d'établir
Un client qui indique connecté signale son propre état, pas l'endroit où va votre trafic. Les six vérifications ci-dessous répondent à cette seconde question. Faites-les une fois après l'installation, une fois après chaque mise à jour du client ou du système, et une fois sur tout réseau que vous n'avez encore jamais utilisé. Ensemble, elles prennent quelques minutes ; les trois premières, une seule.
Connectez-vous d'abord à la sortie que vous utilisez habituellement. Descendez ensuite la liste dans l'ordre : chaque vérification suppose que la précédente a réussi, et les défaillances courantes se trouvent en tête.
1. Votre adresse a changé
- Ouvrez une page indiquant « quelle est mon adresse IP » et lisez l'adresse ainsi que le pays qu'elle signale. Le pays doit correspondre à la sortie choisie ; l'adresse doit être une adresse que vous ne reconnaissez pas comme la vôtre.
- Déconnectez-vous et rechargez la même page. L'adresse devrait revenir à la vôtre. Si ce n'est pas le cas, la page est en cache ou un second tunnel intervient, et le premier résultat n'a rien prouvé.
- Reconnectez-vous et rechargez encore une fois. Trois lectures, dont deux différentes de celle du milieu, constituent l'intégralité du test. Une seule lecture effectuée pendant la connexion ne suffit pas.
Cela établit que la sortie se trouve devant votre navigateur. Cela ne dit rien sur les recherches de noms, les autres applications ou ce qui se passe lorsque le tunnel tombe, ce qui est l'objet du reste de cette page.
2. Les recherches passent dans le tunnel
- Effectuez un test de fuite DNS — n'importe quelle page proposant un test étendu, qui envoie de nombreuses recherches plutôt qu'une seule — et lisez la liste des résolveurs qu'elle signale, avec leurs propriétaires.
- Chaque résolveur doit appartenir au fournisseur VPN ou se trouver dans le pays de la sortie. Une seule entrée appartenant à votre fournisseur d'accès à Internet, ou située dans votre propre pays, suffit à faire échouer le test, quels que soient les autres résultats.
- En cas d'échec, configurez le DNS du client sur le résolveur du fournisseur, ou activez sa protection contre les fuites, reconnectez-vous et recommencez. Le réglage est décrit dans le guide de chaque plateforme ; la signification de la fuite est expliquée sur la page consacrée aux fuites DNS.
3. Le navigateur ne communique pas votre adresse
Les navigateurs prennent en charge un protocole pour les appels et la vidéo qui peut divulguer directement à une page vos adresses locale et publique, en contournant le tunnel. Il s'agit d'un réglage du navigateur, pas du client : un client parfaitement configuré réussit donc tous les autres tests et échoue à celui-ci.
- Effectuez un test de fuite WebRTC dans chaque navigateur que vous utilisez, pendant la connexion. Les fenêtres et profils privés ont leurs propres réglages ; testez donc celui dans lequel vous naviguez réellement.
- L'adresse publique qu'il signale doit être celle de la sortie, ou aucune adresse ne doit être signalée. Une adresse locale du type de celle attribuée par le routeur est normale et sans conséquence ; c'est votre propre adresse publique qui constitue l'échec.
- En cas d'échec, cherchez le réglage WebRTC dans le navigateur lui-même ou dans l'extension de navigateur du fournisseur, où la plupart des clients le placent, puis répétez le test après l'avoir modifié.
4. IPv6 ne le contourne pas
La plupart des réseaux attribuent désormais deux types d'adresses, et un client qui achemine l'ancien type dans le tunnel tout en ignorant le nouveau fuit vers tous les sites qui répondent sur les deux — c'est le cas de la plupart des grands sites. La vérification de l'adresse ci-dessus le manque souvent, car la page utilisée signale l'adresse par laquelle elle a été atteinte.
- Ouvrez une page de test IPv6 pendant la connexion. Les résultats corrects sont « aucune connectivité IPv6 » ou une adresse IPv6 appartenant à la sortie. Une adresse IPv6 située dans votre propre pays constitue une fuite.
- En cas d'échec, cherchez un réglage IPv6 dans le client : bloquer est le choix sûr, acheminer le meilleur lorsqu'il est proposé. Un client qui ne propose ni l'un ni l'autre nécessite de désactiver IPv6 sur l'adaptateur, au niveau du système d'exploitation.
- Répétez ensuite la première vérification : la désactivation d'IPv6 change l'adresse par laquelle la page de test vous contacte, et la réussite précédente doit être confirmée dans ces nouvelles conditions.
5. Un tunnel interrompu échoue en fermant l'accès
Tout ce qui précède décrit le tunnel lorsqu'il fonctionne. La vérification importante sur un mauvais réseau porte sur ce qui se passe lorsqu'il ne fonctionne plus, et elle suit sa propre procédure : comment tester un kill switch VPN. Faites-la une fois sur tout appareil qui sort de chez vous ; en bref, un téléchargement en cours doit s'arrêter net lorsque le tunnel est interrompu sans que le client en reçoive la demande. La raison de cette importance est expliquée sur la page consacrée au kill switch.
6. Une autre application que le navigateur
Jusqu'ici, chaque vérification a été effectuée dans un navigateur, et un navigateur peut être acheminé différemment du reste de la machine : une extension proxy, un VPN réservé au navigateur ou une règle de split tunneling peuvent faire réussir le test au navigateur alors qu'une autre application fuit, ou l'inverse.
- Choisissez une application qui affiche sa propre adresse de connexion — la vérification d'adresse intégrée à un client torrent, le journal de connexion d'un client de messagerie, le panneau réseau d'un jeu — ou effectuez la vérification de l'adresse dans un second navigateur que vous n'avez pas configuré.
- Son adresse doit être celle de la sortie, comme dans le premier test. Une adresse différente signifie que le tunnel ne couvre pas tout le système, et le réglage responsable est soit l'extension du navigateur, soit une règle de split tunneling.
Ce que signifie une réussite
Ce que ces vérifications établissent
+Votre trafic sort par le serveur de sortie, dans le pays sélectionné, depuis toutes les applications et pas seulement une
+Le réseau auquel vous êtes connecté ne voit ni les sites que vous consultez ni les recherches qui permettent de les trouver
+Ni le navigateur ni la nouvelle famille d'adresses ne transportent votre adresse autour du tunnel
Ce qu'elles n'établissent pas
−Elles ne disent rien de ce que conserve le fournisseur — c'est une question de documents, à laquelle répondent les pages sur la conservation
−Elles ne vous rendent pas anonyme : votre navigateur, vos connexions et vos habitudes ne changent pas ; voir ce qu'un VPN ne protège pas
−Une réussite aujourd'hui décrit le client d'aujourd'hui ; la prochaine mise à jour peut réinitialiser n'importe quel réglage de cette page
Lorsqu'un test échoue
La page d'adresse indique mon propre pays alors que le client affiche connecté
Le client fonctionne, mais le trafic ne passe pas par lui. Déconnectez-vous, quittez complètement le client plutôt que de fermer sa fenêtre, redémarrez-le et reconnectez-vous avant toute autre chose. Si le résultat se répète, un second VPN, un réglage proxy du navigateur ou un produit de sécurité doté de son propre filtre réseau prend généralement le trafic en premier.
Vérifiez en dernier les réglages proxy et les extensions du navigateur : une extension qui achemine le navigateur par son propre proxy prend le pas sur le tunnel système, et la page d'adresse voit la sortie de l'extension, pas la vôtre.
Le test DNS répertorie les résolveurs de mon fournisseur d'accès à Internet
Les recherches sortent du tunnel. Dans le client, activez la protection contre les fuites DNS ou configurez le DNS sur le résolveur du fournisseur, reconnectez-vous et relancez le test. Si les résolveurs appartiennent toujours à votre fournisseur d'accès à Internet, le système d'exploitation conserve son propre résolveur sur une autre interface, ce que les guides de chaque plateforme expliquent pour chaque système.
Un seul résolveur dans la liste suffit à faire échouer le test : une seule recherche divulguée révèle le site que vous avez consulté.
Le test IPv6 affiche une adresse lorsque le client est connecté
Le client achemine IPv4 dans le tunnel et laisse passer IPv6, et tous les sites qui répondent sur les deux voient votre véritable adresse. Cherchez un réglage IPv6 dans le client et configurez-le sur bloquer ou acheminer ; si le client ne propose ni l'un ni l'autre, désactivez IPv6 sur l'adaptateur réseau utilisé par le système d'exploitation. Relancez ensuite le test et attendez-vous à ne voir aucune adresse IPv6, ou une adresse appartenant à la sortie.
Tous les tests réussissent sur mon réseau domestique et l'un échoue sur un autre
Le second réseau intervient sur le trafic. Un réseau d'hôtel ou de bureau qui intercepte le DNS, supprime IPv6 ou interrompt les connexions de longue durée produit exactement un test en échec : le problème vient du réseau, pas du client. Le résultat est un fait concernant ce réseau, à garder en tête, et le kill switch empêche qu'un tunnel défaillant sur ce réseau ne devienne une connexion ouverte.
Tout fonctionnait hier et le test DNS échoue aujourd'hui
Quelque chose a changé ; les deux causes habituelles sont une mise à jour du client qui a réinitialisé un réglage et une mise à jour du système qui a ajouté un résolveur. Ouvrez les réglages du client et lisez-les au lieu de vous fier à leur état précédent ; les entrées DNS et kill switch sont les deux qui sont le plus souvent réinitialisées. Une vérification décrit le moment où elle a été effectuée, raison pour laquelle cette page mérite d'être consultée à nouveau après chaque mise à jour.
Mêmes étapes, autres appareils
Le reste des plateformes
Chaque plateforme a son propre guide plutôt qu'un onglet sur celui-ci. Les étapes divergent dès que l'installateur s'ouvre, et une page qui répond à trois plateformes à la fois ne répond correctement à aucune d'elles.