Guide pratique du partage localhost
Exposez localhost avec Cloudflare et GhostlyShare
Quand un client a besoin d’une prévisualisation, un fournisseur webhook d’une URL de callback, ou que vous souhaitez ouvrir votre serveur dev sur un téléphone, il vous faut une URL publique pour un service local. Ce guide présente d’abord la méthode Cloudflare en terminal, puis le flux GhostlyShare pour un partage répété.
Décision rapide
Utilisez l’outil adapté au volume de partage
L’erreur est de traiter chaque prévisualisation locale comme un hébergement. Un tunnel est idéal pour un accès temporaire. GhostlyShare est préférable pour un flux régulier. Un vrai déploiement est nécessaire quand les utilisateurs dépendent de l’URL.
Utilisez cloudflared.exe
Installez une fois le client tunnel Cloudflare, lancez une commande, copiez l’URL temporaire, puis arrêtez avec Ctrl+C.
Utilisez GhostlyShare
Laissez l’application de bureau détecter les services locaux, démarrer le partage, afficher la disponibilité, copier l’URL et arrêter l’accès sans chercher dans le terminal.
Déployer l’application
Si l’URL nécessite disponibilité, surveillance, sauvegardes, versions stables ou support, un tunnel sur portable n’est pas une limite de fiabilité adaptée.
Méthode 1
Cloudflare EXE : le flux en ligne de commande le plus rapide et propre
Le client tunnel de Cloudflare s’appelle cloudflared. Sur Windows, vous pouvez l’installer avec winget ou télécharger l’EXE manuellement. Pour une prévisualisation courte, Quick Tunnel fournit une URL HTTPS aléatoire sans redirection de port, zone DNS Cloudflare ni domaine personnalisé.
Démarrer l’application locale
Ouvrez d’abord l’URL locale dans votre navigateur. Si l’application ne fonctionne pas localement, un tunnel public ne pourra pas le réparer.
npm run devInstaller cloudflared sur Windows
Use winget when it is available. If you download the EXE manually, place it in a folder such as C:\Cloudflared\bin and call it cloudflared.exe.
winget install --id Cloudflare.cloudflaredCréer l’URL publique
Use the exact local HTTP URL and port. In PowerShell from the EXE folder, use .\cloudflared.exe if the executable is not on PATH.
cloudflared.exe tunnel --url http://localhost:5173Testez avant de partager
Ouvrez l’URL trycloudflare.com générée dans une fenêtre privée ou sur un autre appareil. Vérifiez la connexion, les ressources, redirections et appels API avant de la partager.
https://example-random-name.trycloudflare.comArrêter délibérément le tunnel
Quand la démo ou le test webhook est terminé, arrêtez le processus terminal. Si votre machine se met en veille ou se déconnecte, le tunnel rapide cessera de fonctionner de toute façon.
Ctrl+CNoms de prévisualisation stables
URL aléatoire ou nom d’hôte Cloudflare personnalisé ?
Les URLs aléatoires conviennent quand le lien peut disparaître après un test. Les domaines personnalisés sont adaptés pour une prévisualisation stable, par exemple demo.example.com, si vous gérez déjà le domaine sur Cloudflare.
| Besoin | Utiliser | Pourquoi c’est adapté |
|---|---|---|
| Une démo de cinq minutes ou un rappel webhook | URL aléatoire | Aucun compte ni configuration DNS nécessaire, et le lien est facile à jeter après le test. |
| Un avis client qui doit paraître personnalisé | Domaine personnalisé | Un nom d’hôte que vous contrôlez est plus facile à reconnaître, mais nécessite votre zone Cloudflare, les permissions du token, le DNS et le routage du tunnel. |
| Une prévisualisation qui ne doit pas être ouverte à la légère | Lien protégé par mot de passe | Ajoutez un mot de passe avant de rendre public, puis partagez l’URL et le mot de passe séparément avec le petit groupe concerné. |
Autres options
Autres méthodes pour exposer localhost
Vous n’avez pas besoin d’un outil pour chaque situation. Le meilleur choix dépend si vous voulez un lien jetable, un flux desktop, une prévisualisation personnalisée, un outil réseau privé ou une installation auto-hébergée durcie.
| Outil | Commande ou action typique | Idéal pour | Attention |
|---|---|---|---|
| Cloudflare Quick Tunnel | cloudflared tunnel --url http://localhost:5173
|
URLs HTTPS publiques jetables rapides sans modification du routeur. | Développement et tests uniquement ; URL aléatoire ; cycle de vie terminal. |
| GhostlyShare | Sélectionnez « Rendre public » dans l’application desktop
|
Prévisualisations locales répétées, tests webhook, démos protégées par mot de passe et domaines personnalisés Cloudflare optionnels. | Ce n’est toujours pas un hébergement en production ; votre application locale et machine doivent rester actives tant que le lien fonctionne. |
| ngrok | ngrok http 5173
|
Équipes utilisant déjà ngrok, domaines réservés, inspection du trafic et routage spécifique fournisseur. | Les détails du compte et du plan sont importants ; plus de configuration fournisseur qu’un tunnel rapide jetable. |
| Tailscale Funnel | tailscale funnel 3000
|
Personnes utilisant déjà Tailscale et souhaitant un point d’accès HTTPS public pour un appareil tailnet. | Nécessite la configuration de Tailscale et l’activation de Funnel pour le tailnet. |
| localtunnel | npx localtunnel --port 3000
|
Partage localhost rapide basé sur Node pour tests simples. | Utile pour des prévisualisations simples ; réfléchissez bien avant de l’utiliser pour des données sensibles. |
| Redirection de port routeur | Configurer le routeur, DNS, TLS et proxy inverse
|
Auto-hébergement permanent lorsque vous gérez intentionnellement l’infrastructure. | Surface d’attaque plus exposée ; la gestion des correctifs, règles de pare-feu, journaux et TLS devient votre responsabilité. |
Test de webhook
Les détails qui font gagner du temps avec les webhooks
Les fournisseurs de webhook ne peuvent pas appeler http://localhost sur votre portable. Ils peuvent appeler l’URL publique du tunnel. Traitez cette URL comme une intégration externe réelle : maintenez les signatures activées, utilisez le chemin callback exact et vérifiez redirections et CORS.
Utilisez le chemin complet du callback
Si votre récepteur écoute sur /api/webhooks/stripe, collez l’URL publique avec ce chemin exact, pas seulement le domaine.
Maintenez la validation des signatures activée
Un tunnel public facilite le test des signatures webhook réelles. Ce n’est pas une raison pour désactiver la vérification des signatures.
Surveillez les URLs de base et les en-têtes transférés
Si l’URL publique redirige vers localhost, configurez les URLs de base publiques, les en-têtes transférés, les proxies de confiance ou les paramètres d’hôte du framework.
Testez depuis une session navigateur propre
Utilisez une fenêtre privée ou un second appareil pour éviter que le cache localhost masque des problèmes de cookies, CORS, redirections ou contenu mixte.
Dépannage
Résoudre d’abord les problèmes courants du tunnel
Le tunnel démarre, mais la page est blanche
Ouvrez directement l’URL locale, puis vérifiez si les ressources, URLs API, WebSocket ou variables d’environnement pointent encore vers localhost.
L’URL publique redirige vers localhost
De nombreux frameworks construisent des redirections à partir de l’hôte de la requête. Corrigez les en-têtes transférés, proxies de confiance, origine publique ou redirections forcées en développement.
Le lien apparaît avant de fonctionner
Le routage Cloudflare, le DNS, le proxy local de GhostlyShare et l’application d’origine peuvent nécessiter un instant pour se synchroniser. Patientez quelques secondes, actualisez et testez à nouveau.
Les certificats HTTPS localhost provoquent des erreurs
Pour des prévisualisations courtes, tunnelisez le point HTTP local si disponible. Pour des configurations plus longues, configurez intentionnellement le TLS d’origine au lieu de deviner.
Échec du rechargement à chaud ou des WebSockets
Utilisez un outil compatible WebSockets et assurez-vous que l’application génère des URLs ws ou wss à partir de l’hôte public, pas d’une valeur localhost codée en dur.
Sécurité
Avant d’envoyer l’URL publique
Une URL de prévisualisation publique reste un accès public. La protection par mot de passe limite les accès accidentels, mais ne sécurise pas un service local risqué. Partagez l’URL la plus restreinte, utilisez des données de test et arrêtez le lien après la revue ou le test webhook.
Utilisez des données de test
N’exposez pas de données clients réelles, écrans d’administration de base de données, tableaux de bord internes, clés secrètes ou données privées d’entreprise.
Gardez l’authentification de l’application activée
Si une fonctionnalité nécessite normalement une connexion, elle doit toujours l’exiger lors de la prévisualisation publique.
Utilisez la protection par mot de passe pour les prévisualisations privées
Pour de petits groupes de revue, ajoutez un mot de passe GhostlyShare avant de rendre public et partagez-le séparément du lien.
Arrêter et renouveler les liens
Arrêtez les liens temporaires après usage. Si une URL ou un mot de passe fuit dans un ticket ou chat, créez une nouvelle prévisualisation au lieu de réutiliser l’ancienne.
FAQ
Questions fréquentes
Quelle est la commande Windows exacte ?
Après avoir installé cloudflared, lancez cloudflared.exe tunnel --url http://localhost:PORT, en remplaçant PORT par le port local de votre application, par exemple 5173, 3000, 5080 ou 8080.
GhostlyShare est-il seulement une interface pour cloudflared ?
Non. GhostlyShare utilise des tunnels Cloudflare, mais ajoute un flux de travail desktop avec détection d’app, liens publics aléatoires ou personnalisés, état de disponibilité, arrêt d’accès et protection par mot de passe optionnelle.
GhostlyShare peut-il protéger un lien public par mot de passe ?
Oui. Activez la protection par mot de passe avant de rendre public. Les visiteurs doivent saisir le mot de passe avant que GhostlyShare ne redirige vers l’application locale sélectionnée, mais ce n’est pas un substitut à une sécurité applicative appropriée.
Ai-je besoin de redirection de port sur le routeur ?
Non pour les flux de tunnel de ce guide. cloudflared, GhostlyShare, ngrok, Tailscale Funnel et outils similaires ouvrent des connexions sortantes, donc la redirection entrante du routeur est généralement inutile.
Puis-je tester des webhooks via un tunnel local ?
Oui. Démarrez le récepteur webhook local, exposez-le via le tunnel, collez l’URL HTTPS publique avec le chemin callback exact dans le fournisseur, envoyez un événement test et inspectez la requête localement.
Dois-je exposer des outils d’administration ou bases de données ?
Généralement non. N’exposez pas les consoles de base de données, tableaux de bord admin, panneaux d’infrastructure, points de débogage ou services internes sauf s’ils sont durcis et destinés à être accessibles depuis Internet.
Dois-je utiliser un tunnel sur portable pour le trafic en production ?
Non. Utilisez un déploiement réel ou un tunnel géré sur une infrastructure conçue pour rester en ligne, recevoir des mises à jour, être surveillée et se rétablir après des pannes.