Pinggy vs localhost.run: La rebelión de los túneles SSH sin instalación

Quick answer
Pinggy vs localhost.run: La rebelión de los túneles SSH sin instalación: quick comparison answer
Choose the tunnel tool based on the network model: public HTTPS URLs for webhooks and demos, private mesh access for internal apps, and managed infrastructure when policy controls matter most.
Which tunnel tool is best for public webhook testing?
Use a public HTTPS localhost tunnel with stable URLs. InstaTunnel focuses on webhook testing, demos, OAuth callbacks, and MCP endpoint workflows.
When should I choose a private network tool instead?
Choose a private mesh or Zero Trust tool when every user and service should stay inside a controlled private network.
La mayoría de las herramientas de túnel para localhost — ngrok, LocalXpose, Localtonet — te piden descargar un binario primero. En un portátil corporativo con restricciones, eso suele ser donde se detienen las cosas: los agentes EDR detectan ejecutables sin firmar, y las políticas de TI bloquean las instalaciones directamente.
Existe una solución alternativa que no toca ningún gestor de paquetes: simplemente ssh -R. Todos los sistemas operativos modernos incluyen un cliente SSH, y algunos servicios — Pinggy y localhost.run entre los principales — ofrecen puntos de túnel públicos que solo usan reenvío de puertos SSH estándar. Sin cliente que instalar, sin cuenta para uso básico, solo una línea de comando en un terminal que ya tienes abierto.
Pinggy y localhost.run llevan esa misma idea en direcciones distintas: uno la envuelve en un conjunto de funciones bastante completo, el otro se mantiene deliberadamente minimalista. Así es como realmente se comparan, según la documentación actual de cada proveedor.
Pinggy: Túneles SSH con depurador adjunto
El comando base:
ssh -p 443 -R0:localhost:3000 a.pinggy.io
Ejecutar esto solo te lleva a una interfaz interactiva en terminal que muestra la URL pública del túnel, estadísticas en vivo, y un código QR para pruebas rápidas en móvil. Esa es toda la experiencia sin instalación — útil, pero no es un inspector de solicitudes por sí solo.
El depurador web requiere activación, no es automático. Para inspeccionar cabeceras y cargas útiles, reproducir solicitudes y tener un panel en navegador, necesitas reenviar explícitamente el puerto del depurador:
ssh -p 443 -R0:localhost:3000 -L4300:localhost:4300 a.pinggy.io
El flag -L4300:localhost:4300 reenvía el Web Debugger de Pinggy a http://localhost:4300 en tu máquina, donde puedes inspeccionar solicitudes en vivo, cambiar entre pestañas Request/Response, y reproducir o modificar solicitudes antes de reenviarlas. Funciona sin iniciar sesión y no requiere descarga adicional — pero solo aparece si añades ese flag. Si lo omites, el comando SSH simple solo te da la interfaz ligera en terminal. (Pinggy también ofrece un CLI oficial en Node.js, npm install -g pinggy, que añade inspección en solicitud en terminal real — pero instalar un paquete npm significa abandonar el camino de cero instalación.)
Lo que incluye la capa gratuita:
- Túneles HTTP(S), TCP, TLS y UDP — UDP no está restringido en Pro
- Ancho de banda ilimitado — esto también aplica en la capa gratuita, no solo en la de pago
- No se requiere registro para un túnel básico
- Tiempo máximo de sesión de 60 minutos, tras el cual el túnel se cierra y se genera una URL nueva
Lo que añade Pro (actualmente $2.50–$3/mes, más barato si se factura anualmente): eliminación del límite de 60 minutos, subdominios persistentes/personalizados, dominios personalizados (incluyendo dominios raíz), dominios comodín, gestión de equipos, y administración remota de túneles vía panel. Se ofrece una prueba gratuita de 7 días sin tarjeta de crédito.
La integración con agentes AI es real y bastante avanzada. Pinggy publica un servidor MCP que permite a agentes compatibles — Claude Code, Cursor, VS Code, Windsurf — iniciar, detener, inspeccionar y eliminar túneles desde un prompt en lenguaje natural en lugar de copiar y pegar comandos y URLs. También existe un Skill independiente para agentes (npx skills add https://pinggy.io) que solo proporciona la referencia de sintaxis y flags del CLI sin gestionar túneles en vivo. Es importante saber: los túneles iniciados de esta forma viven dentro del proceso del servidor MCP, por lo que reiniciar la app host (Claude Code, Claude Desktop) termina todos los túneles abiertos — no hay un demonio en segundo plano que los persista.
Pinggy también funciona como una imagen Docker (pinggy/pinggy), que es la única vía para obtener túneles UDP sin tocar un cliente SSH en crudo.
localhost.run: minimalista por diseño
El comando base:
ssh -R 80:localhost:3000 nokey@localhost.run
Eso es todo — sin flags para ajustar, sin panel para abrir. En uno o dos segundos obtienes una URL estable tipo lhr.life o lhr.rocks con un certificado TLS provisionado automáticamente. No tiene un inspector de solicitudes integrado; tú traes el tuyo propio (o simplemente revisas los logs de tu app).
Las limitaciones de la capa gratuita son intencionales, no incidentales. localhost.run limita y rota los nombres de dominio de la capa gratuita específicamente para desalentar sitios de phishing que ocupen subdominios de lhr.life — el proveedor lo explica claramente en su documentación. Si añades una clave SSH a una cuenta (gratuita) en lugar de usar nokey@, tu dominio persiste entre reconexiones en lugar de cambiar en cada sesión; solo que no es instantáneo ni permanente por defecto.
Los dominios personalizados cuestan más de lo que algunos comparadores antiguos sugieren. Una suscripción a Dominio Personalizado cuesta $9/mes si se factura anualmente — no los $3.50/mes que circulan en comparaciones viejas. Ese monto te da un dominio estable (el tuyo propio, o un subdominio fijo de lhr.rocks), TLS automático, y prioridad en el ancho de banda que no está sujeto a los límites de velocidad de la capa gratuita.
localhost.run no tiene integración documentada con agentes AI ni MCP hasta la fecha.
Comparativa cara a cara
| Característica | Pinggy | localhost.run |
|---|---|---|
| Enfoque principal | Túneles con muchas funciones y revisión de solicitudes | Túneles minimalistas, rápidos, sin configuración |
| Comando base | ssh -p 443 -R0:localhost:3000 a.pinggy.io |
ssh -R 80:localhost:3000 nokey@localhost.run |
| Inspección de solicitudes | Web Debugger (activable con -L4300:localhost:4300), o CLI separado en npm |
Ninguno integrado |
| Soporte de protocolos | HTTP(S), TCP, TLS, UDP | HTTP(S), TCP; TLS en puerto 443 |
| Puerto compatible con firewall | 443 (soportado explícitamente) | Puerto 22 por defecto en comandos documentados |
| Ancho de banda en capa gratuita | Ilimitado | Limitado por tasa (anti-abuso) |
| Duración de sesión en capa gratuita | 60 minutos | El dominio rota periódicamente; sin límite de tiempo explícito |
| Dominios personalizados | Solo Pro, desde ~$2.50–$3/mes | $9/mes (facturado anualmente) |
| Soporte para agentes AI / MCP | Sí — servidor MCP + Agent Skill | No encontrado |
| Soporte Docker | Sí, imagen oficial | No documentado |
Resumen: si necesitas inspeccionar cabeceras, reproducir cargas útiles de webhooks, túneles UDP para un servidor de juegos, o delegar control de túneles a un agente de código, las funciones de Pinggy justifican su ligera complejidad adicional. Si solo quieres una app local en una URL pública por dos minutos sin configurar nada, la línea de localhost.run es difícil de superar — solo considera pagar $9/mes, no $3.50, si eventualmente quieres un dominio personalizado estable.
Usando túneles SSH para sortear un firewall corporativo (de manera responsable)
La razón de que exista toda esta categoría: una conexión SSH saliente a a.pinggy.io:443 es indistinguible, a nivel de paquetes, del tráfico HTTPS normal. La mayoría de los firewalls corporativos y dispositivos DPI que bloquean ejecutables o puertos no estándar lo dejan pasar sin problemas, porque solo es SSH usando el puerto que todo lo demás.
Los comandos documentados de localhost.run por defecto usan el puerto 22, que es precisamente el puerto que la mayoría de las redes corporativas bloquean en salida — por lo que no tiene la misma historia de evasión de firewall que la opción de Pinggy en puerto 443, aunque la técnica SSH sobre 443 sí funcionaría si el servidor la ofreciera.
Algunas cosas a tener en cuenta si usas cualquiera de estos servicios en una red de trabajo:
- Revisa primero la política de tu empresa. Poder sortear un control de red no significa que esté permitido.
- No expongas datos sensibles. Una vez que un túnel inverso está activo, lo que escuche en ese puerto local será accesible desde internet mientras el túnel esté abierto.
- Utiliza los controles de acceso disponibles. Ambos soportan al menos autenticación HTTP Basic; Pinggy además soporta autenticación con token bearer y listas blancas de IP.
- Cierra los túneles cuando termines. No los dejes funcionando sin supervisión toda la noche.
Desde TI, este patrón explica por qué los equipos de redes han pasado de “bloquear binarios conocidos” a monitoreo basado en comportamiento y políticas de Zero Trust — bloquear un nombre de archivo no detiene una técnica que solo necesita un cliente SSH preinstalado.
Dónde realmente se usan túneles sin instalación
- Dispositivos IoT detrás de CGNAT o NAT móvil — una Raspberry Pi puede abrir un túnel inverso saliente al arrancar para exponer su daemon SSH local para gestión remota, sin tocar reglas de firewall entrantes.
- Desarrollo de webhooks — Stripe, Twilio y GitHub necesitan una URL pública para entregar eventos; un comando SSH de una línea es más rápido que desplegar en staging.
- Pruebas en dispositivos móviles — conectar un dispositivo iOS o Android a una API local es más sencillo mediante una URL pública que por IP en red local.
- Demos rápidas a clientes — compartir trabajo en progreso sin desplegar código a medio hacer.
Conclusión
Ninguno de los servicios intenta reemplazar a ngrok o Cloudflare Tunnel directamente — resuelven un problema más específico: obtener una URL pública desde una máquina bloqueada usando solo el cliente SSH que ya está instalado. Pinggy apuesta por eso con soporte UDP, un depurador real (si se activa), y un servidor MCP para flujos de trabajo con agentes. localhost.run mantiene la idea original: un comando, una URL, sin configuración. La elección depende de si necesitas inspeccionar lo que pasa por el túnel o solo que exista.
Changelog
- Eliminados artefactos residuales de Python/print, marcadores
file-tag, y otros restos del script de generación del borrador original; entregado como Markdown limpio sin frontmatter. - Titulado y ajustado el marco de “rebelión SSH” / “el futuro sin cliente” para alinearse con el estilo de la casa — sin lenguaje de revolución completa, con un enfoque neutral.
- Corregido el precio de dominio personalizado en localhost.run: el borrador indicaba $3.50/mes. La documentación actual (
localhost.run/docs/custom-domains/) indica $9/mes facturado anualmente. Este es un cambio importante y la corrección más significativa en esta revisión. - Corregido el reclamo del Web Debugger: el borrador implicaba que el comando SSH simple de Pinggy reenviaba automáticamente una interfaz de depuración web. Según la documentación, esto requiere explícitamente añadir
-L4300:localhost:4300. Sin ese flag, la opción sin instalación solo ofrece la interfaz ligera (URL, estadísticas, QR) — no inspección de cabeceras ni cargas útiles ni reproducción. Se añadió una nota sobre el CLI separado en npm como la opción real para inspección en terminal, con la advertencia de que instalarlo abandona la propiedad de cero instalación. - Corregido el soporte de ancho de banda ilimitado (pagado): el ancho de banda ilimitado también aplica en la capa gratuita de Pinggy. Lo que Pro realmente limita es la persistencia del túnel (sin límite de 60 minutos), subdominios persistentes/personalizados, y dominios personalizados — no el ancho de banda.
- Confirmado que el soporte para túneles UDP está disponible en la capa gratuita de Pinggy, no solo en Pro, según la documentación y resúmenes de precios de terceros.
- Añadidos y verificados los detalles del servidor MCP y del Agent Skill de Pinggy (soportados hosts: Claude Code, Cursor, VS Code, Windsurf), incluyendo que los túneles viven dentro del proceso del servidor MCP y no sobreviven a reinicios de la app host. No se encontró integración equivalente para localhost.run.
- Añadida una nota diferenciando la postura de evasión de firewall: Pinggy documenta explícitamente conectar sobre puerto 443; localhost.run en sus comandos documentados usa por defecto puerto 22, más probable de ser bloqueado en redes restrictivas.
- Reconstruida la tabla comparativa desde cero (el formato original era ilegible) y añadidas filas para puerto documentado, soporte Docker, y comportamiento de ancho de banda y sesiones en capa gratuita.
- Añadida nota sobre Docker para Pinggy (imagen oficial
pinggy/pinggy, la única vía para túneles UDP sin cliente SSH en crudo). - Nota adicional: este tema se superpone con dos artículos en el blog — “Dejar que la IA conduzca: exponiendo localhost vía servidores MCP” y “Olvídate del panel web: depuración de webhooks completamente en terminal” — ambos corroboran la corrección del Web Debugger arriba (punto 4). Es recomendable enlazarlos si esto se publica, ya que la nuance del depurador ya está establecida en la postura de la casa.
Related InstaTunnel pages
Continue from this article into the most relevant product guides and workflows.
Related Topics
Keep building with InstaTunnel
Read the docs for implementation details or compare plans before you ship.