Mon VPN ne se connecte pas : la question à se poser avant de changer quoi que ce soit (2026)

« Mon VPN ne se connecte pas » recouvre deux pannes opposées, et c'est pour cela que les conseils trouvés au hasard ne fonctionnent presque jamais : ils traitent l'autre.

Avant de changer un protocole, un serveur ou une application, il y a une question à trancher. Elle prend trente secondes et elle divise le problème en deux.

La question : est-ce que le tunnel monte, oui ou non ?

Cas A — le client n'arrive jamais à l'état « connecté ». Il tourne, il expire, il recommence. Rien ne s'établit. La cause est presque toujours à l'extérieur de votre configuration : le réseau ne laisse pas sortir ce qu'il faut, l'adresse du serveur ne répond plus, ou les identifiants sont refusés.

Cas B — le client affiche « connecté », mais plus rien ne passe. C'est une panne complètement différente, et elle est plus fréquente qu'on ne le croit. Le tunnel est monté ; ce qui échoue, c'est ce qui circule dedans.

Confondre les deux fait perdre des heures, parce que les remèdes du cas A n'ont aucun effet sur le cas B.

Cas B d'abord : « connecté », mais pas d'Internet

Le client annonce « connecté » dès que le tunnel est établi. L'accès aux sites dépend d'une étape suivante : la résolution des noms de domaine.

Le symptôme qui identifie ce cas sans ambiguïté : une adresse IP répond encore, mais aucun nom de domaine ne se résout. Si 1.1.1.1 répond au ping et que example.com ne donne rien, ce n'est pas la connexion qui est en cause, c'est le DNS.

Trois causes ordinaires :

le serveur DNS annoncé par le tunnel n'est pas joignable à travers ce tunnel ;
une configuration route tout le trafic mais oublie la route vers ce serveur DNS ;
l'appareil garde en mémoire l'ancien résolveur et interroge une adresse qui n'existe plus dans le nouveau réseau.

Dans les trois cas, le tunnel est en parfait état de marche. C'est ce qui rend le diagnostic contre-intuitif.

Cas A : le tunnel ne monte pas

La preuve la plus rapide : changer de réseau

Testez le même profil sur le partage de connexion de votre téléphone. S'il monte immédiatement là et pas ailleurs, le problème est le réseau et non votre configuration. Aucun outil, aucun réglage modifié, et la moitié des hypothèses tombent.

Une femme aux cheveux bouclés et aux lunettes, en sweat jaune pâle, assise à une table en bois, la main sur le front et les yeux fermés devant un ordinateur portable ouvert

Une femme aux cheveux bouclés portant des lunettes, vêtue d'un sweat jaune pâle, est assise à une table en bois. Elle a la main posée sur le front et les yeux fermés, devant un ordinateur portable ouvert ; l'arrière-plan de la pièce est flou.

Les réseaux qui ne laissent pas sortir l'UDP

Beaucoup de réseaux de passage — hôtels, gares, réseaux invités d'entreprise — ne laissent sortir que du TCP sur les ports 80 et 443. Or la plupart des protocoles VPN modernes reposent sur UDP. Les paquets ne partent tout simplement pas, et le client n'affiche pas d'erreur explicite : il expire.

Deux vérifications utiles sur place :

Le portail captif. Tant que la page d'authentification n'a pas été validée, aucun trafic n'est autorisé. Ouvrez une page en http:// et non en https:// : beaucoup de portails ne savent pas rediriger une page chiffrée, et vous ne voyez jamais le formulaire.
Une variante TCP du même service, si votre client en propose une. C'est le seul changement de protocole qui répond à une cause identifiée plutôt qu'à une intuition.

Sur iPhone : le profil, pas seulement l'application

Sur iOS, un VPN s'appuie sur un profil de configuration et sur le réglage système. Deux causes reviennent régulièrement : un profil révoqué ou jamais validé, et l'option « à la demande » qui relance un ancien tunnel sans qu'on l'ait demandé.

Dans Réglages > Général > VPN et gestion de l'appareil, vérifiez que le profil actif est celui que vous croyez. Désactivez temporairement « à la demande » pour tester une connexion manuelle : si elle passe, c'est l'automatisme qui rejouait un profil obsolète.

Le cas particulier des clients d'entreprise

Un client d'entreprise ajoute des couches absentes du grand public : authentification à plusieurs facteurs, certificat de poste, contrôle de conformité, tunnel partiel. Un échec peut donc venir d'un compte, d'un certificat expiré ou d'une politique, sans qu'aucun réglage réseau ne soit en cause.

C'est un cas où l'auto-dépannage atteint vite sa limite : le service informatique dispose de journaux que vous n'avez pas.

Si vous hébergez vous-même le serveur

Quand le serveur est le vôtre, deux causes supplémentaires apparaissent, et elles n'ont rien à voir avec le client :

