VPNSmith
self-host-vpnCOMP

Headscale frente a WireGuard (2026): uno es el túnel, el otro reparte las claves

Headscale no sustituye a WireGuard: lo coordina. Con WireGuard a secas, cada par se escribe a mano; Headscale reparte claves, direcciones y rutas a los clientes de Tailscale. Qué exige cada uno, qué dice la documentación de Headscale que no es, y cómo elegir.

Por Eric Gerard · Fundador · VPNSmith - Especialista en VPN self-host y VPS GDPR9 min de lecturaPhoto via Pexels

Aviso de afiliación - Este artículo contiene un enlace de afiliado de Contabo. Si contratas un VPS a través de nuestro enlace, recibimos una comisión sin coste adicional para ti. Los datos sobre Headscale y WireGuard que siguen se leyeron en la documentación oficial de cada proyecto el 8 de octubre de 2026.

Respuesta rápida: «Headscale frente a WireGuard» no es una elección entre dos protocolos VPN. WireGuard es el túnel. Headscale es un servidor de control que indica a los clientes de Tailscale qué claves WireGuard, qué direcciones y qué rutas usar, para que no tengas que escribirlas a mano. Quédate con WireGuard a secas si tienes un servidor y un puñado de dispositivos que solo necesitan llegar a ese servidor. Elige Headscale si quieres que muchos dispositivos se alcancen entre sí, a través de NAT, con nombres, reglas de acceso y sin ningún archivo de configuración que editar en cada máquina.

Dos capas, no dos rivales

El proyecto WireGuard resume lo que hace en una frase: encapsula de forma segura paquetes IP sobre UDP. Añades una interfaz, le das tu clave privada y las claves públicas de tus pares, y los paquetes circulan. La misma página es igual de clara sobre lo que deja fuera: todo lo relativo a la distribución de claves y a las configuraciones enviadas a los clientes queda fuera del alcance de WireGuard ("out of scope", en el original).

Esa capa ausente es justo lo que aporta Headscale. Su README lo define como una implementación de código abierto y autoalojada del servidor de control de Tailscale, y describe ese servidor como el punto de intercambio de las claves públicas WireGuard de los nodos de la red: asigna las direcciones IP de los clientes y expone las rutas que anuncian.

La comparación real, por tanto, es esta:

  • WireGuard a secas: el plano de control eres tú. Generas las claves, eliges las direcciones, escribes cada bloque [Peer] y lo copias en ambos extremos.
  • Headscale: el plano de control es un servicio que alojas. Los dispositivos ejecutan el cliente de Tailscale, inician sesión en tu servidor y reciben sus pares automáticamente.

En ambos casos, el tráfico entre tus máquinas va cifrado con el protocolo WireGuard.

Lo que te pide WireGuard a secas

Una red WireGuard se define con archivos de configuración. Cada par es una clave pública más las direcciones de túnel que tiene permitido usar, lo que el proyecto llama Cryptokey Routing:

[Interface]
PrivateKey = <server-private-key>
Address = 10.8.0.1/24
ListenPort = 51820

[Peer]
PublicKey = <laptop-public-key>
AllowedIPs = 10.8.0.2/32

Para un servidor central con unos pocos clientes esto es corto y transparente, y no se ejecuta nada más que la propia interfaz. Nuestra guía de WireGuard en Contabo cubre ese montaje de principio a fin, y wg-easy le añade una interfaz web sin cambiar el modelo.

El coste aparece cuando la red crece en una dirección concreta:

  • Cada dispositivo añadido obliga a editar al menos dos archivos. El nuevo par necesita conocer al servidor, y el servidor al nuevo par.
  • Una malla completa lo multiplica. Si 10 dispositivos deben alcanzar directamente a los otros 9, son 45 parejas que describir, en ambos lados.
  • Alguien tiene que ser alcanzable. Un túnel se establece hacia un punto final, una dirección IP y un puerto UDP. Dos dispositivos que están ambos detrás de NAT no tienen ese punto final el uno para el otro, que es la situación descrita en nuestra guía de WireGuard detrás de CGNAT. La respuesta habitual es hacerlo pasar todo por el servidor.
  • Los nombres y las reglas de acceso los construyes tú. WireGuard te da direcciones. El DNS y el filtrado entre pares son trabajo aparte.

