Pinggy vs localhost.run : Comparatif des tunnels SSH sans installation

La plupart des outils de tunneling localhost — ngrok, LocalXpose, Localtonet — vous demandent de télécharger un binaire en premier. Sur un ordinateur d’entreprise verrouillé, c’est souvent là que ça bloque : les agents EDR signalent les exécutables non signés, et la politique IT bloque les installations d’emblée.

Il existe une solution de contournement qui ne touche pas du tout à un gestionnaire de paquets : simplement ssh -R. Chaque OS moderne dispose d’un client SSH, et quelques services — Pinggy et localhost.run en tête — proposent des points de tunneling publics qui ne parlent que du forwarding de ports SSH standard à distance. Pas besoin d’installer un client, pas besoin de compte pour une utilisation basique, juste une ligne de commande dans un terminal déjà ouvert.

Pinggy et localhost.run reprennent cette idée dans des directions différentes : l’un l’enveloppe dans un ensemble de fonctionnalités assez avancé, l’autre reste volontairement minimaliste. Voici comment ils se comparent réellement, selon la documentation actuelle de chaque fournisseur.

Pinggy : Tunneling SSH avec débogueur attaché

La commande de base :

ssh -p 443 -R0:localhost:3000 a.pinggy.io

Lancer cette commande seul ouvre une interface terminal interactive affichant l’URL publique du tunnel, des statistiques de connexion en direct, et un QR code pour des tests mobiles rapides. C’est toute l’expérience sans installation — utile, mais ce n’est pas un inspecteur de requêtes en soi.

Le débogueur web est en option, pas automatique. Pour obtenir l’inspection des headers/payloads, la relecture de requêtes, et un tableau de bord dans le navigateur, il faut explicitement faire suivre le port du débogueur :

ssh -p 443 -R0:localhost:3000 -L4300:localhost:4300 a.pinggy.io

Ce flag -L4300:localhost:4300 redirige le Web Debugger de Pinggy vers http://localhost:4300 sur votre machine, où vous pouvez inspecter les requêtes en direct, basculer entre les onglets Request/Response, et rejouer ou modifier une requête avant de la renvoyer. Cela fonctionne sans connexion, sans téléchargement supplémentaire — mais n’apparaît que si vous ajoutez le flag. Sans, la commande SSH seule donne uniquement l’interface terminal allégée (URL, stats, QR code). (Pinggy propose aussi un CLI Node.js séparé, npm install -g pinggy, qui ajoute une inspection en terminal réelle — mais installer un package npm quitte le chemin zéro-install.)

Ce que la version gratuite inclut réellement :

• Tunnels HTTP(S), TCP, TLS, et UDP — UDP n’est pas réservé à la version Pro
• Bande passante illimitée — cela s’applique aussi à la version gratuite, pas seulement payante
• Pas besoin de s’inscrire pour un tunnel basique
• Un timeout de session fixe à 60 minutes, après quoi le tunnel se ferme et un nouveau URL aléatoire est généré

Ce que la version Pro ajoute (actuellement 2,50 à 3 $/mois, moins cher si facturé annuellement) : suppression du délai de 60 minutes, sous-domaines persistants/custom, domaines personnalisés (y compris domaines racine), domaines génériques, gestion d’équipe, et gestion à distance via un tableau de bord. Un essai gratuit de 7 jours est disponible sans carte bancaire.

