Túnel SSH SOCKS proxy: como navegar via servidor remoto pelo terminal
Aprenda a criar um túnel SSH SOCKS proxy pra navegar via servidor remoto: comando, config no navegador, autostart e troubleshooting de DNS leak.
Um túnel SSH SOCKS proxy transforma qualquer servidor com SSH numa porta de saída pra todo o tráfego HTTP/HTTPS do seu navegador. Você abre uma conexão SSH com a flag -D apontando pra uma porta local, e o cliente OpenSSH passa a escutar nessa porta como se fosse um proxy SOCKS5 nativo — qualquer programa configurado pra usar 127.0.0.1:1080 envia os pacotes pelo túnel cifrado e sai pra internet com o IP do servidor remoto.
O caso de uso mais comum é debug de aplicações region-locked: você precisa validar como seu site renderiza pra um usuário em outro país, conferir se a CDN está servindo cache regional correto, ou simular a experiência de cliente que está atrás de uma rota diferente. Outras situações típicas: acessar painéis administrativos restritos por IP allowlist (você libera só o IP da VPS), conectar em recursos de rede privada sem expor portas adicionais, ou simplesmente navegar sob conexão que você considera mais confiável que o Wi-Fi público.
Este tutorial mostra o setup completo em ~15 minutos: criar o túnel, configurar o navegador (Firefox e Chrome), validar com checagem de IP, evitar vazamento de DNS, e deixar o túnel persistente com autossh e systemd.
Pré-requisitos
Você precisa de acesso SSH funcional a um servidor Linux — uma VPS comum, sem configuração especial. O OpenSSH server vem pré-instalado em qualquer distribuição padrão (Ubuntu, Debian, Rocky, AlmaLinux) e aceita port forwarding por default. Não é necessário privilégio root no servidor remoto; um usuário comum com shell login basta.
Cliente OpenSSH no seu desktop (Linux/macOS nativos; Windows 10/11 via PowerShell ou WSL2), servidor remoto com SSH ativo e acesso por chave ou senha, e porta 22 acessível. O servidor não precisa de nenhuma configuração extra — port forwarding já vem habilitado no sshd_config padrão.
Dados típicos pra montar o túnel:
203.0.113.42 deploy 22 1080 Criando o túnel SOCKS5
A flag -D do ssh é abreviatura de “dynamic port forwarding” e ativa o modo SOCKS no cliente. Diferente de -L (forward de uma porta específica) ou -R (forward reverso), -D cria um proxy completo que aceita conexões pra qualquer host:porta de destino.
Abra um terminal local e rode o comando do túnel:
ssh -D 1080 -N -C [email protected]-D 1080— abre a porta SOCKS5 em127.0.0.1:1080-N— não executa comando remoto (só mantém o túnel)-C— habilita compressão (útil em links lentos, irrelevante em fibra)
O terminal vai parecer travado depois da autenticação — é normal. O processo está ativo segurando o túnel. Não feche essa janela enquanto estiver usando o proxy.
Em outro terminal, confirme que a porta está escutando localmente:
ss -tlnp | grep 1080A saída esperada é uma linha tipo LISTEN 0 128 127.0.0.1:1080 ... indicando que o cliente SSH está vinculado à porta. Se nada aparecer, o túnel não subiu — volte ao terminal anterior e confira se há mensagem de erro.
Por padrão o túnel escuta só em 127.0.0.1, o que é correto pra uso pessoal. Se quiser compartilhar o proxy com outra máquina da sua LAN, use -D 0.0.0.0:1080 — mas habilite firewall local pra não expor o proxy pra internet inteira.
Configurando o navegador
O túnel está rodando, agora você precisa apontar o navegador pra ele. Firefox e Chrome têm caminhos diferentes — Firefox tem proxy próprio independente do sistema, Chrome usa o proxy do sistema operacional a menos que você force via flag.
Firefox
Abra about:preferences no Firefox, role até “Network Settings” e clique em “Settings…”. Selecione “Manual proxy configuration”, preencha:
- SOCKS Host:
127.0.0.1Port:1080 - Marque “SOCKS v5”
- Marque “Proxy DNS when using SOCKS v5” — fundamental pra evitar leak
Salve e feche. O Firefox passa a rotear todo o tráfego pelo túnel imediatamente.
Confirme em about:config que network.proxy.socks_remote_dns está como true. Essa preferência garante que as queries DNS também passam pelo túnel — sem ela, o Firefox resolve hostnames usando o resolver local antes de mandar o request pelo proxy, vazando sua atividade pro provedor.
Chrome / Chromium
Chrome ignora configuração de proxy no nível da aba — usa a configuração do sistema. Pra forçar SOCKS5 sem mudar o sistema inteiro, abra o navegador com flag:
Feche todas as janelas do Chrome e rode pela linha de comando:
google-chrome \
--proxy-server="socks5://127.0.0.1:1080" \
--host-resolver-rules="MAP * ~NOTFOUND , EXCLUDE 127.0.0.1"A segunda flag força resolução DNS via SOCKS (equivalente ao socks_remote_dns do Firefox). Sem ela, Chrome faz lookup local antes de tunelar.
Verificação
A forma mais simples de confirmar que o tráfego está saindo pela VPS é checar o IP público visto pelo navegador.
No navegador configurado, abra https://ifconfig.me ou https://ipinfo.io. O IP retornado deve ser o IP público da sua VPS, não o IP da sua conexão doméstica.
Pra comparar lado a lado: abra https://ipinfo.io num navegador SEM proxy e copie o resultado. Depois abra a mesma URL no navegador com túnel ativo. Os dois IPs precisam ser diferentes — e o segundo deve bater com o IP do comando curl ifconfig.me rodado direto na VPS.
Teste o leak de DNS visitando https://dnsleaktest.com e rodando o teste estendido. Os resolvers retornados devem ser os do provedor da VPS (geralmente Cloudflare 1.1.1.1, Google 8.8.8.8 ou os DNS do datacenter), não os do seu ISP local. Se aparecerem servidores do seu provedor doméstico, o passo de DNS remoto não foi aplicado — revise a configuração do navegador.
Mesmo com SOCKS proxy ativo, o WebRTC do navegador pode revelar seu IP local via STUN requests. No Firefox, desabilite em about:config setando media.peerconnection.enabled=false. No Chrome, instale a extensão “WebRTC Network Limiter” e configure pra rotear via proxy. Sites tipo browserleaks.com/webrtc mostram exatamente o que vaza.
Túnel persistente em background
Manter um terminal aberto pro túnel é frágil — qualquer fechamento acidental derruba a conexão. Pra uso recorrente, rode em background e configure reconexão automática.
A forma mais simples de jogar o túnel pra background é com a flag -f:
ssh -fND 1080 [email protected]O processo desconecta do terminal e fica rodando. Pra matá-lo depois, encontre o PID:
pgrep -f "ssh -fND 1080"
kill <PID>Limitação: se a conexão de rede cair (Wi-Fi desconecta, modem reinicia), o túnel morre e não volta sozinho.
Pra reconexão automática, instale o autossh:
sudo apt install autossh # Debian/Ubuntu
sudo dnf install autossh # Rocky/Alma
brew install autossh # macOSE rode:
autossh -M 0 -fND 1080 \
-o "ServerAliveInterval 30" \
-o "ServerAliveCountMax 3" \
[email protected]-M 0 desabilita o monitor port do autossh e delega a detecção de falha pros keepalives do próprio SSH. Os parâmetros ServerAliveInterval=30 e ServerAliveCountMax=3 derrubam a conexão se passarem 90 segundos sem resposta, disparando reconexão.
Pra deixar o túnel rodando como serviço de boot no Linux, crie uma unit systemd em ~/.config/systemd/user/ssh-socks.service:
[Unit]
Description=SSH SOCKS5 tunnel via [email protected]
After=network-online.target
[Service]
ExecStart=/usr/bin/autossh -M 0 -NTD 1080 -o ServerAliveInterval=30 -o ServerAliveCountMax=3 [email protected]
Restart=always
RestartSec=10
[Install]
WantedBy=default.targetAtive com:
systemctl --user daemon-reload
systemctl --user enable --now ssh-socksStatus fica visível em systemctl --user status ssh-socks. Pra funcionar sem prompt de senha, você precisa de autenticação por chave SSH e a chave precisa estar carregada no ssh-agent ou ter passphrase vazia (não recomendado em desktop compartilhado).
Resolução de problemas
”channel 1: open failed: connect failed: Connection refused”
A mensagem aparece no terminal do SSH quando o servidor remoto tenta abrir conexão pro destino solicitado pelo navegador e falha. Causa comum: o destino bloqueia tráfego do range de IPs do datacenter (Cloudflare WAF, fail2ban no destino), ou o servidor remoto não tem rota IPv6 e o navegador está tentando IPv6. Solução paliativa: force IPv4 no navegador ou no SSH com -4.
Conexão lenta após algum tempo
Túneis SSH são single-stream TCP e sofrem com TCP-over-TCP penalty quando há perda de pacote. Se a conexão fica boa por alguns minutos e degrada, troque pra uma porta com menos congestão (ssh -p 443 se o servidor estiver configurado) ou considere usar mosh pra shell e túnel SOCKS dedicado em sessão separada.
Túnel cai a cada 5 minutos
Provavelmente o sshd remoto está aplicando ClientAliveInterval e derrubando sessões idle. Adicione -o "ServerAliveInterval=60" no cliente — mensagens keepalive a cada 60 segundos mantêm o servidor convencido de que a conexão está viva.
Próximos passos
Com o SOCKS5 funcionando, dá pra evoluir o setup em algumas direções: configurar PAC file pra ativar o proxy só pra domínios específicos (e não roteamento total), usar sshuttle como alternativa que captura tráfego no nível de rede sem precisar configurar cada aplicação, ou montar tinyproxy no servidor remoto pra ter HTTP proxy mais leve quando você não precisa do SOCKS completo. Pra debug de produção, vale combinar o túnel com mitmproxy rodando localmente — você consegue inspecionar HTTPS saindo pela VPS sem violar TLS do destino.
Se você precisa de uma VPS dedicada exclusivamente pra esse tipo de uso (proxy estável, IP fixo, latência previsível), uma VPS Hostini na região mais próxima do destino reduz o overhead a poucos milissegundos e elimina os bloqueios típicos de IPs compartilhados.
Perguntas frequentes
Qual a diferença entre túnel SSH SOCKS proxy e VPN?
Um proxy SOCKS criado via SSH opera na camada de aplicação — só o tráfego de programas que você configurar explicitamente (navegador, curl, Slack) passa pelo túnel. VPN opera na camada de rede e captura todo o tráfego do sistema, incluindo DNS, jogos e clientes nativos. SSH SOCKS é mais leve, não exige cliente extra e usa só a porta 22 já aberta.
O SOCKS5 via SSH protege o DNS contra leak?
Só se você forçar a resolução DNS pelo proxy. Por padrão, o navegador pode resolver hostnames localmente antes de enviar pelo túnel — vazando seu DNS pro provedor. No Firefox, ative `network.proxy.socks_remote_dns=true` em about:config. No Chrome, use a flag `--proxy-server="socks5://..."` que já força resolução remota.
Posso usar SOCKS5 SSH pra acessar bancos de dados em rede privada?
Sim. Ferramentas como DBeaver, TablePlus e MySQL Workbench aceitam SOCKS5 proxy nas configurações de conexão. Você expõe a porta 1080 local, configura o cliente DB pra usar 127.0.0.1:1080 como SOCKS5 e conecta no host privado como se estivesse dentro do servidor. Alternativa mais direta pra DB específico: túnel local `ssh -L 3306:db-privado:3306`.
Quanto a latência aumenta com SSH SOCKS proxy?
Adiciona o round-trip cliente-servidor em cada request. Se sua VPS está em São Paulo (latência 10ms) e você acessa um site em Frankfurt (180ms direto), o tráfego via túnel vira 10 + 180 + 10 = 200ms aproximado. Pra navegação normal o impacto é imperceptível; pra streaming/gaming, escolha um servidor próximo do destino.
Como manter o túnel SSH SOCKS rodando após fechar o terminal?
Use a flag `-f` (background) combinada com `-N` (sem comando remoto): `ssh -fND 1080 usuario@ip`. Pra rodar como serviço persistente que reconecta sozinho após queda de rede, use `autossh -M 0 -fND 1080 usuario@ip` ou crie uma unit systemd com `Restart=always`.
É legal usar SSH SOCKS proxy pra contornar bloqueio geográfico?
Depende dos termos de uso do serviço acessado. Tecnicamente é tráfego cifrado legítimo via SSH, e nenhuma jurisdição proíbe o protocolo. Mas plataformas como Netflix, bancos e jogos online frequentemente vetam acesso via IP de datacenter — você pode receber bloqueio de conta ou captcha persistente. Para debug profissional (validar CDN, testar geo-targeting) é uso padrão na indústria.