Exposer un Serveur Local avec Cloudflare Tunnel

Pourquoi personne en dehors de votre réseau ne peut atteindre localhost

Un fournisseur de webhook a besoin d’une URL où faire un POST, et votre serveur tourne sur localhost:3000. Ou un collègue veut cliquer sur la branche que vous testez, ou votre téléphone doit atteindre le serveur de dev pour vérifier une mise en page. Le serveur tourne. Rien en dehors de votre réseau ne peut le joindre.

La redirection de port sur votre routeur fonctionnerait, mais elle expose l’IP de votre domicile et demande des droits d’administration que vous n’avez pas toujours. Cloudflare Tunnel prend l’autre direction. cloudflared, un petit daemon que vous lancez à côté de votre serveur, ouvre une connexion sortante vers l’edge de Cloudflare, et Cloudflare renvoie le trafic à travers elle. Vous n’ouvrez aucun port entrant et vous n’avez besoin d’aucune IP publique.

Il existe sous deux formes. Une quick tunnel vous donne une URL HTTPS publique en une seule commande, sur un hostname aléatoire qui meurt dès que vous arrêtez le processus. C’est l’outil pour une démo de cinq minutes ou un test de webhook. Une named tunnel vous donne un hostname stable sur votre propre domaine, qui survit aux redémarrages, ce qui en fait un petit morceau d’infrastructure réelle.

Comment Cloudflare Tunnel fonctionne sans port ouvert

L’astuce est un changement de direction. Exposer un service signifie normalement ouvrir un port entrant : quelque chose sur internet initie une connexion vers votre machine, qui a donc besoin d’une adresse routable et d’une règle de pare-feu qui laisse passer ce trafic. Bloquer exactement cela, c’est le travail du NAT et de la plupart des pare-feux domestiques ou d’entreprise.

cloudflared n’écoute jamais de connexion entrante. Il compose vers l’edge de Cloudflare via une connexion sortante HTTPS ordinaire, le même type de connexion que votre navigateur ouvre toute la journée, et la garde ouverte. Cloudflare pousse ensuite les requêtes le long de cette connexion et lit les réponses en retour, un peu comme un serveur pousse des messages sur un WebSocket vers un navigateur qui s’est connecté en premier. Votre pare-feu voit une seule connexion sortante qu’il autorise déjà. C’est aussi pour ça que le tunnel se comporte de la même façon derrière un NAT ou sur un ordinateur portable sans IP publique : une connexion sortante n’en a rien à faire.

Le prix à payer, c’est que Cloudflare se retrouve maintenant sur le chemin. Le hostname de votre tunnel pointe vers Cloudflare, qui déchiffre chaque requête à son edge, la rechiffre, puis l’envoie dans le tunnel jusqu’à votre daemon. C’est la même architecture qu’exécuter un service derrière un CDN ou un reverse proxy : vous renoncez à l’accès direct en échange d’une boîte intermédiaire qui termine le TLS et peut appliquer des règles d’accès avant que quoi que ce soit n’atteigne votre machine.

Comment créer une quick tunnel en une seule commande

Installez d’abord cloudflared : brew install cloudflared sur macOS, le paquet .deb/.rpm du dépôt de Cloudflare sur Linux, ou l’installeur Windows depuis la page des releases GitHub. Ensuite, avec quelque chose déjà à l’écoute sur un port local :

1

cloudflared tunnel --url http://localhost:3000

Quelques secondes plus tard, vous obtenez une sortie de ce type :

1
2
3
4
5

2026-09-23T10:14:02Z INF Thank you for trying Cloudflare Tunnel. Doing so...
2026-09-23T10:14:03Z INF +--------------------------------------------------------------------------------------------+
2026-09-23T10:14:03Z INF |  Your quick Tunnel has been created! Visit it at (it may take some time to be reachable):  |
2026-09-23T10:14:03Z INF |  https://wise-juvenile-pink-recovered.trycloudflare.com                                   |
2026-09-23T10:14:03Z INF +--------------------------------------------------------------------------------------------+

Cette URL sert du HTTPS avec un certificat géré par Cloudflare, vous ne touchez donc jamais à la configuration TLS. Laissez-lui quelques secondes pour commencer à résoudre. À partir de là, quiconque a le lien atteint votre localhost:3000, jusqu’à ce que vous appuyiez sur Ctrl-C. Le hostname disparaît alors pour de bon, et la prochaine exécution en génère un nouveau. Vous ne vous connectez pas, vous ne créez aucun enregistrement DNS, et vous n’avez besoin d’aucun compte.

Les limites sont réelles, cela dit. Le hostname est aléatoire, donc vous ne pouvez pas le mettre dans une config de webhook qui doit survivre à un redémarrage. Cloudflare plafonne les quick tunnels à 200 requêtes simultanées et ne supporte pas les Server-Sent Events dessus, donc un flux SSE de longue durée se coupera. Il n’y a non plus aucune garantie de disponibilité : les conditions d’utilisation de Cloudflare traitent les quick tunnels comme une commodité de test.

Pour déboguer un webhook maintenant ou laisser votre téléphone atteindre le serveur de dev, c’est tout ce dont vous avez besoin. Si ça doit encore tourner demain, montez une named tunnel.

Comment configurer une named tunnel sur votre propre domaine

Une named tunnel nécessite un compte Cloudflare gratuit et un domaine dont le DNS est chez Cloudflare. Vous faites cette configuration une seule fois.

