TikTok, Shopee, and Lazada in Singapore - the mobile proxy playbook

TikTok, Shopee, and Lazada all treat foreign and datacenter IPs as hostile by default. if you’re running a Singapore brand, a local storefront, or multi-account operations targeting SG customers, you need traffic coming out of real SingTel, StarHub, or M1 mobile IPs. anything else has you fighting the platform instead of using it.

this guide is the long version of that statement. it covers why each platform geo-gates and bot-detects the way it does, what breaks without a Singapore mobile proxy, how to configure a clean stack for each of the three platforms, the operational discipline that separates accounts that last from accounts that get flagged in week two, and an honest look at what a proxy does and does not solve.

if you’re new to mobile proxies and want the conceptual grounding first, what is a mobile proxy and why does it matter is the right primer. come back here after.

why Singapore mobile IPs specifically

Singapore is the cleanest base in SEA for three reasons. first, SingTel, StarHub, and M1 all have strong IP reputation on TikTok, Shopee, and Lazada because their subscriber base is mostly legitimate consumers doing everyday things. second, all three platforms treat Singapore as a premium market, which means SG-IP traffic gets more inherent trust and better default placements. third, Singapore is the regional HQ for almost every SEA brand, so the platforms expect to see SG traffic doing operational work including posting content, running ads, and managing catalogs.

a real Singapore mobile IP looks identical to someone scrolling TikTok on the MRT home. that is the traffic these platforms are built to serve, and the traffic their detection stacks are specifically built to not interfere with.

contrast that with the alternatives. datacenter IPs from AWS Singapore or GCP asia-southeast1 are recognized instantly. the ASN is commercial hosting, not a consumer carrier, and every serious platform flags that class of IP for elevated scrutiny. residential proxies solve the ASN problem but introduce new ones: the exit node pool rotates, the “Singapore residential” label on a peer-to-peer network sometimes means a Singapore VPN user with a foreign upstream, and the session continuity you need for seller accounts is hard to maintain when your IP changes every 2 minutes. mobile IPs from real SIM cards on SingTel, StarHub, or M1 do not have either problem. the carrier, the city, and the reputation are all verifiable and consistent.

how TikTok, Shopee, and Lazada actually detect you

the three platforms share a common detection philosophy: they are not trying to catch bots, they are trying to verify that a session is consistent. a real user has a consistent IP country, consistent device fingerprint, consistent timezone, consistent browsing pattern, and consistent history. when any of those signals conflict, the platform asks questions. when multiple signals conflict, the platform acts.

the signals, roughly in order of weight on these three platforms:

IP type and ASN. the first gate is whether your IP resolves to a consumer carrier or a hosting provider. a SingTel mobile IP resolves to SingTel’s ASN. an AWS IP resolves to Amazon’s ASN. the platforms know every major hosting ASN by heart, they deal with the same abuse sources every day.

IP country. after the ASN check, the country matters. a Singaporean seller with a Malaysia IP is a flag. the content feed, the pricing layer, the seller tools, and the risk engine all key off this.

device fingerprint. TikTok is especially aggressive here. browser fingerprint includes canvas hash, WebGL hash, audio context hash, screen geometry, timezone, installed fonts, language and its regional variant, and hardware concurrency. Shopee and Lazada run similar fingerprint checks on login and on sensitive operations. mismatching a Singapore IP with a fingerprint that reports UTC+8 as “Kuala Lumpur” and language as “en-MY” is a signal.

behavioral pattern. real users have context. they landed somewhere before opening a product page, they scroll at human speed, they read before clicking, they browse intermittently not in machine-regular intervals. automation signatures are detectable partly from timing distributions alone.

session history. older accounts with consistent history get more benefit of the doubt than new accounts. this makes account warming and the first 2-4 weeks of a new account’s life the highest-risk window.

a clean Singapore mobile IP solves the first two gates automatically and makes the third easier. you still need to handle the fingerprint layer and the behavioral layer, but you remove the biggest single cause of flags, which is an IP that does not match the account’s claimed identity.

why mobile beats datacenter and residential for these platforms

this comparison comes up constantly, so here it is in table form:

the cost point is worth dwelling on. mobile proxies are more expensive per IP than datacenter or residential. the economics only make sense if you are doing work where the quality of the IP matters enough to pay the difference. for TikTok account management and Shopee or Lazada seller operations, it does. for bulk scraping of public product listings where you cycle IPs anyway, a residential pool may be more efficient. case studies of mobile proxies in scraping and account work covers the tradeoff with real operational context.

TikTok: the account reach problem

TikTok runs some of the most aggressive device and network fingerprinting in any consumer app. the failure mode for Singapore brands is usually not a hard ban. it is silent suppression: the account posts, the views never come, and you realize three weeks later that every video is stuck at 200 views regardless of quality.

what TikTok checks on every session:

• IP country: must match your content region. a Singapore account posted through a Malaysia VPN gets routed into the Malaysia feed regardless of targeting settings
• IP type: datacenter IPs from AWS, GCP, and OVH are filtered hard. mobile IPs from local carriers pass
• device fingerprint: browser canvas hash, timezone, language, screen size, GPU renderer. must be internally consistent and must match the claimed country
• behavior pattern: real users scroll before they post, not the other way. pure automation is detectable from timing alone, and TikTok’s model is trained on an enormous amount of real behavior

with a dedicated Singapore mobile IP, the IP country and IP type checks pass automatically. you still need browser isolation and human pacing, but you remove the single biggest cause of silent shadow-banning before you even touch content quality.

use cases that work well with SG mobile IPs on TikTok:

multi-account brand management. agencies and content farms running multiple TikTok accounts for different SG brands need each account on its own dedicated IP with its own fingerprint. TikTok links accounts that share IPs, so if three brand accounts all route through the same proxy port, the platform treats them as related and applies risk scores accordingly. one IP per account, no sharing, is the operational rule.

TikTok Ads verification. ad teams need to see their own creatives in the Singapore feed as a real viewer would see them. ad verification from a VPN or datacenter IP returns a different signal: the ad may not serve at all, or may serve a different creative variant. a Singapore mobile IP lets the ad team see exactly what SG users see.

TikTok Shop seller accounts. TikTok Shop has stricter geo-requirements than the content platform. the seller dashboard is region-locked, and some features including live shopping and local shipping integrations only work cleanly from SG IPs.

TikTok Live considerations. if you are running live selling sessions for a Singapore audience, the stream needs to be associated with a Singapore IP from the start of the session. switching mid-stream is possible but can cause feed routing issues. open the live dashboard, confirm the session is on the Singapore mobile IP, then go live.

content creator agencies. running 10 or 20 creator accounts for SG clients from a single machine requires strict IP separation. each account gets a dedicated port, one profile in an antidetect browser, and that combination stays consistent. the accounts should never share an IP, not even briefly during testing.

