Mobile Proxy Not Working — A Diagnostic Checklist That Actually Isolates the Cause

"My proxy isn't working" is one sentence covering four unrelated faults. Before changing a single setting, the useful question is which of the four you have — because the fixes have nothing in common, and applying the wrong one wastes the state you need to diagnose properly.

This page is the triage step. It should take about two minutes.

The one test that eliminates most guesswork

Send a request through the proxy to a neutral endpoint — something with no reason to block anyone — before you test against your real target.

curl -x http://user:pass@your-proxy-host:port https://api.ipify.org

Interpret it like this:

• An IP address comes back → the proxy is working. Your problem is at the destination, and you should skip to the "it works but I'm blocked" section below.
• An authentication error → the tunnel is reachable but rejecting your credentials. See HTTP 407.
• Connection refused → something actively said no. See connection refused.
• A hang, then a timeout → nothing answered at all. Different cause, covered below.

Most people skip this and test against the site they actually care about, which conflates "my proxy is down" with "this site doesn't like me". Those need opposite responses.

The four faults, and how they present

Refused and timeout are not the same symptom

A refusal is something talking to you. A timeout is silence. That distinction narrows the cause more than anything else you can observe cheaply.

Connection refused means your TCP handshake arrived somewhere and was actively rejected. Something is alive at that address and does not want the connection on that port. That is usually a wrong port number, a proxy process that is not running, or an IP allowlist that does not include you.

A timeout means your packets vanished. Nothing sent back a rejection — they were dropped. That is usually a firewall between you and the proxy, an ISP blocking non-standard ports, or a host that is genuinely unreachable.

The practical consequence: refusals are faster to fix, because something is still responding and you can iterate. Timeouts require you to find the thing silently discarding traffic, which is often not under your control.

If you get a block page, the proxy did its job

A 403, a 429, a CAPTCHA or a Cloudflare interstitial all mean your request completed. It travelled through the proxy, reached the destination, and the destination chose to refuse it.

This is worth internalising because it redirects the entire investigation. Nothing about your proxy configuration is broken. What failed is one of:

• The address's reputation. Someone else's behaviour on a shared address, or a datacenter range the destination already distrusts.
• Your request pattern. Rate, regularity, or concurrency that reads as automation.
• Your client fingerprint. A request claiming to be a browser that does not behave like one at the TLS layer.

Changing proxy settings will not fix any of those. The relevant reading is 429 for rate limits, Cloudflare 1015 for throttles and 1020 for firewall rules, and mobile vs residential if the underlying issue is what kind of address you are leaving from.

"Online" is the least trustworthy signal on any dashboard

A device answering a heartbeat is not a device that can carry traffic, and most dashboards report the first while labelling it the second.

The failure mode is specific: the phone keeps its control connection to the relay alive, so the heartbeat is healthy and the status shows green, while the cellular radio is dead. Your requests fail against a proxy that insists it is fine.

The only fix that means anything is testing the data path rather than the control channel — pushing a real request out through the device's cellular connection and marking it healthy only when that completes. Until a provider does that, treat a green light as weak evidence and run the neutral-endpoint test above instead.

We cover why this gap exists, and how to check any provider for it, in the rotation verification study.

One failing is a device problem. Many failing is not.

If a single proxy fails, investigate that device. If failures climb across many devices at once — especially devices in different physical locations — stop touching things.

Simultaneous failure across separate sites rules out anything local to one device. Two causes remain: something changed on the operator's side, or the carrier is having an event. If nothing shipped, it is usually the carrier.

Two counter-intuitive rules that follow from this, both learned expensively:

Do not mass-reboot during a carrier event. It converts a partial outage into a total one, because every device simultaneously tries to re-handshake against a network that is already struggling.

Rotation-failure rate is a better health signal than device-online count. Online count lags badly — a device can hold a stale heartbeat for minutes after it stops being useful. Failure rate moves immediately.

The discipline that actually shortens debugging

Three habits, in rough order of how much time they save:

1. Change one variable at a time. Most proxy problems that become unresolvable are two people changing settings against the same symptom, so neither knows what helped.
2. Do not rotate as a reflex. Rotation destroys the state you were debugging and changes nothing if the fault is authentication or reachability. Diagnose first.
3. Write down what you observed, not what you concluded. "Returned 403 after 0.4s" survives; "the proxy is banned" is a guess that gets repeated until everyone believes it.

When this becomes an infrastructure problem

Everything above diagnoses a single connection. If you are running many proxies and spending real time on this triage repeatedly, the variable that matters shifts from configuration to what you can actually observe.

Three properties make the difference, and they are worth asking any provider about directly:

• Is "online" verified against real egress, or is it a heartbeat? If nobody pushes traffic through the device, nobody knows whether it works.
• Is the exit address recorded after every rotation? If not, "rotation succeeded" cannot be distinguished from "the command was accepted".
• Is the address dedicated to you? On a shared pool you inherit the reputation of whoever used it before you, which means your block rate is partly someone else's behaviour and no amount of debugging on your side will explain it.

Two honest limits, because this is where proxy marketing usually overclaims.

Better observability does not prevent blocks. It tells you faster and more accurately why something failed. That is genuinely valuable when you are debugging at volume, and it is not the same as a higher success rate.

A mobile IP is one input among many. Request patterns, missing sessions and client fingerprints still count, and a mobile address behaving obviously robotically will be flagged like any other. If detection is not your constraint and raw speed is, a datacenter proxy is the better and cheaper tool.

Frequently asked questions

How do I know if the problem is the proxy or the website?

Send one request through the proxy to a neutral endpoint that has no reason to block anyone, such as an IP-echo service. If that returns an address, the proxy is working and the problem is between you and your actual target. This single test eliminates most of the guesswork.

My proxy returns 403 — is it broken?

No, the opposite. A 403 means your request travelled through the proxy, reached the destination, and the destination refused it. The tunnel is healthy. What failed is the reputation or fingerprint of the request, which is a completely different problem to solve.

What is the difference between connection refused and connection timeout?

Refused means something received your TCP handshake and actively rejected it — usually a wrong port, a stopped service, or an allowlist. Timeout means nothing answered at all — usually a firewall dropping packets silently, or an unreachable host. Refused is a faster fix because something is still talking to you.

The dashboard says my proxy is online but nothing works. How?

Most dashboards report a heartbeat over the control channel rather than testing the data path. The phone can answer heartbeats while its cellular radio is unusable. Unless your provider verifies real egress, treat a green light as weak evidence.

Should I rotate the IP when something stops working?

Not as a first move. Rotation changes one variable and destroys the evidence you need to diagnose. Establish whether the proxy is reachable and authenticating first — if it is, rotation may help; if it is not, rotation changes nothing and costs you the state you were debugging.

Everything stopped at once across many proxies. What does that mean?

Simultaneous failure across devices in different physical locations points away from your setup and toward the carrier. Code bugs and config changes take everything down together too, so check whether anything shipped — but if nothing changed on your side, waiting is often correct.