WireGuard en Docker (2026): la forma limpia de autoalojarlo con docker-compose

Aviso de afiliación - Esta guía enlaza a Contabo, el proveedor de VPS que toma como ejemplo. Si contratas a través de nuestro enlace, ganamos una comisión sin coste extra para ti. La configuración de abajo sigue la documentación oficial de cada imagen.

Ejecutar WireGuard en Docker te da lo que hace que valgan la pena los contenedores: un servidor que levantas, derribas, versionas y trasladas a otro host en minutos, sin un solo paquete instalado en la máquina en sí. La pega: un contenedor VPN no es un contenedor normal - toca la pila de red del kernel, así que unos pocos flags son innegociables. Bien puestos, un WireGuard en contenedor es tan rápido como uno bare-metal. Mal puestos, el túnel conecta pero no enruta nada, en silencio.

Esta es la forma limpia, con forma de producción.

¿Aún sin host? Los ejemplos parten de un VPS Cloud de Contabo (enlace de afiliado), desde 5,50 € al mes en 24 meses (precio consultado el 17 de octubre de 2026): funciona bajo KVM, así que el host tiene su propio kernel con el módulo WireGuard integrado del que depende el contenedor. Si prefieres un proveedor estadounidense con 30 días de devolución, el VPS Basic de Ultahost cuesta 5,52 $ al mes a 24 meses (1 GB de RAM, IPv4 dedicada, leído el 21 de octubre de 2026), y sus VPS también funcionan con KVM (según ultahost.com, leído el 26 de octubre de 2026), así que el módulo del kernel también está. Otra opción: HostPapa Unmanaged VPS Lite (enlace de afiliado) por 2,95 $ al mes con un plazo de 3 años, luego a la tarifa normal (1 núcleo, 1 GB de RAM, 25 GB NVMe, acceso root por SSH, garantía de reembolso de 30 días, consultado el 28 de octubre de 2026).

Primero, el error clásico sobre «WireGuard en Docker»

WireGuard es un módulo del kernel. Cuando «ejecutas WireGuard en Docker», el cifrado y el enrutamiento siguen ocurriendo en el kernel Linux del host - el contenedor solo lleva las herramientas de userspace (wg, wg-quick) y tu configuración. Por eso no hay penalización de rendimiento: la ruta de datos nunca entra en el contenedor.

También explica los requisitos. Para crear y gestionar una interfaz de red desde un contenedor, este necesita una capability de red elevada (NET_ADMIN), y el host debe poder reenviar paquetes (net.ipv4.ip_forward=1). No son opciones de endurecimiento - sin ellas, el contenedor se niega a arrancar o levanta sin enrutar nada.

Elige tu imagen: linuxserver/wireguard vs wg-easy

Dos imágenes cubren casi todos los casos:

• linuxserver/wireguard - un servidor limpio gobernado por configuración. Defines los peers mediante variables de entorno o editando archivos en un directorio /config montado. Genera configs de cliente y códigos QR en el primer arranque. Ideal para infrastructure-as-code, muchos peers, o para versionar tu setup en un repo privado.
• wg-easy - WireGuard más un panel web. Crea y revoca peers desde el navegador, escanea códigos QR para móviles, observa el tráfico por cliente en vivo. Ideal para unos pocos dispositivos y alta rápida sin tocar el CLI. Lo cubrimos de principio a fin -incluido el cambio de contraseña de la v14- en la guía completa de wg-easy autoalojado.

Ambas son maduras y muy usadas. La decisión es panel-vs-archivos, no de calidad.

El archivo docker-compose (wg-easy)

Comprobación de versión (25 de octubre de 2026): este ejemplo usa las variables de wg-easy v14, por eso está fijado a la imagen :14. wg-easy v15 (versión actual 15.5.0) ya no lee WG_HOST, PASSWORD_HASH ni WG_DEFAULT_DNS. Para obtener un archivo v15 en un minuto, usa nuestro generador docker-compose de wg-easy.

# wg-easy v15 - generated on vpnsmith.com/en/tools/wg-easy-compose-generator
# Host: vpn.example.com - WireGuard port: 51820/udp - panel: https://wg.example.com

volumes:
  etc_wireguard:
  caddy_data:
  caddy_config:

services:
  wg-easy:
    image: ghcr.io/wg-easy/wg-easy:15
    container_name: wg-easy
    environment:
      - PORT=80
      - TRUSTED_PROXIES=10.42.42.43,fdcc:ad94:bacf:61a3::2b
    networks:
      wg:
        ipv4_address: 10.42.42.42
        ipv6_address: fdcc:ad94:bacf:61a3::2a
    volumes:
      - etc_wireguard:/etc/wireguard
      - /lib/modules:/lib/modules:ro
    ports:
      - "51820:51820/udp"   # WireGuard: the only port clients need
    restart: unless-stopped
    cap_add:
      - NET_ADMIN
      - SYS_MODULE
    sysctls:
      - net.ipv4.ip_forward=1
      - net.ipv4.conf.all.src_valid_mark=1
      - net.ipv6.conf.all.disable_ipv6=0
      - net.ipv6.conf.all.forwarding=1
      - net.ipv6.conf.default.forwarding=1

  caddy:
    image: caddy:2-alpine
    container_name: caddy
    ports:
      - "80:80/tcp"
      - "443:443/tcp"
      - "443:443/udp"
    networks:
      wg:
        ipv4_address: 10.42.42.43
        ipv6_address: fdcc:ad94:bacf:61a3::2b
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile:ro
      - caddy_data:/data
      - caddy_config:/config
    restart: unless-stopped

