Configuración de Proxy para Uso en Navegadores: IPs de Salida por Sesión

Buscas un proxy para uso en navegadores y Google te muestra el diálogo de configuración de Chrome. Esto es lo otro: enrutar la biblioteca de agentes de IA para uso en navegadores a través de IPs residenciales autenticadas, una por agente.

Buscas proxy para uso en navegadores y Google te muestra el diálogo de configuración de Chrome, la API de extensión chrome.proxy y un tutorial de archivo PAC corporativo. Nada de eso es lo que buscabas. Quieres enrutar browser-use - la biblioteca de Python con 108k estrellas en GitHub que permite a un LLM manejar un navegador real - a través de un proxy autenticado, para que tu agente no ataque un objetivo desde la IP de tu oficina. Esta es esa guía: dónde vive realmente el parámetro, por qué deja de funcionar silenciosamente después de una actualización, cómo darle a cada agente paralelo su propia IP de salida y qué sucede con una tarea larga cuando la IP se mueve bajo ella.

Dónde vive realmente el parámetro de proxy para uso en navegadores

El proxy es una propiedad de la sesión del navegador, no del agente. En la biblioteca actual, Browser es un alias para BrowserSession - los documentos son explícitos en que son exactamente la misma clase - por lo que cualquier tutorial que encuentres usando un nombre aplica al otro. El parámetro es proxy, y los documentos lo tipifican como ProxySettings con cuatro campos: server, bypass, username y password. Un dict equivalente funciona, que es lo que la mayoría de la gente pasa:

import asyncio
from browser_use import Agent, Browser
# llm = ...  your model of choice; see the browser-use docs for the import

PROXY = {
    "server": "http://gate.quantumproxies.io:8000",  # scheme is mandatory
    "username": "USER",
    "password": "PASS",
    "bypass": "localhost,127.0.0.1",                  # keep local calls off the proxy
}

browser = Browser(proxy=PROXY, headless=False)

async def main():
    agent = Agent(
        task="Open https://api.ipify.org?format=json and report the IP you see",
        llm=llm,
        browser_session=browser,
    )
    await agent.run()

asyncio.run(main())

Dos detalles que la gente suele hacer mal. Primero, las credenciales pertenecen a los campos username y password, no se deben meter en server - Chromium no responderá a un desafío de autenticación de proxy desde una contraseña incrustada en la URL, y browser-use no tiene un diálogo para escribirla. Segundo, server necesita un esquema. gate.quantumproxies.io:8000 no es una URL de proxy; http://gate.quantumproxies.io:8000 sí lo es. Si las credenciales te están dando problemas, blanquear la IP de tu servidor elimina por completo el usuario:contraseña de la ecuación - la puerta de enlace reconoce al llamante y el navegador nunca ve un 407.

Por qué tu configuración de proxy para uso en navegadores no hace nada

La página más visitada sobre este tema después de los documentos es el problema #2445 de GitHub, presentado en julio de 2025: un proxy que funcionaba en 0.1.45 dejó de tener efecto en 0.5.4, y la única pista era que el agente informaba alegremente DNS_PROBE_FINISHED_NXDOMAIN en su propio resumen. Ese modo de falla - el agente narrando un error de red como si fuera un hecho sobre el sitio web - es la firma de un proxy que está medio configurado. Revisa esta lista antes de gastar más tokens:

Pasaste proxy= a una sesión que el agente nunca recibió. Crea un Browser, pasa ese objeto exacto, y no dejes que se cree una sesión predeterminada a tus espaldas.
Configuraste cdp_url. Conectarse a un Chrome ya en ejecución significa que el proxy pertenece a las banderas de lanzamiento de ese navegador (--proxy-server=...), no a tu configuración de sesión - browser-use no puede adaptarlo retroactivamente.
Una variable de entorno global HTTP_PROXY o HTTPS_PROXY está luchando contra la configuración de la sesión, o peor, enruta silenciosamente tus llamadas a la API de LLM a través de un ancho de banda medido.
El proxy en sí está muerto. Pruébalo fuera del agente primero - no cuesta nada y descarta la mitad del espacio de búsqueda.

import requests

PROXY_URL = "http://USER:PASS@gate.quantumproxies.io:8000"
r = requests.get(
    "https://api.ipify.org?format=json",
    proxies={"http": PROXY_URL, "https": PROXY_URL},
    timeout=20,
)
print(r.status_code, r.text)   # must NOT be your own IP

