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.

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 secas | Headscale | |
|---|---|---|
| Función | Túnel entre pares que configuras tú | Servidor de control para clientes de Tailscale |
| Proceso en el servidor | Una interfaz de red, sin demonio | Un servicio con base de datos (SQLite recomendado) |
| Puertos públicos | Un puerto UDP a tu elección | TCP 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 TLS | No hacen falta | HTTPS en el puerto 443, muy recomendado por la documentación |
| Software cliente | WireGuard en cada dispositivo | Cliente de Tailscale en cada dispositivo |
| Añadir un dispositivo | Editar la configuración en ambos extremos | Un comando tailscale up |
| De dispositivo a dispositivo a través de NAT | Por tu servidor, salvo que uno de los dos tenga un punto final alcanzable | Directo cuando es posible, retransmitido por DERP si no |
| Nombres y reglas de acceso | Se construyen aparte | MagicDNS 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ón | Elige |
|---|---|
| Un VPS, unos pocos dispositivos, todo el tráfico pasa por el servidor | WireGuard |
| Quieres el menor número de piezas móviles y un único puerto UDP | WireGuard |
| Un router o un aparato que solo ofrece un cliente WireGuard | WireGuard |
| Portátiles, teléfonos y servidores que deben alcanzarse directamente | Headscale |
| Varios dispositivos detrás de NAT o CGNAT en ambos lados | Headscale |
| Añades y quitas dispositivos a menudo | Headscale |
| Quieres nombres y reglas de acceso centralizadas | Headscale |
| Cientos de dispositivos que cambian con frecuencia, o necesidad de soporte del fabricante | Ninguno: 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→


