Using Singapore mobile proxies with Anchor Browser in 2026

If you have been running Anchor Browser sessions against Southeast Asian platforms for more than a few weeks, you have almost certainly hit a wall that pure automation hygiene cannot fix. The fingerprinting is clean. The timings are human-patterned. The browser profile is pristine. And the request still lands on a CAPTCHA or a silent 403. The culprit is almost always the IP. Not the browser, not the automation framework, not the agent logic: the IP. Anchor Browser gives you programmable, AI-steerable browser infrastructure, but it does not change the fact that the egress address attached to your session determines how target platforms classify you before a single DOM event fires. When the workflows are SEA-focused, and especially when they touch Singaporean platforms, swapping to Singapore-carrier mobile IPs is the fix that actually holds.

why Anchor Browser hits walls without residential mobile IPs

Anchor Browser sessions originate from infrastructure IPs or, if you are routing through a standard VPN or datacenter proxy layer, from address ranges that fraud and bot detection systems have catalogued extensively. Platforms like Shopee, Lazada, Grab, and local SG fintech apps maintain their own internal IP reputation databases alongside third-party signals from Cloudflare, DataDome, and PerimeterX. A session arriving from an AWS or GCP subnet, or from a well-known residential proxy pool built on US or EU exit nodes, is not going to look like a Singapore mobile user regardless of how well the browser fingerprint is assembled. The geolocation will mismatch the Accept-Language header, the ASN will flag as hosting infrastructure, and the IP history will show concurrent sessions from the same /24 that no real carrier block ever produces.

The specific failure modes Anchor Browser operators report most often are: soft blocks that return HTTP 200 with an empty or degraded payload (common on price-comparison and product catalogue endpoints), aggressive CAPTCHA injection on the second or third page of a session (a signal that the initial session establishment was accepted but subsequent requests failed the ongoing IP reputation check), and account flags on platforms where the session is authenticated. That last category is particularly painful because the flag often does not surface immediately. The session completes, the agent logic reports success, and the account suspension arrives 24 to 48 hours later as a delayed response to the IP anomaly.

What makes mobile IPs structurally different is not just that they are residential. Carrier-assigned mobile IPs are shared, rotated by the carrier itself, and have a legitimate usage pattern that includes many simultaneous users browsing the same platform from the same IP block. A SingTel or StarHub IP hitting a Shopee login looks exactly like the thousands of other Singaporean users doing the same thing from the same carrier block. The IP reputation baseline is set by real human traffic, which means an automated session from the same block is harder to isolate. This is a fundamentally different trust posture than a datacenter IP with a clean-but-thin history, and it is why the fix needs to be mobile carrier IPs specifically, not just any residential pool.

setting up SMP credentials in Anchor Browser

Singapore Mobile Proxy provides credentials in the standard host:port:username:password format. The host is a fixed gateway address, the port determines whether you get a rotating or sticky session, and the username and password are your account credentials. Anchor Browser accepts proxy configuration at the session creation level, which means you can set a different proxy per session, per agent run, or globally as a default for all sessions in a workspace.

The most direct integration is through the Anchor Browser SDK when you are spinning up sessions programmatically. Here is a minimal Node.js example using the Anchor Browser client:

import Anchor from '@anchorbrowser/sdk';

const anchor = new Anchor({ apiKey: process.env.ANCHOR_API_KEY });

const session = await anchor.sessions.create({
  proxy: {
    type: 'http',
    host: '8.219.x.x',       // your SMP gateway host
    port: 10000,              // rotating port
    username: 'smp_user',
    password: 'smp_pass',
  },
  browserSettings: {
    fingerprint: {
      userAgent: 'Mozilla/5.0 (Linux; Android 14; SM-S928B) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.0.0 Mobile Safari/537.36',
    },
  },
});

const browser = await anchor.sessions.connect(session.id);
// ... your Playwright or Puppeteer page logic

Two things to pay attention to in this config. First, the type field should match the protocol you have enabled on your SMP plan. SMP supports both HTTP and SOCKS5 endpoints on the same credential set, and the port assignment differs between the two. If you are doing anything that involves non-HTTP traffic within the browser session (websockets to an authenticated endpoint, for example), SOCKS5 is the more reliable choice since it proxies at the transport layer rather than the application layer. There is a fuller breakdown of the tradeoffs in the HTTP vs SOCKS5 mobile proxies guide if you need to make that call for a specific workflow.