Si eso imprime una IP extranjera, las credenciales y la puerta de enlace están bien y el problema está en el cableado de la sesión. Si imprime tu propia dirección, o un 407, arregla eso primero. Nuestro verificador de IP gratuito te dice cómo se ve la salida desde el otro lado - ASN, tipo y reputación - que es la segunda cosa a verificar cuando las páginas cargan pero cada una de ellas es un CAPTCHA.

Lista de verificación que coincide con los síntomas del proxy para uso en navegadores (errores de DNS, fuga de IP real, configuración que funcionaba en una versión anterior) con las soluciones a verificar — La configuración generalmente parece correcta. La falla casi siempre es la sesión que el agente realmente recibió, el esquema faltante o una variable de entorno global.

Un proxy por sesión, para que los agentes paralelos no compartan una IP de salida

Esta es toda la razón por la que el parámetro se encuentra en la sesión en lugar de en una configuración global. Ejecuta diez agentes a través de un Browser compartido y el objetivo ve diez veces el tráfico desde una dirección, que es la forma más rápida de quemar una IP residencial. Construye la sesión dentro de la corrutina en su lugar, y dale a cada una su propio identificador de sesión persistente para que la puerta de enlace la fije a una sola salida durante la vida de la tarea:

import asyncio, secrets
from browser_use import Agent, Browser

def session_proxy(sid: str, country: str = "us"):
    return {
        "server": "http://gate.quantumproxies.io:8000",
        "username": f"USER-country-{country}-session-{sid}",
        "password": "PASS",
    }

async def run_task(task: str, country: str):
    sid = secrets.token_hex(3)                  # e.g. a1b2c3
    browser = Browser(
        proxy=session_proxy(sid, country),
        user_data_dir=None,                     # incognito: no shared cookies
        allowed_domains=["*.example.com"],      # keep the agent on target
    )
    agent = Agent(task=task, llm=llm, browser_session=browser)
    return await agent.run()

async def main():
    await asyncio.gather(
        run_task("Find the price of SKU-1", "us"),
        run_task("Find the price of SKU-1", "de"),
        run_task("Find the price of SKU-1", "gb"),
    )

asyncio.run(main())

Tres banderas están haciendo un trabajo real allí. user_data_dir=None se ejecuta en modo incógnito, por lo que los agentes no pueden heredar las cookies de los demás y fusionar silenciosamente dos identidades en un perfil. allowed_domains restringe la navegación a una lista de patrones - nota que los comodines en la posición de TLD, como example.*, son rechazados a propósito, y las listas de más de cien entradas se optimizan en conjuntos con coincidencia de patrones desactivada. Y el identificador de sesión en el nombre de usuario es lo que hace que la IP de salida sea estable; los nombres exactos de las banderas para el país y la sesión viven en tu panel de control, pero la forma es la misma en todas partes.

Elegir el país de salida por tarea

Los agentes que compran, comparan precios o verifican disponibilidad están equivocados por defecto si navegan desde el país incorrecto. Debido a que el proxy es por sesión, el país es un argumento por tarea - cambia country-us por country-de y la misma tarea devuelve precios alemanes. Elige entre los más de 200 países en el grupo, y mantén el resto del navegador coherente con él: pasa un idioma coincidente a través de args (Chromium acepta --lang=de-DE) en lugar de dejar que una IP de salida alemana solicite páginas en inglés de EE. UU. Para superficies solo móviles y las salidas de mayor confianza, las IPs móviles se comportan de manera diferente nuevamente, porque el NAT del operador pone a miles de usuarios reales detrás de la misma dirección.

Dale a cada agente su propia IP de salida residencial

Flujo que muestra una cola de tareas desplegándose en una sesión de uso de navegador por agente, cada una con su propia sesión de proxy persistente, para que el sitio objetivo vea IPs residenciales distintas — Construye la sesión dentro de la tarea, no fuera de ella. Un Browser por agente, una sesión persistente por Browser, una IP por identidad.

Qué sucede cuando la IP rota en medio de una tarea

Los agentes son lentos de una manera que los scrapers no lo son. Entre la pausa predeterminada de 0.5s después de cada acción, una espera mínima de estado de página de 0.25s y una espera de inactividad de red de 0.5s, browser-use pasa más de un segundo por paso antes de que el modelo haya dicho algo - y el viaje de ida y vuelta del modelo suele ser varios segundos más. Una tarea de quince pasos, por lo tanto, se ejecuta durante uno a dos minutos de reloj de pared. Si tu IP de salida rota por solicitud, el sitio verá una dirección diferente en cada uno de esos pasos: el inicio de sesión se cae, el carrito se vacía y el agente informa que el botón de pago desapareció.

