Quick Answer
To use a Proxidize residential proxy with Browser Use, pass the dashboard-generated endpoint and credentials to ProxySettings, attach that configuration to Browser, and give the same Browser to the Agent:
The snippet is the core configuration inside an async program; a complete copy-paste example appears below. Use the exact host, port, username, and password generated by Proxidize. The example endpoint is illustrative.
For most multi-page AI-agent tasks, use one sticky Proxidize session for the complete task and rotate when the next independent task starts. Put the proxy on Browser, not only in the prompt: telling an agent to “use a US proxy” does not change Chromium's network route.
Key Takeaways
- Browser Use 0.13.8 accepts a proxy through Browser(proxy=ProxySettings(...)).
- Configure country, city, ISP, protocol, and Sticky or Random mode in Proxidize before copying the generated credentials.
- Verify the exit IP from a page opened inside the Browser Use browser; an ordinary Python HTTP call does not verify Chromium's route.
- Use Sticky mode during a coherent multi-step task and rotate between independent tasks.
- Give concurrent agents separate Browser instances and proxy sessions. The detailed architecture belongs in the multi-agent Browser Use guide.
Browser Use Built-In Proxy vs Proxidize
Browser Use Cloud already includes a US residential proxy by default and supports country selection. You do not need to add Proxidize when that built-in routing covers the workflow.
Proxidize becomes useful when the proxy layer needs more explicit controls or must work outside one hosted browser product.
| Requirement | Browser Use Cloud built-in proxy | Proxidize with Browser Use |
|---|---|---|
| Fastest setup inside Browser Use Cloud | Strong fit; a US residential route is enabled by default | Requires a custom endpoint or local Browser configuration |
| Country selection | Supported through Browser Use Cloud settings | Supported through the Proxidize access point or documented country username selector |
| City and ISP targeting | Not exposed in the Browser Use Cloud proxy page checked for this guide | Configured through the Proxidize dashboard or Session Builder |
| Explicit Sticky or Random access-point policy | Browser Use manages its native route | Configured per Proxidize access point |
| Same proxy layer for Browser Use, Playwright, HTTP clients, and other tools | Tied to Browser Use Cloud | Standard HTTP or SOCKS5 credentials can be reused across compatible tools |
| Proxy dashboard, access points, and independent usage controls | Browser and proxy operations stay within Browser Use | Proxidize manages the proxy layer separately from the browser or LLM |
| Best fit | A Browser Use Cloud workload needing simple country routing | Teams needing city/ISP controls, explicit sessions, cross-tool routing, or separate proxy operations |
This is not a claim that one product replaces the other. Browser Use supplies the agent and browser infrastructure. Proxidize supplies the residential route and its targeting/session policy. A team can use Browser Use's native proxy, Browser Use with Proxidize, or local Browser Use with Proxidize depending on which layer it wants to manage.
Explore Proxidize Residential Proxies if city/ISP targeting, rotating and sticky access points, or one proxy layer across multiple tools is part of the requirement.
Methodology and responsible-use note: Browser Use package behavior, source, and first-party documentation were checked on August 25, 2026. These examples target Browser Use 0.13.8, released August 16, 2026. The Browser lifecycle and ProxySettings path first passed a controlled local HTTP-proxy smoke test. A live authenticated Proxidize Residential HTTP endpoint then passed an in-browser IP check, Example Domain navigation, clean shutdown, and a Sticky-session probe that retained one exit across five fresh Browser/Chromium instances. The browser's geo lookup returned country code TT; because no expected country was supplied, intentional country targeting is not yet verified. The LLM-driven Agent.run() remains pending a Browser Use API key. Proxidize capabilities and pricing were checked against current first-party pages. Use automation and proxies only for lawful, authorized work, and follow applicable laws, contracts, website terms, privacy obligations, and reasonable request rates.
Prerequisites
You need:
- Python 3.12, matching the current Browser Use quickstart.
- Browser Use 0.13.8 and its Chromium runtime.
- A Browser Use API key for ChatBrowserUse, or another supported LLM.
- A Proxidize Residential Proxy plan and completed KYC.
- One dashboard-generated HTTP access point for the primary example.
- Authorization to automate the intended target.
The current Browser Use browser reference recommends Browser directly and documents it as an alias for BrowserSession. Older examples may create a BrowserProfile; that path remains for backward compatibility but is unnecessary here.
| Component | Version or setting used | Note |
|---|---|---|
| Browser Use | 0.13.8 | Pin it because agent and browser APIs evolve quickly |
| Python | 3.12 | Current Browser Use quickstart version |
| LLM | ChatBrowserUse() | Reads BROWSER_USE_API_KEY |
| Proxy | Authenticated Proxidize HTTP access point | Simplest local Chromium configuration |
| IP test | https://api.ipify.org?format=json | Reports the browser's public exit IP |
The Browser Use 0.13.8 release is the version checked for this guide.
Five-Step Browser Use and Proxidize Setup
1. Create a Residential Access Point
In the Proxidize dashboard, create a residential access point and choose its policy before copying the credentials:
| Setting | Recommended starting choice | Change it when... |
|---|---|---|
| Authentication | Username/password | Use IP whitelist only from a stable, known public source IP |
| Protocol | HTTP | The runtime specifically requires SOCKS5 |
| IP mode | Sticky | Every observation is independent and Random mode has been tested with browser connection reuse |
| Country | Required target market | Location does not matter and a broader pool is acceptable |
| City | Required city or Random City | City-level output is or is not part of the task |
| ISP | Required ISP or Random | The workflow genuinely needs an ISP-specific view |
Proxidize generates the server, port, username, and password and provides a cURL test. Copy those values exactly. The residential proxy setup guide covers the dashboard workflow.
Username/password authentication is usually better for laptops, CI runners, containers, and other environments whose source IP can change. With IP whitelist authentication, omit username and password from ProxySettings; access stops if the allowlisted source IP changes.
2. Install Browser Use and Chromium
Browser Use currently recommends uv and Python 3.12:
On Windows PowerShell:
When upgrading Browser Use, update the package and browser runtime together, then repeat the proxy preflight before using a production target.
3. Add the Environment Variables
Create .env:
The public Proxidize page uses gate.proxidize.com:7777 in an HTTP example, but the current dashboard is authoritative. Do not change http:// to https:// merely because the destination is an HTTPS website. The scheme describes the connection to the proxy; Chromium can tunnel an HTTPS destination through an HTTP proxy.
Keep credentials out of source control:
Do not include the proxy password in an agent prompt. The LLM does not need it.
4. Create single_agent.py
This complete example validates the proxy route inside Chromium before spending LLM steps on the task:
Browser Use's ProxySettings has four documented fields:
| Field | Required | Meaning |
|---|---|---|
| server | Yes | Full proxy URL, including the scheme, host, and port |
| username | No | Proxy-authentication username |
| password | No | Proxy-authentication password |
| bypass | No | Comma-separated hosts that connect directly instead |
Be conservative with bypass. Adding the target or IP-check host would silently route it outside Proxidize.
5. Run the Agent
The preflight output should resemble:
The address is documentation-only. A real run should show the Proxidize residential exit, not the automation server's direct public IP. The second JSON object should report the agent result for Example Domain.
If the IP check fails, stop there. Fix endpoint, protocol, authentication, firewall, or access-point configuration before debugging the LLM prompt.
Verify That Chromium Is Actually Proxied
An ordinary Python call does not verify Browser Use:
The correct test opens the IP service through the same Browser object given to the Agent:
The complete program performs this check before Agent.run(). That creates a useful diagnostic boundary:
- IP check fails: proxy connection or authentication problem.
- IP check succeeds but target fails: allowlist, redirect, target, or task problem.
- Target loads but output is wrong: prompting, page state, or extraction problem.
Do not log a credential-bearing proxy URL. Public IPs can also identify infrastructure, so store only the evidence required by the operational policy.
Country, City, and ISP Targeting
Proxidize supports country, city, and ISP selection for residential access points.
The safest method is to configure the desired location in the dashboard or Session Builder and copy the generated credentials unchanged. Proxidize also documents country-only targeting with -country-{iso} appended to the username:
Use lowercase ISO country codes. Configure city and ISP through the dashboard; do not guess additional username segments that are not publicly documented.
For production, give access points policy-oriented names such as:
These are internal labels, not credential syntax.
Validate the Target's Visible Location
A requested city is an input, not proof. Record the requested location, observed exit IP, an approved IP-geolocation result when needed, and the location shown by the target itself.
Websites may use account country, cookies, delivery address, selected store, browser language, or currency preferences in addition to IP location. A city-targeted IP does not automatically select a local store.
Make the expected output explicit in the task:
IP-geolocation databases can disagree or lag behind network changes. Validate the actual target experience rather than treating one lookup service as absolute truth.
Sticky vs Rotating Proxies for Browser Use
The Python configuration is the same for Sticky and Random modes. The Proxidize access point determines the session behavior.
| Behavior | Random mode | Sticky mode |
|---|---|---|
| Exit selection | May choose another eligible peer for a new connection | Attempts to retain one peer for the session |
| Best fit | Independent sampling | Multi-page tasks and coherent localized sessions |
| Browser consideration | One page can open several connections | The residential peer can still disconnect |
| Recommended boundary | Fresh task and browser state | Keep through the work unit; refresh afterward |
A browser page is not one request. Chromium can fetch HTML, JavaScript, styles, images, fonts, and API calls over several reused or multiplexed connections. “Rotate every connection” therefore does not guarantee one new IP per page or one consistent IP for every page resource.
For most Browser Use tasks, start with Sticky mode and rotate between work units. Read how IP rotation works for the underlying connection and session distinctions.
Probe a Sticky or Random Session
Save this shorter probe beside single_agent.py. It reuses that file's validated environment and IP-check helpers but creates a fresh Browser for every observation:
Add the expected mode to .env, then run the probe:
Fresh browser connections make the test more meaningful than reloading one tab, but five samples are not a reliability benchmark. Random mode can select the same peer again. Sticky mode is also a lease, not a promise: residential devices disconnect and ISP leases change.
If a sticky exit changes during an identity-sensitive task, stop, checkpoint the last safe result, and restart the browser/session bundle instead of continuing silently.
Running Multiple Browser Use Agents
Concurrent agents should receive separate Browser instances, temporary profiles, and proxy sessions. Sharing tabs in one mutable profile can mix cookies, storage, selected locations, and target state. Sharing one sticky credential can also make otherwise independent tasks use the same routing state.
The full worker-pool implementation, lease file, semaphore, pre/postflight checks, duplicate-IP handling, and failure recovery now live in a separate guide: How to Run Multiple Browser Use Agents With Residential Proxies.
Browser Use Cloud vs Local Browser Configuration
The decision table near the top explains when each proxy path fits. The code differs as follows.
Local or Open-Source Browser Use
Attach ProxySettings directly to Browser:
For local Browser Use, authenticated HTTP is the safest default. Browser Use's 0.13.8 source handles credentials through HTTP proxy-authentication challenges. For a local socks5:// endpoint, use Proxidize IP whitelist authentication rather than assuming username/password SOCKS5 will behave like HTTP authentication.
Browser Use Cloud V4
Browser Use Cloud's current proxy documentation says a US residential proxy is enabled by default. It supports country selection and custom HTTP or SOCKS5 proxies on paid plans.
To bring a Proxidize endpoint to a hosted V4 run:
Browser Use documents that a custom proxy overrides proxyCountryCode and must be passed again when a follow-up provisions a new browser. Cloud fields and plan requirements can change separately from the open-source package, so recheck the current V4 reference before deploying.
Troubleshooting Browser Use Proxy Errors
| Symptom | Likely cause | What to check |
|---|---|---|
| 407 Proxy Authentication Required | Wrong credentials or authentication-mode mismatch | Copy the generated values again; confirm User/Pass vs IP Whitelist |
| ERR_PROXY_CONNECTION_FAILED | Wrong server, port, scheme, firewall, or unavailable gateway | Run the dashboard-generated cURL test from the same machine |
| ERR_TUNNEL_CONNECTION_FAILED | HTTP CONNECT, authentication, or upstream route failed | Test the same HTTP endpoint against a simple HTTPS page |
| IP check shows the direct IP | Target is bypassed, proxy is on another Browser, or the test ran outside Chromium | Remove the bypass; pass the configured Browser to the Agent; use browser.new_page() |
| IP works but target fails | Domain allowlist, redirect, target behavior, or authorization issue | Review required redirect domains and Browser Use history |
| Random mode keeps one IP | Connection reuse, chance reselection, or wrong access-point mode | Use fresh Browser instances; increase samples; verify dashboard mode |
| Sticky mode changes IP | Peer disconnected, lease changed, or session was refreshed | Quarantine the work unit and restart the browser/proxy bundle |
| Requested city is not visible | Target uses account, cookie, store, or another geo database | Verify dashboard selection, observed IP, and target-visible location separately |
| Agent needs another hostname | Expected redirect, identity provider, or unsafe navigation attempt | Review it and add only an expected, authorized hostname |
| Browser remains after failure | Persistent session was not force-closed | Put browser.kill() in finally when keep_alive=True |
Debug in this order:
- Test the access point with the dashboard-generated cURL command.
- Run session_probe.py without an LLM task.
- Run single_agent.py against Example Domain.
- Add the real target and known redirect domains.
- Add geo-targeting and target-visible validation.
- Add concurrency only after the single-agent path is stable.
This prevents proxy authentication, browser launch, prompting, target behavior, localization, and concurrency from becoming one indistinguishable problem.
Short Production Checklist
- Pin Browser Use and retest proxy behavior after upgrades.
- Keep LLM and proxy credentials in a secret manager, never in prompts or logs.
- Run an in-browser IP preflight before the agent task.
- Use Sticky mode for multi-step work and rotate only after a validated boundary.
- Isolate Browser and proxy state per concurrent agent.
- Restrict allowed_domains, maximum steps, overall runtime, and concurrency.
- Validate the target's visible country, store, language, and currency when location matters.
- Treat an unexpected sticky-IP change as a state failure.
- Always close or kill the browser in finally.
- Use respectful request rates and comply with applicable law and target terms.
An AI browser agent can encounter instructions embedded in untrusted pages. Domain allowlists, limited tools, human approval for consequential actions, and protected browser profiles are as important as the proxy configuration. Proxies can help reduce blocks, but they do not guarantee access or grant permission to automate a target.
For broader collection architecture, see how to use proxies for web scraping and proxy sessions for AI agents.