Using Singapore mobile proxies with undetected-chromedriver in 2026

if you have been running undetected-chromedriver for a while, you have probably noticed the tool buys you less headroom than it did two or three years ago. the patching it does to Chrome’s automation fingerprint still works. but the sites that matter most have shifted their detection weight toward the network layer. the question is no longer just “does this browser look like a human drove it?” it is also “does this IP belong to a human who plausibly lives near the content being requested?” for operators targeting Singapore, Southeast Asia, or any platform that treats SG carrier traffic as a trust signal, that shift changes everything. this post covers exactly how to wire Singapore Mobile Proxy into undetected-chromedriver, when to rotate versus stick, and the three workflow classes where the combination actually changes outcomes.

why undetected-chromedriver hits walls without residential mobile IPs

the core promise of undetected-chromedriver is that it strips or masks the JavaScript-level tells that Selenium leaves behind: navigator.webdriver, the CDP exposure on certain ports, the way Chrome registers automation extension presence, and similar markers. those patches remain effective. but in 2026, the fraud and bot-detection vendors that power the platforms most worth scraping have layered IP reputation scoring deeply into their decision trees.

datacenter IPs, including the big residential-looking pools that run on cloud VMs, carry risk scores derived from years of abuse data. an IP that has ever appeared in a credential-stuffing spray, a scrape campaign, or a captcha farm ends up with an elevated score that follows it for months. when your undetected-chromedriver session hits a Cloudflare challenge, a Recaptcha v3 score wall, or a soft 429 that never becomes a hard block, the browser fingerprint is often not the cause. the IP reputation is. you can patch Chrome all you like and the session still dies because the egress address is already in a blocklist.

VPN IPs have the same problem, and often a worse one. commercial VPN exit nodes are trivially identified by ASN: they belong to a small set of hosting providers that have been catalogued. even if the IP itself is clean, the ASN membership is enough for a site to apply a challenge or a silently degraded experience. for workflows that depend on seeing the same page content a real Singapore user sees, that degradation is invisible and destructive. you get a 200 OK, you parse the page, and you have scraped the rate-limited or geo-modified version of the content without knowing it. SG carrier IPs on real SingTel, StarHub, M1, or Vivifi modems do not have this problem because they share ASNs and IP ranges with millions of legitimate Singapore mobile users.

there is also the fingerprint-coherence problem specific to undetected-chromedriver. the tool typically runs a desktop Chrome build. if you pair that with a residential mobile IP, the IP’s carrier metadata (visible to the site via HTTP headers and inferred from the ASN geolocation) implies a mobile device, while the browser profile implies a desktop. some detection systems flag this mismatch as low confidence but still assign friction. you can address this with careful user-agent selection, which we cover in the pitfalls section. the point is that the IP layer and the browser layer need to be coherent, and getting the IP layer right is the harder problem.

setting up SMP credentials in undetected-chromedriver

Singapore Mobile Proxy delivers HTTP and SOCKS5 endpoints. for undetected-chromedriver, HTTP proxy is the path of least resistance because Chrome’s --proxy-server flag handles it natively without additional subprocess wiring. SOCKS5 is also supported but requires a slightly different flag syntax and has historically had more variance across Chrome versions. if you want to understand the tradeoff in depth, the HTTP vs SOCKS5 mobile proxies breakdown covers the transport differences well.

SMP credentials come in the format host:port:username:password. you will receive these from your dashboard after you pick a plan. the integration with undetected-chromedriver uses Chrome options to inject the proxy, and a separate Chrome extension to handle authenticated proxy credentials, since Chrome dropped support for --proxy-auth on the command line some years back.

here is a working pattern. the extension approach is the reliable one in 2026:

import undetected_chromedriver as uc
import zipfile, os

PROXY_HOST = "sg.example-smp-host.com"  # your SMP endpoint host
PROXY_PORT = 12345                        # your SMP endpoint port
PROXY_USER = "your_username"
PROXY_PASS = "your_password"