La solución es una sesión persistente cuya ventana exceda cómodamente la duración de tu tarea en el peor de los casos, no tu promedio. Cronometra algunas ejecuciones reales, toma la más lenta y añade un margen - los agentes reintentan, y un reintento duplica el reloj. Cuando una tarea realmente necesita sobrevivir a cualquier ventana persistente, divídela: inicia sesión y exporta el estado, luego reanuda en una nueva sesión con las cookies que guardaste a través de storage_state. Y si estás eligiendo entre rotación por solicitud y persistente en absoluto, nuestra lista de verificación de infraestructura para agentes de IA cubre el resto de la capa alrededor de esta decisión.

Mantén el proxy fuera de tus llamadas a LLM

Esto cuesta dinero real y casi nadie lo detecta. Configurar HTTPS_PROXY como una variable de entorno para hacer que el proxy "se aplique en todas partes" también enruta cada llamada a la API del modelo a través de tu puerta de enlace residencial - indicaciones y respuestas, en cada paso, facturado por gigabyte por el privilegio de ir por el camino largo. Configura el proxy solo en el Browser y deja el entorno del proceso en paz. Mientras cuentas bytes, nota que browser-use carga uBlock Origin por defecto a través de enable_default_extensions: déjalo activado, porque cada solicitud de anuncio que mata es una que no pagas. La aritmética completa está en nuestro desglose de lo que cuesta un agente de IA en ancho de banda, y la versión de scraping clásico del compromiso está en navegador sin cabeza vs solicitudes HTTP.

Preguntas frecuentes

¿Cómo configuro un proxy en browser-use?

Pasa proxy= cuando construyas el Browser (también exportado como BrowserSession), luego entrega ese objeto al Agent. El valor lleva server con un esquema http:// explícito, además de username, password y una lista opcional de bypass. No hay configuración de proxy a nivel de agente - pertenece a la sesión.

¿Por qué no funciona mi configuración de proxy para uso en navegadores?

En orden de probabilidad: el agente está ejecutándose en una sesión diferente a la que configuraste, server carece de su esquema, configuraste cdp_url por lo que el navegador se lanzó en otro lugar sin banderas de proxy, o una variable de entorno de proxy global te está anulando. Verifica el proxy con un cliente HTTP simple primero - un error de DNS dentro del registro del agente generalmente significa que no hay ningún proxy adjunto.

¿Puede cada agente de browser-use usar una IP diferente?

Sí, y deberías hacerlo. Crea el Browser dentro de cada corrutina de tarea con sus propias credenciales de proxy en lugar de compartir una instancia. Agregar un identificador de sesión único al nombre de usuario de la puerta de enlace fija cada agente a una salida distinta durante la duración de su ejecución, por lo que diez agentes paralelos parecen diez usuarios en lugar de uno muy ocupado.

¿Qué tipo de proxy es mejor para los agentes de browser-use?

Residencial rotativo para investigación y verificaciones de precios donde cada tarea es independiente, residencial persistente para cualquier cosa con un inicio de sesión o un carrito, y móvil cuando el objetivo es hostil o solo móvil. Las IPs de centros de datos están bien para objetivos internos y páginas no protegidas, y son mucho más baratas por gigabyte - lo que importa, porque un agente de navegador mueve muchos gigabytes.

¿Un proxy evita que browser-use sea detectado?

No. Un proxy solo corrige la capa de IP; la huella digital de un Chromium automatizado es un problema separado, al igual que el comportamiento de un agente que hace clic con precisión de milisegundos. Las salidas residenciales de confianza eliminan la señal más fácil, pero combínalas con una compilación de navegador orientada al sigilo si el objetivo ejecuta una gestión seria de bots.

Nada aquí es exótico: el proxy es una propiedad de la sesión, y las dos cosas que lo rompen son un esquema faltante y una sesión que nunca entregaste. Hazlo bien, dale a cada agente paralelo su propia salida persistente y mantén la puerta de enlace alejada de tus llamadas a la API del modelo. Para una visión más amplia, consulta nuestro mapa de marcos anti-detección y proxies autenticados.

Ejecuta browser-use en más de 90M de IPs residenciales en más de 200 países