Using Singapore mobile proxies with Appium in 2026

If you run Appium against any app with meaningful anti-abuse logic, you have probably already seen the test suite pass locally and fail in CI, or pass on your personal SIM and fail on the emulator. The reason is almost always the IP. App developers in 2026 correlate network type, ASN, geolocation, and carrier metadata as part of their risk stack. A datacenter IP or a VPN tunnel is an immediate signal that something non-human is happening. When your target is a Singaporean app, that problem compounds: the app may geo-fence features to SG carrier IP ranges, run different code paths for residential versus non-residential traffic, or throttle sessions that arrive from outside Southeast Asia entirely. Adding Singapore mobile proxies to your Appium setup is the most direct fix, and this post covers exactly how to do it.

why Appium hits walls without residential mobile IPs

The most common scenario is app testing against a platform that uses IP reputation scoring. Services like Shopee, Grab, and various fintech apps deployed in Singapore route traffic through risk engines that check the ASN of the connecting IP. An AWS or GCP address resolves to a well-known cloud provider ASN and is treated as suspicious by default. Even if the app does not outright block you, it may silently serve degraded responses, skip promotional content, or redirect to a bot-challenge screen that your test never accounts for.

A second problem is geo-fencing at the feature level, not the session level. Some SG apps enable or disable entire screens based on whether the IP resolves to a local carrier. Payment flows, SingPass integrations, and telco-bundled services are the most common examples. If you are testing a checkout flow that triggers carrier billing, the app backend may reject or short-circuit the request the moment it sees a non-SG IP, and your Appium test will hit an error state that never occurs for a real user. Debugging this takes hours because the app gives no explicit error. It just silently drops the flow.

Third: rate limiting is often tiered by IP type. Datacenter IPs and known VPN exit nodes sit in the most aggressive rate-limit bucket by default. If your Appium suite runs 200 sessions per day as part of a regression or a load-profile test, you will burn through datacenter IP allowances in minutes, whereas the same request volume from a residential mobile IP on SingTel or StarHub is treated as normal user traffic. The fix is not to slow down your tests. The fix is to change what IP they originate from.

setting up SMP credentials in Appium

Singapore Mobile Proxy provides HTTP and SOCKS5 endpoints with credentials in the standard host:port:username:password format. The most practical integration point in Appium is at the WebDriver capabilities level, where you configure the proxy before the session starts. For Android automation via UIAutomator2, you pass the proxy through the appium:chromeOptions capability if you need browser-level proxy routing, or you configure it at the ADB/emulator network level if you need system-wide proxy coverage for a native app.

For most native app testing, the cleanest approach is to set the system proxy on the Android device or emulator before the Appium session opens. Here is a working Python example using appium-python-client 3.x:

from appium import webdriver
from appium.options import UiAutomator2Options
import subprocess

SMP_HOST = "proxy.singaporemobileproxy.com"
SMP_PORT = "10000"
SMP_USER = "your_username"
SMP_PASS = "your_password"

def set_device_proxy(serial: str, host: str, port: str):
    """Set HTTP proxy on Android device via ADB before Appium session starts."""
    subprocess.run([
        "adb", "-s", serial,
        "shell", "settings", "put", "global", "http_proxy",
        f"{host}:{port}"
    ], check=True)

def clear_device_proxy(serial: str):
    subprocess.run([
        "adb", "-s", serial,
        "shell", "settings", "put", "global", "http_proxy", ":"
    ], check=True)

options = UiAutomator2Options()
options.platform_name = "Android"
options.device_name = "emulator-5554"
options.app = "/path/to/your.apk"
options.no_reset = True

# SMP endpoints support basic auth in the proxy URL for HTTP proxies
# For SOCKS5 you will need to configure at system level or use a local tunnel
options.set_capability("appium:chromeOptions", {
    "args": [
        f"--proxy-server=http://{SMP_USER}:{SMP_PASS}@{SMP_HOST}:{SMP_PORT}"
    ]
})

DEVICE_SERIAL = "emulator-5554"
set_device_proxy(DEVICE_SERIAL, SMP_HOST, SMP_PORT)

