Quel VPN fonctionne sur TCP 443 lorsque les autres connexions échouent ? J’ai découvert que le port 443 ne suffisait pas

Le navigateur fonctionnait parfaitement. Le VPN, pas du tout. J’étais sur le Wi-Fi invité d’un centre de conférences, vingt minutes avant une démonstration à distance. Actualités : ouvertes. Messagerie web : ouverte. Site du client : ouvert. Puis j’activais mon VPN habituel.

Connecting… Connecting… Échec. Sur le partage 5G de mon téléphone, le même VPN se connectait immédiatement. Retour au Wi-Fi. Échec. J’avais donc déjà isolé une bonne partie du problème : ce n’était ni mon ordinateur, ni mon abonnement, ni probablement le serveur VPN.

C’était ce réseau. J’ai cherché la solution sur mon téléphone et suis tombé sur le conseil qui revient depuis des années : essayez TCP 443. Cela avait du sens. Le port 443 est celui utilisé habituellement par HTTPS. Si le Wi-Fi me permettait d’ouvrir des sites web sécurisés, un VPN fonctionnant sur TCP 443 semblait avoir de bonnes chances de passer lui aussi.

Je pensais avoir trouvé le raccourci. J’allais découvrir qu’un numéro de port ne suffit pas à rendre deux trafics identiques.

Pourquoi TCP 443 est devenu le conseil classique

OpenVPN prend réellement en charge TCP.

Sa documentation explique que le protocole fonctionne généralement mieux en UDP, mais que TCP devient utile sur des réseaux restrictifs qui n’autorisent qu’un petit nombre de protocoles courants. OpenVPN Access Server utilise d’ailleurs TCP 443 par défaut pour ses connexions TCP, précisément parce que ce port associé à HTTPS est très souvent autorisé.

Voilà pourquoi le conseil n’est pas absurde. Imaginez un bâtiment avec vingt portes dont dix-neuf sont fermées. La porte 443 reste ouverte parce que presque tout le monde a besoin du Web. Faire passer le VPN par cette porte peut suffire lorsque le réseau filtre simplement selon le protocole ou le numéro de port.

Mais encore faut-il que le VPN propose réellement cette possibilité. WireGuard, par exemple, ne possède pas de mode TCP natif. Sa documentation est explicite : WireGuard fonctionne en UDP ; faire passer ce trafic via TCP demande une couche supplémentaire.

Cela expliquait déjà pourquoi certains boutons « port 443 » que je cherchais dans des applications n’existaient tout simplement pas.

Je n’étais manifestement pas le seul à chercher ce bouton

Quelques jours avant cette comparaison, le 26 août 2026, un utilisateur de r/VPN décrivait presque exactement cette confusion. Son Wi-Fi bloquait les VPN. Il avait lu qu’OpenVPN sur TCP 443 pouvait aider, installé OpenVPN, activé TCP… puis découvert qu’il ne savait toujours pas comment imposer précisément le port 443 et que son application VPN proposait une autre plage de ports.

C’est une frustration très reconnaissable. Le conseil technique tient en deux mots : TCP 443. L’exécution dépend entièrement de ce que le fournisseur expose dans son application et de la façon dont ses serveurs sont configurés. Mon grand fournisseur proposait heureusement OpenVPN TCP.

Je l’ai donc sélectionné. Puis j’ai choisi 443. Connecter. Cette fois, la tentative est allée plus loin. Puis elle a échoué. J’ai recommencé avec un autre serveur. Même résultat. Le conseil était techniquement valable. Il ne résolvait simplement pas ce Wi-Fi.

Et c’est là que j’ai cessé de croire que le problème se résumait à « trouver le bon port ».

Le port ressemblait à HTTPS ; le trafic n’était pas devenu une page web pour autant

Utiliser TCP 443 signifie que la connexion emprunte le même numéro de port que beaucoup de trafic HTTPS. Cela ne veut pas dire que le trafic devient automatiquement indistinguable d’une navigation web ordinaire. Un filtrage simple peut se contenter de dire :

« TCP 443 est autorisé. » Un réseau plus attentif peut regarder la manière dont la connexion se comporte et reconnaître qu’il ne s’agit pas du trafic attendu. Voilà pourquoi TCP 443 peut être un très bon plan B sans être un passe-partout.

Un autre utilisateur racontait d’ailleurs avoir fait fonctionner OpenVPN sur TCP 443 pendant un temps sur un réseau universitaire restrictif avant que cette solution cesse elle aussi de fonctionner.

Mon propre test me racontait la même chose. La porte 443 était ouverte. Mais quelqu’un regardait encore ce qui la traversait. À ce moment-là, tester un troisième serveur TCP aurait surtout ajouté une nouvelle ligne à ma liste d’essais.

Le choix suivant n’avait même pas de mode « TCP 443 »