1. Authentifiez cloudflared sur votre compte :

1

cloudflared tunnel login

Cela ouvre un navigateur et vous demande de choisir le domaine à autoriser. Un certificat est ensuite enregistré dans ~/.cloudflared/cert.pem, que toutes les commandes suivantes utilisent.

2. Créez le tunnel et notez son ID :

1

cloudflared tunnel create my-app

Cela enregistre un tunnel nommé my-app et écrit un fichier d’identifiants, <TUNNEL-ID>.json, dans ~/.cloudflared/. Ce fichier est l’identité du tunnel. Traitez-le comme un secret : quiconque le détient peut faire passer du trafic par votre tunnel.

3. Écrivez la config. Créez ~/.cloudflared/config.yml :

1
2
3
4
5
6
7
8
9

tunnel: my-app
credentials-file: /home/you/.cloudflared/<TUNNEL-ID>.json

ingress:
  - hostname: app.example.com
    service: http://localhost:3000
  - hostname: api.example.com
    service: http://localhost:8080
  - service: http_status:404

ingress est une liste ordonnée de règles hostname-vers-service, comparées de haut en bas. Si vous avez déjà configuré nginx comme reverse proxy devant vos apps, c’est la même idée de routage, écrite en YAML plutôt qu’en directives proxy_pass. Un seul tunnel peut exposer plusieurs services locaux sur des hostnames différents. La dernière règle est obligatoire. C’est le catch-all qui renvoie 404 pour tout hostname que les règles précédentes n’ont pas capté, et cloudflared refuse de démarrer sans elle.

4. Pointez le DNS vers le tunnel :

1

cloudflared tunnel route dns my-app app.example.com

Cela crée un enregistrement CNAME pour app.example.com pointant vers <TUNNEL-ID>.cfargotunnel.com. C’est de la résolution DNS ordinaire, visant l’infrastructure de tunnel de Cloudflare plutôt qu’une IP de serveur. Exécutez-la une fois pour chaque hostname de votre liste ingress.

5. Lancez-le :

1

cloudflared tunnel run my-app

app.example.com sert désormais tout ce qui écoute sur localhost:3000, en HTTPS. Cloudflare termine le TLS à l’edge, et votre origine peut rester en HTTP simple puisque la connexion du tunnel est déjà chiffrée.

Un tunnel lancé dans un terminal meurt avec le terminal. Pour qu’il survive à un redémarrage, installez-le comme service système :

1

sudo cloudflared service install

Sous Linux, en l’exécutant avec sudo, $HOME devient /root, et cloudflared ne peut plus retrouver un config.yml que vous avez créé en tant qu’utilisateur normal. Pointez-le explicitement vers le fichier à la place :

1

sudo cloudflared --config /home/you/.cloudflared/config.yml service install

Cela copie votre config vers /etc/cloudflared/config.yml et enregistre cloudflared auprès de systemd (ou launchd, ou le gestionnaire de services Windows), pour qu’il démarre au boot et redémarre s’il plante.

Quand Cloudflare Tunnel n’est pas le bon choix

Un tunnel convient quand le trafic part de l’extérieur de votre réseau et doit atteindre une machine sans IP publique, ou une machine que vous ne voulez pas exposer directement : un ordinateur portable, un serveur maison, une machine derrière un NAT d’entreprise. C’est le mauvais outil dans ces cas :

• Vous avez déjà un serveur avec une IP publique. Le tunnel ajoute l’edge de Cloudflare comme saut supplémentaire pour aucun gain. Un enregistrement DNS A plus votre propre reverse proxy ou terminaison TLS est plus simple et a un point de défaillance de moins.
• Vous avez besoin d’une latence garantie faible ou vous déplacez de gros volumes de données. Chaque octet passe par le réseau de Cloudflare. Pour la plupart du trafic web, ce coût est négligeable ; pour des charges à fort débit ou sensibles à la latence, il ne l’est pas.
• Le service doit rester debout quand une machine tombe. Un seul cloudflared sur une seule machine est un point de défaillance unique, et service install ne couvre que les redémarrages de processus. Si cette machine meurt, le hostname s’éteint. La redondance signifie faire tourner le même tunnel depuis une seconde machine.
• Votre code fait confiance à l’adresse TCP source pour des décisions de sécurité. Les requêtes atteignent votre origine depuis les plages d’IP de Cloudflare. La véritable IP du client arrive dans l’en-tête CF-Connecting-IP, et tout ce qui lit l’adresse du socket verra l’edge de Cloudflare à la place.

Quick tunnel ou named tunnel : par laquelle commencer

Si vous ne savez pas laquelle il vous faut, c’est une quick tunnel. Lancez cloudflared tunnel --url http://localhost:<port> contre ce sur quoi vous travaillez en ce moment et ouvrez l’URL. Passez à une named tunnel quand vous atteignez l’une de ses deux vraies limites : un hostname qui doit survivre à la session du terminal, ou un service qui doit continuer de tourner sans surveillance.

Articles associés

• Qu’est-ce qu’un Reverse Proxy et Comment Il Fonctionne
• Qu’est-ce que TLS et Comment Fonctionne le Chiffrement HTTPS
• Qu’est-ce que le DNS et Comment Fonctionne la Résolution
• Qu’est-ce qu’un CDN et Comment Il Fonctionne