Shopee: login loops and bulk-action throttling

Shopee is more aggressive than TikTok on session-level detection. a Shopee seller account accessed from a datacenter IP hits identity verification within the first login. try to run bulk listing edits from the same setup and the account gets temporarily locked within hours. for cross-border or resale operations managing multiple Shopee SG stores, this is a hard operational block.

Shopee personalizes at almost every layer:

• pricing and currency: SGD prices, SG-specific vouchers, local seller surcharges, SG shipping thresholds
• promotions: SG-only flash sales, platform credits, shipping rebates tied to SG postal codes
• search results: SG sellers ranked higher for SG buyers than cross-border equivalents
• seller tools: some bulk-edit and campaign features only unlock from SG IPs, particularly around SG-specific campaigns like 11.11 and 12.12

with a Singapore mobile proxy, your Shopee seller sessions come from the same IP class as every real SG buyer. that removes the verification friction and lets you run bulk operations at normal seller speed.

for scraping Shopee SG pricing, the SG IP also matters because a scrape from any other country returns different prices, different promotions, and different seller rankings. the data is simply wrong for the SG market if you collect it from a non-SG IP. pricing intelligence, competitor rank monitoring, and category analysis all need to be done from a Singapore IP if they’re meant to reflect what SG buyers actually see.

Shopee ToS note. Shopee’s terms of service prohibit automated scraping of their platform. scraping for your own seller intelligence, like monitoring your own category for price changes, sits in a gray area that most sellers practice. scraping competitor catalogs at scale for data resale or to undercut systematically is the kind of thing Shopee actively defends against. this guide is not endorsing ToS violations. use scraping for internal intelligence and test volumes before you scale.

Lazada: ranking, badges, and competitive intel

Lazada works similarly to Shopee on the detection side, but the personalization layer is where SG mobile IPs really pay off. Lazada adjusts seller badges, fulfillment tags, shipping estimates, and ranking boosts based on the buyer’s claimed country. competitive pricing intelligence done from a non-SG IP returns a different ranking order than what Singapore buyers actually see. your competitor analysis is based on a phantom view of the platform if you’re running it from the wrong country.

common Lazada workflows that benefit from a SG mobile proxy:

competitive monitoring. scrape top-ranked sellers in your category from an SG IP to see real SG rankings, real badge placements (LazMall, Preferred Seller, local vs cross-border tags), and real shipping estimates. the same product on Lazada has a different effective position depending on whether Lazada is showing it to an SG buyer or a foreign one.

LazMall seller operations. bulk product updates, campaign enrollment, voucher creation, and promo-slot applications all go through the seller center. logging in from a consistent Singapore mobile IP prevents the re-verification and 2FA prompts that hit seller accounts flagging as unusual.

storefront QA. load your own shop as a real SG buyer sees it, including dynamic badges, trust signals, shipping estimates, and the SG-specific promotions panel. design and content decisions made from a foreign IP may not reflect the experience your actual customers have.

Lazada Ads verification. confirm your sponsored placements are live for SG impressions and appearing in the right positions. same principle as TikTok Ads verification: you need to see what the local audience sees.

Lazada ToS note. same caveat as Shopee. automated scraping is prohibited. the practices above (competitive intel, storefront QA, ad verification) sit in a practical gray area that most professional sellers operate in. high-volume catalog scraping for data resale is a different category and carries more legal and ToS risk.

multi-account selling: the operational rules

running multiple seller accounts on any of these three platforms requires understanding how the platforms link accounts and what isolation discipline looks like in practice.

one IP per seller identity. this is the foundation. if two Shopee accounts share the same IP in the same session window, Shopee links them. once linked, a violation on one account exposes both. on TikTok the same logic applies but the linking heuristics are faster, they also look at device fingerprint, so even two accounts on two different IPs but the same browser profile are vulnerable. on Lazada the IP-linking threshold seems higher but it still applies.

what “dedicated” means in practice. a dedicated Singapore mobile proxy gives you one IP that is yours alone. no sharing with other customers. that IP does not appear on any other account’s session history because no other account uses it. when account A logs in, only account A’s history is on that IP. this is the meaningful difference between a dedicated port and a shared residential pool.

browser profile isolation. each seller account needs its own browser profile in an antidetect browser. the profile binds a fingerprint (canvas hash, WebGL, fonts, screen size, language, timezone) to the account. the proxy for that profile should be the dedicated Singapore mobile IP for that account. the combination is: account A, profile A, IP A. always. never cross-route.

account creation vs operation. the riskiest moment for a multi-account operation is account creation. creating multiple Shopee or Lazada accounts in rapid succession from the same IP, even briefly while setting up proxies, is a linking signal. each account should be created from its own proxy from the start. registrations do not move between proxies safely, the history follows the account.

the linking graph matters more than individual sessions. platforms think in graphs. if account A ever touched IP X, and account B ever touched IP X, they share a node. if they share other nodes too (device fingerprint, payment method, phone number, email domain), the graph thickens and the risk of cascade-banning when one account is flagged rises sharply. isolation is about minimizing shared nodes, not just about the current session.

warming new seller accounts

new accounts on all three platforms get less benefit of the doubt than established ones. the first two to four weeks of a new account’s life are the highest-risk window. warming is not about gaming the algorithm, it is about establishing a consistent history that makes the account look like a real seller building a business.

practical warming protocol for a new Shopee or Lazada seller account:

1. create the account from the dedicated Singapore mobile IP that will be its permanent home. use the antidetect browser profile that this account will always use.
2. fill out the seller profile completely on day one. profile completion is a basic trust signal.
3. browse the platform as a buyer for the first few sessions. scroll category pages, look at products, add items to cart and wishlist without purchasing. this builds a pre-seller behavioral history.
4. list a small number of products in the first few days. do not upload 200 listings in a 4-hour burst on day two. spread it out.
5. respond to any platform-generated prompts (verification emails, seller onboarding steps) promptly from the same IP and profile.
6. hold off on bulk operations until the account is at least a week old and has had genuine activity.

for TikTok:

1. create the account from the dedicated Singapore mobile IP and the antidetect browser profile.
2. scroll the For You feed for 10-15 minutes on the first session. let the algorithm establish you as a content consumer before you are a content creator.
3. watch videos fully, not just glimpses. the engagement signals in the first few sessions seed the account’s content identity.
4. post the first video organically, not via the API or any automation tool. let it sit for 24 hours before the second post.
5. engage with comments on your first video even if there are only two.
6. hold off on TikTok Shop seller applications until the account has at least 2 weeks of organic content history.

sticky sessions and when to rotate

