Configurar proxies en VS Code: guía segura paso a paso

Configurar proxies en VS Code es de esas tareas que, tarde o temprano, le toca a casi todo el mundo: quizá trabajas detrás del firewall corporativo, quizá haces scraping y testing SEO desde IPs españolas, o quizá quieres que tus agentes IA consulten recursos externos sin exponer tu conexión. En esta primera parte de la guía veremos por qué merece la pena enrutar el editor por un proxy, cómo hacerlo desde el settings.json con proxies HTTP/s, qué variables de entorno usar en terminales remotas por SSH o WSL, y cómo dar un paso más con proxies SOCKSv5 mediante túneles SSH. Los ejemplos funcionan igual con proxies dedicados como los de ProxySEO, que ofrecen IPs españolas, anonimato y tráfico ilimitado.

Por qué usar un proxy al desarrollar en VS Code

VS Code no es solo un editor. Constantemente hace peticiones de red: descarga extensiones del Marketplace, sincroniza ajustes, consulta las APIs de GitHub Copilot, ejecuta extensiones que llaman a servicios web… Tráfico que muchas veces ni ves. Si estás en una red corporativa o desarrollas herramientas de SEO y scraping, enrutarlo por un proxy te da tres ventajas claras:

• Acceso controlado a la red: superas firewalls y filtros salientes sin desactivar la seguridad del sistema. Algo habitual, por cierto, en entornos empresariales.
• Testing geolocalizado: si desarrollas o verificas herramientas SEO, comprobar resultados desde una IP española real te ahorra falsos positivos por geo-bloqueos o por esas SERPs personalizadas de datacenter.
• Anonimato y no quemar tu IP: al probar scrapers, crawlers o agentes IA desde el editor, un proxy dedicado absorbe los rate-limits y baneos. Tu IP de oficina queda al margen.

Hay un matiz importante: dedicado, no compartido. Con un proxy dedicado nadie más usa esa IP, y eso reduce drásticamente los captchas y bloqueos en sesiones largas de desarrollo. Lo he comprobado más de una vez.

Configurar proxies en VS Code: settings.json y proxy HTTP/s

VS Code soporta proxies HTTP/s de forma nativa. Abre la paleta de comandos (Ctrl+Shift+P), escribe «Open User Settings (JSON)» y añade:

1. http.proxy: la URL de tu proxy, por ejemplo http://usuario:contraseña@proxy.proxyseo.es:8080.
2. http.proxyStrictSSL: déjalo en true si tu proxy usa certificados válidos; ponlo en false solo en redes corporativas con SSL interceptado.
3. http.proxySupport: usa «on» para que todas las extensiones respeten el proxy, no solo el núcleo del editor.

Y reinicia VS Code tras el cambio. Parece obvio, pero algunas extensiones cachean la configuración de red hasta el siguiente arranque y te volverás loco buscando el problema.

Variables de entorno de proxy para terminales remotas (SSH y WSL)

¿La configuración del editor llega a la terminal integrada? Cuando la terminal es remota, no. En sesiones SSH o WSL, la terminal ejecuta comandos (curl, git, npm, pip) con su propio entorno, así que toca definir las variables estándar a mano:

• HTTP_PROXY y HTTPS_PROXY: export HTTPS_PROXY=http://usuario:contraseña@proxy.proxyseo.es:8080
• NO_PROXY: lista de hosts excluidos, útil para localhost y servicios internos: export NO_PROXY=localhost,127.0.0.1,.empresa.int
• Persistencia: añade las líneas a ~/.bashrc o ~/.zshrc; en WSL funciona igual que en cualquier Linux.

Git merece mención aparte, porque no siempre lee estas variables. Para asegurar que clones y pushes pasen por el proxy, configúralo directamente: git config –global http.proxy http://usuario:contraseña@proxy.proxyseo.es:8080.

Proxies SOCKSv5 con túneles SSH: configuración avanzada

