Quick Tunnels – Votre projet localhost sur le web avec invitation
Cloudflare a sorti il y a petit moment maintenant une commande que pas mal de dev utilisent et dont je vais vous parler aujourd’hui : cloudflared tunnel --url, qui permet de publier un serveur tournant sur votre machine à une adresse en trycloudflare.com, sans avoir besoin de compte, de nom de domaine et surtout sans avoir à ouvrir le moindre port sur votre box toute pourrie.
Et la petite nouveauté depuis quelques jours, c’est que, autant avant, n’importe qui possédant le lien pouvait se connecter à votre service, mais maintenant, Cloudflare a mis en place
qui permet de réserver ce lien à quelques adresses e-mail que vous définissez.
Ce service s’appelle les Quick Tunnels, et pour en profiter, il vous faudra juste un service web qui tourne en local (moi je vais faire ça sur le port 8080 comme d’hab) avec une page de test toute bête servie par Python. Voilà c’est juste de quoi vérifier que tout passe bien avant d’y brancher un vrai projet. Et si vous faites bosser des agents IA avec ce truc, on verra aussi comment mettre un garde-fou pour éviter l’exposition sur le web de trucs pas prévus ! Argh !!
Installer cloudflared
cloudflared, c’est le petit connecteur open source de Cloudflare, celui qui établit la connexion sortante vers leur réseau. Sur Mac, pour l’installer c’est fastoche, suffit d’utiliser Homebrew :
brew install cloudflared
Sous Debian ou Ubuntu, passez par conte par le
de Cloudflare. Il a changé de clé de signature récemment, donc reprenez bien ces commandes plutôt que celles d’autres vieux tutos qui traînent :
sudo mkdir -p --mode=0755 /usr/share/keyrings
curl -fsSL https://pkg.cloudflare.com/cloudflare-main.gpg | sudo tee /usr/share/keyrings/cloudflare-main.gpg >/dev/null
echo 'deb [signed-by=/usr/share/keyrings/cloudflare-main.gpg] https://pkg.cloudflare.com/cloudflared any main' | sudo tee /etc/apt/sources.list.d/cloudflared.list
sudo apt-get update && sudo apt-get install cloudflared
Et sous Windows (les courageux !! lol), la page de téléchargement de Cloudflare propose un MSI ou un exécutable, en 32 ou 64 bits, et le paquet existe aussi chez winget sous l’identifiant Cloudflare.cloudflared. Dans tous les cas, vérifiez ensuite la version, car l’option d’authentification dont on va parler plus bas n’arrive qu’à partir de la version 2026.9.3 :
cloudflared --version
Ouvrir un tunnel public
Tout d’abord, lancez votre serveur local, puis dans un autre terminal, faites :
cloudflared tunnel --url http://localhost:8080
Au bout de quelques secondes, cloudflared affichera un encadré avec une adresse aléatoire composée de quatre mots, du genre quelque-chose-truc-bidule.trycloudflare.com, en prévenant qu’elle peut mettre un moment à répondre. Donc soyez un peu patient, le temps que le DNS résolve ce truc (et
si ça veut vraiment pas le faire).
Ensuite, ouvrez cette URL depuis un autre appareil, genre votre téléphone en 4G par exemple et hop, vous tomberaz sur votre serveur local. Et si vous voulez tout couper, un petit Ctrl+C dans le terminal et c’est fini ! Pas de panique, au prochain lancement de cloudflared, vous aurez une nouvelle adresse.
La commande de base, et le cadre où cloudflared affiche l’adresse trycloudflare.com à partager
Notez aussi que le port n’est pas imposé puisque --url accepte tout ce que cloudflared peut joindre, une adresse IP de votre réseau local comprise. Par contre, si votre projet tourne sous Vite, vous allez prendre un « Blocked request » en pleine tronche, car Vite ne répond par défaut qu’à localhost, aux domaines en .localhost et aux adresses IP. La parade la plus simple consiste donc à faire croire à Vite qu’on l’appelle via localhost:5173 en faisant comme ceci :
cloudflared tunnel --url http://localhost:5173 --http-host-header localhost:5173
L’autre solution, c’est d’ajouter l’hôte dans le réglage server.allowedHosts de Vite. Mais évitez de passer ce réglage à true pour aller plus vite, en effet
le déconseille puisque ça expose votre serveur de dev à des attaques par DNS rebinding. Oupsi oups !
Gardez aussi en tête que c’est un outil de test et de démo et que c’est pas fait pour de la prod. Si on en croit
, Cloudflare ne garantit aucune disponibilité, sans oublier que chaque tunnel encaisse au max 200 requêtes en simultanné (au-delà, ça vous fera une
) et les Server-Sent Events ne passeront pas. Voilà, donc si vous voulez un nom fixe et du vrai trafic, il faudra plutôt créer un tunnel nommé à partir d’un vrai compte Cloudflare et d’un domaine de votre choix.
Réserver l’adresse à quelques personnes
Et maintenant, pour limiter l’accès à votre service à quelques personnes, ajoutez --allowed-mail suivi de l’adresse email de celui à qui vous voulez montrer votre merveilleux boulot :
cloudflared tunnel --url http://localhost:8080 --allowed-mail korben@example.com
L’encardré change alors de "ton" en vous annonçant que le tunnel est "protégé" par une authentification de type code à usage unique via Cloudflare Access, ainsi que la quantité d’adresses autorisées. Les adresses elles-mêmes n’apparaissent nulle part, même dans la ligne des réglages où elles sont remplacées par des astérisques, ce qui est plutôt bien vu si vous faites une démo en mode partage d’écran. Ça évite les fuites de données perso !
Avec –allowed-mail, le cadre annonce le code à usage unique et le nombre d’adresses autorisées, sans jamais les afficher
Vous pouvez ensuite répéter l’option autant de fois que nécessaire, séparer plusieurs adresses par des virgules, ou autoriser tout un domaine. Mettez simplement des guillemets autour du "joker" (c’est l’étoile) pour que votre misérable shell ne tente pas de l’interpréter comme un gros teubé :
cloudflared tunnel --url http://localhost:8080
--allowed-mail korben@example.com
--allowed-mail bob@example.com
--allowed-mail '*@example.com'
Côté Wrangler, si vous bossez sur Workers, un petit npx wrangler tunnel quick-start acceptera la même option :
npx wrangler tunnel quick-start http://localhost:8080 --allowed-mail korben@example.com
De son côté, votre invité VIP n’aura alors plus qu’à ouvrir l’URL que vous lui avez donné et cloudflared renverra son browser vers login.trycloudflare.com. Il tombera alors sur une page Cloudflare Access qui lui demandera son adresse mail. Il recevra ensuite un code dans sa boîte, devra le taper, et arrivera enfin (ouf !!) sur votre merveille application probablement vibe codée (lol).
Et quelqu’un qui n’est pas sur la liste des invité ne verra quand à lui qu’une réponse de base lui expliquant qu’il peut bien aller se faire voir (et sa requête n’atteindra jamais votre application).
Ce que voit votre invité en ouvrant l’URL protégée : la page Cloudflare Access qui lui demande son adresse mail
Et votre liste d’emails, elle, n’est jamais diffusée hors de votre ordi puisque Cloudflare vérifie seulement que la personne contrôle l’adresse qu’elle a saisie. Ensuite c’est cloudflared qui compare les accès en mémoire, avec ce que vous avez tapé. Une fois entré, le visiteur gardera alors sa session jusqu’à 4 heures max.
Et si vous voulez modifier cette liste d’accès, il faudra alors arrêter le tunnel et en relancer un autre, ce qui coupera l’accès à tout le monde et vous donnera une nouvelle adresse à renvoyer. Donc soyez sûr de votre coup avant de casser la tête aux gens qui vont tester votre appli.
Sachez aussi que cette vérification ne pourra se faire qu’avec un vrai navigateur et pas des trucs du genre un webhook Stripe, un GitHub, un script en curl ou encore n’importe quel client automatique qui restera coincé devant cette page de connexion.
Pour ces cas-là précieusement, je vous recommande plustôt d’ouvrir un tunnel public le temps du test et de le couper juste après. Et si le webhook doit tourner durablement, passez sur un tunnel nommé avec Cloudflare Access, sur votre propre domaine.
Le confier à votre agent IA
Maintenant, parlons un petit peu à agents IA parce que oui… Un agent de code a besoin d’un endroit pour vous montrer ce qu’il vient de faire de beau, et Cloudflare décrit justement ce cas de figure dans son article.
Pour éviter qu’un agent IA ne diffuse publiquement ce qu’il vient de faire à la vue de tous, ce que recommande Cloudflare, c’est donc d’ajouter une ligne dans le fichier d’instructions de l’agent AGENTS.md comme ceci :
Quand tu lances un Quick Tunnel, ajoute toujours --allowed-mail moi@exemple.fr.
Sauf qu’une consigne reste une consigne… C’est un prompt que l’agent peut choisir d’ignorer… Donc gardez bien en tête que ces fichiers sont traités comme du contexte et pas comme une configuration imposée.
Maintenant, si vous voulez vraiment bloquer une action, peu importe ce que décide le modèle, ce que je vous recommande d’utiliser à la place, c’est un hook « PreToolUse ». Moi, j’en mets partout dans mes configs Claude Code pour plus de sécurité.
Si vous ne savez pas ce qu’est un hook, en fait c’est un petit script contenant la commande en JSON, et que Claude Code lance avant chaque commande bash. Si ce script se termine avec le code "2" l’appel est alors bloqué. Pour faire ça, il faut donc créer dans le dossier .claude/hooks/ de votre projet, le script suivant :
#!/bin/bash
# .claude/hooks/tunnel-protege.sh
COMMAND=$(jq -r '.tool_input.command')
if echo "$COMMAND" | grep -qE 'cloudflared.*tunnel.*--url|wrangler.*tunnel.*quick-start'
&& ! echo "$COMMAND" | grep -q -- '--allowed-mail'; then
echo "Quick Tunnel public refusé : ajoutez --allowed-mail, ou demandez-moi d'abord." >&2
exit 2
fi
exit 0
Puis rendez-le exécutable avec chmod +x, et installez jq si vous ne l’avez pas encore fait.
Déclarez-le ensuite dans le .claude/settings.json du projet, sur l’outil Bash comme ceci :
{
"hooks": {
"PreToolUse": [
{
"matcher": "Bash",
"hooks": [
{
"type": "command",
"command": "${CLAUDE_PROJECT_DIR}/.claude/hooks/tunnel-protege.sh"
}
]
}
]
}
}
Maintenant, si ça vous prend trop le chaud de faire ça, sachez que j’ai fait un petit kit à télécharger ici, pour les
:
Ensuite, à partir de là, un cloudflared tunnel --url ou un wrangler tunnel quick-start lancé sans le paramètre --allowed-mail ne fonctionnera pas, et l’agent recevra le message du hook qui lui dira d’ajouter l’option ou de vous demander s’il doit y avoir un contournement.
Et bien sûr, un tunnel nommé lancé avec cloudflared tunnel run, lui, passera normalement.
Comme d’hab, ce genre de garde-fou a ses limites, puisqu’il ne lit que le texte de la commande et ne vérifiera pas l’adresse qui suit l’option. Il ne verra non plus les tunnels qui pourraient être lancés depuis un script ou à l’aide d’une variable d’environnement TUNNEL_URL, qui permet aussi de lancer un Quick Tunnel. Voilà, donc laissez la consigne dans AGENTS.md en plus du hook, au cas où… Les deux devraient bien se compléter.
Pour
, le kit ci-dessus reprend donc ce hook avec les consignes à coller dans AGENTS.md, dont l’exception des clients automatiques (l’agent vous demande au lieu de retirer l’option).
Il y a aussi là dedans un script qui lance le tunnel protégé et ne renvoie que son adresse. Et si vous préférez scripter ça vous-même, partez de --output json, qui transformera chaque ligne du log en objet JSON. L’adresse sera alors accessible dans le champ message, et vous pourrez alors l’extraire avec une expression régulière.
Ah et un dernier point avant de lâcher un agent là-dessus sur le portable de votre boulot, je vous invite à lire ce que
concernant des campagnes de malware qui s’appuient sur ce genre de tunnels gratuits. Ça explique pourquoi des outils de sécurité comme Elastic ont des règles qui repèrent cloudflared quand il est utilisé pour exposer un service local. Leur conseil c’est de bloquer les domaines de tunnel quand l’usage n’est pas autorisé, donc si vous comptez utiliser ça dans votre boite, allez voir Dieu Tout Puissant (le sysadmin grognon quoi…) pour lui demander l’autorisation. Il va pester, souffler, éventuellement vous cracher dessus puis finira probablement par accepter, donc pas d’inquiétude ^^.
Et comme la protection par mail est gratuite, au même titre que les Quick Tunnels eux-mêmes, je ne vois aucune raison valable de balancer une démo accessible sur le web sans utiliser cette authentification.
Source : korben.info