singapore mobile proxy provides both sticky session ports (same IP held indefinitely) and on-demand rotation. for these three platforms the general rule is:

sticky for account work. a seller account needs the same IP for every session. rotating mid-session or between sessions looks like the account is being accessed from multiple locations, which triggers additional verification on all three platforms. set the sticky port, leave it, only rotate deliberately when you have a reason.

rotate for price scraping. if you are running product scraping at volume, the IP that does the scraping should not be the same IP as the seller account’s identity. use a rotating port for scraping and a separate sticky port for the account. the platforms rate-limit by IP as well as by session; rotating IPs for scraping extends how long you can run before hitting limits.

when to deliberately change a sticky IP. reasons that justify rotating a seller account’s IP: the old IP is degraded or down, you are moving the account to a different device and want a fresh start, or a security review is underway. when you do rotate, expect the platform to trigger a re-verification step. log in from the new IP, complete whatever verification it asks for (email code, SMS, security question), and then maintain the new IP consistently.

the rotation endpoint. with SMP, rotation is triggered via a URL call, not by reconnecting the proxy. your seller account’s sticky port stays connected, you hit the rotation URL to get a new IP on demand when you actually want it. do not accidentally hit the rotation URL during an active session.

device and browser fingerprint hygiene

the IP is one layer. the device fingerprint is another. getting the IP right and ignoring the fingerprint is how accounts get flagged even on clean mobile IPs.

what these platforms fingerprint. browser-based sessions (Shopee and Lazada desktop, TikTok web) collect: canvas fingerprint (a hash of how your GPU renders a specific scene), WebGL renderer string, audio context fingerprint, installed fonts, screen resolution, color depth, timezone and timezone offset, language and its variant, platform string, user agent, browser plugin list, hardware concurrency (logical CPU count), device memory, and touch point count.

native mobile app sessions (TikTok on a real Android or iOS device) collect: device ID (IDFA on iOS, GAID on Android), device model, Android fingerprint string, SIM carrier information, battery state, device sensors, installed app list (on Android), and network type (WiFi vs cellular vs which cellular carrier).

antidetect browser for desktop operations. for Shopee and Lazada seller dashboards and TikTok web, an antidetect browser like Multilogin, GoLogin, or AdsPower creates isolated browser profiles where every fingerprint signal is consistent, spoofed to a believable value, and different between profiles. the profile for account A has fingerprint A, the profile for account B has fingerprint B, and they never cross.

the key settings to configure per profile: - proxy: the dedicated SMP port for that account - timezone: Asia/Singapore (UTC+8) - language: English (Singapore), locale en-SG - screen resolution: a real device resolution, 1920x1080 or 1366x768 are common - WebGL vendor and renderer: should match a real GPU, not “Software Rasterizer” - canvas noise: most antidetect browsers do this automatically - user agent: keep it on a modern Chrome version for Windows or macOS, avoid exotic user agents

for TikTok mobile operations on real Android devices routed through the proxy, the SIM card in the device matters too. a device on SingTel is more consistent than a device on a foreign carrier with a Singapore proxy layered on top.

the timezone trap. this is the most common mistake and one of the easiest to miss. a Singapore mobile IP exits in Singapore, which is UTC+8. but if your browser or device is set to UTC or a different UTC+8 city (Taipei, Kuala Lumpur, Beijing), the timezone name leaks that it is not Singapore. set the timezone explicitly to Asia/Singapore in both the browser profile and in any operating system timezone if you are using a VM or cloud machine.

language variant. Singapore uses en-SG. not en-GB, not en-US, not en-MY. small difference, and most platforms do not penalize wrong English locale heavily, but it is another consistency signal. when everything else is correct, do not leave this one wrong.

step-by-step proxy setup

the setup is the same across the three platforms. once you have a Singapore mobile proxy working for one, the others are essentially copy-paste.

getting your credentials

start a 2-hour free trial to get your proxy credentials. you will receive:

host:     sg1.smp.example.com   (the actual host is on your port page)
port:     45001                 (your dedicated sticky port)
username: your_username
password: your_password
rotation: https://sg1.smp.example.com/rotate/your-token

the sticky port holds the same Singapore mobile IP until you hit the rotation endpoint. the rotation endpoint changes the IP without changing the host, port, or credentials.

antidetect browser setup (recommended for Shopee and Lazada seller work)

using GoLogin as an example, the process is similar in Multilogin and AdsPower:

1. create a new profile for the account you are setting up
2. in the proxy section of the profile, select SOCKS5 and enter: host: sg1.smp.example.com port: 45001 username: your_username password: your_password
3. set timezone to Asia/Singapore
4. set language to en-SG
5. set screen resolution to 1920x1080 or 1366x768
6. do not enable WebRTC (disable it or use fake IP mode in the browser)
7. save the profile and launch it
8. in the opened browser, go to whatismyip.com or ipinfo.io to confirm the IP shows as Singapore and the carrier as SingTel, StarHub, or M1

TikTok on Android via WiFi proxy (for real device sessions)

if you are running TikTok on a real Android device for a more authentic mobile session:

1. go to Settings, then WiFi, long-press your connected network, select Modify Network
2. under Advanced Options, set Proxy to Manual
3. enter your SMP host and port
4. tap Save
5. open TikTok and verify the region by checking what appears in your For You feed (should be SG-heavy content)
6. note: this routes all WiFi traffic through the proxy, not just TikTok. for isolation, either route at the router level for a dedicated device, or use a per-app VPN app that accepts SOCKS5 (ProxyDroid on Android does this)

Python scraping setup for Shopee and Lazada price data

import requests
from requests.auth import HTTPProxyAuth

proxy_host = "sg1.smp.example.com"
proxy_port = 45001
proxy_user = "your_username"
proxy_pass = "your_password"

proxies = {
    "http":  f"socks5h://{proxy_user}:{proxy_pass}@{proxy_host}:{proxy_port}",
    "https": f"socks5h://{proxy_user}:{proxy_pass}@{proxy_host}:{proxy_port}",
}

headers = {
    "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.0.0 Safari/537.36",
    "Accept-Language": "en-SG,en;q=0.9",
}

resp = requests.get(
    "https://shopee.sg/api/v4/search/search_items?keyword=laptop&limit=10",
    proxies=proxies,
    headers=headers,
    timeout=30,
)
print(resp.json())

use socks5h:// (not socks5://) so that DNS resolution happens at the proxy server, not locally. this prevents DNS leaks that reveal your real location even when the HTTP traffic is going through the proxy.

rotating the IP between scrape sessions

import requests

rotation_url = "https://sg1.smp.example.com/rotate/your-token"

def rotate_ip():
    resp = requests.get(rotation_url)
    if resp.status_code == 200:
        print(f"rotated to: {resp.json().get('new_ip')}")
    else:
        print(f"rotation failed: {resp.status_code}")