Nada de esto es un defecto. Es el alcance que eligió el proyecto, y para un único servidor es una ventaja: menos piezas móviles, un solo puerto UDP.

Lo que añade Headscale

Con Headscale, el trabajo por dispositivo se reduce a un comando. En el servidor creas un usuario y una clave preautenticada:

headscale users create <USER>
headscale preauthkeys create --user <USER_ID>

y en cada dispositivo, con el cliente de Tailscale instalado:

tailscale up --login-server <YOUR_HEADSCALE_URL> --authkey <YOUR_AUTH_KEY>

El dispositivo recibe entonces su dirección y sus pares desde tu servidor. La lista de funciones de la documentación de Headscale incluye:

  • MagicDNS y split DNS, para que las máquinas tengan nombres en lugar de direcciones.
  • ACL en un archivo de políticas central, en vez de reglas de cortafuegos en cada host.
  • Routers de subred y nodos de salida, para llegar a toda una LAN o enviar todo el tráfico a través de un nodo.
  • Un servidor DERP integrado. La documentación describe DERP como un relé usado sobre todo cuando no se puede establecer una conexión directa entre dos nodos. Viene desactivado por defecto.
  • Registro mediante OpenID Connect, además de las claves preautenticadas.
Paneles traseros de dos servidores de rack apilados, vistos de frente: rejillas metálicas perforadas, un puerto serie sobre una etiqueta verde, un puerto VGA azul, una toma Ethernet RJ45 y dos ranuras de módulos superpuestas en cada uno, con un cable naranja desenfocado que cruza la esquina inferior izquierda
Los paneles traseros de dos servidores de rack, cada uno con un puerto serie, un puerto VGA y una toma Ethernet. Elijas la opción que elijas, una máquina con dirección pública tiene que ser alcanzable por todas las demás.

Lo que la documentación de Headscale dice que no es

Es la parte que las comparativas suelen saltarse, y el propio proyecto la escribe sin rodeos.

  • Alcance. El README indica que Headscale cubre un alcance reducido: una sola red de Tailscale (tailnet), adecuada para uso personal o para una pequeña organización de código abierto.
  • Escala. Las preguntas frecuentes dicen que Headscale no es software empresarial ("not enterprise software") y que el rendimiento no es una prioridad. Estiman que el servidor probablemente puede gestionar cientos de dispositivos cuando la red cambia poco.
  • Funciones ausentes. Funnel, Serve y los registros de flujo de red aparecen sin marcar en la lista de funciones.
  • Despliegue. El README señala que los mantenedores no dan soporte ni recomiendan usar proxies inversos ni contenedores para ejecutar Headscale. El soporte oficial cubre los binarios y los paquetes DEB. Las imágenes de contenedor se construyen por comodidad.
  • Clientes. Los dispositivos usan el cliente de Tailscale. El proyecto aspira a ser compatible con sus 10 últimas versiones, en Linux, OpenBSD, FreeBSD, Windows, Android, macOS, iOS y tvOS.
  • Base de datos. Se recomienda SQLite. PostgreSQL sigue siendo compatible, pero se describe como en "maintenance mode".

Headscale se publica bajo la licencia BSD-3-Clause. La última versión en GitHub en la fecha en que se escribió esta página es la v0.29.4, publicada el 23 de septiembre de 2026.

Lo que necesita cada uno en el servidor

WireGuard a secasHeadscale
FunciónTúnel entre pares que configuras túServidor de control para clientes de Tailscale
Proceso en el servidorUna interfaz de red, sin demonioUn servicio con base de datos (SQLite recomendado)
Puertos públicosUn puerto UDP a tu elecciónTCP 443 (HTTPS); UDP 3478 si el DERP integrado está activado; TCP 80 solo si el cliente de Let's Encrypt incorporado usa el desafío HTTP-01
Dominio y TLSNo hacen faltaHTTPS en el puerto 443, muy recomendado por la documentación
Software clienteWireGuard en cada dispositivoCliente de Tailscale en cada dispositivo
Añadir un dispositivoEditar la configuración en ambos extremosUn comando tailscale up
De dispositivo a dispositivo a través de NATPor tu servidor, salvo que uno de los dos tenga un punto final alcanzableDirecto cuando es posible, retransmitido por DERP si no
Nombres y reglas de accesoSe construyen aparteMagicDNS y ACL incluidos

