Pangolin vs Cloudflare Tunnel (2026): quién controla el punto de salida

Ambas herramientas resuelven el mismo problema molesto: tienes algo funcionando en casa y quieres acceder desde fuera sin abrir un puerto en el router (algo que quizá ni siquiera sea posible detrás de CGNAT).

Y lo resuelven de la misma manera: un daemon en tu máquina abre una conexión saliente hacia un endpoint público, y el tráfico vuelve por ese conducto. Nada escucha en la IP de tu casa.

La diferencia cabe en una palabra: de quién es el endpoint público.

Con Pangolin, ese endpoint es un servidor que alquilas: cualquier VPS pequeño con una IPv4 pública sirve, por ejemplo un Contabo Cloud VPS (enlace de afiliado), desde 5,50 €/mes con 24 meses de permanencia (precio comprobado el 17 de octubre de 2026).

Respuesta corta

Cloudflare Tunnel entrega el endpoint público a Cloudflare. Nada que alquilar, nada que actualizar, y funciona en minutos.

Pangolin pone ese endpoint en una máquina que alquilas y administras, normalmente un VPS pequeño. El camino sigue siendo tuyo, y heredas un servidor del que ocuparte.

Ese es todo el intercambio. Todo lo que sigue es consecuencia de ello.

¿Quién está en el camino?

Con Cloudflare Tunnel, los visitantes se conectan a Cloudflare, y Cloudflare se conecta a ti. Si Cloudflare termina el TLS de tu nombre de host (la configuración estándar), tu tráfico se descifra en su edge antes de volver a cifrarse por el túnel. No es un comportamiento oculto; es la única forma en que pueden funcionar la caché y el filtrado.

Que eso importe depende de lo que expongas. Un blog público y un servidor de documentos no son la misma decisión, y vale la pena hacer esa distinción de forma deliberada y no por defecto.

Con Pangolin, el endpoint es tu VPS. Tu proveedor sigue alojando la máquina, así que decir "nadie está en el camino" sería exagerado; pero el software que termina tu tráfico es tuyo, y su configuración también.

Estar en el camino también significa fijar las reglas del camino, y Cloudflare las publica como cifras fijas. Entre Cloudflare y tu origen, los límites documentados incluyen un timeout de ACK TCP de 90 segundos, un intervalo de keep-alive TCP de 30 segundos y un timeout de inactividad del proxy de 900 segundos, cada uno con el error HTTP que produce al superarse (522 y 520). Entre el visitante y Cloudflare, una conexión HTTP/1.1 o HTTP/2 inactiva se cierra a los 400 segundos. La propia tabla de Cloudflare marca todos ellos como no configurables, y remite a los usuarios de túneles a la configuración de origen, aparte, para cambiar lo poco que se puede cambiar. En tu propio endpoint los fijas tú directamente, algo que importa el día que expones algo de larga duración, un websocket o una subida grande, que no cabe dentro de los valores por defecto de otro.

El endpoint público siempre vive en la máquina de alguien. La pregunta que responde un túnel no es si hay un servidor en el camino, sino de quién es.

Lo que cuesta realmente cada uno

Cloudflare Tunnel está disponible en el plan gratuito, y mucha gente lo usa durante años sin pagar. El planteamiento honesto: gratis describe el precio, no el acuerdo. Tu tráfico transita por una infraestructura que no controlas, con condiciones que pueden cambiar.

Pangolin no tiene coste de licencia, pero tampoco es gratis. Pagas el VPS y, lo que sale más caro, cargas con el mantenimiento: actualizaciones, certificados, monitorización y una copia de seguridad de la configuración.

La gente compara las cifras mensuales y se queda ahí. El coste recurrente que la sorprende es el segundo.

¿Cuál para un servidor doméstico?

• Quieres que funcione esta noche, sin nada que mantener → Cloudflare Tunnel. Difícil argumentar en contra.
• Expones algo que no confiarías a un tercero → túnel autoalojado hacia tu propio VPS.
• Estás detrás de CGNAT y no tienes dirección pública → ambos funcionan; es exactamente para lo que sirven.
• Quieres aprender cómo funciona esto → Pangolin te enseña más, porque montas tú las piezas.

Una nota sobre el VPS, ya que es donde el plan suele toparse con la realidad: el endpoint necesita una dirección pública estable, algo que una conexión doméstica detrás de CGNAT no puede darte. El plan más pequeño de cualquier proveedor serio basta para un túnel: no es una carga de trabajo que necesite núcleos. Lo que necesita es seguir funcionando, y seguir actualizado, dentro de ocho meses.

El error al que invitan ambas herramientas

Un túnel no es autenticación.

Elimina el puerto abierto. No decide quién puede pasar. Lo que expongas es accesible para cualquiera que conozca el nombre de host, y los nombres de host se filtran, entre otras vías, a través de los registros de Certificate Transparency. Esto último no es una hipótesis. Certificate Transparency, especificado en el RFC 6962 en junio de 2013, publica los certificados TLS emitidos en registros de solo anexado que cualquiera puede consultar, y los principales navegadores exigen ahora que los certificados aparezcan en ellos para considerarlos de confianza. Así que en cuanto tu túnel obtiene un certificado de una CA pública, su nombre de host queda publicado, se puede buscar y es permanente. Ponerle a un servicio un nombre imposible de adivinar no te sirve de nada aquí.

Ambos proyectos incluyen controles de acceso exactamente por este motivo. Úsalos. El túnel nunca fue la frontera de seguridad; solo era la fontanería que permitía que llegara el tráfico.

Entonces, ¿cuál?

Pregúntate a quién quieres al mando del punto de salida.

Si la respuesta es "no quiero administrar un servidor para esto", Cloudflare Tunnel es la herramienta adecuada, y no hay nada de qué avergonzarse: la alternativa es una máquina que debes mantener viva durante años.

Si la respuesta es "el camino tiene que ser mío", eso es Pangolin, y el precio es un VPS cuyo mantenimiento pasa a ser tuyo.

Lo que ninguno de los dos responde es la pregunta que viene después: lo que acabas de exponer sigue necesitando su propia autenticación, sus propias actualizaciones y su propia copia de seguridad. El túnel solo lo hizo accesible.