Proxies para testers de QA: cómo verificar aplicaciones web desde 20 países sin viajar

Has lanzado una nueva versión, y en una hora llega un informe de errores: "En Alemania se muestra una versión incorrecta de la página", "En EE.UU. no funciona el pago", "En Rusia el contenido está bloqueado". Reproducir esto desde la máquina local es imposible. Aquí es donde los proxies se convierten de "herramienta de arbitraje" en una herramienta de trabajo completa para el ingeniero de QA.

En este artículo, analizaremos cómo utilizar correctamente los proxies para probar el comportamiento geodependiente de las aplicaciones, qué tipos de proxies son adecuados para diferentes tareas de QA, y mostraremos escenarios paso a paso: desde la verificación de geocontenido hasta la prueba de pasarelas de pago.

¿Por qué necesita un tester de QA proxies: escenarios reales?

Muchos equipos todavía prueban el comportamiento "internacional" de la aplicación solo desde máquinas locales, conectándose ocasionalmente a una VPN. Esto crea una enorme zona ciega. La VPN cambia la dirección IP, pero no simula la red real del usuario de un país específico: proveedor, tipo de conexión, operador móvil. Los proxies, en cambio, permiten acceder a Internet a través de una dirección IP real de la región o tipo de red deseada.

Aquí hay tareas concretas con las que los testers de QA se enfrentan todos los días:

• Geocontenido y localización. La aplicación muestra contenido diferente según el país del usuario: precios en la moneda local, promociones regionales, secciones bloqueadas. Sin proxies, esto es imposible de verificar.
• Sistemas de pago regionales. Stripe funciona de manera diferente en la UE y EE.UU. PayPal en Brasil es un caso aparte. Es necesario probar el flujo de pago desde el país correspondiente.
• CDN y caché. La red de entrega de contenido puede ofrecer diferentes versiones de recursos desde diferentes puntos. QA debe asegurarse de que la estática se carga correctamente para los usuarios en Asia, Europa y América.
• Bloqueos y restricciones. En algunos países, ciertas funciones de la aplicación no están disponibles por ley. Es necesario asegurarse de que el bloqueo funcione correctamente y que el usuario vea un mensaje claro.
• Pruebas A/B por geolocalización. Si el experimento se lanza solo para usuarios del Reino Unido, QA debe acceder con una IP británica y asegurarse de que ve el variante correcta.
• Pruebas SEO. Metatags, hreflang, versiones regionales de páginas: todo esto debe verificarse con una IP del país correspondiente, de lo contrario, el motor de búsqueda y el usuario real verán cosas diferentes.
• Pruebas de velocidad desde diferentes regiones. El tiempo de carga de la página desde Singapur y desde Moscú puede diferir entre 3 y 5 veces. Los proxies permiten reproducir esto desde un solo lugar de trabajo.

Qué tipos de proxies son adecuados para pruebas

No todos los proxies son igualmente útiles para QA. La elección del tipo depende de lo que estés probando. Analicemos tres tipos principales y su aplicabilidad para las tareas del tester.

Proxies residenciales

Son direcciones IP de usuarios domésticos reales de países y ciudades específicas. El sitio los ve como personas normales, no como un centro de datos o una red corporativa. Los proxies residenciales son la opción óptima para la mayoría de las tareas de QA: pruebas de geocontenido, pruebas A/B, flujos de pago y verificación de localización. Imitan con gran precisión a un usuario real del país deseado.

Ventajas para QA: alta confianza por parte de sitios y aplicaciones, amplia cobertura geográfica (más de 100 países), posibilidad de elegir una ciudad o proveedor específico. Desventaja: son un poco más lentos que los proxies de centros de datos, lo que debe tenerse en cuenta al probar el rendimiento.

Proxies móviles

Direcciones IP de operadores móviles (3G/4G/5G). Son críticos cuando pruebas el comportamiento de la aplicación para usuarios móviles. Muchos sitios y aplicaciones se comportan de manera diferente al acceder con una IP móvil: muestran la versión móvil, contenido diferente, o manejan la geolocalización de otra manera. Los proxies móviles son indispensables al probar aplicaciones móviles a través de emuladores o al verificar la adaptabilidad de la versión web.

