VPNSmith
self-host-vpnINFO

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

Ejecuta WireGuard en Docker bien: linuxserver/wireguard vs wg-easy, el archivo docker-compose, los fallos de NET_ADMIN y sysctl, la persistencia, y cuándo un contenedor supera una instalación bare-metal.

Por Eric Gerard · Fundador · VPNSmith - Especialista en VPN self-host y VPS GDPR5 min de lecturaFoto vía Unsplash

Aviso de afiliación - Esta guía enlaza a Contabo, el VPS en el que corre nuestro propio WireGuard autoalojado. Si contratas a través de nuestro enlace, ganamos una comisión sin coste extra para ti. Solo documentamos lo que de verdad ejecutamos.

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.

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)

Racks de servidores iluminados en azul en un centro de datos
Racks de servidores iluminados en azul en un centro de datos

services:
  wg-easy:
    image: ghcr.io/wg-easy/wg-easy:latest
    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. Nosotros corremos el nuestro en Contabo por la 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.

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.

★ Datacenter Núremberg GDPR · ✓ IPv4 dedicada incluida · 200+ Mbps garantizados

Aloja tu VPN en tu propio VPS → ContaboAcceso root completo · IPv4 pública · elige tu región

Preguntas frecuentes

¿Es WireGuard más lento en Docker que en bare-metal?
Sin diferencia apreciable. WireGuard corre en el kernel Linux del host, no dentro del contenedor - el contenedor solo lleva las herramientas de userspace (wg, wg-quick) y la configuración. La ruta de datos pasa por el mismo módulo del kernel en ambos casos, así que el rendimiento y la latencia igualan a una instalación bare-metal. El contenedor es empaquetado, no una capa de rendimiento.
¿Qué imagen elegir - linuxserver/wireguard o wg-easy?
linuxserver/wireguard es el servidor mínimo gobernado por archivos de configuración: gestionas los peers editando archivos o variables de entorno. wg-easy añade una interfaz web para crear peers, mostrar códigos QR y ver el tráfico en vivo - mucho más cómodo para unos pocos dispositivos. Elige linuxserver/wireguard para infra-as-code y muchos peers; elige wg-easy para un panel y alta rápida de clientes.
¿Por qué mi contenedor WireGuard no arranca o no enruta?
Tres causas habituales. Una: el contenedor necesita la capability NET_ADMIN (y a veces SYS_MODULE) para gestionar la interfaz - añade `cap_add: [NET_ADMIN]`. Dos: el reenvío IP debe estar activo: `sysctl: net.ipv4.ip_forward=1` en compose o en el host. Tres: el puerto UDP publicado (51820/udp por defecto) debe estar abierto en el firewall cloud Y en el host. Si falta uno, el túnel conecta pero no enruta nada.
¿Sigo necesitando un VPS para ejecutar WireGuard en Docker?
Solo si quieres un punto de salida público con IP estable - para acceso remoto a una red doméstica puedes correr el contenedor en un servidor casero detrás de un port-forward. Para un VPN al que te conectas desde cualquier sitio (y para una IP estática limpia), un VPS pequeño es la opción estándar. Una instancia de 4-6 €/mes satura su enlace con WireGuard sin esfuerzo.
¿Cómo persisto peers y claves entre reinicios del contenedor?
Monta el directorio de configuración en el host (p. ej. `./config:/config`). Las claves y definiciones de peers viven ahí, así que `docker compose down && up` mantiene a cada cliente funcionando. Nunca guardes las claves solo en la capa escribible del contenedor - un recreate las borra y cada cliente tiene que re-enrolarse.