rotate_ip()
# then run your next scrape batch through the same proxy credentials

for scraping, rotate between batches of requests, not between every single request. rotating too aggressively creates its own pattern. a natural rotation cadence is every 50-200 requests, or every time you complete a category scan.

ad verification and creative testing

ad verification is one of the cleaner use cases for Singapore mobile proxies on these platforms because the objective is simple: see what Singapore users see, in their feed, with their personalization context.

TikTok Ads verification. TikTok’s ad delivery is personalized by region, by device type, and by the audience targeting parameters on the ad. to verify that a sponsored post or in-feed ad is live and serving correctly to SG users:

1. log into a real-looking TikTok account (not a brand account) from the Singapore mobile IP
2. set the account’s region to Singapore
3. scroll the For You feed naturally for a few minutes to let TikTok personalize it
4. the ad should appear if it is live and your account profile matches the targeting

for broader creative testing, where you want to see which creative variant is being served to different audience segments, you need multiple accounts with different profile characteristics (age group, interest signals, engagement history), each on its own Singapore mobile IP.

Shopee and Lazada Ads. both platforms serve sponsored listings that look identical to organic results in the search UI. to verify your sponsored placement:

1. open a browser profile on the Singapore mobile IP that is not your seller account (a buyer account or a clean browser session)
2. search for your target keyword
3. check the first few results for the sponsored tag
4. verify your listing is appearing in the expected position

if your sponsored listing is not appearing, the first diagnostic step is to confirm you are searching from an SG IP and that SGD prices are showing. an SG placement only serves to SG viewers.

price scraping and competitive intelligence

price scraping is where mobile proxies earn their keep for ecommerce operations. the data quality difference between a Shopee SG scrape from an SG IP and a Shopee SG scrape from a US IP is significant: different prices, different promotions, different ranking order, different seller badges, different shipping options.

what to scrape and what not to. scraping public product pages, search results, and category rankings is what most sellers do for competitive intelligence. it is frowned upon in the ToS but ubiquitous in practice. scraping private seller data (order histories, customer data, internal analytics) is a different category and is both a ToS violation and likely a legal issue in Singapore under the Computer Misuse Act. the guide covers the former, not the latter.

practical scraping setup for Shopee SG price monitoring.

import requests
import time
import json

proxy_host = "sg1.smp.example.com"
proxy_port = 45001
proxy_user = "your_username"
proxy_pass = "your_password"

proxies = {
    "https": f"socks5h://{proxy_user}:{proxy_pass}@{proxy_host}:{proxy_port}",
}

session = requests.Session()
session.proxies.update(proxies)
session.headers.update({
    "User-Agent": "Mozilla/5.0 (iPhone; CPU iPhone OS 17_4 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.4 Mobile/15E148 Safari/604.1",
    "Accept-Language": "en-SG,en;q=0.9",
    "Referer": "https://shopee.sg/",
})

def get_category_products(category_id, limit=20, page=0):
    url = f"https://shopee.sg/api/v4/search/search_items"
    params = {
        "by": "sales",
        "catid": category_id,
        "limit": limit,
        "newest": page * limit,
        "order": "desc",
        "page_type": "search",
    }
    resp = session.get(url, params=params, timeout=20)
    time.sleep(2)  # respect the platform, add delays
    return resp.json()

the data you get from an SG IP vs a non-SG IP.

for any competitive intelligence that will drive SG pricing or promotional decisions, the data must be collected from an SG IP. it is not a nice-to-have, the data is genuinely different.

payment and checkout geo-checks

payment and checkout flows on Shopee and Lazada do additional geo-verification. this matters for operations that need to test payment flows, verify voucher redemption, or QA the checkout experience for SG buyers.

Shopee’s checkout geo-checks: - SG-only payment methods (PayNow, Shopee Pay local, GrabPay) only appear for SG sessions - SG-specific shipping options (J&T Singapore, Singpost, Ninja Van SG) tie to SG delivery addresses, which Shopee validates against the session IP - platform vouchers issued for SG buyers are only redeemable in SG sessions - Shopee Coins and credits have SG-specific redemption rules

Lazada’s checkout geo-checks: - LazMall SG sellers have different shipping SLAs for SG buyers vs foreign buyers - SG credit/debit card acceptance and PayNow integration are SG-session-only - free shipping thresholds are SG-specific (SGD values differ from regional thresholds) - promotional bundle pricing often only triggers for SG buyer sessions

if you are doing QA on the checkout experience that SG buyers will have, the session must come from an SG IP. a checkout test done from a VPN or from your home country produces a different experience and may not catch SG-specific bugs.

TikTok live selling considerations

TikTok Live in Singapore has additional requirements beyond regular account management. live selling sessions associate the stream with the IP address that initiates the broadcast, and the content discovery for SG viewers is influenced by that association.

before going live: - confirm the session is on the Singapore mobile IP by checking ipinfo.io in the same browser before opening the live dashboard - verify your TikTok Shop is connected and the seller account is in good standing - test the stream setup (camera, product links, overlay) in a shorter dry-run session before the actual live

during the live session: - do not switch networks or proxies once the stream is live. network change mid-stream causes quality drops and can cause the stream to be misclassified - the live session inherits the session’s IP for its duration. stable connection is more important during live than rotation flexibility

after the live: - review the analytics to confirm the viewer region breakdown. for a Singapore-targeted live, SG viewers should dominate. if they do not, investigate whether the account’s region settings and the IP’s country are fully consistent

live automation. some sellers use overlay management tools or chatbot integrations during live sessions. these tools should be configured with the same SG IP as the seller account, not run from a separate machine on a different IP, otherwise the activity on the account during the live comes from two IP addresses simultaneously, which is a flag.

common mistakes that still get accounts flagged

a clean proxy is necessary but not sufficient. the proxy removes the biggest flag (IP country and type). these are the mistakes that get accounts flagged even on clean mobile IPs:

shared device fingerprints. running 5 seller accounts from the same browser profile, even on 5 separate IPs, tells the platform it is one person. the canvas hash and WebGL hash are the same across all 5 sessions. the platform links them. fix: antidetect browser with one isolated profile per account.

timezone or language mismatch. proxy is Singapore, but the browser reports UTC+8 as “Taipei Standard Time” and language as “en-GB”. small inconsistencies stack up. fix: explicitly set Asia/Singapore as timezone and en-SG as language in every browser profile.

bulk actions from cold sessions. logging in and immediately editing 200 product listings or running 50 ad campaigns is not how real sellers work. a real seller warms up, checks messages, opens the dashboard, then works at human speed. fix: warm the session for 5-10 minutes of normal browsing before bulk operations.