Además, las IP móviles son direcciones dinámicas que un operador distribuye a miles de suscriptores. Esto significa que tu tráfico de prueba no parece sospechoso incluso con solicitudes intensivas.

Proxies de centros de datos

Son los más rápidos y baratos. Son adecuados para pruebas de carga, pruebas automatizadas con un gran número de solicitudes, verificación de puntos finales de API. Los proxies de centros de datos son fácilmente detectables como "no residenciales", por lo que son menos adecuados para probar la experiencia del usuario, pero son la opción óptima para verificaciones técnicas y carga.

Pruebas de contenido geodependiente: paso a paso

La prueba geodependiente es el escenario más común para el uso de proxies en QA. Así es como se hace en la práctica, sin escribir código, a través de un navegador común.

Paso 1. Obtén los datos del proxy

Después de conectarte al servicio, obtienes los datos de conexión: host (IP o dominio), puerto, nombre de usuario y contraseña. Para proxies residenciales, generalmente puedes elegir el país y la ciudad directamente en el panel de usuario o a través de los parámetros en la cadena de conexión.

Un ejemplo de cadena de conexión para un proxy residencial con selección de país se ve así: el host contiene el parámetro del país (por ejemplo, country-de para Alemania), el puerto es estándar, el nombre de usuario y la contraseña son tus credenciales.

Paso 2. Configura el proxy en el navegador

Para pruebas manuales, lo más conveniente es usar extensiones para el navegador que permiten cambiar rápidamente el proxy sin modificar la configuración del sistema. Opciones populares: Proxy SwitchyOmega (Chrome/Firefox), FoxyProxy (Firefox).

Configuración paso a paso a través de Proxy SwitchyOmega:

1. Instala la extensión desde Chrome Web Store.
2. Abre la configuración de la extensión → haz clic en "Nuevo perfil" → selecciona "Perfil de proxy".
3. Ingresa los datos del proxy: Protocolo (SOCKS5 o HTTP), Servidor (host), Puerto (puerto).
4. Si se requiere autenticación, ingresa el nombre de usuario y la contraseña en los campos correspondientes.
5. Guarda el perfil y actívalo a través del ícono de la extensión en la barra del navegador.
6. Ve al sitio whatismyip.com o 2ip.ru — asegúrate de que se muestra la IP del país deseado.

Paso 3. Verifica los elementos geodependientes

Después de conectar el proxy con la geolocalización deseada, verifica:

• Idioma de la interfaz (determinación automática por IP)
• Moneda de precios y métodos de pago
• Disponibilidad/no disponibilidad de ciertas secciones del sitio
• Banners y promociones para la región específica
• Corrección de los tags hreflang (abre el código fuente de la página)
• Redirecciones a subdominios regionales (por ejemplo, de.site.com en lugar de site.com)
• Banners de cookies (en la UE son obligatorios según GDPR)

Pruebas desde diferentes tipos de redes

Además de la geografía, es importante probar el comportamiento de la aplicación según el tipo de red del usuario. Esto es especialmente crítico para productos con una audiencia global, donde una parte significativa de los usuarios accede desde dispositivos móviles a través de redes de operadores.

Redes corporativas y firewalls

Los usuarios de redes corporativas a menudo trabajan a través de servidores proxy de la empresa y firewalls que bloquean ciertos tipos de solicitudes, conexiones WebSocket o CDN externos. Para simular tales condiciones, los testers utilizan proxies de centros de datos con configuraciones limitadas, lo que permite reproducir un entorno corporativo "estricto".

Qué verificar en este escenario: si funcionan las notificaciones push, si se cargan las fuentes de Google Fonts (a menudo bloqueadas por firewalls corporativos), si la autorización a través de OAuth funciona correctamente.

Redes móviles (3G/4G/5G)

A través de proxies móviles, el tester no solo obtiene una IP móvil, sino también las condiciones reales de la red móvil: diferentes latencias, características de NAT, encabezados específicos de solicitudes de los operadores móviles. Algunas aplicaciones manejan las solicitudes de manera diferente desde IP móviles, por ejemplo, ofrecen descargar la aplicación en lugar de mostrar la versión web.

