Using Singapore mobile proxies with browser-use in 2026

If you’ve shipped a browser-use agent that works perfectly on localhost but starts hitting 403s, CAPTCHAs, or silent redirects in production, the problem is almost never your prompt. It’s the IP. The gap between what a well-tuned browser-use agent can do and what a detection system will allow has narrowed to a single variable: whether your egress IP looks like a real user from the right place. For workflows targeting Singapore-based platforms, financial services portals, or e-commerce sites serving SEA users, a datacenter IP from AWS ap-southeast-1 is not a neutral starting point. It is an instant flag.

why browser-use hits walls without residential mobile IPs

browser-use agents run on Playwright, which means they inherit Playwright’s headless browser signatures unless you explicitly patch them. Even with stealth patches applied, the IP layer gives the game away. Most serious anti-bot systems, including those deployed by Cloudflare, Akamai Bot Manager, and Imperva, score each request using a combination of TLS fingerprint, HTTP/2 settings, browser canvas hash, and IP reputation. A datacenter IP, even one registered in a Singapore region, carries a commercial ASN that any threat intelligence feed immediately classifies as non-residential. The challenge score goes up before your agent has made a single meaningful request.

The problem compounds with the workflows browser-use is actually used for. Agents that scrape pricing data, fill out signup forms, compare search result rankings, or interact with SingPass-integrated portals are exactly the workflows that commercial sites actively monitor. When your agent’s IP appears in threat intelligence databases as belonging to a hosting provider or VPN service, the site’s bot detection layer doesn’t need to analyze behavior at all. The IP alone is enough to rate-limit, fingerprint, or silently serve degraded content. You won’t always get a 429. Sometimes you get a different version of the page designed specifically for bots, and your agent happily processes the wrong data with no error signal.

Mobile IPs change this calculus. A real SingTel or StarHub IP carries the ASN and geolocation metadata of a consumer mobile subscriber. These IPs cycle through CGNAT pools the way real users’ phones do, and they appear in traffic logs as ordinary consumer traffic. Anti-bot systems assign them lower challenge scores because they are statistically associated with legitimate browsing patterns. This is the core reason to understand what is a mobile proxy before wiring anything up, because the technical distinction between a mobile carrier IP and a residential broadband IP matters for how detection systems score your traffic.

setting up SMP credentials in browser-use

SMP provides credentials in the format ip:port:username:password. The host and port identify the proxy endpoint; the username and password authenticate your session. browser-use passes proxy configuration directly to Playwright’s browser context, so the setup maps cleanly onto Playwright’s native proxy options object, which is documented in the Playwright network guide.

Here is a minimal working configuration using browser-use’s BrowserConfig:

import asyncio
import os
from langchain_openai import ChatOpenAI
from browser_use import Agent, Browser, BrowserConfig

SMP_HOST = os.environ["SMP_HOST"]
SMP_PORT = os.environ["SMP_PORT"]
SMP_USER = os.environ["SMP_USER"]
SMP_PASS = os.environ["SMP_PASS"]

browser = Browser(
    config=BrowserConfig(
        proxy={
            "server": f"http://{SMP_HOST}:{SMP_PORT}",
            "username": SMP_USER,
            "password": SMP_PASS,
        }
    )
)

llm = ChatOpenAI(model="gpt-4o")

async def run():
    agent = Agent(
        task="Go to a Singapore e-commerce site and extract the current pricing tiers.",
        llm=llm,
        browser=browser,
    )
    result = await agent.run()
    print(result)

asyncio.run(run())

A couple things to know. The server field takes a full URI including scheme. Use http:// for HTTP proxies and socks5:// if you are using SMP’s SOCKS5 endpoint. For latency-sensitive agents, SOCKS5 is generally preferable because it proxies at the TCP layer rather than the HTTP layer, which reduces overhead on HTTPS connections. The HTTP vs SOCKS5 mobile proxies comparison covers the tradeoffs in detail if you need to make that case internally.

