Browsergebruik Proxyconfiguratie: Per-sessie Exit IP's

Zoek naar een browsergebruik proxy en Google geeft je het instellingenvenster van Chrome. Dit is het andere: het routeren van de browsergebruik AI-agent bibliotheek via geauthenticeerde residentiële IP's, één per agent.

Zoek naar browsergebruik proxy en Google geeft je het instellingenvenster van Chrome, de chrome.proxy extensie API en een tutorial voor een corporate PAC-bestand. Geen van dat is wat je zocht. Je wilt browsergebruik - de Python-bibliotheek met 108k GitHub-sterren die een LLM een echte browser laat besturen - routeren via een geauthenticeerde proxy, zodat je agent niet een doelwit vanuit je kantoor-IP bestookt. Dit is die gids: waar de parameter eigenlijk leeft, waarom het stilletjes stopt met werken na een upgrade, hoe je elke parallelle agent zijn eigen exit IP geeft, en wat er gebeurt met een lange taak wanneer het IP eronder beweegt.

Waar de browsergebruik proxyparameter eigenlijk leeft

De proxy is een eigenschap van de browsersessie, niet van de agent. In de huidige bibliotheek is Browser een alias voor BrowserSession - de documentatie is expliciet dat ze precies dezelfde klasse zijn - dus elke tutorial die je vindt met de ene naam geldt ook voor de andere. De parameter is proxy, en de documentatie typt het als ProxySettings met vier velden: server, bypass, username en password. Een equivalent dict werkt, wat de meeste mensen doorgeven:

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())

Twee details die mensen verkeerd doen. Ten eerste, inloggegevens horen in de velden username en password, niet in server gestopt - Chromium zal niet reageren op een proxy-authenticatie-uitdaging van een URL-ingebed wachtwoord, en browsergebruik heeft geen dialoog om het in te typen. Ten tweede, server heeft een schema nodig. gate.quantumproxies.io:8000 is geen proxy-URL; http://gate.quantumproxies.io:8000 is dat wel. Als inloggegevens je problemen geven, verwijdert whitelisting van het IP van je server gebruikersnaam:wachtwoord volledig uit de vergelijking - de gateway herkent de beller en de browser ziet nooit een 407.

Waarom je browsergebruik proxyconfiguratie stilletjes niets doet

De meest bezochte pagina over dit onderwerp na de documentatie is GitHub-issue #2445, ingediend in juli 2025: een proxy die werkte in 0.1.45 stopte met effect hebben op 0.5.4, en de enige aanwijzing was dat de agent vrolijk DNS_PROBE_FINISHED_NXDOMAIN rapporteerde in zijn eigen samenvatting. Die faalmodus - de agent die een netwerkfout vertelt alsof het een feit over de website is - is het kenmerk van een proxy die half geconfigureerd is. Werk deze lijst door voordat je meer tokens verbrandt:

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

Als dat een buitenlands IP afdrukt, zijn de inloggegevens en gateway in orde en ligt het probleem in de sessiebedrading. Als het je eigen adres afdrukt, of een 407, los dat dan eerst op. Onze gratis IP-checker vertelt je hoe de exit eruitziet vanaf de andere kant - ASN, type en reputatie - wat het tweede is om te controleren wanneer pagina's laden maar elke een CAPTCHA is.

Checklist die browsergebruik proxy-symptomen (DNS-fouten, echt IP-lekken, configuratie die werkte op een oudere versie) koppelt aan de te controleren oplossingen
De configuratie ziet er meestal goed uit. De fout is bijna altijd de sessie die de agent daadwerkelijk ontving, het ontbrekende schema, of een globale omgevingsvariabele.

Eén proxy per sessie, zodat parallelle agents geen exit IP delen

Dit is de hele reden waarom de parameter op de sessie zit in plaats van op een globale configuratie. Laat tien agents door één gedeelde Browser lopen en het doelwit ziet tien keer het verkeer van één adres, wat de snelste manier is om een residentieel IP te verbranden. Bouw de sessie binnen de coroutine in plaats daarvan, en geef elk zijn eigen sticky sessie-identificator zodat de gateway het aan één exit bindt voor de duur van de taak:

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())

Drie vlaggen doen daar echt werk. user_data_dir=None draait incognito, zodat agents elkaars cookies niet kunnen overnemen en stilletjes twee identiteiten op één profiel samenvoegen. allowed_domains beperkt navigatie tot een patroonlijst - let op dat wildcards in de TLD-positie, zoals example.*, opzettelijk worden afgewezen, en lijsten van meer dan honderd items worden geoptimaliseerd tot sets met patroonmatching uitgeschakeld. En de sessie-identificator in de gebruikersnaam is wat het exit IP stabiel maakt; de exacte vlaggenamen voor land en sessie staan in je dashboard, maar de vorm is overal hetzelfde.

Het kiezen van het exitland per taak

Agents die winkelen, prijzen vergelijken of beschikbaarheid controleren zijn standaard verkeerd als ze vanuit het verkeerde land browsen. Omdat de proxy per sessie is, is het land een per-taak argument - verwissel country-us voor country-de en dezelfde taak geeft Duitse prijzen terug. Kies uit de 200+ landen in de pool, en houd de rest van de browser daarmee coherent: geef een bijpassende taal door via args (Chromium accepteert --lang=de-DE) in plaats van een Duitse exit IP pagina's in Amerikaans Engels te laten aanvragen. Voor alleen mobiele oppervlakken en de meest vertrouwde exits, gedragen mobiele IP's zich weer anders, omdat carrier NAT duizenden echte gebruikers achter hetzelfde adres plaatst.