Combina proxies móviles con un emulador de dispositivos en Chrome DevTools (modo Device Toolbar) para obtener un entorno lo más cercano posible al del usuario real.

Proveedores con acceso limitado

En algunos países, los proveedores de Internet bloquean ciertos recursos o ralentizan el tráfico hacia competidores. Si tu producto opera en mercados con Internet restringido (China, Irán, Rusia), las pruebas a través de proxies residenciales de esos países mostrarán la verdadera disponibilidad del servicio.

Pruebas de pasarelas de pago y funciones regionales

La prueba de pagos es una de las áreas más problemáticas para QA en productos internacionales. Los sistemas de pago utilizan activamente la geolocalización para verificar fraudes: si la IP del usuario no coincide con su dirección de pago o el país de la tarjeta, la transacción puede ser rechazada o marcada como sospechosa.

El tester de QA debe reproducir exactamente ese escenario: acceder con una IP del país donde se emitió la tarjeta de prueba y pasar por todo el flujo de pago. Sin proxies, esto es imposible de hacer desde una sola máquina para varias regiones.

Qué verificar a través de proxies en las pruebas de pago

• Visualización de los métodos de pago disponibles (PayPal, Stripe, Klarna, SEPA, PIX — cada región tiene los suyos)
• Corrección de la conversión de moneda y visualización de comisiones
• Funcionamiento de la verificación 3DS desde diferentes países
• Comportamiento al no coincidir la IP y el país de la tarjeta (debe haber un mensaje de error claro)
• Impuestos regionales (IVA en la UE, GST en Australia) — ¿se calculan correctamente?
• Funcionamiento de métodos de pago regionales: iDEAL en los Países Bajos, Sofort en Alemania, Boleto en Brasil

Pruebas de funciones regionales (GDPR, CCPA y otros)

Los requisitos legales para los productos varían según el país del usuario. Para QA, es importante asegurarse de que la aplicación determina correctamente la jurisdicción y aplica las reglas necesarias:

• UE (GDPR): al acceder desde una IP europea, debe aparecer un banner de cookies con la opción de rechazar el seguimiento
• California (CCPA): el enlace "No vender mi información personal" debe mostrarse para usuarios de California
• Rusia: si los datos de los usuarios rusos deben almacenarse en servidores en Rusia, verifica que la localización funcione correctamente
• China: si se bloquean servicios externos (Google Analytics, Facebook Pixel) al acceder desde una IP china, y si esto no rompe la página

Herramientas para QA con soporte de proxies

Los proxies se pueden utilizar no solo manualmente en el navegador, sino también integrarse en pruebas automatizadas y herramientas de QA. Analicemos las opciones principales.

Postman

Para probar APIs a través de proxies en Postman: ve a Configuración → Proxy → activa Usar proxy del sistema o especifica el proxy manualmente. Esto permite verificar cómo responden los puntos finales de la API a las solicitudes desde diferentes países, lo cual es relevante para APIs geodependientes que devuelven contenido diferente según la IP.

Charles Proxy / Fiddler

Estas herramientas interceptan tráfico HTTP/HTTPS y son proxies en sí mismas. Se pueden configurar para que pasen tráfico a través de un servidor proxy externo (upstream proxy). Esto permite interceptar y analizar solicitudes al mismo tiempo que se prueba con la IP geolocalizada deseada.

En Charles: Proxy → Configuración de Proxy Externo → activa Usar proxy externo y especifica los datos de tu servidor proxy.

Playwright y Selenium

Para pruebas automatizadas, el proxy se conecta a nivel de configuración del navegador. En Playwright, esto se hace a través del parámetro proxy al crear el contexto del navegador. En Selenium, se hace a través de las opciones de ChromeDriver especificando el servidor proxy. Esto permite ejecutar suites de prueba desde decenas de países en modo paralelo sin configuraciones manuales.

BrowserStack y Sauce Labs