DNS leaks. the browser or OS resolves DNS through the local ISP instead of through the proxy. the proxy handles the HTTP traffic but the DNS queries reveal the real location. fix: use socks5h:// in code-based clients (the h suffix forces proxy-side DNS resolution). in antidetect browsers, enable the proxy DNS option (usually called “resolve DNS through proxy” or similar). in Firefox, go to Settings, Network Settings, Manual Proxy Configuration, tick “Proxy DNS when using SOCKS v5”.

cookie leaks across accounts. logging out of account A in a shared browser and logging into account B in the same browser session carries over cookies and local storage from A. fix: each account in a completely isolated browser profile with separate storage. never reuse profiles between accounts.

IP rotation at the wrong time. rotating the proxy IP during an active seller session triggers re-verification. platforms expect a session to stay on one IP. fix: plan rotation for between sessions, not during them.

payment method linking. using the same credit card or PayNow account across multiple seller accounts on Shopee or Lazada creates an account link that bypasses IP isolation. fix: use different payment methods per seller entity. this is often the last link that causes cascade bans after an account is flagged.

troubleshooting matrix

when something goes wrong, this table maps symptoms to likely causes and fixes:

the universal first check. before debugging the platform, debug the proxy. go to ipinfo.io in the exact browser profile and proxy configuration you are using. confirm three things: the IP is not your real IP, the org field shows a Singapore carrier (SingTel, StarHub, or M1), and the country is SG. if any of these fail, the proxy is the issue. if all three pass, the problem is at the platform or fingerprint layer.

legality and acceptable use

using proxies in Singapore. using a proxy to access Shopee, Lazada, or TikTok is not illegal in Singapore. there is no law that prohibits individuals or businesses from routing their traffic through a proxy server. the Computer Misuse Act covers unauthorized access to computer systems, not the use of proxy infrastructure to access public platforms in a normal way.

multi-account operations. running multiple seller accounts on Shopee or Lazada may violate the platform ToS if you are using them to circumvent per-account limits, engage in sham competition, or manipulate rankings. operating multiple legitimate businesses with separate accounts is generally acceptable. the ToS risk is real and platform-enforced through account bans, not legally enforced.

scraping. scraping public product data (prices, rankings, product descriptions visible to any visitor) is in a legal gray area internationally. Singapore does not have a specific anti-scraping law. the relevant considerations are: does the scraping violate the platform’s ToS (yes, almost always), does it constitute unauthorized access under the Computer Misuse Act (unlikely for public pages, more arguable for rate-limit bypassing or authentication bypass), and does it cause measurable harm to the platform. for internal competitive intelligence at reasonable volumes, the practical risk is ToS enforcement (account bans, IP blocks), not legal action. for large-scale data extraction for commercial sale, consult legal counsel.

our acceptable use policy. SMP proxies are for legitimate business operations: seller account management, ad verification, competitive intelligence, market research. we do not support using the proxies for fraud, credential stuffing, platform manipulation, or any activity that would constitute unauthorized access under applicable law.

the cost math: when mobile proxies make sense

mobile proxy pricing is higher than datacenter or residential proxies per IP. whether it makes sense depends on what you are using it for.

TikTok account management. if a TikTok account runs SG branded content, the reach difference between a suppressed account (wrong IP) and a clean account (SG mobile IP) is substantial. an account getting 200 views per video vs 5,000 views per video for the same content is a real business outcome. the proxy cost is trivially small relative to the value of content distribution.

Shopee and Lazada seller operations. seller account blocks mean lost sales during the downtime and the time cost of re-verification or account recovery. for any seller doing meaningful volume, even one blocked day costs more than a month of proxy subscription.

price scraping and competitive intelligence. the value is in data quality. wrong data from a non-SG IP leads to wrong pricing decisions. the cost math: if one pricing decision (setting a price based on real SG market data vs phantom data) is worth $500 to the business, and the proxy costs $50/month, the ROI question answers itself.

when mobile proxies may not be worth it. bulk scraping of public product data at very high volume where data quality matters less and volume matters more. for that use case, a residential proxy pool may be more cost-effective. the pool absorbs blocks through rotation, and the data quality difference is acceptable if you are sampling at scale rather than doing precise competitive monitoring.

the proxy pool gives an overview of the SG carrier IPs available. dedicated ports are fixed monthly, with plans starting from a few dollars per port. the plans page has current pricing.

FAQ

can I run multiple TikTok accounts from one mobile proxy?

no, and you should not try to. TikTok links accounts that share IPs. two accounts on one IP creates a connection between them in TikTok’s graph. if one account is flagged, the other is more exposed. one dedicated port per TikTok account is the correct setup.

do I need a mobile proxy for just one Shopee seller account?

if you are accessing Shopee from Singapore on a normal home broadband or mobile connection, your IP is already a Singapore residential or mobile IP, and you do not need a proxy for basic access. you need a mobile proxy when: you are accessing from outside Singapore, you are managing multiple accounts and need isolation, or you are doing automated scraping.

will a mobile proxy prevent my TikTok account from getting banned?

it removes the IP-based causes of banning. it does not protect against content violations, ToS violations for the multi-account setup, or platform actions based on behavioral signals. proxy is one layer of a stack, not a guarantee.

what is the difference between HTTP and SOCKS5, and which one should I use?

