WireGuard em Docker (2026): a forma limpa de auto-hospedar com docker-compose

Executar o WireGuard em Docker oferece-lhe aquilo que torna os containers valiosos: um servidor que pode ser iniciado, desmontado, versionado e movido para outro host em minutos, sem instalar pacotes na máquina em si. A questão é que um container VPN não é um container normal - ele interage com a pilha de rede do kernel, por isso alguns parâmetros são inegociáveis. Configure-os corretamente e um WireGuard containerizado é tão rápido quanto um bare-metal. Configure-os incorretamente e o túnel conecta-se mas não encaminha nada silenciosamente.

Esta é a forma limpa e orientada para produção de o fazer.

Ainda sem servidor? Os exemplos partem de um VPS Cloud da Contabo (link afiliado), a partir de 5,50 € por mês em 24 meses (preço consultado a 17 de outubro de 2026): corre sob KVM, por isso o host tem o seu próprio kernel com o módulo WireGuard integrado de que o contentor depende. Se preferir um fornecedor dos EUA com 30 dias de reembolso, o VPS Basic da Ultahost custa 5,52 $ por mês em 24 meses (1 GB de RAM, IPv4 dedicado, lido a 21 de outubro de 2026), e os seus VPS também correm em KVM (indicado em ultahost.com, lido a 26 de outubro de 2026), por isso o módulo do kernel também está lá. Outra opção: HostPapa Unmanaged VPS Lite (link de afiliado) a 2,95 $ por mês num prazo de 3 anos, depois ao preço normal (1 núcleo, 1 GB de RAM, 25 GB NVMe, acesso root por SSH, garantia de reembolso de 30 dias, consultado a 28 de outubro de 2026).

Primeiro, o erro que as pessoas cometem sobre "WireGuard em Docker"

WireGuard é um módulo do kernel. Quando "executa o WireGuard em Docker", a encriptação e o encaminhamento ainda ocorrem no kernel Linux do host - o container apenas transporta as ferramentas de espaço de utilizador (wg, wg-quick) e a sua configuração. É por isso que não há penalização de desempenho: o caminho dos dados nunca entra no container.

Isso também explica os requisitos. Para criar e gerir uma interface de rede a partir de dentro de um container, esse container precisa de capacidade de rede elevada (NET_ADMIN), e o host deve estar autorizado a encaminhar pacotes (net.ipv4.ip_forward=1). Estas não são escolhas opcionais de endurecimento - sem elas, o container ou se recusa a iniciar ou surge inativo.

Escolha a sua imagem: linuxserver/wireguard vs wg-easy

Duas imagens cobrem quase todos os casos de uso:

• linuxserver/wireguard - um servidor limpo e orientado por configuração. Define os pares através de variáveis de ambiente ou editando ficheiros num diretório montado /config. Gera configurações de cliente e códigos QR na primeira execução. Ideal quando deseja infraestrutura como código, muitos pares, ou para guardar a sua configuração num repositório privado.
• wg-easy - WireGuard mais um painel web. Crie e revogue pares a partir de um navegador, digitalize códigos QR para telemóveis, veja estatísticas de transferência ao vivo por cliente. Melhor para um punhado de dispositivos e integração rápida sem tocar na linha de comando. Cobrimo-lo de ponta a ponta - incluindo a mudança de palavra-passe da v14 - no guia completo de wg-easy auto-hospedado.

Ambos são maduros e amplamente utilizados. A decisão é entre painel vs ficheiros, não qualidade.

O ficheiro docker-compose (wg-easy)

Verificação de versão (25 de outubro de 2026): este exemplo usa as variáveis do wg-easy v14, por isso está fixado na imagem :14. O wg-easy v15 (versão atual 15.5.0) já não lê WG_HOST, PASSWORD_HASH nem WG_DEFAULT_DNS. Para obter um ficheiro v15 num minuto, use o nosso gerador docker-compose para 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. Firewall: primeiro SSH, depois a porta do 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
# Atenção: as portas publicadas pelo Docker contornam o ufw. Abra/feche-as também na firewall do fornecedor.

# 2. Crie a pasta e cole o ou os ficheiros gerados
sudo mkdir -p /etc/docker/containers/wg-easy
cd /etc/docker/containers/wg-easy
sudo nano docker-compose.yml
sudo nano Caddyfile

# 3. Arranque o wg-easy
sudo docker compose up -d
# Acompanhe os registos (Ctrl+C para sair)
sudo docker compose logs -f wg-easy