def make_proxy_extension(host, port, user, password):
    manifest = """{
  "version": "1.0.0",
  "manifest_version": 2,
  "name": "proxy_auth",
  "permissions": ["proxy", "tabs", "unlimitedStorage", "storage",
                  "<all_urls>", "webRequest", "webRequestBlocking"],
  "background": {"scripts": ["background.js"]},
  "minimum_chrome_version": "22.0.0"
}"""
    background = f"""
var config = {{
    mode: "fixed_servers",
    rules: {{
        singleProxy: {{
            scheme: "http",
            host: "{host}",
            port: parseInt("{port}")
        }},
        bypassList: ["localhost"]
    }}
}};
chrome.proxy.settings.set({{value: config, scope: "regular"}}, function() {{}});
function callbackFn(details) {{
    return {{
        authCredentials: {{
            username: "{user}",
            password: "{password}"
        }}
    }};
}}
chrome.webRequest.onAuthRequired.addListener(
    callbackFn,
    {{urls: ["<all_urls>"]}},
    ["blocking"]
);
"""
    ext_path = "/tmp/smp_proxy_ext.zip"
    with zipfile.ZipFile(ext_path, "w") as zf:
        zf.writestr("manifest.json", manifest)
        zf.writestr("background.js", background)
    return ext_path

ext = make_proxy_extension(PROXY_HOST, PROXY_PORT, PROXY_USER, PROXY_PASS)

options = uc.ChromeOptions()
options.add_extension(ext)

driver = uc.Chrome(options=options, version_main=124)
driver.get("https://ipinfo.io/json")
print(driver.page_source)
driver.quit()

a few things to keep in mind with this pattern. the extension zip is written to /tmp and reused across sessions. if you are running concurrent sessions, write unique paths per worker. the version_main argument should match your locally installed Chrome; undetected-chromedriver will patch that specific version’s binary. a mismatched version is the most common source of immediate crashes.

rotating IPs per request or per session

the choice between rotating and sticky sessions depends entirely on what your workflow needs the browser state to do.

sticky sessions hold the same exit IP for a configurable window, typically 10 to 30 minutes depending on the plan. use sticky sessions whenever you are doing anything that involves login state, cart state, or multi-step form flows. if you rotate the IP mid-session, the server sees a coherent cookie but an entirely different egress address. that is a strong fraud signal on most platforms. for account management workflows, checkout flows, or anything that touches a session cookie you care about, sticky is the right mode.

rotating endpoints assign a new IP on each connection or on each HTTP request, depending on how the endpoint is configured. use rotation for high-volume collection tasks where each request is stateless: SERP scraping, price monitoring, public API polling, or any workflow where you are not carrying session state between requests. rotating through real SG carrier IPs for this kind of work means your request stream looks like it is coming from a realistic cross-section of Singapore mobile users rather than a single source.

SMP provides separate hostnames or port ranges for rotating versus sticky sessions. you switch modes by changing the endpoint you point the extension at. here is a minimal example that rebuilds the extension between sessions to swap from sticky to rotating:

import time

def run_session(proxy_host, proxy_port, proxy_user, proxy_pass, url):
    ext = make_proxy_extension(proxy_host, proxy_port, proxy_user, proxy_pass)
    options = uc.ChromeOptions()
    options.add_extension(ext)
    driver = uc.Chrome(options=options, version_main=124)
    try:
        driver.get(url)
        time.sleep(2)
        return driver.page_source
    finally:
        driver.quit()
        os.remove(ext)

# sticky session endpoint for a login flow
result = run_session(
    "sticky.your-smp-endpoint.com", 12345,
    "your_username", "your_password",
    "https://target-site.sg/account"
)

# swap to rotating endpoint for bulk collection
for product_url in product_urls:
    result = run_session(
        "rotate.your-smp-endpoint.com", 12346,
        "your_username", "your_password",
        product_url
    )

in practice, most operators run two pools: a sticky pool sized to however many concurrent authenticated sessions they manage, and a rotating pool for high-throughput stateless collection. the sticky pool is smaller and more expensive per port. the rotating pool is where volume lives.

three real workflows where this combo wins

Singapore SERP and local pack monitoring

Google’s local search results for Singapore queries are heavily geo-gated. what a user in Singapore sees for “best broadband plans sg” or “tuition centre near me” is meaningfully different from what the same query returns from a US or EU IP, and different again from a Singapore datacenter IP. datacenter IPs get the generic international SERP. real SG carrier IPs get the local pack, the localized ad inventory, and the Singapore-specific featured snippets. for any operator doing mobile proxies for SEO research, this is not a marginal difference. it is the difference between collecting the actual competitive landscape and collecting a synthetic one. undetected-chromedriver is a natural fit here because Google’s bot detection is aggressive enough that headless requests without browser fingerprint patches get challenged almost immediately.

Shopee and Lazada SG price and inventory scraping

