How to Use PROXIES.SX with GeeLark: Cloud Phone Proxy Integration
GeeLark gives each cloud phone a real Android environment. PROXIES.SX gives each one a real carrier network identity. This guide covers the whole path: choosing between a dedicated port and the Pool Gateway, the exact credential format to paste into GeeLark, verifying the exit IP before you log into anything, and the small alignment details that decide whether an account survives its first week.
Before you start
- ·A GeeLark account with at least one cloud phone available.
- ·A PROXIES.SX account with GB on the balance. Endpoints are free - you pay only for the GB you use, and GB never expire.
- ·Decide the target country per phone up front, because the phone locale should match it.
Which product to bind
Dedicated port
One modem pinned on a fixed host and port with its own login. The host, port and credentials stay stable, which suits a phone that represents one long-lived identity.
socks5h://proxyLogin:proxyPassword@serverIp:socksPortPool Gateway
One credential reaching every country in your tier, with country, network and rotation chosen inside the username. Best when phones come and go across geos.
socks5h://psx_<userId>-peer-us:proxyPassword@gw.proxies.sx:7001Port rules
On the Pool Gateway, 7000 is HTTP-only and 7001 is SOCKS5-only. Dedicated ports expose a separate httpPort and socksPort. Sending one protocol to the other protocol's port is the single most common setup mistake.
Step by step
Decide which PROXIES.SX product each phone should use
Two options, and the choice changes what you paste into GeeLark later. A dedicated port pins one modem on a fixed host and port - best when a cloud phone must look like the same device for weeks. The Pool Gateway is one credential that reaches every country in your tier, with routing selected inside the username - best when you are spinning phones up and down across geos. Both draw on the same prepaid GB balance.
Collect the credentials
For a dedicated port, open the port in the dashboard and copy serverIp, httpPort or socksPort, proxyLogin and proxyPassword. For the Pool Gateway, set a proxy password once under Account, then use gw.proxies.sx with port 7000 for HTTP or 7001 for SOCKS5, your account username psx_<userId> plus routing tokens, and that proxy password.
Open the cloud phone’s proxy settings in GeeLark
In the GeeLark console, open the cloud phone you want to bind and go to its proxy configuration. GeeLark accepts a standard manual proxy entry, so you are filling in four fields plus a protocol - exactly the values you copied in step 2. Configure the proxy before the phone’s first launch so no app ever touches the network on an unproxied route.
Fill in protocol, host, port and credentials
Choose SOCKS5 where GeeLark offers it - a cloud phone runs real apps, and SOCKS5 carries traffic those apps generate more completely than an HTTP proxy. Enter the host and port, then the username and password. Save the configuration.
Test the connection before you log into anything
Use GeeLark’s built-in proxy test if present, then launch the phone and open an IP-check site in its browser. Confirm the country matches what you selected and that the IP is a carrier or residential address rather than your own. This 30-second check is what separates a clean account from one flagged on day one.
Align the phone’s locale with the exit IP
Set the cloud phone’s system language, region and time zone to match the country the proxy exits from. A US exit IP on a phone reporting a European time zone is one of the most common self-inflicted signals, and it is entirely avoidable.
Keep one endpoint per phone
Assign a distinct endpoint to every cloud phone rather than sharing one across several. Endpoints are free on PROXIES.SX and you only pay for the GB you actually use, so the isolation costs nothing extra. Reusing one IP across phones is the fastest way to have platforms treat them as one operator.
Getting sticky sessions right
A cloud phone that changes country mid-session looks like a stolen account. On the Pool Gateway, stickiness comes from two tokens in the username: a rotation mode and a session name. The session name is the part people forget - without it, stickiness cannot persist across connections, because each new connection gets a fresh short-lived session.
Sticky pins the modem, not the IP
Mobile carriers re-NAT their egress addresses on their own schedule, so a pinned modem can still surface a different exit IP on short calls. If a workflow needs one address held for hours, use a residential peer endpoint or a dedicated modem on a static plan rather than a mobile sticky session.
Frequently asked questions
Should I use SOCKS5 or HTTP with a GeeLark cloud phone?
Prefer SOCKS5 where the option exists. A cloud phone runs real Android apps rather than just a browser, and SOCKS5 operates at a lower level than an HTTP proxy, so it carries app traffic more completely. PROXIES.SX issues both: dedicated ports expose an httpPort and a socksPort, and the Pool Gateway listens on 7000 for HTTP and 7001 for SOCKS5. Do not send HTTP traffic to the SOCKS port or vice versa - the ports are protocol-specific.
Dedicated port or Pool Gateway for cloud phones?
Use a dedicated port when a phone represents a long-lived identity that should keep the same modem for weeks - the host, port and credentials stay fixed. Use the Pool Gateway when you are creating and destroying phones across many countries, since one credential reaches every country in your tier and the routing lives in the username string. Both bill from the same prepaid GB balance, so you can mix them.
How do I keep the same IP for a given cloud phone?
On the Pool Gateway, add a rotation mode and a session name to the username - a sticky rotation token plus a sid keeps requests pinned to the same endpoint. Without a session name, stickiness cannot persist across connections. One caveat worth knowing: on mobile carriers, sticky pins the modem rather than guaranteeing a fixed exit IP, because carriers re-NAT egress addresses on their own schedule. If you need an IP that holds for hours, a residential peer endpoint or a dedicated modem on a static plan is the better fit.
Can I automate proxy assignment when creating phones in bulk?
Yes. The PROXIES.SX REST API can create, list and rotate ports programmatically, so a script can provision an endpoint and hand its credentials straight to your cloud-phone creation step. Set the proxy at create time rather than afterwards, so a phone never boots on an unproxied connection.
The cloud phone shows my real IP - what went wrong?
Usually one of three things: the proxy was added after the phone had already launched, the protocol and port do not match (HTTP credentials sent to a SOCKS port, or the reverse), or the credentials were pasted with a trailing space. Re-check the four fields, confirm the protocol, save, restart the phone, and re-run the IP check before opening any app that matters.
Give every cloud phone its own carrier IP
Real 4G/5G mobile and residential exits, sticky sessions, and a full REST API for bulk provisioning. $4/GB dropping to $2.40/GB at volume, GB never expire, and endpoints are free - so one endpoint per phone costs nothing extra.