Running proxies behind a corporate firewall and strict egress rules
We get this question a few times a month from people running scraping or multi-account browser work out of an office: “your proxies work fine from home, but nothing connects from my work laptop.” Nine times out of ten it’s not our gateway. It’s whatever sits between that laptop and the internet.
Corporate networks aren’t hostile to proxies specifically, they’re hostile to unrecognized outbound traffic in general. Once you understand what the firewall is actually checking, getting a mobile proxy working through it is a config problem, not a dead end.
What “strict egress” usually means in practice
Most locked-down corporate networks use some combination of these, often all at once:
- A forced proxy. The machine doesn’t route to the internet directly. It’s handed a PAC file (via WPAD or a Group Policy push) that points every outbound request at an internal proxy server. Nothing leaves without going through that box first.
- Port restrictions. Outbound firewall rules that only allow 80 and 443. Anything on a nonstandard port gets dropped at the edge, no error, no explanation, the packet just doesn’t arrive.
- A destination allowlist instead of a blocklist. Some environments flip the usual model: instead of blocking known-bad domains, they only permit traffic to domains someone approved. If your destination isn’t on the list, it doesn’t matter what protocol you’re using, it’s denied by default.
- TLS interception. The corporate proxy terminates your HTTPS connection, inspects it, and re-encrypts it with the company’s own root CA, which is installed as trusted on the managed device. This is how IT reads “encrypted” traffic without actually breaking encryption for the end user.
- Authenticated proxy access. The forced proxy often requires the logged-in domain account to authenticate via NTLM or Kerberos before it’ll forward anything at all.
Any one of these can be the reason a proxy connection fails silently. Stacked together, they’re the reason it feels like nothing works.
The real task is chaining two proxies
Once there’s a mandatory corporate proxy in front of you, connecting to a mobile proxy isn’t a single hop anymore, it’s two. Your traffic has to go: your machine, to the corporate proxy, to our gateway, out through the connected SIM.
The mechanism that makes this possible is the HTTP CONNECT method. When a client asks an HTTP proxy to CONNECT to a host and port, a compliant proxy opens a raw TCP tunnel to that destination and just relays bytes from there, it doesn’t need to understand what’s inside. This is exactly how your browser reaches HTTPS sites through a corporate proxy today: it sends a CONNECT example.com:443 request, gets a tunnel, then does the TLS handshake itself inside that tunnel.
You can use the same mechanism to tunnel to a second proxy. If the corporate proxy allows CONNECT to our gateway’s host and port, your automation tool ends up with an open tunnel straight to us, and everything downstream, including the TLS handshake and any proxy authentication we require, happens inside that tunnel where the corporate box can’t see it (unless it’s doing full TLS interception, which is a separate problem, more on that below).
In practice you don’t configure this by hand in every tool. You run a small local forwarder on the machine, something like cntlm for NTLM-authenticated corporate proxies, or an equivalent lightweight proxy chainer, that logs into the corporate proxy once and exposes a plain localhost port. Your scraper, Puppeteer, Playwright, or Selenium instance then points at that localhost port like it’s a normal single-hop proxy. The forwarder handles the double authentication in the background.
Why HTTP beats SOCKS5 here
Our gateways expose both HTTP(S) and SOCKS5 endpoints, and normally which one you pick is a matter of taste. Behind a corporate firewall it’s not. SOCKS5 is a different protocol from what a forced HTTP proxy speaks, so a strict corporate proxy usually has nothing to relay it through, there’s no CONNECT-style tunneling concept in the same way, and SOCKS traffic on a nonstandard port gets blocked by the port rule anyway even if the proxy itself would allow it.
HTTP CONNECT on port 443 looks, from the firewall’s point of view, identical to a normal person browsing an HTTPS site. That’s the whole reason it survives strict egress rules when SOCKS5 doesn’t. If you’re setting this up from an office network, use our HTTPS gateway port, not SOCKS5.
Get the gateway whitelisted, not an IP range
This is the part people usually get wrong when they go to IT for an exception. Our exit IP, meaning the actual SingTel, M1, or StarHub mobile IP your request appears to come from, rotates. That’s the point of a SIM-based farm, we’re not going to hand you a stable residential-looking IP that never changes, that defeats the purpose.
But the gateway you connect your tooling to is not the exit IP. It’s a fixed hostname and port on our end that routes your session to whichever handset is currently assigned to you. For allowlist purposes, that’s the only thing IT needs to add: one hostname (or its resolved IP) and one port. Nobody needs to chase mobile carrier IP ranges, which would be pointless since those blocks are shared with ordinary phone traffic and change constantly on the carrier side, not just on ours.
When you ask IT for an exception, ask for exactly this: outbound HTTPS CONNECT permitted to [gateway hostname]:[port]. That’s a narrow, auditable request, and it’s the kind of thing a network admin can approve without opening the whole firewall.
Where automation tools actually break
Assuming the network side is sorted, the next failure point is almost always proxy configuration inside the automation tool itself. Puppeteer, Playwright, and Selenium each expect exactly one upstream proxy passed at launch, they weren’t built with a two-hop chain in mind. That’s why the local forwarder exists, it collapses the chain into something that looks like a single proxy to the tool.
The other common failure is credentials. If the corporate proxy needs NTLM auth and your forwarder isn’t configured with the right domain, username, and password, you’ll get connection resets that look identical to a network block. Check the forwarder’s own logs before assuming the mobile proxy gateway is the problem, in our experience it rarely is.
When it genuinely can’t be done
If IT’s allowlist is default-deny and they won’t add an exception for anything outside a short list of approved SaaS domains, there’s no chaining trick that gets around it. A default-deny firewall isn’t a technical obstacle you route through, it’s a policy decision enforced at the network edge, and no client-side configuration changes what the firewall lets leave the building.
At that point the honest answer is to move the work off that network. Run the automation from a personal machine on a home connection, or from a cloud VM you control, and point it at our gateway directly with no corporate hop in between. Trying to tunnel around a hard policy block on a company-owned machine is also the kind of thing that gets flagged by IT monitoring, which isn’t a place we’d point anyone.
What to bring to your IT team
If you want the short version to hand to a network admin: the hostname and port of our gateway, confirmation that it’s outbound HTTPS CONNECT traffic only, and nothing else. No new inbound rules, no new ports beyond 443. Most admins can approve that in minutes once they see it’s a single, specific destination rather than an open-ended exception.
If you’re setting up scraping or browser automation on a company network and want to talk through your specific firewall setup before you go to IT, get in touch with Singapore Mobile Proxy.
Get new guides and videos first — join the Telegram channel.