Shopee Singapore and Lazada Singapore both apply geo-fenced pricing and inventory logic. a product may be listed as out of stock for non-SG requests while showing available for SG users. flash sale prices are sometimes only rendered to users whose IP resolves to Singapore. both platforms also run bot detection that has evolved significantly: they check the browser fingerprint, the TLS fingerprint, and the IP reputation independently. undetected-chromedriver handles the browser layer. real SingTel or StarHub IPs handle the network layer. the combination gets you through both checks and delivers the SG-specific content that actually reflects what local buyers see.

account warming and multi-account management for SG platforms

operating multiple accounts on Singapore-specific platforms, whether for legitimate A/B testing, agency management, or platform research, requires that each account’s login history comes from plausibly different and realistic IP origins. platforms flag accounts that share egress IPs, particularly when those IPs belong to datacenters. real SG mobile IPs on different carriers (SingTel versus StarHub versus M1) look like different humans in different parts of Singapore. for this workflow, sticky sessions are mandatory: you assign each account a sticky endpoint and keep it consistent across the account’s session lifetime. rotating mid-account is exactly what gets accounts flagged or suspended. done correctly, this workflow is also where it is worth reviewing ethical mobile proxy use to make sure your automation stays inside platform terms and applicable law.

common pitfalls

user-agent and IP class mismatch: a real SG mobile IP implies a mobile device. Chrome’s default user-agent string reports a desktop. some platforms score this mismatch as suspicious. set a realistic Android or iOS user-agent string in your Chrome options to match the IP class. do not use a user-agent that implies a browser version significantly older than your patched Chrome binary.
rotating IPs mid-session: rebuilding the proxy extension and relaunching Chrome mid-session destroys the browser’s cookie jar and local storage. if you need to rotate IPs, close the session cleanly first. never rotate the proxy underneath a running browser instance; the in-flight requests will fail and the site may flag the IP change as an anomaly.
geolocation API conflicts: some workflows use --disable-geolocation or override the Geolocation API via CDP. if the IP resolves to Singapore but the Geolocation API returns a spoofed non-SG location, that inconsistency is detectable. either let the IP determine the geolocation naturally or override both consistently.
extension reload on Chrome restart: undetected-chromedriver restarts Chrome internally during its patching process on some configurations. if the proxy extension is loaded before that restart, it may not survive. load the extension after the patching cycle completes, or use the driver_executable_path argument to point at a pre-patched binary.
concurrent session limits: SMP plans have a concurrency limit tied to the number of ports or modems on your plan. spawning more Chrome instances than you have proxy ports means some sessions will queue or fail. size your worker pool to your plan’s port count.
ignoring the exit IP verification step: before running any real workflow, always verify the egress IP by loading a JSON IP-check endpoint in the browser. skip this and you risk running a full scrape job through your real IP because the extension failed to load silently.

when Singapore IPs specifically matter

there is a class of platforms and services where “any residential IP” is not good enough and the carrier origin of the IP is the variable that matters. Singapore is one of the most concentrated examples of this. the major local platforms, including government digital services, banking apps, and dominant e-commerce players, have trained their fraud models on SG carrier traffic. SingTel, StarHub, and M1 ASNs appear in enormous volumes in their legitimate user traffic. when your request arrives from one of those ASNs, it slots into a distribution the platform already trusts. a US or European residential IP, even a clean one, falls outside that distribution and gets treated with more friction.

for SEA market entry research, competitor analysis, and any work where you need to see what a real Singapore user sees, the IP origin is not a proxy for authenticity. it is the authenticity. platforms render different ad formats, different pricing tiers, different content recommendations, and different compliance notices based on the inferred country and carrier of the requestor. a researcher using a non-SG IP is studying a counterfactual. the SG mobile proxy collapses that counterfactual and gives you access to the actual user experience.

getting started

if you are already running undetected-chromedriver and the integration above makes sense, the next step is picking a plan that matches your concurrency needs. the Singapore Mobile Proxy plans page breaks down the options by port count and session type. for most scraping and monitoring workflows, a rotating plan is the right starting point. for account management or anything session-heavy, look at the sticky session options. if you are coming to mobile proxies for the first time and want more background on what separates them from residential or datacenter pools, the HTTP vs SOCKS5 mobile proxies guide is worth reading before you commit to a protocol choice. the integration above is straightforward once the credentials are in hand, and the IP quality difference from what you are probably using now will be obvious in the first session.