A maioria dos problemas de VPN se resume a poucas causas, e checar na ordem certa economiza uma noite inteira. Rode os comandos no servidor, a menos que o passo diga outra coisa. Os exemplos usam WireGuard na porta padrão 51820/udp; para OpenVPN ou Xray, troque pelo nome do seu serviço e pela sua porta.
Última verificação em 2026-11-13.
1. O servidor está em um plano com IPv4 próprio?
Um cliente VPN se conecta ao seu servidor de fora. Um plano NAT só deixa entrar de fora uma porta, a sua porta SSH pessoal, então nenhuma VPN consegue funcionar nele. Se o painel mostra um endereço com uma porta do tipo 20xxx, você está em NAT. Mudar para um IPv4 próprio mantém seus dados e não exige reinstalação; veja Trocar o endereço IP.
2. O serviço está rodando?
systemctl status wg-quick@wg0
journalctl -u wg-quick@wg0 -n 30 --no-pager
No OpenVPN a unidade costuma ser openvpn-server@server; no Xray, xray. Um serviço que não subiu quase sempre diz o motivo nas últimas linhas do log: um erro de digitação na configuração, um arquivo de chave faltando, uma porta já em uso.
3. Ele está escutando na porta que você espera?
ss -ulpn | grep 51820 # UDP: WireGuard, OpenVPN via UDP
ss -tlpn | grep 443 # TCP: Xray / VLESS, OpenVPN via TCP
Sem saída significa que o serviço não está escutando ali, diga o que disser a configuração. Compare a porta com a do seu cliente.
4. O firewall deixa passar?
ufw status verbose
Se o firewall está ativo e a sua porta não aparece, abra-a:
ufw allow 51820/udp
Preste atenção no protocolo: o WireGuard precisa de UDP, e uma regra 51820/tcp não faz nada por ele. Mantenha sua regra de SSH antes de ativar ou recarregar o firewall, senão você mesmo fica trancado do lado de fora. Se isso acontecer mesmo assim, o console no navegador do painel coloca você de volta.
5. O cliente realmente chega ao servidor?
No WireGuard, quem diz é o handshake:
wg show
latest handshake: N seconds ago em um peer significa que o cliente chegou ao servidor e que as chaves batem. Nenhuma linha de handshake significa que ele nunca chegou. Então confira, nesta ordem: o IP e a porta do endpoint na configuração do cliente, o firewall do passo 4 e se a chave pública do cliente está no bloco [Peer] do servidor (e vice-versa).
6. Conecta, mas nada abre?
O túnel funciona, mas o servidor não deixa o tráfego sair para a internet. Confira o encaminhamento:
sysctl net.ipv4.ip_forward
Tem que aparecer 1. Se não aparecer, ative de forma permanente:
echo 'net.ipv4.ip_forward=1' > /etc/sysctl.d/99-vpn.conf
sysctl --system
Depois confira a regra de NAT. Em uma configuração do WireGuard é a linha PostUp com MASQUERADE, e o nome da interface nela precisa ser o nome real da interface do seu servidor:
ip -br addr
Se a linha diz -o eth0 mas a sua interface tem outro nome, corrija a configuração e reinicie o serviço.
7. Teste a partir de outra rede
Conecte pelos dados móveis em vez do Wi-Fi de casa, ou peça para alguém em outro país testar. Se a VPN funciona lá mas não na sua rede de sempre, o servidor está bem e alguma coisa no meio do caminho está bloqueando a conexão.
- Para ver se o seu servidor é acessível a partir de um país específico: Como verificar se o IP do seu VPS está acessível a partir da Rússia e do Irã.
- Onde WireGuard e OpenVPN são reconhecidos e bloqueados, o VLESS + Reality parece HTTPS comum e é muito mais difícil de bloquear.
8. Ainda não funcionou?
Abra um ticket e conte o que você já verificou: a saída dos passos 2 a 5 e o nome do seu cliente VPN. Com isso, normalmente conseguimos dizer onde está o problema já na primeira resposta.
Comentários
Nenhum comentário ainda. Seja o primeiro.