try:
    driver = webdriver.Remote("http://localhost:4723", options=options)
    # your test steps here
    driver.quit()
finally:
    clear_device_proxy(DEVICE_SERIAL)

A few notes on this pattern. The set_capability approach with chromeOptions only covers WebView contexts. For native app traffic you need the ADB-level proxy set before the session, which is what set_device_proxy does. On a real physical device connected over USB, the adb -s flag targets the correct device by serial. On an emulator you use the emulator’s serial as shown.

If you prefer SOCKS5 (which is worth reading about in detail in the HTTP vs SOCKS5 mobile proxies comparison), the standard approach is to run a local SOCKS5-to-HTTP proxy bridge such as microsocks or goproxy, point your Android device at 127.0.0.1:local_port, and have the bridge forward to SMP’s SOCKS5 endpoint with the credentials. This adds one extra hop but gives you SOCKS5’s lower-level protocol coverage for apps that open raw TCP connections rather than standard HTTP.

rotating IPs per request or per session

The decision between rotating and sticky sessions depends entirely on what you are testing. Rotating endpoints assign a new SG mobile IP on every new connection, which is useful when you want each Appium session to simulate a distinct user from a fresh carrier IP. Sticky sessions pin a single IP for the duration of a time window (typically 10 or 30 minutes), which is what you want when a single test session must maintain authenticated state, persist a shopping cart, or complete a multi-step flow that the backend ties to IP consistency.

A common mistake is using a rotating endpoint for a test that involves login, then wondering why the session is invalidated halfway through. The backend sees the IP change mid-session, treats it as a session hijack signal, and forces re-authentication or drops the session entirely. Use sticky sessions for anything that involves user authentication or stateful flows.

SMP provides separate endpoint hostnames for rotating and sticky variants. Switching between them is a one-line change in your config. Here is a minimal wrapper that reads the session type from an environment variable so you can control it per test run without modifying code:

import os

PROXY_MODE = os.getenv("SMP_MODE", "sticky")  # "rotating" or "sticky"

PROXY_ENDPOINTS = {
    "rotating": "rotate.singaporemobileproxy.com",
    "sticky": "sticky.singaporemobileproxy.com",
}

SMP_HOST = PROXY_ENDPOINTS[PROXY_MODE]
SMP_PORT = os.getenv("SMP_PORT", "10000")
SMP_USER = os.getenv("SMP_USER")
SMP_PASS = os.getenv("SMP_PASS")

PROXY_URL = f"http://{SMP_USER}:{SMP_PASS}@{SMP_HOST}:{SMP_PORT}"

Running SMP_MODE=rotating pytest tests/scrape_suite.py gives you fresh IPs per session. Running SMP_MODE=sticky pytest tests/checkout_suite.py preserves IP continuity for your login-and-transact flows. For teams running Appium in CI, this pattern slots cleanly into environment variable injection at the pipeline level without requiring separate test configurations.

three real workflows where this combo wins

testing geo-fenced onboarding flows for SG fintech apps

Several Singapore-based fintech and neobank apps present a different onboarding flow depending on whether the registering device has a SG carrier IP. Features like SingPass MyInfo prefill and local NRIC validation are only shown to users on SG residential IPs. If you are a developer or QA engineer who lives outside Singapore, or if your CI runners sit in a US or EU data centre, these flows are invisible to your automated tests. Pointing Appium at an SMP sticky endpoint gives the emulator the appearance of a SingTel or StarHub mobile subscriber, which surfaces the full onboarding path exactly as a local user sees it.

regression testing Shopee and Lazada SG storefronts

Price, promotion, and product availability on Shopee Singapore and Lazada Singapore differ based on carrier and region. A product available for SG-subsidised purchase under a telco bundle may not appear at all when the session IP is outside SG or on a datacenter range. Automated regression tests that verify storefront rendering, price display, and add-to-cart flows need to run from SG mobile IPs to actually validate what a real customer in Singapore experiences. Using rotating SMP endpoints here means each test session gets a fresh mobile IP from the SG carrier pool, which avoids accumulating session history that might affect personalisation logic in the platform.