Geef elke agent zijn eigen residentiële exit IP

Stroomdiagram dat een takenwachtrij laat zien die uitwaaiert naar één browsergebruik sessie per agent, elk met zijn eigen sticky proxy sessie, zodat de doelwebsite verschillende residentiële IP's ziet
Bouw de sessie binnen de taak, niet erbuiten. Eén Browser per agent, één sticky sessie per Browser, één IP per identiteit.

Wat gebeurt er als het IP midden in de taak roteert

Agents zijn traag op een manier die scrapers niet zijn. Tussen de standaard 0,5s pauze na elke actie, een 0,25s minimale paginastatuswacht en een 0,5s netwerk-idle wacht, besteedt browsergebruik meer dan een seconde per stap voordat het model iets heeft gezegd - en de modelronde-trip is meestal nog enkele seconden meer. Een vijftien-stappen taak duurt daarom één tot twee minuten van kloktijd. Als je exit IP per verzoek roteert, ziet de site een ander adres bij elke stap: de login valt weg, de winkelwagen leegt, en de agent meldt dat de afrekenknop verdwenen is.

De oplossing is een sticky sessie waarvan het venster comfortabel je slechtste geval taaktijd overschrijdt, niet je gemiddelde. Tijd een paar echte runs, neem de langzaamste, en voeg marge toe - agents proberen opnieuw, en een herhaling verdubbelt de klok. Wanneer een taak echt langer moet duren dan elk sticky venster, verdeel het: log in en exporteer de status, hervat dan in een nieuwe sessie met de cookies die je via storage_state hebt opgeslagen. En als je überhaupt moet kiezen tussen rotatie per verzoek en sticky, behandelt onze infrastructuurchecklist voor AI-agents de rest van de laag rond deze beslissing.

Houd de proxy weg van je LLM-aanroepen

Dit kost echt geld en bijna niemand merkt het. Het instellen van HTTPS_PROXY als een omgevingsvariabele om de proxy "overal toe te passen" routeert ook elke model API-aanroep via je residentiële gateway - prompts en reacties, bij elke stap, per gigabyte gefactureerd voor het voorrecht om de lange weg te gaan. Configureer de proxy alleen op de Browser en laat de procesomgeving met rust. Terwijl je bytes telt, merk op dat browsergebruik standaard uBlock Origin laadt via enable_default_extensions: laat het aan, want elke advertentieaanroep die het doodt is er een die je niet hoeft te betalen. De volledige rekenkunde staat in onze uiteenzetting van wat een AI-agent kost in bandbreedte, en de klassieke scraping-versie van de afweging staat in headless browser vs HTTP-aanvragen.

Veelgestelde vragen

Hoe stel ik een proxy in bij browsergebruik?

Geef proxy= door wanneer je de Browser (ook geëxporteerd als BrowserSession) construeert, en geef dat object dan door aan de Agent. De waarde bevat server met een expliciet http:// schema, plus username, password en een optionele bypass lijst. Er is geen agent-niveau proxy-instelling - het behoort tot de sessie.

Waarom werkt mijn browsergebruik proxyconfiguratie niet?

In volgorde van waarschijnlijkheid: de agent draait op een andere sessie dan degene die je hebt geconfigureerd, server mist zijn schema, je hebt cdp_url ingesteld zodat de browser elders werd gestart zonder proxyvlaggen, of een globale proxy omgevingsvariabele overschrijft je. Verifieer de proxy eerst met een gewone HTTP-client - een DNS-fout in het agentlogboek betekent meestal dat er helemaal geen proxy is aangesloten.

Kan elke browsergebruik agent een ander IP gebruiken?

Ja, en dat zou je moeten doen. Maak de Browser binnen elke taakcoroutine met zijn eigen proxy-inloggegevens in plaats van één instantie te delen. Door een unieke sessie-identificator toe te voegen aan de gateway gebruikersnaam, wordt elke agent vastgepind aan een afzonderlijke exit voor de duur van zijn run, zodat tien parallelle agents eruitzien als tien gebruikers in plaats van één zeer drukke.

Welk proxytype past het beste bij browsergebruik agents?

Roterende residentiële voor onderzoek en prijscontroles waar elke taak onafhankelijk is, sticky residentiële voor alles met een login of een winkelwagen, en mobiel wanneer het doelwit vijandig of alleen mobiel is. Datacenter IP's zijn prima voor interne doelen en onbeschermde pagina's, en ze zijn veel goedkoper per gigabyte - wat van belang is, omdat een browseragent veel gigabytes verplaatst.

Voorkomt een proxy dat browsergebruik wordt gedetecteerd?

Nee. Een proxy lost alleen de IP-laag op; de vingerafdruk van een geautomatiseerde Chromium is een apart probleem, net als het gedrag van een agent die met milliseconde precisie klikt. Vertrouwde residentiële exits verwijderen het gemakkelijkste signaal, maar combineer ze met een stealth-georiënteerde browserbuild als het doelwit serieus botbeheer uitvoert.

Niets hier is exotisch: de proxy is een sessie-eigenschap, en de twee dingen die het breken zijn een ontbrekend schema en een sessie die je nooit hebt overgedragen. Krijg die goed, geef elke parallelle agent zijn eigen sticky exit, en houd de gateway weg van je model API-aanroepen. Voor het bredere plaatje, zie onze kaart van anti-detect frameworks en geauthenticeerde proxies.

Draai browsergebruik op 90M+ residentiële IP's in meer dan 200 landen