En bref

  • Problème : exposer vite un petit service local pour le vérifier depuis ailleurs, sans transformer un test en infrastructure durable.
  • Ce que j’ai testé : Cloudflare Quick Tunnel, Tailscale Funnel et Cloudflare Named Tunnel sur la même app HTTP jetable, puis un retest téléphone sur Quick Tunnel.
  • Résultat : Quick Tunnel et Funnel ont répondu en 200 ; le Named Tunnel a répondu en HTTPS 200 seulement après passage à un hostname couvert par le certificat Cloudflare ; une relance Quick Tunnel a aussi reçu un retour téléphone positif.
  • À retenir : le test prouve un routage HTTP/HTTPS limité, pas une recommandation générale pour Project Pezzos.
  • Repo lié : pezzos/container-exposure-lab.

Pourquoi je garde ce test

Le cas qui m’intéresse n’est pas seulement “mettre un service en ligne”. C’est plus précis : un agent ou une session Codex produit un petit service local, souvent dans un container, puis je dois pouvoir le vérifier depuis un téléphone, depuis un autre réseau, ou le partager temporairement avec quelqu’un.

Il y a déjà une base connue côté maison : une route Freebox vers un NAS avec Docker et Traefik. Le problème devient moins propre quand le service tourne sur un Mac, dans un réseau client, ou pendant un déplacement. L’IP locale change, l’IP publique change, et le besoin reste le même : obtenir une URL testable sans transformer un essai en infrastructure durable.

Je garde cette note parce que c’est exactement le genre de sujet où l’intuition ment facilement. “Un tunnel” peut vouloir dire accès privé, preview publique, DNS custom, authentification, ou hébergement géré. Les détails changent tout.

Le point qui m’a le plus servi

Le résultat le plus utile n’est pas “Cloudflare marche” ou “Tailscale marche”. C’est plus petit : le choix du hostname Cloudflare a compté.

Le premier Named Tunnel utilisait container-exposure-lab.labs.projectpezzos.com. Le routage HTTP passait, mais HTTPS échouait au handshake TLS. En passant au hostname de premier niveau container-exposure-lab.projectpezzos.com, le même type de test a répondu en HTTPS 200, avec vérification TLS valide.

La leçon que je garde : un tunnel DNS custom ne se résume pas à “le CNAME route”. Il faut aussi que le nom choisi tombe dans la couverture certificat attendue. Pour un essai rapide, ce détail suffit à transformer un chemin qui semble bon en résultat inutilisable depuis un navigateur.

Les chemins testés

J’avais besoin de comparer trois familles qui se ressemblent de loin :

  • Cloudflare Quick Tunnel : URL temporaire trycloudflare.com, sans DNS custom ;
  • Tailscale Funnel : URL publique ts.net, liée au tailnet ;
  • Cloudflare Named Tunnel : hostname contrôlé côté Cloudflare, avec DNS custom.

Les docs officielles servent surtout à cadrer les contraintes : Funnel a ses conditions Tailscale et son nom ts.net ; Cloudflare Tunnel sait router un hostname vers cloudflared, mais le DNS et le certificat restent des sujets concrets ; AWS App Runner ou ECS Anywhere relèvent davantage de l’hébergement géré que d’une preview immédiate d’un service déjà lancé sur mon laptop.

Ce que le lab a vraiment prouvé

Le dépôt public pezzos/container-exposure-lab contient l’app jetable utilisée pour ce premier passage : un serveur HTTP Node minimal, un Dockerfile, un compose.yaml, des scripts de validation, et un RESULTATS.md.

Le 20 mai 2026, j’ai testé la même app locale containerisée sur 127.0.0.1:18082, avec un endpoint /healthz, une page /, aucun volume hôte, un rootfs read-only, un user non-root, cap_drop: ALL et no-new-privileges.

Résultats vérifiés :

  • /healthz et / ont répondu en 200 via Cloudflare Quick Tunnel ;
  • /healthz et / ont répondu en 200 via Tailscale Funnel ;
  • le Named Tunnel a routé le hostname profond en HTTP, mais pas en HTTPS ;
  • le Named Tunnel a répondu en HTTPS 200 sur le hostname de premier niveau ;
  • les expositions ont été fermées et le conteneur local supprimé après test.