Fuentes: wireguard.com, el README de Headscale y la documentación de Headscale (requisitos, funciones, preguntas frecuentes, DERP), leídos el 8 de octubre de 2026.

Los dos necesitan lo mismo por debajo: una pequeña máquina Linux con una dirección IP pública que permanezca en línea. Ninguno de los dos proyectos publica un mínimo de RAM o de CPU en las páginas citadas aquí, y un VPS de gama de entrada es el alojamiento habitual de cualquiera de ellos.

Ver los planes actuales de Contabo Cloud VPS

¿Cuál deberías montar?

Tu situaciónElige
Un VPS, unos pocos dispositivos, todo el tráfico pasa por el servidorWireGuard
Quieres el menor número de piezas móviles y un único puerto UDPWireGuard
Un router o un aparato que solo ofrece un cliente WireGuardWireGuard
Portátiles, teléfonos y servidores que deben alcanzarse directamenteHeadscale
Varios dispositivos detrás de NAT o CGNAT en ambos ladosHeadscale
Añades y quitas dispositivos a menudoHeadscale
Quieres nombres y reglas de acceso centralizadasHeadscale
Cientos de dispositivos que cambian con frecuencia, o necesidad de soporte del fabricanteNinguno: mira el servicio alojado de Tailscale

Si la última fila se parece a tu caso, Tailscale frente a Headscale compara el servicio alojado y el servidor autoalojado, y Tailscale frente a WireGuard autoalojado aborda la misma pregunta desde el lado de WireGuard.

¿Se pueden usar los dos?

Sí, y es un montaje razonable. Una interfaz WireGuard corriente en su propio puerto UDP y un servicio Headscale en el puerto TCP 443 no compiten por el mismo puerto. Un reparto habitual: un túnel WireGuard para un enlace fijo, como la conexión sitio a sitio entre dos redes, y Headscale para los dispositivos personales que se mueven. El precio son dos sistemas que mantener actualizados, así que hazlo solo si cada uno resuelve un problema que el otro no resuelve.

Resumen

WireGuard es un protocolo y te deja a ti la distribución de claves. Headscale es una forma de hacer esa distribución por tu cuenta, con el cliente de Tailscale, en un servidor que controlas. Empieza con WireGuard a secas cuando baste un servidor central. Pasa a Headscale cuando los archivos de configuración se conviertan en lo principal que mantienes, y lee antes su documentación: deja claro que está pensado para redes personales y grupos pequeños. La instalación paso a paso está en nuestra guía del plano de control de Headscale.

★ 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→

Preguntas frecuentes

¿Headscale está construido sobre WireGuard?
Sí, de forma indirecta. Headscale es una implementación autoalojada del servidor de control de Tailscale, y su README describe Tailscale como una VPN construida sobre WireGuard. Los paquetes entre tus dispositivos son paquetes WireGuard; Headscale solo indica a cada cliente de Tailscale qué claves, direcciones y rutas debe usar.
¿Puedo usar Headscale con el cliente estándar de WireGuard?
No. Headscale habla el protocolo de control de Tailscale, así que los dispositivos se unen con el cliente de Tailscale apuntando a tu servidor mediante la opción login-server. Una interfaz wg0 corriente, configurada con wg o wg-quick, no puede registrarse en Headscale.
¿Headscale necesita un servidor con IP pública?
Sí. La página de requisitos de Headscale pide un servidor con una dirección IP pública, servido por HTTPS en el puerto 443, sobre un Linux o BSD razonablemente moderno. Si activas el relé DERP integrado, también hay que exponer el puerto UDP 3478 para STUN.
¿Cuántos dispositivos puede gestionar Headscale?
Las preguntas frecuentes de Headscale responden «depende» y señalan que el proyecto no es software empresarial: se centra en homelabs y en quien autoaloja. Indican que Headscale probablemente puede gestionar cientos de dispositivos cuando la red cambia poco, y que muchos nodos que cambian a menudo es el caso en el que empieza a sufrir.
¿Cuál es más sencillo para dos o tres dispositivos?
WireGuard a secas. Un servidor, dos o tres bloques de pares y un único puerto UDP dan menos trabajo que un servidor de control con base de datos, dominio y certificado TLS. Headscale empieza a compensar cuando el número de dispositivos, o el número de parejas que deben hablarse directamente, vuelve propensa a errores la configuración escrita a mano.