Proxy Solutions
Point a browser profile at Proxy Solutions residential proxies. Three steps, no plugin, no proxy-auth extension.
Proxy Solutions mobile proxies: one dedicated channel per order, with its own IP and two ports - HTTP and SOCKS5 - rather than a shared gateway with country codes in the username. Measured on a live Poland order, not read off a docs page.
https://proxy-solutions.net/en/services/mobile-proxies
1. Get the credentials
In your Proxy Solutions dashboard, open the residential product and copy the gateway host, the port, and the username and password. Everything below assumes those four values.
2. Build the proxy URL
One string, credentials included. Targeting and session options go in whichever half this provider puts them in - the table below says which.
http://<order login, e.g. ps166787>:<order password>@82.97.251.114:16920 3. Launch
Timezone, locale and WebRTC are derived from the exit address, so a US exit does not arrive with your own timezone attached.
await ab.launch({
profile: 'acc-01',
proxy: 'http://<order login, e.g. ps166787>:<order password>@82.97.251.114:16920',
}) launch(
profile="acc-01",
proxy="http://<order login, e.g. ps166787>:<order password>@82.97.251.114:16920",
) Prefer not to run an account at all? Managed residential proxies are included on paid plans.
Parameters
Read off Proxy Solutions's own documentation on 2026-09-17. Ports and endpoints differ by plan and by zone, so where this table and your dashboard disagree, the dashboard is right.
| Gateway | 82.97.251.114 |
| Ports | 16920 on the shared HTTP gateway above; SOCKS5 uses the same port on its own gateway, 185.247.16.34. Each order additionally gets its own channel address with two ports of its own (1051 HTTP and 1052 SOCKS5 on the order tested) - both routes were measured and both reach the same exit. |
| Protocols | HTTP and SOCKS5, on separate ports. Both were tested and both worked with the same credential. |
| Options ride in | Not published on the page above - see the provider docs |
| Country targeting | Chosen when the order is placed, not in the credential. The order tested was Poland and came out on Orange Polska in Poznan; the channel also reports its city and operator through the API. |
| Sticky session | The channel holds one mobile IP until it rotates. Measured, not read off the dashboard: the exit had already moved on its own between two runs about an hour apart (37.47.132.48 to 37.47.140.0) with auto-reset set to 20 minutes, and calling the change-ip URL their API returns moved it again within 10 seconds (37.47.140.0 to 37.47.132.174). Hold one profile on the channel to hold one identity between rotations. |
| Session length | One channel per unit ordered; the plan tested was a single Poland channel. |
| Source | https://proxy-solutions.gitbook.io/api-en/ |
Worth knowing
- The endpoint is not shown on the orders table - the IP column reads "1 pcs.". It comes from their Download export, or from their API: GET /api/user/orders/{id} with the api-key from the dashboard's API for developers page returns the channel with its IP, both ports, the operator and the change-ip URL.
- Measured on 2026-09-17 with AntiBrow, one profile per route: the channel ports and both shared gateways all exited on 37.47.132.48 - public-gprs384239.centertel.pl, AS5617 Orange Polska, Poznan. A mobile carrier address, not a datacenter one.
- The browser timezone followed the exit - Europe/Warsaw, offset -120 - while the locale stayed at the profile's configured en-US. Same split as every other vendor page here: timezone follows the exit, language does not.
- No WebRTC leak: the ICE candidates carried the exit address and 0.0.0.0, with no local or host address alongside.