Túnel SSH SOCKS proxy: cómo navegar mediante servidor remoto desde la terminal
Aprende a crear un túnel SSH SOCKS proxy para navegar mediante un servidor remoto: comando, configuración del navegador, autostart y solución de DNS leak.
Un túnel SSH SOCKS proxy convierte cualquier servidor con SSH en una puerta de salida para todo el tráfico HTTP/HTTPS de tu navegador. Abres una conexión SSH con la opción -D apuntando a un puerto local, y el cliente OpenSSH empieza a escuchar en ese puerto como si fuera un proxy SOCKS5 nativo: cualquier programa configurado para usar 127.0.0.1:1080 envía los paquetes por el túnel cifrado y sale a internet con la IP del servidor remoto.
El caso de uso más común es el debug de aplicaciones region-locked: necesitas validar cómo se renderiza tu sitio para un usuario en otro país, comprobar si la CDN está sirviendo el caché regional correcto, o simular la experiencia de un cliente que está detrás de una ruta diferente. Otras situaciones típicas: acceder a paneles administrativos restringidos por IP allowlist (autorizas solo la IP de la VPS), conectar con recursos de red privada sin exponer puertos adicionales, o simplemente navegar bajo una conexión que consideras más confiable que el Wi-Fi público.
Este tutorial muestra el setup completo en ~15 minutos: crear el túnel, configurar el navegador (Firefox y Chrome), validar con verificación de IP, evitar filtración de DNS y dejar el túnel persistente con autossh y systemd.
Prerequisitos
Necesitas acceso SSH funcional a un servidor Linux: una VPS común, sin configuración especial. El servidor OpenSSH viene preinstalado en cualquier distribución estándar (Ubuntu, Debian, Rocky, AlmaLinux) y acepta port forwarding por defecto. No es necesario privilegio root en el servidor remoto; basta con un usuario común con shell login.
Cliente OpenSSH en tu escritorio (Linux/macOS nativos; Windows 10/11 mediante PowerShell o WSL2), servidor remoto con SSH activo y acceso por clave o contraseña, y puerto 22 accesible. El servidor no necesita ninguna configuración extra: el port forwarding ya viene habilitado en el sshd_config por defecto.
Datos típicos para montar el túnel:
203.0.113.42 deploy 22 1080 Creando el túnel SOCKS5
La opción -D de ssh es la abreviatura de “dynamic port forwarding” y activa el modo SOCKS en el cliente. A diferencia de -L (forward de un puerto específico) o -R (forward inverso), -D crea un proxy completo que acepta conexiones a cualquier host:puerto de destino.
Abre una terminal local y ejecuta el comando del túnel:
ssh -D 1080 -N -C [email protected]-D 1080— abre el puerto SOCKS5 en127.0.0.1:1080-N— no ejecuta comando remoto (solo mantiene el túnel)-C— habilita compresión (útil en enlaces lentos, irrelevante en fibra)
La terminal parecerá colgada después de la autenticación: es normal. El proceso está activo manteniendo el túnel. No cierres esa ventana mientras estés usando el proxy.
En otra terminal, confirma que el puerto está escuchando localmente:
ss -tlnp | grep 1080La salida esperada es una línea del tipo LISTEN 0 128 127.0.0.1:1080 ... indicando que el cliente SSH está vinculado al puerto. Si no aparece nada, el túnel no se ha levantado: vuelve a la terminal anterior y comprueba si hay algún mensaje de error.
Por defecto el túnel escucha solo en 127.0.0.1, lo que es correcto para uso personal. Si quieres compartir el proxy con otra máquina de tu LAN, usa -D 0.0.0.0:1080, pero habilita el firewall local para no exponer el proxy a internet entera.
Configurando el navegador
El túnel está funcionando, ahora necesitas apuntar el navegador hacia él. Firefox y Chrome tienen caminos diferentes: Firefox tiene proxy propio independiente del sistema, Chrome usa el proxy del sistema operativo a menos que lo fuerces mediante opción.
Firefox
Abre about:preferences en Firefox, desplázate hasta “Network Settings” y haz clic en “Settings…”. Selecciona “Manual proxy configuration” y completa:
- SOCKS Host:
127.0.0.1Port:1080 - Marca “SOCKS v5”
- Marca “Proxy DNS when using SOCKS v5” — fundamental para evitar leak
Guarda y cierra. Firefox empieza a enrutar todo el tráfico por el túnel inmediatamente.
Confirma en about:config que network.proxy.socks_remote_dns está como true. Esa preferencia garantiza que las consultas DNS también pasen por el túnel: sin ella, Firefox resuelve hostnames usando el resolver local antes de enviar la petición por el proxy, filtrando tu actividad al proveedor.
Chrome / Chromium
Chrome ignora la configuración de proxy a nivel de pestaña: usa la configuración del sistema. Para forzar SOCKS5 sin cambiar el sistema entero, abre el navegador con una opción:
Cierra todas las ventanas de Chrome y ejecuta desde la línea de comandos:
google-chrome \
--proxy-server="socks5://127.0.0.1:1080" \
--host-resolver-rules="MAP * ~NOTFOUND , EXCLUDE 127.0.0.1"La segunda opción fuerza la resolución DNS mediante SOCKS (equivalente al socks_remote_dns de Firefox). Sin ella, Chrome hace lookup local antes de tunelar.
Verificación
La forma más simple de confirmar que el tráfico está saliendo por la VPS es comprobar la IP pública vista por el navegador.
En el navegador configurado, abre https://ifconfig.me o https://ipinfo.io. La IP devuelta debe ser la IP pública de tu VPS, no la IP de tu conexión doméstica.
Para comparar lado a lado: abre https://ipinfo.io en un navegador SIN proxy y copia el resultado. Después abre la misma URL en el navegador con el túnel activo. Las dos IPs deben ser diferentes, y la segunda debe coincidir con la IP del comando curl ifconfig.me ejecutado directamente en la VPS.
Prueba el leak de DNS visitando https://dnsleaktest.com y ejecutando el test extendido. Los resolvers devueltos deben ser los del proveedor de la VPS (generalmente Cloudflare 1.1.1.1, Google 8.8.8.8 o los DNS del datacenter), no los de tu ISP local. Si aparecen servidores de tu proveedor doméstico, el paso de DNS remoto no se ha aplicado: revisa la configuración del navegador.
Incluso con el SOCKS proxy activo, el WebRTC del navegador puede revelar tu IP local mediante peticiones STUN. En Firefox, deshabilítalo en about:config configurando media.peerconnection.enabled=false. En Chrome, instala la extensión “WebRTC Network Limiter” y configúrala para enrutar mediante proxy. Sitios como browserleaks.com/webrtc muestran exactamente qué se filtra.
Túnel persistente en background
Mantener una terminal abierta para el túnel es frágil: cualquier cierre accidental tira la conexión. Para uso recurrente, ejecuta en background y configura la reconexión automática.
La forma más simple de enviar el túnel al background es con la opción -f:
ssh -fND 1080 [email protected]El proceso se desconecta de la terminal y queda ejecutándose. Para terminarlo después, encuentra el PID:
pgrep -f "ssh -fND 1080"
kill <PID>Limitación: si la conexión de red cae (Wi-Fi se desconecta, el módem se reinicia), el túnel muere y no vuelve solo.
Para reconexión automática, instala autossh:
sudo apt install autossh # Debian/Ubuntu
sudo dnf install autossh # Rocky/Alma
brew install autossh # macOSY ejecuta:
autossh -M 0 -fND 1080 \
-o "ServerAliveInterval 30" \
-o "ServerAliveCountMax 3" \
[email protected]-M 0 deshabilita el monitor port de autossh y delega la detección de fallo a los keepalives del propio SSH. Los parámetros ServerAliveInterval=30 y ServerAliveCountMax=3 tiran la conexión si pasan 90 segundos sin respuesta, disparando la reconexión.
Para dejar el túnel ejecutándose como servicio de boot en Linux, crea una unidad systemd en ~/.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.targetActívala con:
systemctl --user daemon-reload
systemctl --user enable --now ssh-socksEl estado queda visible en systemctl --user status ssh-socks. Para que funcione sin prompt de contraseña, necesitas autenticación por clave SSH y la clave debe estar cargada en el ssh-agent o tener passphrase vacía (no recomendado en escritorio compartido).
Solución de problemas
”channel 1: open failed: connect failed: Connection refused”
El mensaje aparece en la terminal del SSH cuando el servidor remoto intenta abrir conexión al destino solicitado por el navegador y falla. Causa común: el destino bloquea tráfico del rango de IPs del datacenter (Cloudflare WAF, fail2ban en el destino), o el servidor remoto no tiene ruta IPv6 y el navegador está intentando IPv6. Solución paliativa: fuerza IPv4 en el navegador o en SSH con -4.
Conexión lenta después de un tiempo
Los túneles SSH son single-stream TCP y sufren con la penalización TCP-over-TCP cuando hay pérdida de paquetes. Si la conexión va bien durante unos minutos y se degrada, cambia a un puerto con menos congestión (ssh -p 443 si el servidor está configurado así) o considera usar mosh para shell y un túnel SOCKS dedicado en sesión separada.
El túnel cae cada 5 minutos
Probablemente el sshd remoto está aplicando ClientAliveInterval y tirando sesiones idle. Añade -o "ServerAliveInterval=60" en el cliente: los mensajes keepalive cada 60 segundos mantienen al servidor convencido de que la conexión está viva.
Próximos pasos
Con SOCKS5 funcionando, puedes evolucionar el setup en varias direcciones: configurar un PAC file para activar el proxy solo en dominios específicos (y no enrutamiento total), usar sshuttle como alternativa que captura tráfico a nivel de red sin necesidad de configurar cada aplicación, o montar tinyproxy en el servidor remoto para tener un HTTP proxy más ligero cuando no necesitas el SOCKS completo. Para debug de producción, vale la pena combinar el túnel con mitmproxy ejecutándose localmente: puedes inspeccionar HTTPS saliendo por la VPS sin violar el TLS del destino.
Si necesitas una VPS dedicada exclusivamente para este tipo de uso (proxy estable, IP fija, latencia predecible), una VPS Hostini en la región más cercana al destino reduce el overhead a pocos milisegundos y elimina los bloqueos típicos de las IPs compartidas.
Preguntas frecuentes
¿Cuál es la diferencia entre túnel SSH SOCKS proxy y VPN?
Un proxy SOCKS creado mediante SSH opera en la capa de aplicación: solo el tráfico de los programas que configures explícitamente (navegador, curl, Slack) pasa por el túnel. La VPN opera en la capa de red y captura todo el tráfico del sistema, incluyendo DNS, juegos y clientes nativos. SSH SOCKS es más ligero, no requiere cliente adicional y usa solo el puerto 22 que ya está abierto.
¿SOCKS5 mediante SSH protege el DNS contra leak?
Solo si fuerzas la resolución DNS por el proxy. Por defecto, el navegador puede resolver hostnames localmente antes de enviar la petición por el túnel, filtrando tu DNS al proveedor. En Firefox, activa `network.proxy.socks_remote_dns=true` en about:config. En Chrome, usa la opción `--proxy-server="socks5://..."` que ya fuerza resolución remota.
¿Puedo usar SOCKS5 SSH para acceder a bases de datos en red privada?
Sí. Herramientas como DBeaver, TablePlus y MySQL Workbench aceptan SOCKS5 proxy en la configuración de conexión. Expones el puerto 1080 local, configuras el cliente DB para usar 127.0.0.1:1080 como SOCKS5 y conectas al host privado como si estuvieras dentro del servidor. Alternativa más directa para una BD específica: túnel local `ssh -L 3306:db-privada:3306`.
¿Cuánto aumenta la latencia con SSH SOCKS proxy?
Añade el round-trip cliente-servidor en cada petición. Si tu VPS está en São Paulo (latencia 10ms) y accedes a un sitio en Fráncfort (180ms directo), el tráfico por el túnel será aproximadamente 10 + 180 + 10 = 200ms. Para navegación normal el impacto es imperceptible; para streaming/gaming, elige un servidor cercano al destino.
¿Cómo mantengo el túnel SSH SOCKS funcionando después de cerrar la terminal?
Usa la opción `-f` (background) combinada con `-N` (sin comando remoto): `ssh -fND 1080 usuario@ip`. Para ejecutar como servicio persistente que reconecta solo tras una caída de red, usa `autossh -M 0 -fND 1080 usuario@ip` o crea una unidad systemd con `Restart=always`.
¿Es legal usar SSH SOCKS proxy para sortear bloqueo geográfico?
Depende de los términos de uso del servicio accedido. Técnicamente es tráfico cifrado legítimo mediante SSH, y ninguna jurisdicción prohíbe el protocolo. Pero plataformas como Netflix, bancos y juegos online frecuentemente vetan el acceso desde IPs de datacenter: puedes recibir bloqueo de cuenta o captcha persistente. Para debug profesional (validar CDN, probar geo-targeting) es uso estándar en la industria.