← back to blog

Mobile proxy errors decoded: 407, 429, connection reset and dns leaks

mobile proxies proxy errors troubleshooting dns leak singapore 2026

Mobile proxy errors decoded: 407, 429, connection reset and dns leaks

You ran a job and got back one cryptic line. 407. Or 429. Or “connection reset by peer.” No context, no explanation, and no way to tell whether the problem is you, the proxy, or the site you’re hitting.

Most of these errors are not the proxy failing. They’re either your client code, your settings, or the target pushing back. Once you can read the code, you stop switching providers and start fixing the actual cause. Here’s what each one means and how to fix it. If the foundation is new to you, what is a mobile proxy covers the basics first.

407 proxy authentication required

This is the one people search for most, and it’s almost always small. 407 means the proxy got your request but rejected your credentials. Three things cause it.

First, a wrong username or password. Copy them straight from your dashboard, with no trailing space, and check that special characters aren’t getting mangled in your config.

Second, the wrong auth mode. Some setups expect username and password auth, others expect IP allowlist auth, and the two don’t mix. If your provider has you on allowlist auth, sending a username and password gets you a 407, and vice versa.

Third, your IP isn’t on the allowlist. If you’re using IP auth and your public address changed, the proxy no longer recognizes you. Add your current IP to the allowlist and the 407 clears.

429 too many requests

A 429 is not your proxy breaking. It’s the target site rate limiting you. The site counted your requests, decided you’re going too fast, and told you to slow down.

The fix is on your side. Add real delays between requests, lower your request rate, and back off when you see a 429 instead of hammering through it. Switching proxies won’t help here, because the proxy is doing exactly what it should. You’re the one being throttled, not the line.

Connection reset by peer

This one looks scary and has three common causes. A tower blip, too much concurrency, or the site dropping you.

A mobile IP is a real radio on a real tower. When the SIM hands off between cells or the signal dips, the connection blinks for a second. Your code should retry once on a reset instead of crashing.

Too many concurrent connections through one device causes resets too. A mobile proxy is one phone with one radio. Fire forty parallel threads through it and it starts dropping connections. Cap your concurrency to a handful per IP.

And sometimes the site is resetting you on purpose. When you trip a bot rule, many sites don’t return a clean error, they just reset the connection. If resets only happen on one target and never on a neutral test, the site is dropping you, not the proxy.

Connection refused

Connection refused means nothing answered on the other end. Usually it’s a wrong port. One modem maps to one port, and the http port is different from the socks5 port, so a single wrong digit gets you refused. Double check the port against your dashboard.

If the port is right and it’s still refused, the line may be down. Test a neutral endpoint to confirm, then send your provider the exact host and port.

Connection timeout

A timeout is often just your client giving up too early. Mobile connections have higher latency than datacenter connections, anywhere from eighty to three hundred and fifty milliseconds, so a three second timeout that works on a datacenter proxy fires before a mobile line can respond.

Raise your request timeout to fifteen to thirty seconds. That single change clears most timeout reports, because the connection was about to respond and your client didn’t wait.

Dns leak

A dns leak means your real resolver answered the lookup instead of the proxy, which quietly exposes your real location even though your traffic goes through a Singapore IP.

The usual cause is using socks5 instead of socks5h. Plain socks5 resolves dns on your machine. socks5h sends the hostname through the tunnel so the proxy resolves it. Switch to socks5h, then verify with a dns leak test and confirm the resolver is on the carrier side, not your own. This matters a lot for scraping work, which is why the setups in web scraping with mobile proxies: 7 case studies all route dns through the tunnel.

Ip not changing

If your IP isn’t rotating when you expect it to, you’re probably on a sticky port. Sticky ports hold one IP on purpose so a session survives. Rotating ports give you a fresh IP per request or per timer.

Pick the port that matches the job. Use the rotating port, or call your provider’s rotation trigger, when you actually want a new address. The IP staying still is a feature, not a fault.

Ip changing too fast

The opposite problem. Your IP rotates in the middle of a login or a checkout and the site sees a session that teleported to a new address. That’s a sticky duration set too short.

Extend the sticky session to cover your whole flow, a few minutes at least, and rotate only when you choose to, not on a timer firing mid transaction.

Ssl or certificate errors

An ssl or certificate error usually means something is intercepting your traffic, or you’ve got the wrong scheme. A man in the middle proxy or a corporate interceptor in the chain breaks the certificate, so remove it. And make sure you’re using the right scheme for the port, an https request through a plain http config will throw certificate errors too.

Telling a client bug from a real fault

Here’s the test that settles it. Send the same request to a neutral IP check endpoint, at low concurrency, with a clean client using socks5h and a thirty second timeout. If that works and your target fails, the target is blocking you. If the neutral endpoint fails too, then it’s the proxy or your settings.

The order I diagnose in: neutral endpoint first, then concurrency, then client settings, then the provider last. Most people skip straight to blaming the provider, switch services, and see the exact same errors, because the real cause was a three second timeout or forty threads through one device.

Try real Singapore mobile proxies

If you’re tired of guessing whether it’s you or the line, start with hardware you can trust. There’s a free trial of Singapore Mobile Proxy, real SG SIMs from SingTel, M1, and StarHub, with socks5h support and sticky or rotating ports so you control rotation instead of fighting it. Use code YT30 on signup.

Get new guides and videos first — join the Telegram channel.

ready to try Singapore mobile proxies?

2-hour free trial. no credit card required.

start free trial
message me on telegram