C’est la partie qui m’aurait semblé illogique une heure plus tôt. J’ai ouvert OnlydogVPN^↗. Le service possède moins de régions et moins de recul public que mon fournisseur habituel. Et surtout, il ne s’agit pas d’un VPN TCP 443 : son transport documenté est basé sur HTTP/3, donc sur QUIC, qui utilise UDP.

Si ce Wi-Fi avait réellement bloqué tout UDP et n’avait autorisé que TCP 80 et TCP 443, cette différence aurait été décisive en faveur d’un service proposant OpenVPN TCP 443. Mais ce n’était manifestement pas ce qui se passait devant moi. Le réseau laissait passer certaines connexions et en perturbait d’autres.

J’ai donc arrêté de chercher le bon numéro et choisi le mode destiné aux réseaux restrictifs. Pas de sélection manuelle du port. Pas de troisième serveur TCP. Connexion. Connected. J’ai attendu. Toujours connecté. Je suis revenu à l’outil de démonstration.

Il s’est ouvert.

Le moment décisif n’a pas été le badge « Connected »

Je n’avais pas besoin d’un VPN supplémentaire capable d’afficher une icône verte. J’avais besoin de prendre la main sur une machine distante avant le début de ma présentation. Identifiant. Validation. Le bureau distant est apparu. J’ai déplacé une fenêtre.

Réponse immédiate. J’ai ouvert la présentation. Diapositive 1. Diapositive 2. Vidéo de démonstration. Lecture. Il me restait onze minutes. C’est seulement après que j’ai regardé ce que le second service faisait différemment.

Son mode pour réseaux restrictifs combine un transport basé sur HTTP/3 avec une couche d’obfuscation supplémentaire. Le but n’est pas simplement de changer de port, mais de rendre le tunnel moins évident à identifier comme une connexion VPN classique.

Sur ce Wi-Fi, c’était exactement la différence qui m’intéressait. Même ordinateur. Même réseau. Même destination. OpenVPN TCP 443 n’avait pas terminé la connexion. Le mode restrictif avait ouvert mon bureau distant.

HTTP/3 sur 443 et TCP 443 sont deux choses qu’il vaut mieux ne jamais confondre

C’est probablement le détail technique le plus utile de toute cette expérience. Le Web moderne utilise largement le port 443, mais il peut y arriver par deux chemins différents. HTTP/1.1 et HTTP/2 utilisent généralement TCP. HTTP/3 utilise QUIC.

QUIC fonctionne sur UDP. Donc : TCP 443 ≠ UDP 443. Le numéro est identique. Le transport ne l’est pas. Je le vois comme deux files qui passent par une entrée portant le même numéro. Le gardien peut laisser entrer les deux.

Il peut n’en autoriser qu’une. Il peut aussi regarder ce que chaque file transporte. Voilà pourquoi demander seulement « le port 443 est-il ouvert ? » ne permet pas de prédire quel VPN fonctionnera. Cette distinction m’a évité de transformer la suite en chasse au port.

Le test que je fais maintenant prend moins de deux minutes

Quand un VPN fonctionne sur mon partage 5G mais échoue sur un Wi-Fi précis, je ne commence plus par changer cinq fois de pays. Je coupe d’abord le VPN et vérifie que le réseau fonctionne réellement. Ensuite, je regarde ce que le fournisseur permet. S’il propose OpenVPN TCP 443, je le teste : c’est particulièrement utile lorsqu’un réseau bloque UDP ou les ports VPN habituels.

Si TCP 443 échoue aussi alors que HTTPS fonctionne, je cesse de croire que le numéro du port résoudra tout. Je cherche une méthode qui modifie davantage la manière dont le tunnel se présente au réseau — exactement ce que vise un mode d’obfuscation conçu pour les environnements restrictifs.

Cette distinction m’aurait évité plusieurs minutes perdues au centre de conférences.

TCP 443 reste utile. Ce n’était simplement pas le vrai critère ce jour-là

Je continue à vouloir cette option dans une boîte à outils VPN. OpenVPN lui-même explique pourquoi elle existe : certains réseaux publics laissent passer le trafic TCP courant tout en bloquant UDP ou des ports moins ordinaires, et TCP 443 peut alors être exactement le chemin nécessaire.

Mais ce matin-là, j’avais confondu : « TCP 443 peut passer certains pare-feu » avec :

« tout VPN utilisant TCP 443 passera n’importe quel réseau restrictif ».

La première phrase est utile. La seconde ne tient pas. Mon grand fournisseur m’avait donné le mode TCP que je cherchais. Le service plus petit m’avait donné ce dont j’avais réellement besoin : une connexion utilisable sur ce réseau sans me demander de continuer à deviner le port, le protocole et le serveur.

J’avais commencé la matinée en cherchant quel VPN fonctionne sur TCP 443.

Onze minutes avant ma démonstration, la question qui comptait n’était plus de savoir par quelle porte le tunnel était entré : mon bureau distant était déjà ouvert de l’autre côté.