MangoProxy
Point a browser profile at MangoProxy residential proxies. Three steps, no plugin, no proxy-auth extension.
MangoProxy residential proxies: four regional gateways on the same two ports, with the sub-account, pool, country and sticky session all encoded in the username. Measured on a live 1 GB residential account, with the grammar read off the dashboard's own connection generator.
1. Get the credentials
In your MangoProxy 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://<sub-account>-zone-custom-region-us-session-<id>-sessTime-30:<sub-account password>@p1.mangoproxy.com:2334 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://<sub-account>-zone-custom-region-us-session-<id>-sessTime-30:<sub-account password>@p1.mangoproxy.com:2334',
}) launch(
profile="acc-01",
proxy="http://<sub-account>-zone-custom-region-us-session-<id>-sessTime-30:<sub-account password>@p1.mangoproxy.com:2334",
) Prefer not to run an account at all? Managed residential proxies are included on paid plans.
Parameters
Read off MangoProxy's own documentation on 2026-10-15. Ports and endpoints differ by plan and by zone, so where this table and your dashboard disagree, the dashboard is right.
| Gateway | p1.mangoproxy.com (Europe), p2.mangoproxy.com (Asia), p3.mangoproxy.com (North America) and p4.mangoproxy.com (CIS) - the dashboard labels them by region, and its own banner says to try the CIS server if a connection gives trouble. The server is only the entry point, not the exit country: Japan came out through p3 and Germany through p4, so pick the one closest to you. |
| Ports | 2334 and 2333, and both take either protocol. The code samples on the developer page use 2334 over HTTP; the dashboard generator hands out 2333 for SOCKS5. Measured: HTTP and SOCKS5 both worked on both ports, and all four gateways answered on 2334. |
| Protocols | HTTP, HTTPS and SOCKS5. HTTP and SOCKS5 were both measured in AntiBrow with the same credential. |
| Options ride in | the username |
| Country targeting | -region-<iso2>, after -zone-custom. Case does not matter (region-US worked as well as region-us). Measured: region-us, region-de, region-jp, region-gb and region-br each came out in that country. Do not write -country-: the gateway accepts it without an error and ignores it, and the two tries came out in Chile and in a random US city. The generator also offers state, city and ASN targeting. |
| Sticky session | -session-<id>-sessTime-<minutes>, both together. Measured: one session id returned 99.51.157.153 in two separate AntiBrow launches, and the same address in WebRTC. Without the session segment the exit changes per connection. The dashboard calls the two modes Sticky sessions and Instant. |
| Session length | Up to 120 minutes, per the dashboard and the Public API (sessionDuration 0 to 120). The generator defaults to 15. |
| Source | https://mangoproxy.com/dev/ |
Worth knowing
- Keep a sticky profile on one gateway host. The session is not reliably shared between the four servers: one session id held the same exit across p1 and p4, but another came out in Orlando on p3 and in Bellflower on p1, and stayed that way on every repeat. Switching the server can silently switch the IP.
- Measured on 2026-10-15 with AntiBrow, one profile per case: US exits on Armstrong, Cablevision, AT&T and Comcast, the German one on Deutsche Telekom in Saxony, the Japanese one on KDDI in Tokyo, the British one on Plusnet in London. Every exit looked up sat on a consumer ISP. In rotating mode two pages loaded one after the other in the same profile saw two different addresses, so add a session whenever the site has to see one IP.
- The timezone and language followed the exit: America/New_York, America/Detroit, America/Denver, Europe/Berlin with de, Asia/Tokyo with ja, Europe/London with en-GB. The first page took 1.3 to 5.1 seconds. One launch out of nine was slow (17 seconds), its geo lookup did not finish, and the profile kept its default America/Los_Angeles; the same credential relaunched came back on America/Detroit. Check browser.timezone after launch if it matters.
- No WebRTC leak: the real address never appeared, only mDNS .local host names and a public srflx candidate. With a sticky session the srflx address was the exit itself. In rotating mode it was yet another address in the same country, because the STUN request is a new connection and gets a new exit.
- A wrong password comes back as a clean 407, so an authentication mistake is easy to tell apart from a bad targeting segment, which authenticates and simply ignores what it does not understand.
- MangoProxy blocks payment systems such as Stripe and PayPal, banks and government websites on its dynamic proxies, and the SMTP/SSH ports 22, 25, 465, 587, 2525, 5060 and 5061, per its integrations page. A profile meant for checkout or banking will not work through it.
- The credential is a sub-account: its name and password are listed in the dashboard under Residential - Sub-accounts, and Proxy Setup builds the full string from it. -zone-custom is the default pool; leaving it out also worked. The Public API (x-api-key from the dashboard, base backend.mangoproxy.com) can create sub-accounts, generate connection strings and refresh a sticky session, but the key itself only comes from the dashboard, and the dashboard login sits behind an hCaptcha image puzzle. The account tested was 1 GB of residential.