Mucha automatización se ejecuta en un VPS en otro país: es más barato, la oferta es mayor y la latencia hacia las APIs globales es buena. El problema aparece cuando el destino es local: sitios que solo responden a accesos desde España o desde México, precios y contenidos distintos por país, paneles que desconfían de un login que llega desde un datacenter en Alemania o en Estados Unidos.
Un proxy con IP del país que necesitas le da al VPS una salida en ese país sin cambiar de servidor. Esta página muestra cuándo compensa, cómo configurarlo y cuándo la mejor respuesta es otra.
Cuándo compensa el proxy y cuándo no
| Situación | Mejor camino |
|---|---|
| El servidor funciona bien donde está y solo parte del tráfico tiene que salir desde otro país | Proxy en las aplicaciones que acceden a esos destinos |
| Varias cuentas o instancias en el mismo VPS necesitan IP distintas | Proxy, una IP por cuenta o instancia |
| Todo el tráfico tiene que salir desde ese país y la latencia importa | Un VPS en ese país puede ser más sencillo |
| Recolección en volumen repartida entre muchas direcciones | Varias IP o lotes, no un VPS con una sola IP fija |
Siendo directos: si toda tu aplicación tiene que estar en un país, contratar el VPS en una región de ese país puede resolverlo sin proxy. El proxy gana cuando quieres mantener el servidor donde está, separar IP por cuenta o tener un origen de proveedor residencial.
Qué producto usar
| Uso en el VPS | Producto | Por qué |
|---|---|---|
| Bots, integraciones y paneles con IP fija | IPv4 dedicado | Dirección fija en el país elegido, sin cobro por GB |
| WhatsApp API por número | Proxy para Evolution API y Baileys | Una IP por instancia, fuera de la IP compartida del VPS |
| Cuentas sensibles a datacenter | ISP residencial estático | IP de proveedor de internet, en los países donde está disponible |
| Integraciones con lista blanca de IP | IP fija para API | Una salida estable para registrar en el servicio |
| Recolección y scraping | IPv6 en lotes o residencial por GB (Brasil) | Muchas direcciones o IP que cambia |
El país de las IP se elige en el checkout; la disponibilidad de cada tipo depende del país.
Cómo configurarlo en el servidor
La autenticación es por usuario y contraseña, así que el VPS no necesita tener su IP autorizada: la misma credencial funciona desde cualquier servidor.
Por aplicación (recomendado)
Configura el proxy solo en lo que tiene que salir por él. Es la forma más predecible, porque el resto del servidor (actualizaciones, SSH, APIs globales) sigue por la ruta normal.
``bash``
curl -x http://usuario:contraseñ[email protected]:8000 https://api.ipify.org
Guías por herramienta: Python, n8n, Evolution API, Playwright, Puppeteer y Scrapy.
Por variable de entorno
Muchas bibliotecas y herramientas de línea de comandos leen estas variables:
``bash``
export HTTP_PROXY="http://usuario:contraseñ[email protected]:8000"
export HTTPS_PROXY="http://usuario:contraseñ[email protected]:8000"
export NO_PROXY="localhost,127.0.0.1"
Defínelas en el servicio concreto (en el archivo de systemd, en el docker-compose o en el .env de la aplicación) y no en todo el sistema, para no enviar por el proxy el tráfico que no lo necesita.
En contenedores
En Docker, pasa las mismas variables en el environment del servicio. Cada contenedor puede usar un proxy distinto, lo que resuelve el caso de varias instancias con IP separadas en el mismo VPS.
Comprueba la salida
Después de configurarlo, compruébalo desde dentro de la aplicación o del contenedor:
``bash``
curl -s -x http://usuario:contraseñ[email protected]:8000 https://ipwho.is/ | head -c 400
El país debe ser el que elegiste y la IP, la del proxy. Si da error, mira error 407 y el proxy no conecta.
Lo que el proxy no resuelve
- No reduce la latencia. El tráfico da un rodeo hasta el país del proxy; para aplicaciones sensibles al tiempo de respuesta, un VPS en ese país es mejor.
- No sustituye al cortafuegos ni a la seguridad del servidor. SSH, puertos y actualizaciones siguen siendo tu responsabilidad.
- No autoriza usos prohibidos. Los envíos masivos no solicitados, los ataques y el acceso no autorizado están fuera de nuestra política de uso aceptable.