Second, the user agent in the browser fingerprint needs to match the mobile IP class. This is the single most common misconfiguration. When Anchor Browser defaults to a desktop Chrome user agent but the egress IP is a SingTel mobile block, any platform doing UA-to-IP consistency checks will flag the mismatch. Set a mobile Android or iOS user agent when routing through mobile IPs.

rotating IPs per request or per session

The right rotation strategy depends entirely on whether your workflow is stateful. Rotating the IP mid-session on an authenticated flow (a logged-in account, a multi-step checkout, an agent filling out a form) will almost always break the session. Platforms bind session tokens to the originating IP, particularly on mobile-classified traffic where carrier IP changes are less expected than they are in a desktop browsing context. If the IP changes between the login POST and the subsequent authenticated GET, the session token is invalidated or the account is flagged.

For stateful workflows, use sticky sessions. SMP sticky sessions hold the same exit IP for a configurable duration (the standard is 10 to 30 minutes depending on plan). Create one Anchor Browser session per sticky proxy credential, run the full workflow, then tear the session down. When you create a new session for the next account or the next run, you can request a fresh sticky IP by cycling to a new sticky port or using SMP’s session reset mechanism described in your dashboard.

For stateless workflows (bulk SERP checks, product catalogue scraping, availability polling), rotating per request or per page load is usually fine and gives you a broader spread across the carrier IP pool. Here is how that looks when you are managing a small pool of Anchor sessions and want to round-robin fresh IPs across them:

const STICKY_PORTS = [10001, 10002, 10003, 10004, 10005];

async function createRotatingSession(index) {
  const port = STICKY_PORTS[index % STICKY_PORTS.length];
  return anchor.sessions.create({
    proxy: {
      type: 'http',
      host: '8.219.x.x',
      port,
      username: 'smp_user',
      password: 'smp_pass',
    },
  });
}

Each sticky port on SMP maps to a distinct exit IP for the duration of the session. By cycling ports across concurrent Anchor Browser sessions you get IP diversity without triggering the mid-session IP change problem. When a session ends and you reuse the same port for a new session, SMP issues a new exit IP, so you are not replaying the same IP for unrelated tasks.

Do not use the rotating (non-sticky) endpoint for workflows where any two requests in the same logical task need to appear co-located. Even if your agent logic does not maintain explicit session state, platforms correlate requests within a short time window, and a sudden IP change between page 1 and page 2 of a product search is an anomaly signal.

three real workflows where this combo wins

monitoring SEA e-commerce pricing and availability

Price and availability endpoints on Shopee SG and Lazada SG return different data depending on the detected country of the visitor, and both platforms have become significantly more aggressive about serving degraded or sanitised data to non-SG IPs since 2024. An Anchor Browser agent running product monitoring against these platforms from a US residential pool will get redirected to regional variants, receive pricing in local currency adjusted for non-SG audiences, or simply receive a bot challenge on repeated polling. Routing through SingTel or StarHub IPs fixes all three of these failure modes because the platform’s geo-detection correctly identifies the session as a Singapore visitor and serves the canonical SG storefront. The data the agent receives is the same data a Singaporean consumer sees, which is the data you actually need if you are doing competitive pricing analysis or availability tracking for SG market inventory decisions.

AI agent testing against SG government and financial platforms

Operators building AI agents that assist users with SingPass workflows, CPF-adjacent tools, or local banking apps face an unusual IP requirement: these platforms are often explicitly geo-fenced to Singapore IPs at the infrastructure level, not just at the content level. A session from a non-SG IP will receive a block before any browser fingerprinting even matters. Singapore Mobile Proxy’s use of real carrier-assigned SG IPs satisfies this hard geo-fence requirement in a way that “Singapore datacenter” IPs increasingly do not, since the major SG financial platforms have added carrier-type checks that distinguish residential mobile, residential broadband, and datacenter ASN classifications. For agents doing regression testing, UX validation, or accessibility audits of SG-regulated platforms, this is the only class of proxy that consistently gets through.