for browser-based seller operations, either works. SOCKS5 is preferred because it handles DNS through the proxy correctly by default (with the socks5h:// scheme in code), and it is supported by all antidetect browsers. HTTP proxy works fine for basic browser use but some tools and protocols do not support it well. for code-based scraping, use socks5h:// to ensure DNS resolution goes through the proxy server.

can I use a Singapore mobile proxy on a real mobile device, not a browser?

yes. on Android, you can set a WiFi proxy (host and port) under the WiFi network settings, or use an app like ProxyDroid to route specific app traffic through a SOCKS5 proxy. on iOS, WiFi proxy settings support HTTP proxies but not SOCKS5 natively. for iOS, a VPN app that accepts SOCKS5 (or the PAC file approach) is the workaround.

how do I verify the proxy is actually a Singapore mobile IP and not a Singapore datacenter or VPN IP?

go to ipinfo.io while connected through the proxy. the org field should show a mobile carrier: SingTel, StarHub, M1, or their affiliate brands. it should not show “Amazon”, “Google”, “Digital Ocean”, “Limelight”, or any hosting company name. the hostname field may show a carrier-assigned hostname. if any of those check out wrong, the IP is not a genuine mobile carrier IP and the platform-level protection degrades significantly.

how long does a sticky session last?

SMP sticky sessions hold the same IP until you explicitly rotate or the modem IP changes due to a carrier-assigned refresh. typically an IP stays stable for days to weeks. you can trigger a fresh IP at any time via the rotation endpoint when you want a new one. for seller accounts, never rotate unless you have a reason to.

how many accounts can I realistically manage with SMP proxies?

each dedicated port serves one account. if you need 10 isolated TikTok accounts, you need 10 dedicated ports, one per account. each port is a dedicated modem on a real Singapore SIM card. the plans page shows per-port pricing, and at the right volume the cost per account comes down. if you need a large number of ports, the pool shows what is available and you can contact us for volume arrangements.

running a TikTok content agency from Singapore

a TikTok content agency managing accounts for multiple Singapore brands deals with a specific operational challenge that a solo seller does not: scale and separation at the same time. you are responsible for multiple brand identities, each of which must be isolated from the others, while also running workflows efficiently enough to make the operation profitable.

the agency stack. a well-organized TikTok agency handling SG brands typically has:

• one antidetect browser seat per operator or shared via a team plan with profile-level access controls
• one dedicated SMP port per brand account, assigned at the time the account is created and never changed
• a credentials registry mapping brand name, account handle, assigned port, profile ID, and operator
• a content calendar that drives posting timing, so no two brand accounts are posting from the same physical machine in the same 10-minute window (overlap is not a hard ban trigger but it is unnecessary exposure)
• a test account on a separate port used to validate new workflows before applying them to client accounts

content posting workflow. for each brand account:

1. open the antidetect browser profile for that account (it loads the dedicated SMP port automatically)
2. confirm the session is live by checking ipinfo.io, takes 10 seconds
3. open TikTok web or TikTok Studio
4. warm the session for 5 minutes (scroll, watch 2-3 videos fully)
5. upload the video, add the caption and hashtags, set the region to Singapore if the option appears, publish
6. stay in the session for 5 minutes after publishing, engage with any early comments
7. close the profile without logging out (the session stays alive for the next posting window)

scaling across accounts without cross-contamination. the failure mode at scale is context-switching. operator opens brand A’s profile, posts, accidentally opens brand B in the same browser window while brand A is loading, closes brand A’s tab before brand B is fully loaded, which briefly has both sessions active in the same browser process. most antidetect browsers sandbox processes per profile, making this a non-issue, but it is worth confirming that your tool of choice uses separate processes rather than shared memory within a single browser instance.

managing TikTok Ads for multiple brands. TikTok’s Ads Manager is a separate web application from the creator account. for brands that run paid promotion, the Ads Manager account is usually the brand’s business account, which has its own IP association. when the agency team logs into Ads Manager on behalf of a client, they should do so from the same SMP port as the client’s creator account, not from their personal connection. a discrepancy between where the creator account is operated and where the Ads Manager is accessed is a potential flag, especially for new brand accounts still building platform trust.

Shopee seller operations deep dive

beyond the basics, Shopee seller operations have nuances that affect how proxy discipline plays out in daily work.

the Shopee seller center vs the buyer-facing app. Shopee has two separate interfaces: the seller center (seller.shopee.sg) and the buyer-facing app and website (shopee.sg). for operational work, you will use both. the seller center handles listings, orders, promotions, and analytics. the buyer-facing side is where you verify how your storefront appears to customers, including dynamic pricing, badge display, and search ranking. both should come from the same Singapore mobile IP and the same browser profile for an account.

seller center login and 2FA. Shopee requires 2FA on the seller center for security. the 2FA is usually tied to a phone number (SMS OTP) or an authenticator app. this is independent of the proxy. what matters for the proxy is that the session IP is consistent. Shopee flags accounts that log in from a different IP than usual and asks for re-verification. with a sticky SMP port, the IP is always the same and re-verification prompts are rare.

bulk listing operations. Shopee allows bulk CSV uploads for product listings. when uploading a CSV with 500 products, the entire upload session should stay on the same IP. start the upload, let it run, do not switch networks or proxies partway through. Shopee does per-session rate limiting for bulk uploads, and a mid-session IP change can orphan the upload, requiring you to restart from the beginning.

managing flash sale enrollment. Shopee’s campaign slots for flash sales are applied for through the seller center. applications typically open 7-14 days before the event. for sellers managing multiple stores across different Shopee accounts, each account should apply from its own dedicated SMP port. applying for flash sale slots from two different seller accounts from the same IP on the same day raises a flag.

voucher creation and inventory management. creating platform vouchers and adjusting inventory are seller center operations that Shopee monitors for suspicious patterns (creating 50 vouchers in 2 minutes looks automated). add human-realistic delays between actions: 3-10 seconds between clicks, not sub-second machine timing.

Shopee affiliate and referral programs. Shopee has affiliate programs for sellers and for independent affiliates. if you are managing both a seller account and an affiliate account for the same business, run them from different SMP ports and different browser profiles. Shopee explicitly prohibits self-referral, and running both accounts from the same IP makes the connection obvious.

customer message response. responding to buyer messages is one of the seller metrics Shopee tracks (response rate and response time directly affect seller rating). do message responses from the same session you use for other seller work. do not use a separate machine or proxy for messaging while the main seller session is on a different IP; two simultaneous sessions from different IPs on one account is unusual.

Lazada seller center operations deep dive

LazMall vs marketplace sellers. Lazada has two seller tiers: LazMall (brand-owned stores with a stricter vetting process) and the regular marketplace. LazMall sellers get additional trust signals visible to buyers (the LazMall badge, guaranteed authenticity labelling) but are also subject to stricter performance standards and audits. the proxy discipline is the same for both but the consequences of account flags are more severe for LazMall accounts, which can be suspended pending review.

managing Lazada Ads through the seller center. Lazada Ads (sponsored listings) are managed through the seller center’s marketing tab. for campaigns, the typical setup is:

1. log in from the SMP port assigned to this seller account
2. set up the campaign structure: campaign name, daily budget, targeting
3. select products to sponsor
4. set bids at the category benchmark, not at the extreme low or high end initially
5. monitor performance from the same session over the following days

ad management sessions tend to be longer than listing sessions. staying on a stable IP for a 2-hour seller center session is normal behavior, the same way a real seller would sit down and work through their advertising dashboard. no need to worry about session length as long as the IP is not changing mid-session.

Lazada category management and campaign applications. similar to Shopee, Lazada runs platform-wide campaigns (Lazada Birthday Sale, 11.11, 12.12) where sellers can apply for featured placement. application windows open weeks in advance. for sellers managing multiple Lazada accounts for different brands, each account should apply from its own SMP port.

cross-border sellers on Lazada. Lazada SG allows both local Singapore sellers and cross-border sellers (primarily from China, Malaysia, and Thailand) to list on the SG marketplace. for cross-border sellers specifically, routing seller center operations through a Singapore mobile IP makes the session look like a local operator, which affects some of the seller tier classifications and feature access. if you are a cross-border seller running operations from outside Singapore, an SG mobile proxy is the technical bridge to accessing the full SG seller toolset.

API access for Lazada. Lazada provides an official Seller Open Platform API for automated order management, product updates, and reporting. API access is authenticated via OAuth, so the proxy is less relevant for automated API calls (the token carries the authentication, not the IP). however, the API access setup (OAuth authorization, app approval) happens through the web-based seller center and should be done from the SMP port consistent with the account.

competitor intelligence workflows at scale

doing competitive intelligence on Shopee and Lazada is a discipline with its own structure. here is how a systematic competitor monitoring operation looks in practice.

what to monitor and how often.

the data collection setup. for a monitoring operation at this cadence:

1. assign a dedicated SMP rotating port for scraping. this is separate from the seller account port.
2. write category-level scrapers for Shopee and Lazada that pull search results for your target keywords
3. store the raw data in a database with timestamps
4. compute the derived metrics (price changes, rank changes, new entrants) in a separate processing step
5. alert on significant changes (competitor drops price by more than 10%, a new product enters top 10 for your keyword)

rate limiting and respectful scraping. both platforms have anti-scraping infrastructure. adding delays between requests (2-5 seconds minimum between page loads, 30-60 seconds between category scans) reduces the chance of IP blocks and is also more respectful of the platform’s bandwidth. rotating the IP between category scans (not between every request, that looks like its own pattern) further reduces fingerprinting.

structuring requests to look like browser traffic. pure API scraping (hitting the internal JSON endpoints directly) is faster but more obviously automated. browser-emulating requests with full headers (including Referer, Cookie from a real session, Accept-Language, and a modern User-Agent) blend better with real traffic and hold up longer before rate limiting.

import requests
import time
import random

def make_shopee_request(session, url, params=None):
    """make a request that looks like browser traffic"""
    time.sleep(random.uniform(2, 5))  # human-like delay

    headers = {
        "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.0.0 Safari/537.36",
        "Accept": "application/json, text/plain, */*",
        "Accept-Language": "en-SG,en;q=0.9,zh-SG;q=0.8",
        "Accept-Encoding": "gzip, deflate, br",
        "Referer": "https://shopee.sg/",
        "x-api-source": "pc",
        "x-requested-with": "XMLHttpRequest",
    }

    resp = session.get(url, params=params, headers=headers, timeout=20)
    return resp

def get_search_results(session, keyword, page=0):
    url = "https://shopee.sg/api/v4/search/search_items"
    params = {
        "by": "relevancy",
        "keyword": keyword,
        "limit": 60,
        "newest": page * 60,
        "order": "desc",
        "page_type": "search",
    }
    return make_shopee_request(session, url, params)

storing and analyzing the data.

import sqlite3
from datetime import datetime

def init_db(db_path="competitor_intel.db"):
    conn = sqlite3.connect(db_path)
    conn.execute("""
        CREATE TABLE IF NOT EXISTS product_snapshots (
            id INTEGER PRIMARY KEY AUTOINCREMENT,
            scraped_at TIMESTAMP,
            platform TEXT,
            keyword TEXT,
            rank INTEGER,
            seller_name TEXT,
            product_name TEXT,
            price_sgd REAL,
            original_price_sgd REAL,
            rating REAL,
            review_count INTEGER,
            sales_count INTEGER,
            is_sponsored INTEGER,
            badges TEXT
        )
    """)
    conn.commit()
    return conn

def store_results(conn, platform, keyword, results):
    now = datetime.utcnow().isoformat()
    rows = []
    for rank, item in enumerate(results, 1):
        rows.append((
            now, platform, keyword, rank,
            item.get("shop_name", ""),
            item.get("name", ""),
            item.get("price", 0) / 100000,  # Shopee stores in cents * 1000
            item.get("price_before_discount", 0) / 100000,
            item.get("item_rating", {}).get("rating_star", 0),
            item.get("item_rating", {}).get("rating_count", [0])[0],
            item.get("sold", 0),
            1 if item.get("is_advertisement") else 0,
            str(item.get("badge_info_list", [])),
        ))
    conn.executemany("""
        INSERT INTO product_snapshots
        (scraped_at, platform, keyword, rank, seller_name, product_name,
         price_sgd, original_price_sgd, rating, review_count, sales_count,
         is_sponsored, badges)
        VALUES (?,?,?,?,?,?,?,?,?,?,?,?,?)
    """, rows)
    conn.commit()

this pattern gives you a time-series database of competitor data. simple SQL queries reveal price trends, rank movement, and new entrants over time.

integrating Singapore mobile proxies into existing automation stacks

if you already have a scraping or automation stack and are adding SMP proxies to it, here is how the integration looks for common tools and frameworks.

Playwright (Python). for browser automation that needs to behave like a real browser, not just send HTTP requests:

from playwright.async_api import async_playwright

async def run():
    async with async_playwright() as p:
        browser = await p.chromium.launch(
            proxy={
                "server": "socks5://sg1.smp.example.com:45001",
                "username": "your_username",
                "password": "your_password",
            }
        )
        context = await browser.new_context(
            locale="en-SG",
            timezone_id="Asia/Singapore",
            user_agent="Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.0.0 Safari/537.36",
            viewport={"width": 1920, "height": 1080},
        )
        page = await context.new_page()
        await page.goto("https://shopee.sg")
        # your workflow here
        await browser.close()

setting locale and timezone_id at the context level ensures these values are consistent with the Singapore IP, removing one fingerprint inconsistency.

Scrapy (Python). for large-scale structured scraping:

# in settings.py
DOWNLOADER_MIDDLEWARES = {
    'scrapy.downloadermiddlewares.httpproxy.HttpProxyMiddleware': 110,
}

# in spider or middleware
import os
os.environ['http_proxy'] = 'socks5h://your_username:your_password@sg1.smp.example.com:45001'
os.environ['https_proxy'] = 'socks5h://your_username:your_password@sg1.smp.example.com:45001'

or using rotating middleware for batch-level rotation:

class RotatingProxyMiddleware:
    def __init__(self, rotation_url):
        self.rotation_url = rotation_url
        self.request_count = 0

    def process_request(self, request, spider):
        self.request_count += 1
        if self.request_count % 100 == 0:
            # rotate every 100 requests
            import requests as req
            req.get(self.rotation_url)

        request.meta['proxy'] = 'socks5h://your_username:your_password@sg1.smp.example.com:45001'

Node.js / Puppeteer. for JavaScript-based automation:

const puppeteer = require('puppeteer');

(async () => {
  const browser = await puppeteer.launch({
    args: [
      '--proxy-server=socks5://sg1.smp.example.com:45001',
      '--lang=en-SG',
    ],
  });

  const page = await browser.newPage();

  await page.authenticate({
    username: 'your_username',
    password: 'your_password',
  });

  await page.setExtraHTTPHeaders({
    'Accept-Language': 'en-SG,en;q=0.9',
  });

  // emulate timezone
  await page.emulateTimezone('Asia/Singapore');

  await page.goto('https://lazada.sg', { waitUntil: 'networkidle2' });

  // your workflow here
  await browser.close();
})();

httpx (Python async). for modern async scraping:

import httpx
import asyncio

async def fetch_lazada_search(keyword: str) -> dict:
    proxy_url = "socks5://your_username:your_password@sg1.smp.example.com:45001"

    async with httpx.AsyncClient(
        proxies=proxy_url,
        headers={
            "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.0.0 Safari/537.36",
            "Accept-Language": "en-SG,en;q=0.9",
        },
        timeout=30.0,
    ) as client:
        resp = await client.get(
            "https://www.lazada.sg/catalog/",
            params={"q": keyword, "_keyori": "ss", "from": "input"},
        )
        return resp.json()

asyncio.run(fetch_lazada_search("wireless earphones"))

httpx supports SOCKS5 proxies natively via the httpx[socks] extra (pip install httpx[socks]). use socks5:// for standard SOCKS5 with local DNS, or socks5h:// (requires the socksio library) for proxy-side DNS resolution.

Singapore ecommerce calendar and proxy strategy

the SG ecommerce calendar has predictable high-stakes periods where account health, ad performance, and competitor intelligence matter most. planning your proxy strategy around the calendar prevents scrambling during peak periods.

pre-campaign preparation. for major campaigns (11.11, 12.12, 9.9), prepare your seller accounts 2-3 weeks in advance:

• verify the SMP port is healthy and the IP is clean (no degradation)
• log into the seller center from the clean IP and complete any pending profile or compliance requirements
• apply for campaign slots before the window closes, typically 7-10 days before the event
• set up monitoring scrapes for your key keywords to establish a pre-campaign baseline

on peak days. on the actual campaign days, platform load is high and seller center sessions may be slower. do not mistake slow seller center responses for proxy issues. test your proxy health on a non-Shopee/Lazada URL (ipinfo.io is fine) to confirm the proxy is up. if the proxy is up and the seller center is slow, the platform is under load, not your stack.

building a multi-platform proxy registry

at any real operational scale, the proxy-to-account mapping lives in a structured registry, not in your memory or a flat document. here is a minimal but functional registry schema in SQLite:

CREATE TABLE proxy_ports (
    id INTEGER PRIMARY KEY AUTOINCREMENT,
    port_id TEXT UNIQUE NOT NULL,        -- e.g. smp_port_045001
    host TEXT NOT NULL,                   -- e.g. sg1.smp.example.com
    port INTEGER NOT NULL,
    username TEXT NOT NULL,
    password TEXT NOT NULL,
    rotation_url TEXT,
    carrier TEXT,                         -- SingTel, StarHub, M1
    status TEXT DEFAULT 'active',         -- active, degraded, retired
    last_verified TIMESTAMP,
    notes TEXT
);

CREATE TABLE accounts (
    id INTEGER PRIMARY KEY AUTOINCREMENT,
    platform TEXT NOT NULL,               -- tiktok, shopee, lazada
    account_handle TEXT NOT NULL,
    brand_name TEXT,
    assigned_port_id TEXT REFERENCES proxy_ports(port_id),
    browser_profile_id TEXT,              -- antidetect browser profile ID
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    status TEXT DEFAULT 'active',         -- active, suspended, retired
    notes TEXT
);

CREATE TABLE account_events (
    id INTEGER PRIMARY KEY AUTOINCREMENT,
    account_id INTEGER REFERENCES accounts(id),
    event_type TEXT,                      -- login, post, rotation, flag, recovery
    event_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    ip_used TEXT,
    operator TEXT,
    notes TEXT
);

this schema lets you answer the questions that matter: which account is on which IP, what happened on each account’s history, which ports are currently in active use, and whether any account has recently had flags or recovery events.

a simple query to find any port shared across multiple accounts (which should never happen):

SELECT assigned_port_id, COUNT(*) as account_count, GROUP_CONCAT(account_handle) as accounts
FROM accounts
WHERE status = 'active'
GROUP BY assigned_port_id
HAVING COUNT(*) > 1;

if this query returns any rows, you have a sharing problem to fix before it causes cascade-banning.

monitoring proxy health continuously

do not wait for an account to get flagged to discover your proxy is degraded. set up a simple health check that runs on a schedule:

import requests
import datetime

def check_proxy_health(host, port, username, password):
    proxies = {
        "https": f"socks5h://{username}:{password}@{host}:{port}"
    }
    try:
        resp = requests.get(
            "https://ipinfo.io/json",
            proxies=proxies,
            timeout=15,
        )
        data = resp.json()
        return {
            "healthy": True,
            "ip": data.get("ip"),
            "org": data.get("org"),
            "country": data.get("country"),
            "city": data.get("city"),
            "checked_at": datetime.datetime.utcnow().isoformat(),
        }
    except Exception as e:
        return {
            "healthy": False,
            "error": str(e),
            "checked_at": datetime.datetime.utcnow().isoformat(),
        }

# run this for each active port in your registry
result = check_proxy_health("sg1.smp.example.com", 45001, "your_username", "your_password")
print(result)

run this every 30 minutes for all active ports. log the results. alert if a port is down for two consecutive checks. for production seller operations, knowing a proxy is down before the operator starts their morning session is the difference between a smooth day and an hour of debugging.

the health check also tells you if the IP has changed (a new IP after carrier-side refresh) or if the carrier has changed (SIM replacement or carrier reassignment). if the org field changes, note it: platform history for the account was built on a different IP, and the first session on the new IP may prompt re-verification.

bottom line

TikTok, Shopee, and Lazada all do serious detection work. a Singapore mobile IP from a real carrier (SingTel, StarHub, or M1) solves the most fundamental layer of that detection: the IP type and country signals that cause silent suppression, login blocks, and seller account friction.

the proxy is not magic. you still need antidetect browser isolation per account, consistent fingerprints, disciplined session management, and behavioral patterns that look like real sellers and creators. but you need a clean IP to build any of that on, and a shared residential pool or a datacenter IP is the wrong foundation for serious ecommerce and social platform work in Singapore.

start with the 2-hour free trial to test your setup before committing. point an antidetect browser profile at the SMP port with Asia/Singapore timezone and en-SG language, log into TikTok, Shopee, and Lazada, check that the For You feed is SG-heavy and that prices are in SGD, run one seller operation on each, and confirm the proxy is doing what it should before scaling your operation on top of it.