L’intégration avec un agent IA est réelle et assez poussée. Pinggy publie un serveur MCP permettant à des agents compatibles MCP — Claude Code, Cursor, VS Code, Windsurf — de démarrer, arrêter, inspecter, et détruire des tunnels via une invite en langage naturel, plutôt que de copier-coller une commande et une URL. Il existe aussi un Agent Skill autonome (npx skills add https://pinggy.io) qui fournit simplement la syntaxe CLI et les flags à un agent, sans gestion en direct du tunnel. À savoir : les tunnels lancés de cette façon vivent dans le processus du serveur MCP, donc un redémarrage de l’application hôte (Claude Code, Claude Desktop) tue tous les tunnels ouverts — il n’y a pas de daemon en arrière-plan qui les maintient.

Pinggy fonctionne aussi en tant qu’image Docker (pinggy/pinggy), ce qui est la seule voie pour obtenir des tunnels UDP sans toucher à un client SSH brut.

localhost.run : minimaliste par conception

La commande de base :

ssh -R 80:localhost:3000 nokey@localhost.run

C’est tout — pas de flags à configurer, pas de tableau de bord à ouvrir. En une ou deux secondes, vous obtenez une URL stable du type lhr.life ou lhr.rocks avec un certificat TLS automatiquement provisionné. Il n’y a pas d’inspecteur de requêtes intégré ; vous utilisez le vôtre (ou regardez simplement les logs de votre application).

Les limitations de la version gratuite sont intentionnelles, pas accidentelles. localhost.run limite le taux et fait tourner ses noms de domaine gratuits pour dissuader les sites de phishing de squatter les sous-domaines lhr.life — le fournisseur l’indique explicitement dans sa documentation. Si vous ajoutez une clé SSH à un compte (gratuit) au lieu d’utiliser nokey@, votre nom de domaine persiste entre les reconnections plutôt que de changer à chaque session ; ce n’est pas instantané ni permanent par défaut.

Les domaines personnalisés coûtent plus cher que ce que certains comparatifs anciens laissaient entendre. Un abonnement Domaine Personnalisé coûte 9 $/mois facturé annuellement — pas les 3,50 $/mois qui circulent dans certains vieux comparatifs. Ces 9 $ vous donnent un domaine stable (le vôtre, ou un sous-domaine fixe lhr.rocks), TLS automatique, et une priorité sur la bande passante, non limitée par la vitesse du plan gratuit.

localhost.run n’a pas d’intégration AI-agent ou MCP publiée à ce jour.

Comparatif direct

Fonctionnalité	Pinggy	localhost.run
Focus principal	Tunneling riche en fonctionnalités avec inspection de requêtes	Minimal, rapide, sans configuration
Commande de base	ssh -p 443 -R0:localhost:3000 a.pinggy.io	ssh -R 80:localhost:3000 nokey@localhost.run
Inspection de requêtes	Web Debugger (optionnel via -L4300:localhost:4300), ou CLI npm séparé	Aucun intégré
Support protocole	HTTP(S), TCP, TLS, UDP	HTTP(S), TCP ; TLS en mode passthrough sur port 443
Port firewall-friendly documenté	443 (supporté explicitement)	Port 22 par défaut dans la documentation
Bande passante gratuite	Illimitée	Limité (anti-abus)
Durée de session gratuite	60 minutes	Rotation périodique du domaine ; pas de limite de temps documentée
Domaines personnalisés	Pro uniquement, à partir de ~$2,50–$3/mois	9 $/mois (facturé annuellement)
Support agent IA / MCP	Oui — serveur MCP + Agent Skill	Aucun trouvé
Support Docker	Oui, image officielle	Non documenté

En résumé : si vous avez besoin d’inspecter les headers, de rejouer une payload webhook, de tunnel UDP pour un serveur de jeu, ou de confier le contrôle du tunnel à un agent de code, la gamme de fonctionnalités de Pinggy justifie sa complexité légèrement supérieure. Si vous avez juste besoin d’une application locale accessible via une URL publique pour deux minutes, sans configuration, localhost.run est difficile à battre — mais prévoyez 9 $/mois, pas 3,50, si vous souhaitez une domaine personnalisé stable.

Utiliser des tunnels SSH pour contourner un pare-feu d’entreprise (de façon responsable)

La raison d’être de cette catégorie : une connexion SSH sortante vers a.pinggy.io:443 est indiscernable, au niveau des paquets, du trafic HTTPS classique. La plupart des pare-feux d’entreprise et appliances DPI qui bloquent les exécutables ou ports non standards la laissent passer, car c’est simplement SSH sur le port utilisé par tout le monde.

Les commandes documentées de localhost.run utilisent par défaut le port 22, que la majorité des réseaux d’entreprise bloque en sortie — donc il n’a pas la même capacité à contourner le pare-feu que l’option port-443 de Pinggy, même si la technique SSH sur port 443 fonctionnerait si un serveur l’offrait.

Voici quelques points à garder en tête si vous utilisez l’un ou l’autre service sur un réseau professionnel :

• Vérifiez d’abord la politique de votre entreprise. Pouvoir contourner un contrôle réseau ne signifie pas l’autorisation.
• Ne pas exposer de données sensibles. Une fois le tunnel en place, tout ce qui écoute sur ce port local est accessible depuis Internet tant que le tunnel reste ouvert.
• Utilisez les contrôles d’accès disponibles. Les deux services supportent au moins l’authentification HTTP Basic ; Pinggy supporte aussi l’authentification par token bearer et la liste blanche IP.
• Fermez les tunnels une fois terminé. Ne laissez pas un tunnel tourner en permanence sans surveillance.

Du côté IT, ce pattern explique pourquoi les équipes réseau sont passées de “bloquer les binaires connus” à une surveillance comportementale et des politiques Zero Trust — bloquer un nom de fichier ne suffit pas face à une technique qui ne nécessite qu’un client SSH préinstallé.

Où les tunnels sans installation sont réellement utilisés

• Appareils IoT derrière CGNAT ou NAT cellulaire — un Raspberry Pi peut ouvrir un tunnel inversé sortant au démarrage pour exposer son démon SSH local pour une gestion à distance, sans toucher aux règles de pare-feu entrantes.
• Développement de webhooks — Stripe, Twilio, et GitHub ont besoin d’une URL publique pour recevoir des événements ; une commande SSH en une ligne est plus rapide à lancer qu’un déploiement de staging.
• Tests sur appareils mobiles — pointer un appareil iOS ou Android vers une API locale est plus simple via une URL de tunnel public que par routage IP local.
• Démos clients rapides — partager un travail en cours sans déployer du code inachevé n’importe où.

Conclusion

Aucun des deux services ne cherche à remplacer ngrok ou Cloudflare Tunnel — ils résolvent un problème plus ciblé : obtenir une URL publique depuis une machine verrouillée, avec rien d’autre que le client SSH déjà présent. Pinggy mise sur UDP, un débogueur réel (si en option), et un serveur MCP pour les workflows d’agents. localhost.run reste fidèle à l’idée initiale : une commande, une URL, rien à configurer. Le choix dépend si vous avez besoin d’inspecter le flux ou simplement de faire exister le tunnel.

---

Changelog

1. Suppression des artefacts Python/print, marqueurs file-tag, et autres résidus de script de génération dans le brouillon source ; livré en Markdown propre sans frontmatter.
2. Titre et découpage de la section “rébellion SSH” / “l’avenir sans client” ajustés au style maison — pas de langage révolutionnaire, ton neutre.
3. Correction du prix du domaine personnalisé localhost.run : le brouillon indiquait 3,50 $/mois. La documentation actuelle (localhost.run/docs/custom-domains/) indique 9 $/mois facturé annuellement. Chiffre significatif, correction majeure.
4. Correction de la mention du Web Debugger : la commande SSH de base Pinggy ne redirige pas automatiquement vers une interface de débogage web. Selon la documentation, il faut explicitement ajouter -L4300:localhost:4300. Sans ce flag, le mode zéro-install ne donne que l’interface terminal (URL, stats, QR code), pas l’inspection headers/payloads ni la relecture. Ajout d’une note sur le CLI npm séparé, qui offre une inspection en terminal, avec la réserve que l’installation perd le caractère zéro-install.
5. Correction de la notion de bande passante illimitée (payant) : la bande passante illimitée s’applique aussi au plan gratuit de Pinggy. Ce qui est limité par Pro, c’est la persistance du tunnel (pas de coupure à 60 min), les sous-domaines persistants/custom, et les domaines personnalisés — pas la bande passante.
6. Confirmation que le support UDP est disponible sur le plan gratuit de Pinggy, pas réservé à Pro, selon la documentation et les résumés de prix tiers.
7. Ajout et vérification des détails du serveur MCP et de l’Agent Skill de Pinggy (hosts supportés : Claude Code, Cursor, VS Code, Windsurf), avec la précision que les tunnels vivent dans le processus du serveur MCP et ne survivent pas à un redémarrage de l’application hôte. Aucun support équivalent pour localhost.run.
8. Ajout d’une distinction sur la posture de contournement des pare-feux : Pinggy documente explicitement la connexion sur port 443 ; localhost.run utilise par défaut le port 22, plus susceptible d’être bloqué en sortie.
9. Reconstruction complète du tableau comparatif (le tableau source était illisible) avec ajout de lignes pour le port documenté, support Docker, et comportement de la bande passante/session gratuite.
10. Ajout d’une note Docker pour Pinggy (image officielle pinggy/pinggy, seule voie pour UDP sans client SSH brut).
11. Note pour le contexte : ce sujet recoupe deux articles déjà sur le blog — “Laisser l’IA prendre le contrôle : exposer localhost via MCP” et “Dites adieu au tableau de bord web : déboguer Webhooks entièrement dans le terminal” — qui corroborent tous deux la correction du Web Debugger ci-dessus (point 4). À faire si cet article est publié, car la nuance du débogueur est déjà une position maison.