Un complément du 22 mai 2026 a rouvert uniquement Cloudflare Quick Tunnel, sans DNS ni Named Tunnel. Après un premier essai trop court, le tunnel a été relancé sans teardown automatique rapide. Les endpoints / et /healthz ont encore répondu en 200 depuis la machine de test à travers l’URL publique https://skin-acknowledge-dvds-stores.trycloudflare.com, puis Alexandre a confirmé que le test fonctionnait depuis un téléphone. Le tunnel et le conteneur ont ensuite été fermés, et l’URL temporaire ne servait plus l’app.

C’est utile, mais ça ne transforme pas le lab en recommandation complète : aucun collègue, auth, veille du Mac, changement de réseau ou run long n’a été validé, et les détails du téléphone n’ont pas été notés.

Ce que j’en déduis

  • Quick Tunnel suffit pour obtenir rapidement une URL HTTPS temporaire sur une app déjà validée localement.
  • Funnel fonctionne aussi pour ce cas court si le daemon et la tailnet sont prêts.
  • Le choix du hostname Cloudflare compte : un nom plus profond peut casser HTTPS si la couverture certificat ne suit pas.

Ce que je ne peux pas prouver

  • le comportement après veille du Mac, changement de Wi-Fi ou run long ;
  • l’accès depuis un collègue hors de cette session ;
  • les détails du test téléphone au-delà du résultat opérateur ;
  • l’intérêt de Cloudflare Access dans ce montage ;
  • le bon choix final entre Funnel, Cloudflare Tunnel et hébergement géré.

Ce que je retiens pour la suite

La suite doit séparer trois usages qui se ressemblent trop sur le papier :

  1. accès privé depuis mes appareils
  2. preview publique temporaire
  3. relecture collègue avec une forme d’authentification

Pour chaque usage, les points qui comptent sont très concrets : temps de setup, DNS nécessaire ou non, URL obtenue, comportement téléphone, reprise après veille ou reconnexion, surface publique exposée, logs observables, et suppression propre du tunnel et des DNS.

Conclusion provisoire

Ces tests prouvent trois choses limitées : pour une app HTTP jetable déjà validée localement, Cloudflare Quick Tunnel donne rapidement une URL HTTPS temporaire ; Tailscale Funnel expose aussi le même service via une URL publique ts.net quand le daemon et la tailnet sont prêts ; et Cloudflare Named Tunnel peut router un hostname custom en HTTPS si le nom choisi est couvert par le certificat edge Cloudflare. Ils montrent aussi une contrainte importante : le hostname profond choisi au départ ne passe pas en HTTPS avec la couverture certificat actuelle.

Cela ne prouve pas encore qu’un Named Tunnel avec DNS custom, un Funnel plus long, ou une solution AWS soit le bon choix pour Project Pezzos. Ça donne seulement une base plus propre pour tester la suite sans confondre routage court, accès privé, auth et hébergement durable.

Ce que tu peux reprendre

  • l’app HTTP minimale avec / et /healthz ;
  • la méthode : valider localement, exposer, vérifier, fermer ;
  • la matrice de résultats entre Quick Tunnel, Funnel et Named Tunnel ;
  • les garde-fous Docker du conteneur jetable.

Ce qu’il ne faut pas copier aveuglément

  • les hostnames utilisés pendant le lab ;
  • l’exposition publique sans auth pour autre chose qu’un service jetable ;
  • une conclusion sur collègue, auth, reconnexion ou longue durée : ce n’est pas encore testé ;
  • l’idée que cloudflared nettoie automatiquement le DNS créé pour toi.

Le repo contient

  • un serveur HTTP Node minimal ;
  • un Dockerfile et un compose.yaml ;
  • des scripts de validation ;
  • un RESULTATS.md avec les commandes, URLs, validations, échecs et teardown.

Il sert à

  • reproduire le lab sans reconstruire l’app de test ;
  • comparer les chemins d’exposition sur une base simple ;
  • garder les preuves factuelles séparées de cette note.

Il ne sert pas à

  • exposer un vrai service avec données sensibles ;
  • choisir une stratégie durable de preview ou d’hébergement ;
  • prouver le comportement réseau hors de la session testée.

Sources et liens utiles