Ambos proyectos responden a la misma pregunta (cómo montar una red mallada privada sin pagar a una empresa para que custodie el mapa) y la responden de formas casi opuestas. Elegir entre ellos no es realmente una decisión de rendimiento. Es una decisión sobre de qué software cliente estás dispuesto a depender y qué fallo preferirías explicar a tus compañeros.
En ambos casos necesitas una máquina pública: el servidor de control de Headscale o el lighthouse de Nebula debe estar en un host con una IPv4 pública accesible, algo que cubre un VPS pequeño como un Contabo Cloud VPS 4 (enlace de afiliado) por 5,50 € al mes con un plazo de 24 meses.
¿Comparas Headscale con el propio servicio alojado? Nuestra comparativa Tailscale vs Headscale enumera las funciones que faltan, el coste a 3 años y un veredicto según el tamaño del equipo.
La versión en una frase
Headscale sustituye el servidor de coordinación de Tailscale por uno que ejecutas tú, conservando los clientes oficiales y el plano de datos WireGuard. Nebula lo sustituye todo, con su propio protocolo, su propio binario y una autoridad de certificación que gestionas tú mismo, y por eso comparar Nebula con el propio WireGuard es comparar una red completa con un protocolo de túnel.
Ambos son proyectos consolidados y no experimentales, y ambos tienen licencias permisivas, lo que importa si apuestas tu infraestructura por ellos: Slack liberó Nebula en noviembre de 2019 bajo licencia MIT, y Headscale arrancó en junio de 2020 con licencia BSD-3-Clause.
Ambos, ojo, son mallas. Si la pregunta de fondo es si montar una malla o un único servidor al que se conecta todo, se trata de otra comparativa: Headscale vs OpenVPN la plantea como una cuestión de topología más que de funciones.
Dónde reside realmente la confianza
Esta es la diferencia que sobrevive a cualquier comparativa de funciones.
En una red Headscale, una máquina se une autenticándose ante tu servidor de control. El servidor es tuyo, así que la decisión es tuya, pero el cliente es software mantenido por Tailscale Inc., que apunta a tu servidor sobrescribiendo la URL de inicio de sesión. Ese arreglo se ha mantenido durante años, y no es contractual.
En una red Nebula, una máquina se une porque posee un certificado firmado por tu autoridad de certificación. Tú generas esa CA, y nunca tiene que salir de la máquina en la que la generaste. Nada se inscribe sin tu firma. El precio es que el ciclo de vida de los certificados (emitir, distribuir, caducar, revocar) pasa a ser tu trabajo desde el primer día, en lugar de algo que vas asumiendo con el tiempo. Ese precio tiene fecha: nebula-cert ca usa por defecto una validez de 8760 horas, un año, así que una red desatendida deja de inscribir nodos exactamente doce meses después de montarla, salvo que alguien haya renovado la CA.
Ningún modelo es más seguro en abstracto. Uno te pide confiar en la tolerancia continuada de un proveedor de clientes; el otro te pide saber gestionar una CA.
Cómo encuentra cada uno a sus pares
Nebula usa lighthouses: nodos con una dirección estable y accesible cuyo trabajo es saber dónde está cada uno y presentar a los pares entre sí. Son nodos Nebula normales con una opción activada (am_lighthouse: true), transportan muy poco tráfico y lo habitual es ejecutar dos en instancias VPS baratas. Nebula escucha por defecto en UDP 4242, y la configuración de ejemplo indica que un lighthouse debe tener su puerto fijo, mientras que los nodos itinerantes funcionan mejor con el puerto 0, que pide al sistema operativo uno dinámico.
Headscale asume él mismo el papel de coordinación, distribuyendo claves y el mapa de red, con relés DERP para el tráfico que no logra establecer una ruta directa. Puedes ejecutar tu propio DERP en lugar de usar los públicos.
Las arquitecturas se parecen. Lo que cambia es la forma operativa: el lighthouse de Nebula es un nodo de la malla, el plano de control de Headscale es un servicio con una base de datos detrás.
Reglas de cortafuegos, y dónde se aplican
Nebula coloca un cortafuegos de host en la propia configuración del nodo. Cada host declara qué conexiones entrantes acepta, expresadas en términos de grupos de certificados y no de direcciones IP. La aplicación es local, lo que significa que un plano de control comprometido no puede abrir un host en silencio.
Headscale expresa el control de acceso como ACL compatibles con Tailscale, definidas de forma centralizada y distribuidas a los nodos. Un único archivo describe toda la red, lo que es mucho más fácil de auditar y razonar, y que hace que dependa mucho más de que ese archivo sea correcto.
Una política centralizada es más legible; una política distribuida es más difícil de vulnerar desde un solo punto.
Una forma práctica de elegir
| Si esto describe tu flota | Inclínate por |
|---|---|
| Portátiles y móviles usados por personas que no deberían gestionar certificados | Headscale |
| Servidores, contenedores y appliances que ya configuras de forma declarativa | Nebula |
| Quieres MagicDNS, nodos de salida y un flujo de inicio de sesión conocido | Headscale |
| No quieres ninguna dependencia de la hoja de ruta de clientes de un proveedor | Nebula |
| Tu instinto dice que un plano de control comprometido no debe poder abrir hosts | Nebula |
| Tu instinto dice que un único archivo de políticas auditable vale más que muchos | Headscale |
Ambos acaban en el mismo tipo de servidor: Headscale necesita un VPS pequeño siempre encendido con IP pública y un dominio, y Nebula necesita uno para su lighthouse. Si la tabla apunta a Headscale, nuestro generador de configuración de Headscale gratuito escribe el config.yaml, el archivo Docker Compose y el bloque del proxy inverso para ese VPS, y un Contabo Cloud VPS 4 aparece desde 5,50 €/mes en contabo.com (comprobado el 17 oct. 2026). Si prefieres un proveedor estadounidense con garantía de reembolso de 30 días, Ultahost VPS Basic cuesta 5,52 $ al mes con un plazo de 24 meses (1 GB de RAM, IPv4 dedicada, consultado el 21 de octubre de 2026), suficiente para un servidor Headscale de un equipo pequeño.
Lo que no afirmaríamos
Circulan muchas comparativas de rendimiento entre ambos, y en su mayoría miden la máquina en la que se ejecutaron. WireGuard suele ejecutarse en el kernel de Linux mientras que el transporte de Nebula funciona en espacio de usuario, lo que tiende a favorecer a WireGuard en un servidor Linux, pero en enlaces saturados, en otros sistemas operativos o en CPU modestas esa ventaja a menudo se diluye en el ruido. Si el rendimiento es de verdad tu factor decisivo, la única cifra que vale la pena tener es la que mides en tu propia ruta, con tu propio hardware, en el trayecto que realmente sigue tu tráfico.
★ Datacenter Núremberg GDPR · ✓ IPv4 dedicada incluida · puerto de 200 Mbit/s
Aloja tu VPN en tu propio VPS → ContaboAcceso root completo · IPv4 pública · elige tu región→