Don’t hardcode credentials in source files. Pull them from environment variables or a secrets manager before your agent initializes. This matters when you are running multiple agents with different proxy credentials for different task types, because a leaked credential means burning through your IP pool or exposing your session.

rotating IPs per request or per session

The decision between rotating and sticky sessions is not about preference. It is about what your task actually requires. Rotating endpoints assign a new IP from the SMP pool on each connection or on a time-based interval. Sticky endpoints hold the same IP for the duration of a session window, typically measured in minutes. Getting this wrong wastes money and breaks tasks in ways that are genuinely hard to debug.

Use rotating endpoints when your agent is doing stateless or read-only operations: checking prices, pulling search rankings, reading public listings. Each request can come from a fresh IP with no side effects. Use sticky sessions when your agent needs to maintain authenticated state: logging in, working through a multi-step checkout flow, completing a form across several pages. If your login request comes from one IP and the subsequent page load comes from a different IP, the session cookie will often be invalidated by the site’s fraud detection layer.

SMP exposes both endpoint types. For rotation, you trigger a new IP via your rotation link, which is available in your account dashboard. For sticky sessions, you use the same endpoint continuously until the session window expires. The code pattern for managing both in a browser-use agent looks like this:

import os
from browser_use import Browser, BrowserConfig

def make_browser(sticky: bool = False) -> Browser:
    host = (
        os.environ["SMP_STICKY_HOST"]
        if sticky
        else os.environ["SMP_ROTATING_HOST"]
    )
    return Browser(
        config=BrowserConfig(
            proxy={
                "server": f"http://{host}:{os.environ['SMP_PORT']}",
                "username": os.environ["SMP_USER"],
                "password": os.environ["SMP_PASS"],
            }
        )
    )

# for a login + multi-step workflow
auth_browser = make_browser(sticky=True)

# for a bulk data collection pass
scrape_browser = make_browser(sticky=False)

In practice, most non-trivial browser-use workflows need both modes. A common pattern is to handle authentication with a sticky connection, persist the resulting cookies, and then replay that authenticated state into a new browser context that uses a rotating proxy for the actual data collection phase. Session integrity stays intact while the IP varies across your collection requests.

three real workflows where this combo wins

monitoring Singapore e-commerce pricing

browser-use agents that track product pricing on Lazada, Shopee, or Qoo10 run into aggressive bot detection because these platforms treat automated price scrapers as a direct business threat. The detection logic is not subtle: repeated visits to product pages from the same IP, or from IPs in the same datacenter subnet, trigger rate limiting or serve cached and potentially incorrect prices to suspected bots. Running this agent through a SingTel or StarHub residential IP means requests look identical to a consumer browsing from their phone. The agent can check hundreds of SKUs per session without triggering anomaly detection, and the prices it returns are the same ones a real Singapore shopper sees, not a bot-targeted variant.

automating SingPass-integrated portals

Several Singapore government and financial services portals use SingPass for authentication and apply geolocation checks on top of standard session controls. An agent that needs to interact with these portals from outside a recognized Singapore residential IP range will often hit either a hard block or a soft redirect to a warning page. The portal backend verifies that the ASN and geolocation metadata of the requesting IP align with expected consumer traffic originating from Singapore. A real SingTel mobile IP passes this check cleanly. If you are building automated workflows on top of government digital services or testing integrations that touch CPF, IRAS, or MyInfo-connected platforms, this is not optional. Data Research Tools has additional context on automating data collection workflows across regional platforms if your use case spans multiple SEA countries beyond Singapore.

testing how SG users actually experience your own product

QA and UX research workflows that use browser-use to simulate real user interactions need the agent to see the same version of your product that Singapore mobile users see. CDNs, A/B testing frameworks, and feature flag systems frequently serve different content based on IP geolocation and ASN. A browser-use agent running from a developer’s laptop in Europe or a CI server in us-east-1 will see a different content branch, different pricing in local currency, or a different set of payment methods than a Singapore mobile user. Running the agent through SMP gives you a ground-truth view of what your actual target audience sees. This is useful for regression testing, conversion funnel analysis, and competitive benchmarking where accuracy depends on seeing the Singapore-specific content variant.