load-profile simulation for SG e-commerce checkout

Load testing with Appium is less common than with HTTP-level tools, but it does happen for teams that need to verify checkout resilience under concurrent mobile sessions. If your load test originates from a single datacenter IP or a small VPN pool, the platform’s rate limiter fires almost immediately and your test measures the rate limiter, not the checkout flow. Distributing Appium sessions across a rotating SMP pool means each virtual user presents a unique SG mobile IP, which keeps traffic below per-IP rate-limit thresholds and produces a load profile that actually resembles organic user traffic from Singapore. This is also the workflow most likely to surface geo-specific edge cases like carrier billing prompts that only appear for SG subscribers, which is relevant context in the broader discussion of mobile proxies for SEO research where similar simulation patterns apply.

common pitfalls

user-agent and IP carrier mismatch: if your Appium session sends a desktop Chrome user-agent while connecting from a mobile carrier IP, the backend risk engine may flag the inconsistency. Set a realistic Android mobile user-agent in your WebView capabilities to match the IP type.
rotating IPs mid-session: using a rotating endpoint for a test that involves login or basket state will cause the backend to invalidate the session when the IP changes between requests. Always use sticky endpoints for stateful flows.
not clearing the device proxy after tests: if your test crashes before the finally block runs, the ADB proxy setting persists on the device and breaks the next test run (or your manual testing). Consider a fixture-level teardown that always calls clear_device_proxy regardless of outcome.
proxy auth credentials in logs: Appium logs capabilities including proxy URLs, which means username:password ends up in your test logs in plaintext. Pull credentials from environment variables and configure your CI log scrubber to redact them.
HTTPS certificate pinning blocking proxy traffic: some apps implement certificate pinning, which means they reject traffic from a proxy because the TLS certificate chain does not match the expected pin. Mobile proxies do not bypass certificate pinning. If you hit this, you need to either disable pinning in a debug build or use a Frida-based unpinning script alongside your proxy setup.
assuming datacenter fallback is fine for flaky tests: when a proxy connection fails intermittently, some proxy client libraries fall back to a direct connection silently. In a testing context that means some sessions run on the proxy and some run on your datacenter CI IP, giving you inconsistent results. Fail hard on proxy connection errors rather than allowing fallback.

when Singapore IPs specifically matter

The SEA market has enough platform fragmentation that “any residential proxy” is not an adequate answer for teams targeting Singapore specifically. Indonesian residential IPs, Malaysian residential IPs, and general APAC pools do not satisfy the carrier-level checks that SG apps implement. Grab, for example, operates across Southeast Asia but its Singapore product has separate risk logic tied to local SG carrier ASNs. SingPass integrations check that the connecting session comes from a recognised SG network. Banking apps on DBS, OCBC, and UOB have geo-restriction layers that respond differently to SG carrier traffic versus generic residential traffic from elsewhere in the region. SMP runs real modems on SingTel, StarHub, M1, and Vivifi, which means the ASN, the reverse DNS, and the IP range metadata all resolve as genuine SG mobile carrier infrastructure. Datacenter proxies and US or EU residential pools do not come close to this for SG-targeted work.

There is also a timing dimension. SG carrier IPs have legitimate session histories with the platforms you are testing against. A freshly provisioned datacenter IP has no such history and often sits in a pre-blocked or heavily scrutinised bucket from day one. Understanding this distinction is part of what ethical mobile proxy use looks like in practice: using carrier IPs that reflect the actual network your target users are on, rather than trying to impersonate users from infrastructure that clearly is not theirs.

getting started

If you are ready to add SMP to your Appium pipeline, the Singapore Mobile Proxy plans page covers the available bandwidth tiers and endpoint options. Start with a sticky session endpoint while you get your ADB proxy setup working and your test fixtures handling teardown correctly, then switch to rotating endpoints for the test suites that do not require session continuity. The credential format is standard enough that the code in this post slots into any existing Appium Python or Java setup without restructuring your test architecture.