# 4. Abra o painel: 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        # o domínio do seu VPS ou IP público
      - PASSWORD_HASH=<bcrypt-hash>     # login na interface web
      - WG_DEFAULT_DNS=1.1.1.1
    volumes:
      - ./config:/etc/wireguard         # persistência - mantenha isto no host
    ports:
      - "51820:51820/udp"               # dados do WireGuard
      - "51821:51821/tcp"               # interface web (proteja este com firewall para o seu IP)
    cap_add:
      - NET_ADMIN
      - SYS_MODULE
    sysctls:
      - net.ipv4.ip_forward=1
      - net.ipv4.conf.all.src_valid_mark=1
    restart: unless-stopped

Três linhas fazem o trabalho pesado e são os pontos de falha habituais:

• cap_add: NET_ADMIN permite que o container gerencie a interface wg0. Sem isso, o container não consegue ativar o túnel.
• sysctls: net.ipv4.ip_forward=1 transforma a máquina num router. Sem isso, o túnel conecta-se mas nenhum tráfego o atravessa - a causa mais comum de "diz que está conectado mas nada funciona".
• volumes: ./config mantém as chaves e pares no host para que uma recriação não apague todos os clientes.

Exponha a porta de dados UDP publicamente; proteja a porta TCP da interface web para o seu próprio IP - nunca deixe a 51821 aberta para a internet.

A lista de verificação do host (faça isto antes de culpar o container)

Um container pode estar perfeito e ainda assim não encaminhar nada por causa da camada subjacente:

1. Firewall na nuvem: abra 51820/udp no grupo de segurança do seu fornecedor, não apenas no host. Esta é a falha silenciosa número um num VPS. Vê que porta o WireGuard usa e como abri-la se alterares a porta padrão.
2. Módulo do kernel do host: a maioria das distribuições modernas traz o módulo WireGuard no kernel (Linux 5.6+). Se modprobe wireguard falhar no host, instale os cabeçalhos do kernel - o container não pode carregar um módulo que o host não tem.
3. DNS para clientes: defina WG_DEFAULT_DNS para que os clientes não vazem consultas para qualquer resolvedor que estavam a usar. Combine isso com o nosso guia de prevenção de vazamento de DNS do WireGuard.

Quando um container é a escolha certa - e quando não é

Use Docker quando executa outros serviços na mesma máquina e quer o WireGuard isolado e reproduzível, quando deseja o painel do wg-easy, ou quando faz redeploy frequentemente entre hosts. Toda a configuração torna-se num ficheiro compose que pode versionar e mover.

Evite Docker quando o VPS não faz nada além do WireGuard. Uma instalação bare-metal apt install wireguard mais um ficheiro de configuração é mais simples, tem uma peça a menos e é trivialmente scriptável - veja os nossos modelos de configuração WireGuard e o walkthrough completo Contabo + WireGuard auto-hospedado. Para uma caixa VPN de propósito único, o container adiciona uma embalagem que não precisa.

O VPS por baixo

Containerizado ou não, o WireGuard precisa de um host com um IP público e uma ligação decente. Um pequeno VPS é suficiente - o WireGuard é leve o suficiente para que uma instância de 4-6 €/mês sature a sua porta de rede muito antes de o CPU notar. A Contabo serve aqui de exemplo pela relação preço-largura de banda:

Obtenha um VPS Contabo para o seu container WireGuard →

Para a análise completa de preço/desempenho entre fornecedores, veja o VPS mais barato para um VPN WireGuard.

Para ter o essencial à mão: a WireGuard Cheat Sheet gratuita (PDF de 5 páginas em inglês, download direto, sem registo) reúne as tabelas de keepalive e MTU, os comandos wg genkey/wg pubkey/wg genpsk e as quatro verificações de servidor numa linha a correr primeiro quando um túnel não passa tráfego. O WireGuard Self-Hosting Kit pago (9 USD, em inglês) acrescenta uma checklist de diagnóstico com 12 causas e 11 modelos de configuração.

Uma VPN muda o seu IP. Não muda o seu navegador.

Um túnel substitui o endereço que um serviço vê. Não altera nada do que o seu navegador anuncia por conta própria - tipos de letra, ecrã, fuso horário, pilha gráfica - e essa combinação costuma bastar para o reconhecer de uma sessão para a outra.

Meça a sua impressão digital de navegador - medição passiva, sem perguntas, sem conta, sem e-mail.

A limitação honesta

Docker torna o WireGuard portátil, não mais seguro. O container partilha o kernel do host, executa-se com NET_ADMIN e é apenas tão seguro quanto o host. Não isola o WireGuard da máquina - qualquer pessoa com acesso root no host controla o túnel. Trate o container como uma conveniência de implementação, endureça o host como se o WireGuard estivesse instalado diretamente nele, e mantenha a porta da interface web fora da internet pública. Faça isso, e o WireGuard containerizado é a configuração de auto-hospedagem mais limpa que existe.