Managing multiple Telegram, WhatsApp Business, or TikTok accounts from a single Anchor Browser deployment requires that each account session originates from a distinct, plausible IP with no cross-contamination in IP history. These platforms use IP-to-account association as a primary signal for coordinated behaviour detection. A pool of SG mobile IPs gives each Anchor Browser session an IP that is genuinely distinct at the carrier level, comes with the legitimate shared-use history of a real SG carrier block, and does not appear in the ASN history of the other sessions in your pool. This is different from datacenter IPs where the entire /24 is often flagged together once any one IP in the block is associated with policy violations. The carrier IP model means IP reputation is largely isolated per-account rather than contagious across your deployment.

common pitfalls

user agent and IP class mismatch: routing through a mobile carrier IP while presenting a desktop Chrome UA is the fastest way to get flagged. set a mobile user agent in Anchor Browser’s fingerprint config whenever you are on a mobile proxy.
rotating IPs inside authenticated sessions: do not use the rotating endpoint for any workflow where a session token was established. the IP change invalidates the session on most platforms. use sticky sessions for anything that involves a login step.
ignoring SOCKS5 for websocket-heavy workflows: HTTP proxies intercept and re-encode traffic in ways that can break websocket handshakes or cause unexpected behaviour with streaming responses. if your Anchor Browser agent is interacting with a platform that uses websockets for real-time features (chat, live inventory updates, live bidding), switch to SOCKS5.
not matching the geolocation header to the proxy IP: some Anchor Browser integrations allow you to set explicit geolocation permissions for the browser context. if you set geolocation to a non-SG coordinate while the IP resolves to Singapore, platforms that cross-reference the two (mapping apps, delivery platforms, anything with location-based pricing) will see an inconsistency. set the geolocation to a SG coordinate when using SG IPs.
reusing the same sticky port across unrelated accounts: if two accounts are both routed through the same sticky port in the same session window, they share an IP. platforms looking for account linkage will find it. use one sticky port per logical account identity.
not accounting for carrier IP rotation at the infrastructure level: mobile carrier IPs are reassigned by the carrier periodically. SMP manages this transparently, but it means that a sticky session IP today is not the same IP that was used in a previous run against the same platform. if your automation logic assumes the IP is persistent across runs (for allowlisting, for example), you need to account for this. use IP allowlisting strategies that handle dynamic IPs.

when Singapore IPs specifically matter

The SEA internet is not a monolith and SG-specific IPs are not interchangeable with other Southeast Asian IP blocks for most high-value Anchor Browser workflows. Singapore-based platforms, particularly in e-commerce, fintech, and government services, segment their user experience at the IP level in ways that go beyond simple geo-redirect. Shopee SG and Lazada SG serve different seller inventories, different promotional pricing, and different logistics options to SG IPs versus MY, ID, or PH IPs even when the consumer-facing URL is the same. An Anchor Browser agent that needs to see the SG-specific version of that experience needs a SG IP, and specifically a SG mobile carrier IP given how these platforms now weight the carrier-type signal in their personalisation and fraud stacks.

Beyond platform segmentation, there is a growing class of SG regulatory and compliance contexts where carrier-class SG IPs are effectively mandatory. MAS-regulated financial platforms, SingPass-authenticated services, and several large SG enterprise SaaS products that proxy external APIs through SG-residency checks all apply ASN-level validation that excludes datacenter IPs including major cloud providers running SG regions. Anchor Browser operators building agents for these environments have found that the only proxy class that consistently satisfies these checks is a real SG carrier block. SMP’s infrastructure runs on physical SingTel, StarHub, M1, and Vivifi modems, which means the ASN and carrier metadata that these platforms inspect reflects genuine SG mobile network assignment rather than a cloud instance with a SG geolocation tag.

If you are evaluating whether your Anchor Browser workflows fall into this category, the reliable test is to check whether your sessions behave identically from a SG mobile device on a local SIM versus from your current proxy. If there is a divergence in what the platform serves, serves faster, or allows, the IP class is the variable. As platforms in the SEA region have matured their bot detection, mobile proxies for SEO research and broader automation use cases have increasingly required carrier-level IP accuracy rather than just regional accuracy.

getting started

SMP offers plans sized for both low-volume testing and high-throughput production deployments. The plans page covers the current bandwidth tiers and sticky session options. If you are new to mobile proxies and want to understand the underlying mechanics before committing to a configuration, the ethical mobile proxy use guide covers the operational and compliance considerations worth keeping in mind before scaling any browser automation workflow. The setup from the credentials section above is enough to get a working Anchor Browser session running against SG platforms, and from there the main tuning work is matching sticky versus rotating endpoints to your specific workflow’s session state requirements.