Proxies para agentes de IA en 2026: configuración de Playwright MCP, uso de navegadores y navegadores en la nube

```html

El agente de IA que navega por los sitios web por sí mismo — Claude con Playwright MCP, browser-use, Browserbase en la nube — se enfrenta a la misma pared que un parser convencional: un par de docenas de solicitudes desde una dirección, y después, en lugar de una página, llega un desafío de Cloudflare. La diferencia es que el agente no se ofende y simplemente se queda atrapado, quemando tokens en intentos de "presionar un botón que no existe".

Esto se soluciona con proxies. Pero conectar un proxy al agente resulta ser inesperadamente poco obvio: la mitad de las instrucciones en internet ofrecen una sintaxis que Chromium ignora en silencio. A continuación, se presentan configuraciones funcionales para los tres stacks más comunes del año 2026 y un análisis de las trampas en las que todos tropiezan.

¿A quién le interesa?

Guía para aquellos que ya han lanzado un agente y han experimentado uno de los síntomas:

• el agente realiza de 10 a 20 pasos, y luego cada paso siguiente devuelve un captcha o una página "Verifica que eres humano";
• el agente no ve el mismo contenido que tú: los precios, los resultados y la disponibilidad del producto se muestran bajo tu IP de servidor, y no bajo el país deseado;
• el agente se ejecuta en la nube (VPS, GitHub Actions, contenedor), y la dirección del centro de datos del proveedor ya está marcada como bot;
• has configurado un proxy con nombre de usuario y contraseña, y el navegador se inicia como si no hubiera proxy en absoluto.

Si aún estás en la etapa de "¿por qué bloquean a los agentes en general?" — primero lee el análisis sobre cómo los sistemas anti-bot distinguen el navegador de un agente de un humano: allí se habla de las señales de detección, y aquí — pura práctica de conexión.

Trampa n.º 1: Chromium no acepta nombre de usuario y contraseña en la cadena del proxy

El error más común, y cuesta a las personas horas de depuración. La forma clásica de la cadena del proveedor es user:pass@host:port. La insertas en la bandera de inicio del navegador:

--proxy-server="http://user:[email protected]:8080"

Y nada funciona. Chromium no admite la transmisión de credenciales dentro de la bandera --proxy-server: aparece un error en la consola sobre un proxy no soportado, y el tráfico pasa de largo. Si eliminas las credenciales y dejas solo host:port, el navegador en modo normal mostrará una ventana del sistema pidiendo nombre de usuario y contraseña — y ahí se detiene todo, porque en modo headless no hay ventana y no hay nadie que haga clic en ella.

De esto se derivan tres caminos funcionales, y debes elegir con conciencia:

1. Autenticación por IP (whitelist). La opción más limpia para los agentes. Agregas la dirección de la máquina donde corre el agente a la lista blanca en el panel del proveedor — y luego te conectas sin nombre de usuario y contraseña, solo con la cadena host:port. La bandera --proxy-server comienza a funcionar como se esperaba, headless no pregunta nada más. ProxyCove admite ambos métodos — tanto nombre de usuario:contraseña como IP-whitelist, y de hecho, simultáneamente, así que puedes establecer una lista blanca para el agente y dejar la contraseña para tareas manuales.
2. Transmitir credenciales a nivel de API, no de bandera. Playwright, Puppeteer y browser-use pueden aceptar username y password como campos separados — este no es el mismo mecanismo que la bandera de línea de comandos, y funciona. Es útil cuando escribes el código del agente tú mismo.
3. Relay local. Configuras un proxy sin contraseña que reenvía solicitudes al upstream con contraseña, y le indicas al agente la dirección local. Opción para casos donde la lista blanca no está disponible: por ejemplo, la IP de la máquina cambia.

Playwright MCP: configuración que realmente funciona

Playwright MCP de Microsoft — hoy es el estándar de facto para agentes que necesitan un navegador real. El proxy se establece mediante argumentos del servidor directamente en la configuración del cliente MCP:

{"mcpServers":{"playwright":{"command":"npx","args":["@playwright/mcp@latest","--browser","chromium","--headless","--proxy-server","http://gate.example.com:8080","--proxy-bypass",".local,.internal","--isolated","--viewport-size","1920x1080"]}}}

Lo que es importante aquí por puntos:

• --proxy-server acepta tanto direcciones HTTP como SOCKS5 en la forma socks5://host:port. Sin credenciales — ver trampa anterior.
• --proxy-bypass — lista de dominios separados por comas que van directamente sin pasar por el proxy. No es una opción decorativa: si el agente tiene servicios internos o una API local, enviar tráfico a través de un canal residencial es tráfico adicional que cuesta por gigabyte.
• --isolated mantiene el perfil en memoria y no lo escribe en disco. Útil cuando cada tarea debe comenzar desde cero. La desventaja es que las cookies no sobreviven al reinicio, y cada sesión para el sitio parece un nuevo visitante.
• --user-data-dir — por el contrario, un perfil permanente. Para escenarios con autenticación, elige esto en lugar de la aislamiento, y asegúrate de fijar la IP (ver sección sobre sticky a continuación).
• --storage-state permite inyectar cookies y localStorage guardados en una sesión aislada — un compromiso entre las dos anteriores.
• --allowed-origins y --blocked-origins limitan a dónde puede ir el agente. Ahorro subestimado: un agente que se obsesiona con la analítica y dominios publicitarios puede triplicar fácilmente el consumo de tráfico.
• --device (por ejemplo, "iPhone 15") y --user-agent cambian cómo se presenta el agente como navegador. Configúralos de manera coherente con el tipo de proxy: un User-Agent móvil sobre una IP de centro de datos es una contradicción que el sistema anti-bot detecta de inmediato.

Separadamente sobre --cdp-endpoint: conecta MCP a un navegador ya en ejecución. Entonces, el proxy se configura no con banderas MCP, sino al iniciar ese navegador — razón típica por la cual "el proxy está configurado, pero la IP es la misma".

browser-use: proxy a través de ProxySettings

Si el agente está construido sobre browser-use, la configuración se envía en un objeto de configuración, y aquí se puede pasar el nombre de usuario y la contraseña — se envían a través de la API, no a través de la línea de comandos:

from browser_use import Browser, ProxySettings
proxy = ProxySettings(server='http://gate.example.com:8080', username='user', password='pass', bypass='localhost,127.0.0.1')
browser = Browser(proxy=proxy)

El campo server es obligatorio, los demás son opcionales. El mismo principio se aplica en Playwright puro: el proxy se establece globalmente al iniciar el navegador, o por separado para cada contexto a través de browser.newContext({ proxy: { server: ... } }). Lo segundo es clave para agentes paralelos: cada contexto recibe su propia dirección de salida, y diez tareas no comparten una sola IP.

Navegadores en la nube: proxy a nivel de sesión

En Browserbase y servicios similares, el navegador vive en la nube de otro, por lo que las banderas de inicio no están disponibles para ti — el proxy se configura en los parámetros de sesión, generalmente como una cadena del tipo http://nombre:contraseña@puerta:puerto en la variable de entorno del servidor MCP. La limitación de Chromium aquí no molesta: el proveedor de la nube analiza la cadena y configura el navegador desde adentro.

Un matiz práctico: los navegadores en la nube tienen su propio grupo de proxies, y todos los clientes comparten el mismo. Si la tarea es sensible a la reputación de la dirección — ingreso a la cuenta, trabajo con una plataforma donde ya has estado — tu propio canal es más predecible que el general.

Rotación o fijación: elige según el tipo de tarea

El error de un principiante es activar la rotación en cada solicitud y preguntarse por qué el agente se desconecta. Los escenarios de agentes tienen dos modos, y no son intercambiables:

• Rotación en cada solicitud (en ProxyCove es el puerto 824) — para exploración: pasar por cien tarjetas de producto, recopilar resultados, verificar precios en diferentes regiones. Cada solicitud sale desde una nueva dirección, es difícil vincularlas entre sí.
• Sesión fijada (puertos 10000+, intervalo de cambio de 1 a 120 minutos) — para todo lo que consiste en pasos: inicio de sesión, carrito, formulario de varias páginas, diálogo largo con la interfaz. Si la IP cambia en medio de la cadena, el sitio en el mejor de los casos pedirá reautenticarse, en el peor — marcará la sesión como sospechosa.

El agente casi siempre trabaja en el segundo modo: por definición, realiza una secuencia de pasos, no un solo disparo. Los detalles sobre la elección del intervalo y errores típicos se analizan en la guía sobre cuándo se necesitan sesiones sticky y cómo configurarlas.

Cinco trampas

1. SOCKS5 con autenticación en Chromium. La sintaxis socks5:// está disponible en Playwright, pero la combinación "SOCKS5 más nombre de usuario y contraseña" en los navegadores basados en Chromium históricamente ha sido problemática — la solicitud correspondiente en el rastreador de Playwright está abierta desde noviembre de 2021. Si hay opción, para agentes elige el canal HTTP(S), es más predecible.
2. Filtración de DNS y WebRTC. El tráfico pasa a través del proxy, pero los nombres se resuelven directamente o WebRTC entrega la dirección real — y toda la ocultación pierde sentido. Esto debe verificarse antes, no después de iniciar el agente: cómo cerrar WebRTC al trabajar a través de un proxy.
3. Desincronización de geolocalización y localización. IP en Alemania, zona horaria de la máquina en Moscú, idioma de la interfaz en inglés — un conjunto que por sí mismo parece automatización. En Playwright, la localización y la zona horaria se establecen mediante parámetros de contexto, asegúrate de que coincidan con el país del proxy.
4. Tráfico que no solicitaste. El agente abre la página en su totalidad, junto con imágenes, fuentes y scripts publicitarios. En un canal residencial con pago por gigabyte, esto es un gasto notable — bloquea dominios innecesarios y, donde sea posible, desactiva la carga de medios.
5. El proxy no está configurado donde se inicia el navegador. Al trabajar a través de --cdp-endpoint, mediante un contenedor Docker o a través de un servicio en la nube, las banderas MCP no afectan la conexión real. Lo primero que debes hacer después de la configuración es hacer que el agente abra cualquier servicio de verificación de IP y asegurarte de que la dirección y el país sean los correctos.

Qué tipo de proxy elegir para el agente

La regla es simple: cuanto más cerca esté la tarea de un usuario real, más "humano" debe ser la dirección.

• Proxies residenciales — la base para los agentes. Estas son direcciones de proveedores domésticos, y para el sitio, el agente parece un visitante normal. Necesarios en todas partes donde hay Cloudflare, precios regionales y cualquier indicio de anti-bot.
• Proxies móviles — artillería pesada para redes sociales y plataformas donde los cuentas son tratadas con especial nerviosismo. Detrás de una dirección móvil se encuentran miles de abonados reales, por lo que prohibirla completamente es costoso para la plataforma.
• Proxies de centro de datos — para APIs internas, bancos de pruebas y fuentes abiertas sin protección. Rápido y barato, pero en sitios protegidos el agente se encontrará con un desafío casi de inmediato.

Un detalle útil para los escenarios de agentes: cambiar el protocolo en ProxyCove se hace reemplazando el prefijo en la cadena de conexión — HTTP, HTTPS y SOCKS5 están disponibles en el mismo proxy, no es necesario reconfigurar el proxy. Hay más de 195 países en el grupo, así que "mostrar al agente resultados locales" se resuelve eligiendo el país al comprar.

Conclusión

Conectar un proxy a un agente de IA no es solo una línea, sino tres soluciones consecutivas: cómo autenticar (para un agente headless casi siempre es una lista blanca de IP, no una contraseña), dónde establecer el proxy (banderas MCP, objeto de configuración o parámetros de sesión en la nube — pero necesariamente donde realmente se inicia el navegador) y en qué modo trabajar (para escenarios de múltiples pasos — dirección fijada, no rotación en cada solicitud). Además, verificación obligatoria de fugas de DNS y WebRTC antes del lanzamiento operativo.

Hazlo bien una vez — y el agente dejará de gastar tokens en conversaciones con captcha. Los proxies residenciales de ProxyCove se conectan a Playwright MCP y browser-use en unos minutos, el pago es por tráfico, la lista blanca de IP para el modo headless se activa en el panel.