Por Cómo instalar Headscale para alojar tu propio Tailscale
Instala Headscale en un VPS desde el paquete oficial .deb, configura server_url, reinicia el servicio y conecta tu primer nodo a tu tailnet.
Qué es headscale
Headscale es una implementación autohospedada del servidor de control de Tailscale. Por tanto, la máquina que coordina su red privada es un VPS que usted controla. Es un proyecto comunitario y Tailscale Inc. no lo mantiene. Cada máquina sigue ejecutando el cliente oficial de tailscale, configurado para usar su servidor mediante un indicador: --login-server.
El servidor de control es el componente que sabe quién pertenece a la red. Asigna a cada nodo una dirección de 100.64.0.0/10, distribuye claves públicas e indica a los nodos dónde encontrarse. Los túneles siguen usando WireGuard y se establecen entre nodos. El tráfico entre dos de sus máquinas no pasa por el servidor de headscale, salvo que no se pueda establecer una ruta directa y los nodos tengan que usar un relay. Ejecutar usted mismo esa función de coordinación cambia quién la administra, no lo que puede hacer. Por eso conviene entender qué puede y qué no puede alcanzar un servidor de control en este modelo antes de considerar el cambio una mejora de seguridad por sí solo.
Headscale sirve un tailnet (una red de Tailscale) por instancia. El proyecto lo considera adecuado para uso personal o para una organización pequeña. Con tres o cuatro máquinas, una VPN WireGuard sencilla en un VPS propio implica ejecutar menos software y tener menos componentes que puedan fallar. Headscale resulta útil cuando ya no quiere escribir manualmente un bloque [Peer] para cada portátil nuevo. El coste suele ser el motivo inicial para buscar alternativas, por lo que conviene leer qué incluye realmente el plan gratuito alojado antes de hacerse cargo de un servidor, ya que un puñado de máquinas personales normalmente cabe dentro de sus límites. Si ya ha superado ese límite, haga los cálculos comparándolo con el coste de los planes de pago por usuario y recurso etiquetado, porque los dispositivos de usuario son ilimitados, mientras que los recursos etiquetados tienen límites y cargos independientes. Si quiere un plano de control autohospedado, pero prefiere tener su propio cliente y una interfaz web para administrar los pares en lugar de un reemplazo directo de Tailscale, NetBird en un solo VPS es la alternativa que conviene valorar. Ambos transportan el tráfico mediante WireGuard, por lo que la elección depende de cómo se escriben las reglas de acceso y de cómo se comportan los relés. Antes de instalar cualquiera de los dos, conviene comparar NetBird con Tailscale en esos aspectos. Para una comparación más amplia de ambos modelos, consulte las diferencias entre WireGuard y Tailscale.
Qué necesita antes de instalar
- Un VPS con Ubuntu 24.04, una dirección IPv4 pública y acceso mediante sudo. Si el servidor es nuevo, siga primero los primeros diez minutos en un VPS nuevo.
- Un registro DNS A que apunte a esa dirección. Esta guía usa
headscale.example.com. - Un segundo dominio o subdominio para MagicDNS. Esta guía usa
tailnet.example.net. No debe ser el mismo dominio que el deserver_url. - Un equipo cliente para conectar, con Linux, macOS, Windows, Android o iOS. Headscale 0.29.6 requiere Tailscale versión 1.80.0 o posterior.
Instalar headscale desde el .deb oficial
El proyecto publica paquetes .deb en su página de versiones de GitHub. A fecha del 27 de octubre de 2026, la versión estable más reciente es 0.29.6, publicada el 24 de octubre de 2026. Compruebe primero su arquitectura, porque el nombre del archivo la incluye.
sudo apt update
sudo apt install -y wget
dpkg --print-architectureEsto muestra amd64 en un VPS x86 normal y arm64 en un plan basado en Ampere o Graviton. Introduzca la respuesta en la variable siguiente.
HEADSCALE_VERSION="0.29.6"
HEADSCALE_ARCH="amd64"
wget --output-document=headscale.deb \\
"https://github.com/juanfont/headscale/releases/download/v${HEADSCALE_VERSION}/headscale_${HEADSCALE_VERSION}_linux_${HEADSCALE_ARCH}.deb"
sudo apt install -y ./headscale.deb
headscale versionEl ./ delante del nombre del archivo es obligatorio. Sin él, apt busca un paquete llamado headscale.deb en sus repositorios y falla.
El paquete crea un usuario del sistema headscale, escribe un archivo /etc/headscale/config.yaml predeterminado, instala una unidad de systemd y después inicia el servicio. Por tanto, headscale ya está en ejecución cuando apt termina, y sudo systemctl is-active headscale muestra active. Sin embargo, en una instalación nueva el paquete no habilita la unidad, por lo que el servicio no volverá a iniciarse después de un reinicio hasta que lo habilite; el paso de reinicio siguiente lo hace. También se ejecuta con la configuración incluida, que apunta server_url a http://127.0.0.1:8080, una dirección que ningún cliente suyo puede alcanzar. Todavía no se expone nada, porque el listen_addr incluido también está en loopback, pero no conecte ningún cliente hasta haber configurado server_url y reiniciado el servicio, como hacen los dos pasos siguientes.
Configurar server_url antes de que se una cualquier cliente
Edite /etc/headscale/config.yaml con sudo nano /etc/headscale/config.yaml o aplique los mismos tres cambios con sed. Conserve una copia del archivo original, porque es largo, contiene muchos comentarios y es la mejor referencia disponible para el resto de la configuración.
sudo cp /etc/headscale/config.yaml /etc/headscale/config.yaml.orig
sudo sed -i 's|^server_url:.*|server_url: https://headscale.example.com|' /etc/headscale/config.yaml
sudo sed -i 's|^listen_addr:.*|listen_addr: 127.0.0.1:8080|' /etc/headscale/config.yaml
sudo sed -i 's|^ base_domain:.*| base_domain: tailnet.example.net|' /etc/headscale/config.yaml
sudo grep -E '^(server_url|listen_addr):|^ base_domain:' /etc/headscale/config.yamlserver_url es la dirección pública que headscale usa al generar las URL de registro. Los clientes usan la dirección de control configurada con --login-server. Por tanto, use el mismo nombre público con https:// en ambos lugares, nunca 127.0.0.1. La documentación de headscale indica que se puede usar HTTP sin cifrar o HTTPS en un puerto distinto de 443, pero recomienda encarecidamente HTTPS en el puerto 443 para producción. El resto de esta guía presupone esa configuración.
listen_addr indica dónde se enlaza el proceso. Déjelo en loopback. Un reverse proxy en el mismo equipo termina TLS (seguridad de la capa de transporte) y reenvía las solicitudes a ese proceso. Por tanto, nada fuera del servidor necesita acceder al puerto 8080.
base_domain es el sufijo de MagicDNS, el dominio bajo el que los nodos reciben sus nombres. Debe ser un nombre de dominio completo sin un punto final y debe ser distinto del dominio indicado en server_url, porque de lo contrario los dos espacios de nombres entrarían en conflicto.
No modifique la sección de la base de datos. El valor predeterminado es SQLite en /var/lib/headscale/db.sqlite, dentro de un directorio creado y propiedad del paquete. SQLite es suficiente para una tailnet de este tamaño.
Reiniciar headscale y demostrar que está en ejecución
sudo systemctl restart headscale
sudo systemctl enable headscale
sudo systemctl is-active headscale
sudo systemctl is-enabled headscale
curl -sS -o /dev/null -w '%{http_code}\\n' http://127.0.0.1:8080/healthis-active muestra active, is-enabled muestra enabled y curl muestra 200. El reinicio es el paso que carga los cambios. Headscale lee su configuración una vez, al iniciar, por lo que el proceso iniciado por el paquete sigue usando el server_url proporcionado hasta que lo reinicie. sudo systemctl enable --now headscale no hace este trabajo: el servicio ya está en ejecución, por lo que el comando --now no cambia nada y el valor anterior sigue activo. El inicio durante el arranque corresponde a enable y no se configura automáticamente: en una instalación nueva, el paquete inicia el servicio sin habilitarlo, así que ejecute sudo systemctl enable headscale una vez, como se indica arriba.
Si is-active muestra algo distinto de active o curl no muestra 200, lea el journal con sudo journalctl -u headscale -n 50 --no-pager. En esta fase, el fallo casi siempre está en el archivo de configuración, porque headscale analiza el archivo completo antes de abrir un socket. Una indentación incorrecta o un ajuste obligatorio no válido detiene el proceso antes de que escuche en ningún puerto. Corrija el archivo y después ejecute sudo systemctl restart headscale. Cada cambio posterior de configuración requiere el mismo reinicio. Los clientes se vuelven a conectar automáticamente. Si las unidades de systemd son nuevas para usted, ejecutar sus propios servicios y temporizadores con systemd explica los comandos usados aquí.
Compruebe los archivos de estado mientras está en el shell:
stat -c '%U %n' /var/lib/headscale/db.sqlite /var/lib/headscale/noise_private.keyLas dos líneas empiezan por headscale, el usuario sin privilegios que creó el paquete. noise_private.key es la identidad del servidor para sus clientes. Consérvelo. Si lo elimina, headscale genera uno nuevo y los clientes deben obtener la nueva clave del servidor antes de volver a conectarse; los registros existentes permanecen en la base de datos.
Configurar TLS delante de headscale
Los clientes deben acceder a server_url mediante HTTPS. Caddy es la opción más sencilla porque solicita y renueva el certificado automáticamente.
sudo apt install -y caddySustituya /etc/caddy/Caddyfile por el bloque de la documentación de headscale:
headscale.example.com {
reverse_proxy 127.0.0.1:8080 {
header_up True-Client-IP {remote_host}
header_up X-Real-IP {remote_host}
}
}sudo caddy validate --adapter caddyfile --config /etc/caddy/Caddyfile
sudo systemctl restart caddy
sudo systemctl is-active caddyvalidate muestra adapted config to JSON cuando el archivo se puede analizar. Una advertencia que indica que el archivo no está formateado sólo es estética. Desde su portátil, curl -sS -o /dev/null -w '%{http_code}\\n' https://headscale.example.com/health también debería mostrar 200. Esta comprobación confirma que el DNS, el firewall, el certificado y el proxy funcionan juntos.
Este es el detalle del proxy que puede consumir una tarde. La conexión de control de Tailscale es una actualización HTTP. Se inicia con POST en lugar de GET, y el valor de la cabecera Upgrade es tailscale-control-protocol. Caddy la reenvía sin configuración adicional. nginx no lo hace, por lo que un front end de nginx debe reenviar explícitamente las cabeceras Upgrade y Connection. La documentación de headscale lo configura mediante un mapa de actualización:
map $http_upgrade $connection_upgrade {
default keep-alive;
'' close;
}
server {
listen 443 ssl;
server_name headscale.example.com;
location / {
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_buffering off;
proxy_pass http://127.0.0.1:8080;
}
}Si omite esas líneas, las peticiones normales siguen funcionando. Por eso /health devuelve 200 y todo parece correcto, mientras la conexión de control nunca se establece: los nodos nuevos no pueden registrarse y los nodos existentes no pueden volver a conectarse ni informar de que están en línea. Si elige nginx, Certbot en Ubuntu 24.04 con nginx cubre la parte del certificado.
Qué puertos abrir en UFW
sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verboseEl puerto 443 transporta la conexión de control de cada cliente a headscale. Si más adelante habilita el relay DERP integrado, también necesitará 3478/udp, que se explica más abajo. El puerto 80 se utiliza para el desafío HTTP de ACME (entorno de gestión automática de certificados) y para la redirección a HTTPS. Caddy puede obtener un certificado aunque el puerto 80 esté cerrado, porque puede usar el desafío TLS-ALPN en el puerto 443. Sin embargo, con el puerto 80 abierto están disponibles ambos desafíos y las solicitudes http:// sin cifrar se redirigen.
El puerto 8080 permanece cerrado. listen_addr es 127.0.0.1:8080, por lo que el proxy llega a headscale mediante la interfaz de loopback y no interviene ninguna regla del firewall. Abrir el puerto 8080 en UFW no expondría nada, porque ningún servicio escucha en él desde el exterior. Tampoco aportaría ninguna ventaja. Tenga en cuenta que la mayoría de los proveedores ejecutan un segundo firewall en su panel de control, separado de UFW. Por eso, un puerto puede estar abierto en el servidor y seguir cerrado en el perímetro. Conceptos básicos del firewall UFW en un VPS explica con más detalle la sintaxis de las reglas.
Crear un usuario y una clave de preautenticación
sudo headscale users create alice
sudo headscale users listEl comando headscale es un cliente. Se comunica con el daemon en ejecución mediante el socket Unix ubicado en /var/run/headscale/headscale.sock, que tiene el modo 0770 y pertenece al grupo headscale. Esto implica dos cosas. El comando falla si el servicio está detenido, que es otra razón por la que importa el orden de esta guía, y necesita sudo, a menos que añada su propia cuenta al grupo headscale.
users list muestra un ID junto a cada nombre. Necesita ese número porque el comando de claves acepta un ID de usuario numérico, no un nombre.
sudo headscale preauthkeys create --user 1 --expiration 24hLa clave se muestra una sola vez. Cópiela ahora. Una clave de preautenticación se puede usar una sola vez y es válida durante una hora, a menos que indique lo contrario, por lo que conviene configurar --expiration 24h mientras aún está realizando pruebas. Añada --reusable para crear una clave que inscriba varias máquinas y trátela como una contraseña, porque cualquiera que la tenga puede unirse a su red.
Conecta tu primer cliente con --login-server
En la máquina que quieres unir:
curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up --login-server https://headscale.example.com --auth-key 'hskey-auth-PASTE-YOUR-KEY-HERE'
tailscale status
tailscale ip -4tailscale ip -4 muestra la dirección que headscale asignó, por ejemplo 100.64.0.1. De vuelta en el servidor, sudo headscale nodes list muestra el nodo con su ID, su usuario y su estado en línea.
Usa la dirección HTTPS pública de server_url para --login-server. El cliente elimina las barras finales de su URL de control; no hay una comparación exacta de cadenas que obligue a omitir una.
Una máquina que inició sesión anteriormente en el servicio alojado de Tailscale conserva esa sesión. Ejecuta primero sudo tailscale logout y, después, tailscale up con --login-server.
Si omites --auth-key, el cliente muestra una URL. Ábrela y la página mostrará el identificador de ese intento de registro. Apruébalo en el servidor:
sudo headscale auth register --user alice --auth-id PASTE-THE-ID-FROM-THE-PAGEEse formulario es más práctico para tu propio portátil. Las claves de preautenticación son mejores para cualquier proceso automatizado, porque no es necesario que una persona lo supervise. Cuando el propio VPS ya es un nodo, también puede transportar el tráfico de Internet de tus otras máquinas. Esa es la configuración del nodo de salida, con la diferencia de que debes aprobar la ruta anunciada en el servidor mediante el comando headscale, en lugar de hacerlo en una consola de administración alojada. Si quieres acceder a una red privada situada detrás de ese VPS, en vez de usarlo como salida a Internet, el mismo paso de aprobación sirve para anunciar esa subred al resto de tu tailnet. Publicar una aplicación desde un nodo, en lugar de enrutar redes completas a través de él, es otra tarea. serve y funnel son las dos formas de hacerlo, aunque ambos dependen de los certificados y del mecanismo de entrada propios de Tailscale. Por tanto, considéralos funciones de una tailnet alojada, no algo que headscale proporcione directamente.
DERP y el componente que retransmite el tráfico cuando falla una ruta directa
DERP (designated encrypted relay for packets) es la ruta de respaldo. Cuando dos nodos no pueden abrir una conexión directa de WireGuard, normalmente porque ambos están detrás de una NAT (network address translation) estricta, envían los paquetes a través de un relay. El relay no tiene claves, por lo que no puede leer el tráfico. Sí puede ver qué nodos se comunican y cuántos datos se transfieren.
Debe quedar claro qué hace la configuración predeterminada. Headscale se distribuye apuntando a https://controlplane.tailscale.com/derpmap/default con auto_update_enabled: true y update_frequency: 3h, de modo que el plano de control es suyo, mientras que los relays son de Tailscale. Para la mayoría de los usuarios, es un intercambio razonable. Si no lo es, ejecute su propio relay.
Para ejecutar su propio relay, configure enabled: true dentro de derp.server en config.yaml, sustituya ipv4: 198.51.100.1 y ipv6: 2001:db8::1 incluidos por las direcciones públicas de su relay, o elimine ambas opciones para usar DNS. Después, reinicie headscale y abra el puerto STUN (session traversal utilities for NAT) con sudo ufw allow 3478/udp. Esas opciones de dirección tienen prioridad sobre DNS, por lo que dejar cualquiera de los valores de marcador envía los clientes a una dirección inaccesible. El archivo de configuración indica claramente el requisito: server_url debe usar https, porque DERP requiere TLS. Vaciar la lista derp.urls elimina los relays de Tailscale del mapa. Antes de hacerlo, mantenga un relay integrado o personalizado que funcione. Headscale se niega a iniciar con un mapa de relays vacío. Además, un mapa que sólo contiene un relay inaccesible deja sin comunicación a los nodos que no pueden conectarse directamente.
Desde un cliente, tailscale netcheck muestra la latencia de cada región de relay que conoce. tailscale status muestra direct con una dirección o relay con un código de región para las conexiones activas entre pares. Si un par permanece en relay, debe comprobar su ruta directa, incluidas las reglas de NAT y del firewall. Si un par está en direct y sigue siendo lento, se trata de otro problema. La respuesta habitual en ese caso es MTU, no el túnel en sí.
¿Por qué un nodo aparece como desconectado?
El proxy está descartando la actualización. La señal es que /health devuelve 200, mientras los registros nuevos fallan o los nodos existentes no pueden volver a conectarse. La conexión de control es un POST que contiene Upgrade: tailscale-control-protocol. Un proxy que no lo reenvía bloquea tanto el registro como el canal que comunica el estado del nodo. Compare la configuración de nginx con las líneas de actualización anteriores o cambie a Caddy para descartar el proxy.
La dirección pública de control cambió. Los nodos siguen conectándose a la dirección configurada con --login-server. Cambiar server_url no actualiza esa configuración del cliente. Si la dirección anterior ya no llega al servidor, ejecute sudo tailscale up --login-server https://headscale.example.com --force-reauth en cada nodo.
El cliente no está en ejecución. En el nodo, ejecute sudo systemctl is-active tailscaled y sudo journalctl -u tailscaled -n 50 --no-pager. Un cliente que no puede resolver su dominio o conectarse a él registra allí sus reintentos.
La clave caducó. Se explica en la sección siguiente.
Para supervisar el lado del servidor durante la prueba, ejecute sudo journalctl -u headscale -f en el VPS y reinicie tailscaled en el cliente. Revise también el journal del cliente: que una petición llegue a headscale no garantiza que aparezca una línea con el nivel de registro predeterminado. Por tanto, el silencio en los registros del servidor no demuestra por sí solo que exista un fallo de DNS, del firewall o del proxy.
Expiración de claves y el nodo que deja de funcionar semanas después
Existen dos expiraciones independientes. Confundirlas hace perder tiempo.
Las claves de preautenticación caducan rápidamente por diseño. El valor predeterminado es una hora y un uso. Si tailscale up rechaza la clave, genere una nueva en el servidor en lugar de editar nada en el cliente.
Las claves de nodo son la parte de larga duración. La sección node de config.yaml establece expiry: 0, y 0 significa que no hay una expiración predeterminada; aun así, puede aplicarse una expiración explícita del cliente o una expiración de OIDC. Los nodos etiquetados no están sujetos a la expiración automática, aunque un administrador puede hacerlos caducar explícitamente. Establezca expiry: 180d si quiere un valor predeterminado de 180 días para los registros sin etiquetas, pero la expiración solicitada por el cliente tiene prioridad y OIDC puede sustituir el valor predeterminado. Cambiar esta configuración no modifica retroactivamente los registros existentes. Un nodo con una expiración necesita volver a autenticarse antes de ese plazo mediante sudo tailscale up --login-server https://headscale.example.com --force-reauth. Un servidor sin interfaz al que nadie vuelva a autenticar quedará fuera de la red cuando expire su registro.
Hágalo manualmente cuando alguien pierda un portátil. sudo headscale nodes list le proporciona el ID, sudo headscale nodes expire -i 3 cierra la sesión de ese nodo y sudo headscale nodes delete -i 3 lo elimina por completo de la red.
Copias de seguridad y actualizaciones
/var/lib/headscale y /etc/headscale forman todo el servidor. Detenga el servicio antes de copiarlos, porque SQLite puede tener escrituras en curso y una base de datos copiada bajo carga puede quedar inconsistente.
sudo systemctl stop headscale
sudo tar czf /root/headscale-state.tgz -C /var/lib headscale
sudo tar czf /root/headscale-config.tgz -C /etc headscale
sudo systemctl start headscale
sudo chmod 600 /root/headscale-*.tgzTraslade ambos archivos fuera del servidor. Contienen las claves privadas y todos los registros, por lo que requieren el mismo cuidado que el propio servidor. copias de seguridad con restic desde un VPS explica cómo hacerlo de forma programada y cifrada.
Las actualizaciones repiten la instalación: descargue el nuevo .deb, sudo apt install ./headscale.deb, reinicie y vuelva a ejecutar las comprobaciones is-active y /health. Desde 0.29, la ruta de actualización es estricta. No se puede omitir una versión menor ni volver a una versión menor anterior. Actualice una versión menor cada vez, haga una copia de seguridad antes de cada paso y lea primero las notas de la versión correspondiente, porque esa versión modificó el comportamiento de la política ACL y cambió de ubicación varias claves de configuración. La versión 0.29.6 también incluye actualizaciones de seguridad para la validación de certificados y las dependencias, por lo que las instalaciones existentes de 0.29 deberían aplicar esta versión de corrección.
FAQ
¿headscale ya está en ejecución justo después de instalar el archivo .deb?
Sí. El paquete inicia el servicio en cuanto se instala, con el valor proporcionado en /etc/headscale/config.yaml, que escucha sólo en loopback y establece server_url en http://127.0.0.1:8080. En una instalación nueva no habilita el servicio, por lo que no se iniciará durante el arranque hasta que ejecute sudo systemctl enable headscale. La dirección proporcionada no sirve para los clientes, así que edite server_url, listen_addr y base_domain; después ejecute sudo systemctl restart headscale y confirme con sudo systemctl is-active headscale. Tiene que ser restart: headscale sólo lee el archivo cuando se inicia, y enable --now en un servicio que ya está en ejecución lo habilita para el arranque, pero no lo reinicia, por lo que los valores antiguos siguen activos. Si falla después del reinicio, sudo journalctl -u headscale -n 50 --no-pager identifica el problema. En esta etapa casi siempre se trata de un error de YAML, porque headscale analiza todo el archivo antes de asociar un puerto.
¿También tengo que instalar el cliente normal de Tailscale en mis equipos?
Sí. Headscale sólo sustituye al servidor de control. Cada nodo ejecuta el cliente oficial de Tailscale, y usted lo configura para usar su servidor con sudo tailscale up --login-server https://headscale.example.com. Esa opción existe en el cliente estándar, por lo que no es necesario aplicar parches ni recompilarlo.
¿El tráfico pasa por el servidor de headscale?
Normalmente no. Headscale coordina la red y distribuye claves y direcciones, mientras que la ruta de datos usa WireGuard directamente entre los nodos. El tráfico sólo toma una ruta alternativa cuando dos nodos no pueden comunicarse directamente y recurren a un relay DERP. Con la configuración proporcionada, esos relays son los públicos de Tailscale. Ejecute tailscale status en un nodo para comprobar si un peer determinado está direct o usa un relay.
¿Por qué mi nodo permanece desconectado después de registrarse?
Si un nodo aparece en headscale nodes list pero nunca pasa a estar en línea, debe comprobar su conexión de control, incluido el reverse proxy. Esa conexión es una actualización HTTP enviada como POST con la cabecera Upgrade: tailscale-control-protocol. nginx la descarta si no reenvía explícitamente las cabeceras Upgrade y Connection mediante proxy_set_header, como hace la configuración anterior a través de su bloque map $http_upgrade $connection_upgrade. Eliminar esas cabeceras también impide registrar nodos nuevos. Caddy la reenvía sin configuración adicional, por lo que permite comprobar rápidamente si el problema está en el proxy.
¿Necesito un nombre de dominio y TLS para headscale?
Para esta configuración, sí: use un nombre de dominio y HTTPS. Los certificados también pueden cubrir direcciones IP sin nombre de dominio, pero el archivo de configuración indica que DERP requiere TLS. Un dominio y Caddy requieren unos cinco minutos de configuración y proporcionan un endpoint HTTPS que se renueva automáticamente. HTTP sin cifrar es posible, pero la documentación de headscale recomienda encarecidamente HTTPS en el puerto 443 para producción y señala que el cliente de Tailscale presupone HTTPS en el puerto 443 en determinadas situaciones.