networks:
  wg:
    driver: bridge
    enable_ipv6: true
    ipam:
      driver: default
      config:
        - subnet: 10.42.42.0/24
        - subnet: fdcc:ad94:bacf:61a3::/64

wg.example.com {
	reverse_proxy wg-easy:80
}

# 1. Cortafuegos: primero SSH, luego el puerto de WireGuard
sudo ufw allow OpenSSH
sudo ufw allow 51820/udp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw allow 443/udp
sudo ufw enable
# Ojo: los puertos publicados por Docker saltan ufw. Ábrelos/ciérralos también en el cortafuegos del proveedor.

# 2. Crea la carpeta y pega el o los archivos generados
sudo mkdir -p /etc/docker/containers/wg-easy
cd /etc/docker/containers/wg-easy
sudo nano docker-compose.yml
sudo nano Caddyfile

# 3. Arranca wg-easy
sudo docker compose up -d
# Sigue los registros (Ctrl+C para salir)
sudo docker compose logs -f wg-easy

# 4. Abre el panel: https://wg.example.com

services:
  wg-easy:
    image: ghcr.io/wg-easy/wg-easy:14
    container_name: wg-easy
    environment:
      - WG_HOST=vpn.example.com        # dominio o IP pública de tu VPS
      - PASSWORD_HASH=<hash-bcrypt>     # login de la interfaz web
      - WG_DEFAULT_DNS=1.1.1.1
    volumes:
      - ./config:/etc/wireguard         # persistencia - mantenlo en el host
    ports:
      - "51820:51820/udp"               # datos WireGuard
      - "51821:51821/tcp"               # interfaz web (firewall a tu IP)
    cap_add:
      - NET_ADMIN
      - SYS_MODULE
    sysctls:
      - net.ipv4.ip_forward=1
      - net.ipv4.conf.all.src_valid_mark=1
    restart: unless-stopped

Tres líneas hacen el trabajo pesado y son los puntos de fallo habituales:

• cap_add: NET_ADMIN permite al contenedor gestionar la interfaz wg0. Sin ella, el contenedor no puede levantar el túnel.
• sysctls: net.ipv4.ip_forward=1 convierte la máquina en router. Sin ello, el túnel conecta pero ningún tráfico lo cruza - la causa nº 1 del «dice conectado pero nada funciona».
• volumes: ./config persiste claves y peers en el host para que un recreate no borre a todos los clientes.

Expón el puerto UDP de datos públicamente; pon firewall al puerto TCP de la interfaz web limitándolo a tu propia IP - nunca dejes el 51821 abierto a internet.

La checklist del host (hazla antes de culpar al contenedor)

Un contenedor puede ser perfecto y no enrutar nada por la capa de debajo:

1. Firewall cloud: abre 51820/udp en el security group de tu proveedor, no solo en el host. Es el fallo silencioso nº 1 en un VPS. Consulta qué puerto usa WireGuard y cómo abrirlo si cambias el puerto por defecto.
2. Módulo del kernel del host: la mayoría de distros modernas traen el módulo WireGuard (Linux 5.6+). Si modprobe wireguard falla en el host, instala las cabeceras del kernel - el contenedor no puede cargar un módulo que el host no tiene.
3. DNS de los clientes: ajusta WG_DEFAULT_DNS para que los clientes no filtren sus consultas a su antiguo resolutor. Combínalo con nuestra guía anti-fugas DNS de WireGuard.

Cuándo el contenedor es la opción correcta - y cuándo no

Usa Docker cuando corres otros servicios en la misma máquina y quieres WireGuard aislado y reproducible, cuando quieres el panel de wg-easy, o cuando redespliegas a menudo entre hosts. Todo el setup se vuelve un archivo compose versionable y trasladable.

Evita Docker cuando el VPS solo hace WireGuard. Un apt install wireguard bare-metal más un archivo de configuración es más simple, tiene una pieza móvil menos, y se scripta trivialmente - mira nuestras plantillas de configuración WireGuard y el tutorial completo Contabo + WireGuard. Para una máquina VPN de un solo propósito, el contenedor añade empaquetado que no necesitas.

El VPS debajo

En contenedor o no, WireGuard necesita un host con IP pública y un enlace decente. Un VPS pequeño basta de sobra - WireGuard es lo bastante ligero para que una instancia de 4-6 €/mes sature su puerto de red mucho antes de que el CPU se inmute. Contabo sirve aquí de ejemplo por su relación precio/ancho de banda:

Consigue un VPS Contabo para tu contenedor WireGuard →

Para el desglose completo de precio/rendimiento entre proveedores, mira el VPS más barato para un VPN WireGuard.

Su VPN oculta su IP. No su navegador.

Un túnel WireGuard bien configurado sustituye la dirección que ve un sitio. No cambia nada de lo que su navegador anuncia por su cuenta: fuentes, pantalla, zona horaria, pila gráfica. Esa combinación suele bastar para seguirle de una sesión a otra.

Mida su huella de navegador, medición pasiva, sin preguntas, sin cuenta, sin correo electrónico.

La limitación, con honestidad

Docker hace WireGuard portable, no más seguro. El contenedor comparte el kernel del host, corre con NET_ADMIN, y solo está tan blindado como el host. No aísla WireGuard de la máquina - quien tenga root en el host posee el túnel. Trata el contenedor como comodidad de despliegue, endurece el host como si WireGuard estuviera instalado directamente en él, y mantén el puerto de la interfaz web fuera de internet. Hazlo, y WireGuard en contenedor es el setup autoalojado más limpio que hay.