A veces el tráfico HTTP se queda corto. Cuando necesitas enrutar TCP completo, el protocolo SOCKSv5 es la opción más flexible que tienes sobre la mesa. VS Code acepta proxies SOCKS en http.proxy (socks5://usuario:contraseña@proxy.proxyseo.es:1080), y los proxies SOCKSv5 dedicados de ProxySEO funcionan bien en este escenario.

Hay un patrón que me parece especialmente útil: combinar SOCKSv5 con un túnel SSH dinámico para saltos intermedios. ssh -D 1080 -N usuario@servidor-intermedio crea un proxy SOCKS local, que luego declaras en VS Code como socks5://127.0.0.1:1080. Así encadenas la seguridad del túnel con la IP final española del proxy. Ideal, por ejemplo, para depurar agentes IA que hacen llamadas a APIs con restricciones geográficas. Antes de lanzar cargas de trabajo reales, verifica la conectividad: curl –socks5 usuario:contraseña@proxy.proxyseo.es:1080 https://api.ipify.org. Comprueba que la IP devuelta es la esperada. Tarda segundos y te ahorra horas.

Integrar proxies con agentes IA y soporte MCP en tu flujo de desarrollo

¿Trabajas con agentes IA? Claude, GPT, asistentes locales con LangChain o frameworks parecidos. Pues atención, porque configurar el proxy en VS Code solo resuelve la mitad del problema: el agente ejecuta sus propias llamadas de red desde procesos independientes del editor. Ahí entra el soporte MCP (Model Context Protocol), que permite que tus servidores MCP respeten el mismo túnel de proxy sin acabar con configuraciones dispares por todas partes.

Variables de entorno para procesos de agente

Lo más robusto para propagar el proxy a los agentes es definir las variables estándar en tu shell o en el archivo settings.json de VS Code, dentro de terminal.integrated.env.linux (o su equivalente según tu sistema):

• HTTP_PROXY: http://usuario:contraseña@proxy.proxyseo.es:8080
• HTTPS_PROXY: la misma URL para tráfico TLS
• NO_PROXY: localhost,127.0.0.1, para no enrutar tráfico local

Con esto, cualquier agente lanzado desde la terminal integrada hereda automáticamente la IP española dedicada. En el caso de servidores MCP, añade las variables en la configuración del servidor dentro de .vscode/mcp.json usando el campo env. Así las herramientas que invoque el agente saldrán por el mismo proxy.

Errores comunes y mejores prácticas de seguridad

Siguiendo la guía al pie de la letra igual te vas a topar con fallos recurrentes. Conviene anticiparlos:

1. Credenciales en texto plano en el repositorio: nunca subas settings.json con usuario y contraseña a Git. Usa .gitignore o variables de entorno del sistema.
2. Confundir proxy HTTP con SOCKSv5: si el servidor es SOCKSv5 y pones el prefijo http://, tendrás errores de handshake. Verifica qué protocolo has contratado.
3. Olvidar NO_PROXY: enrutar localhost por el proxy rompe servidores de desarrollo locales y depuradores. Más de un depurador ha dejado de responder por esto.
4. SSL inspeccionado sin CA configurada: si tu proxy hace MITM_TLS, añade el certificado con http.systemCertificates activado o apuntando al archivo PEM correspondiente.
5. Proxy caído sin fallback: monitoriza la disponibilidad antes de ejecutar pipelines de CI/CD que dependan de la IP española.

Sobre seguridad, algo evidente pero que merece decirse: un proxy dedicado y anónimo como los de ProxySEO evita el riesgo principal de los proxies gratuitos, que es la intercepción de tráfico y la inyección de contenido. Aun así, mantén siempre TLS de extremo a extremo y rota credenciales periódicamente, sobre todo si varios miembros del equipo comparten acceso al proxy.

Conclusión: desarrolla de forma segura con proxies dedicados españoles

Configurar bien los proxies en VS Code convierte tu entorno de desarrollo en un punto de salida controlado, seguro y con identidad IP española verificable. Desde el ajuste de http.proxy y las reglas de bypass, pasando por la depuración con la extensión Debugger for Chrome, hasta la integración de agentes IA mediante MCP y variables de entorno, cada capa del flujo puede —y debería— pasar por el mismo túnel.

La clave está en usar infraestructura seria. Los proxies HTTP/s y SOCKSv5 dedicados de ProxySEO ofrecen IPs españolas exclusivas, anonimato real y tráfico ilimitado, con respaldo técnico para entornos profesionales de SEO, scraping y desarrollo con IA. Evita proxies compartidos o gratuitos, documenta tu configuración y verifica siempre la IP de salida antes de operar. Con estos hábitos, ni tu productividad ni tu seguridad dependerán de la suerte.