common pitfalls

user-agent and IP class mismatch. A mobile carrier IP paired with a default desktop Chrome user-agent creates a statistical anomaly that detection systems flag. If you are using SMP mobile IPs, configure Playwright to send a user-agent that is realistic for the browser type your task actually needs. OWASP’s Automated Threats to Web Applications catalogue covers credential cracking and scraping patterns where signal combinations like this are the detection trigger.
rotating IPs during authenticated sessions. Switching IPs mid-session breaks session cookies on sites that bind cookies to the originating IP. This is a silent failure mode. Your agent will not throw an exception. It will silently get logged out and then process a login page as if it were the target page, returning garbage data.
not closing browser contexts between rotations. If you want a true IP rotation, you need to close and recreate the browser context. Playwright reuses connections aggressively. If you swap proxy credentials but keep the same browser context open, the old TCP connection may persist for several more requests, defeating the rotation entirely.
ignoring proxy authentication errors. A 407 Proxy Authentication Required response means your credentials are wrong or expired. browser-use will not surface this as a clean, actionable error by default. The agent will see a failed page load and may retry against the same broken credentials in a loop. Add explicit error handling around proxy auth failures before you run any long job.
over-rotating on sticky workflows. Some operators configure aggressive rotation timers assuming more rotation is always better for anonymity. For multi-step workflows, this guarantees session breakage. Set rotation intervals that are longer than your expected task duration plus a reasonable safety margin.
DNS resolver mismatch. Your agent might be exiting from a Singapore IP but resolving DNS through a non-Singapore resolver, which can cause CDN routing mismatches where your request hits a different CDN edge node than Singapore users normally reach. Configure a Singapore-based DNS resolver in your environment if your workflow is sensitive to CDN-level routing differences.

when Singapore IPs specifically matter

Singapore has a specific internet infrastructure profile that makes it distinct from other SEA countries and from generic “Asia residential” proxy pools. SingTel, StarHub, M1, and MVNO providers like Vivifi occupy well-known ASN ranges that major platforms recognize as legitimate Singapore consumer traffic. Sites that serve Singapore-specific content, including local banking portals, government services, regional e-commerce platforms, and Singapore-specific search result variants, use a combination of IP geolocation and ASN lookup to determine what to serve. A US residential IP that claims to be in Singapore via a spoofed header still resolves to a US ASN, and any server doing ASN-level checks will see through it. Real carrier IPs from actual SingTel and StarHub modems do not have this problem because the ASN, the geolocation record, and the routing path all agree.

For browser-use workflows targeting SEA markets more broadly, Singapore is also the most reliable proxy origin because its internet infrastructure is among the most stable in the region. Latency from a Singapore proxy to regional targets in Malaysia, Indonesia, Thailand, and the Philippines is consistently lower than routing from Europe or North America. This matters for agents that have timeouts or that need to interact with real-time features like live pricing or inventory availability checks. If your use case involves regional competitive intelligence or mobile proxies for SEO research, Singapore is the natural anchor point for an SEA proxy fleet. The Cloudflare bot score documentation gives a useful overview of how IP reputation factors into automated traffic scoring, which helps explain why carrier-grade IPs from a specific country consistently outperform generic residential pools when geographic signal is part of the detection model. For teams that also need cloud Android devices to pair with a browser-use agent for full-stack mobile simulation, cloudf.one runs Singapore-based cloud Android phones that complement SMP as an additional layer when you need a complete mobile environment rather than just a mobile IP.

getting started

SMP’s proxy plans, including HTTP and SOCKS5 endpoints on real SingTel, StarHub, M1, and Vivifi modems, are on the Singapore Mobile Proxy plans page. If you are still evaluating whether mobile proxies are the right fit for your specific workflow, the ethical mobile proxy use guide covers which use cases are appropriate and what to check before you automate against third-party sites. The code patterns in this post are enough to wire up a working integration in an afternoon, and the sticky versus rotating distinction is the main configuration decision that will determine whether your agent behaves correctly once it is in production.