l'adresse publique a changé. Sur un accès sans IP fixe, tous les profils pointent ensuite dans le vide. Un nom DynDNS règle la question une fois pour toutes ;
la redirection de port ne correspond plus. Le port ouvert, le port écouté et le port inscrit côté client doivent coïncider — notre article sur le port utilisé par WireGuard détaille les trois points à aligner.

Reste le cas où aucune redirection n'est possible, parce que l'opérateur ne fournit pas d'adresse publique dédiée. Là, il n'y a rien à régler : il faut un serveur qui en possède une.

Ce qu'un tunnel qui fonctionne ne corrige pas

Une fois le VPN connecté, l'adresse que voient les sites est bien celle du serveur. En revanche, rien ne change dans ce que votre navigateur annonce de lui-même : polices, résolution d'écran, fuseau horaire, pile graphique. Cette combinaison suffit souvent à vous reconnaître d'une session à l'autre, tunnel ou pas.

Mesurez votre propre empreinte de navigateur — mesure passive, aucune question, aucun compte, aucune adresse e-mail. Elle vous dit combien de navigateurs sur N ressemblent au vôtre, et quel attribut vous singularise.

En résumé

Ce que vous observez	Cause probable	Premier geste
Jamais « connecté »	réseau bloque l'UDP	tester via le partage de connexion
Jamais « connecté », partout	serveur ou identifiants	vérifier l'adresse et le compte
« Connecté », rien ne charge	DNS	tester une IP brute contre un nom de domaine
iPhone seulement	profil ou « à la demande »	vérifier le profil dans Réglages
Client d'entreprise	compte, certificat, politique	passer par le service informatique

La règle qui fait gagner le plus de temps : ne changer qu'un paramètre à la fois, et le remettre comme avant quand il n'a rien changé. Une pile de réglages modifiés au hasard finit par créer une seconde panne par-dessus la première.

★ Datacenter Nuremberg GDPR · ✓ IPv4 dédiée incluse · 200+ Mbps garantis

Héberge ton VPN sur ton propre VPS → ContaboAccès root complet · IPv4 publique · choisis ta région→

Questions fréquentes

Mon VPN dit « connecté » mais je n'ai plus Internet, pourquoi ?

Parce que ce sont deux étapes distinctes. Le client annonce « connecté » quand le tunnel est monté ; l'accès à Internet dépend ensuite de ce qui passe dedans, c'est-à-dire du routage et surtout de la résolution DNS. Si le tunnel capte tout le trafic mais que le serveur DNS annoncé n'est pas joignable à travers lui, aucun nom de domaine ne se résout : les adresses IP répondent encore, les sites non. C'est la panne la plus fréquente derrière la formule « connecté mais pas d'Internet », et elle n'a rien à voir avec un échec de connexion.

Comment savoir si le problème vient du réseau ou de ma configuration ?

Testez le même profil sur une autre connexion, typiquement le partage de connexion de votre téléphone. Si le tunnel monte immédiatement là et pas sur le réseau d'origine, le problème est le réseau et non votre configuration : c'est la preuve la plus rapide à obtenir, sans outil et sans modifier un seul réglage. Beaucoup de réseaux de passage, en hôtel ou en entreprise, ne laissent sortir que du TCP sur les ports 80 et 443 et bloquent l'UDP dont dépendent la plupart des protocoles VPN modernes.

Pourquoi mon VPN ne se connecte pas sur iPhone alors qu'il fonctionne sur l'ordinateur ?

Sur iOS, un VPN passe par un profil de configuration et par le réglage système, pas seulement par l'application. Deux causes reviennent : le profil a été révoqué ou n'a jamais été validé dans Réglages, et l'option « à la demande » réactive un ancien tunnel sans que vous le demandiez. Vérifiez dans Réglages > Général > VPN et gestion de l'appareil que le profil actif est bien celui que vous croyez, et désactivez temporairement « à la demande » pour tester une connexion manuelle.

Faut-il changer de protocole quand la connexion échoue ?

Seulement après avoir identifié la cause. Passer d'un protocole UDP à une variante TCP a un intérêt précis - franchir un réseau qui ne laisse sortir que du TCP - et c'est une vraie solution dans ce cas. Mais si la panne vient du DNS, d'un profil expiré ou d'identifiants refusés, changer de protocole ne corrige rien et ajoute une variable de plus à démêler. La règle utile est de ne modifier qu'un paramètre à la fois, et de revenir en arrière quand il n'a rien changé.

Un VPN d'entreprise se dépanne-t-il comme un VPN personnel ?

Non, et c'est une source de confusion fréquente. Un client d'entreprise ajoute des couches qui n'existent pas côté grand public : authentification à plusieurs facteurs, certificat de poste, contrôle de conformité de la machine, tunnel partiel qui ne route qu'une partie du trafic. Un échec peut donc venir d'un compte, d'un certificat expiré ou d'une politique, sans qu'aucun réglage réseau ne soit en cause. Dans ce contexte, le service informatique voit des journaux que vous n'avez pas, et c'est par là qu'il faut commencer.