Las plataformas en la nube para pruebas tienen herramientas integradas para probar desde diferentes regiones. Sin embargo, sus capacidades para elegir un proveedor específico o tipo de red (móvil/residencial) son limitadas. Los proxies ofrecen más flexibilidad: tú eliges el país, la ciudad, el tipo de IP y el proveedor.

k6 y JMeter (pruebas de carga)

Para pruebas de carga desde diferentes regiones, los proxies de centros de datos se conectan a través de la configuración del cliente HTTP. Esto permite simular la carga de usuarios reales de diferentes países y verificar cómo manejan el tráfico geográficamente distribuido los CDN y balanceadores de carga.

Lista de verificación: qué verificar a través de proxies antes del lanzamiento

Utiliza esta lista de verificación para cada lanzamiento que afecte a una audiencia internacional. Se recomienda verificar al menos 3-5 regiones clave de tu producto.

Errores comunes al probar a través de proxies

Incluso los testers experimentados cometen errores al trabajar con proxies. Analicemos los más comunes.

Error 1: No verificar que el proxy realmente funcione

Antes de comenzar las pruebas, siempre verifica la IP actual en un recurso independiente (whatismyip.com, 2ip.ru, ipleak.net). A veces, el proxy está configurado, pero el navegador sigue utilizando la conexión directa, especialmente si la extensión no está activada o hay un conflicto con la configuración del sistema.

Error 2: Ignorar filtraciones de DNS

Las solicitudes DNS pueden ir más allá del proxy, revelando la IP real del tester. Esto es especialmente importante al probar bloqueos geográficos: el sitio puede determinar el país real a través de DNS, incluso si la dirección IP ha sido cambiada. Verifica las filtraciones de DNS a través de ipleak.net o dnsleaktest.com.

Error 3: Usar un solo proxy para todas las tareas

Un proxy de centro de datos no es adecuado para probar la experiencia del usuario: el sitio puede mostrarle un captcha o una página bloqueada que un usuario real nunca vería. Usa el tipo de proxy correcto para cada tarea (ver tabla anterior).

Error 4: Olvidar la caché del navegador

Al cambiar entre geolocalizaciones, el navegador puede entregar contenido en caché de la sesión anterior. Siempre limpia la caché y las cookies antes de cambiar a un nuevo proxy, o usa el modo incógnito para cada nueva prueba geodependiente.

Error 5: No documentar las sesiones de prueba

Al encontrar un error a través de un proxy, asegúrate de registrar: el país y la ciudad del proxy, el tipo de proxy (residencial/móvil), la hora de la prueba, la versión del navegador. Sin estos datos, será difícil para el desarrollador reproducir el problema. Agrega una captura de pantalla con la confirmación de la IP en el informe de errores.

Error 6: Confundir proxies y VPN en la documentación

En los equipos, a menudo se escribe en los informes de errores "reproducido a través de VPN desde Alemania", pero VPN y proxies funcionan de manera diferente. La VPN cifra todo el tráfico y cambia la IP a nivel del sistema operativo, mientras que el proxy opera a nivel de aplicación. Para algunos errores, esta es una diferencia fundamental. Usa formulaciones precisas en la documentación.

Conclusión

Los proxies para el tester de QA no son una excentricidad, sino una herramienta básica para cualquier producto con una audiencia internacional. Permiten reproducir las condiciones reales de los usuarios de diferentes países, verificar contenido geodependiente, pasarelas de pago, requisitos legales y el comportamiento de los CDN, todo esto directamente desde el lugar de trabajo, sin viajes y máquinas remotas.

Conclusiones clave: para probar la experiencia del usuario, utiliza proxies residenciales; para escenarios móviles, usa proxies móviles; para pruebas de carga y API, son adecuados los proxies de centros de datos. Siempre verifica la IP antes de comenzar la prueba, presta atención a las filtraciones de DNS y documenta las sesiones de prueba con los parámetros geográficos.

Si deseas comenzar a probar el comportamiento geodependiente de tu aplicación, te recomendamos probar proxies residenciales — proporcionan la reproducción más precisa de un usuario real del país deseado y permiten una selección flexible de geolocalización hasta la ciudad y el proveedor.