"My proxy isn't working" — the TCP, UDP and connection-type checklist

Nine times out of ten, "my proxy isn't working" isn't a dead line — it's a connection-type mismatch between your app's settings and how a proxy actually works. The line tests perfectly from our side, your traffic is flowing, and yet one app misbehaves. Almost always the culprit is a single setting most people never think about: UDP. This post explains the one distinction that clears it up, why our proxies speak HTTP and SOCKS5, when you genuinely need the VPN tier instead, and a short checklist to run before you assume anything is broken.

The one distinction: TCP vs UDP

Almost all internet traffic rides one of two transport protocols. TCP is the reliable one: it opens a connection, guarantees every byte arrives in order, and resends anything lost. Web pages, logins, API calls, uploads, messaging — the things you do when you run an account — are TCP. UDP is the fire-and-forget one: it sprays packets with no delivery guarantee, trading reliability for raw speed. It's built for live video, voice calls, games, and QUIC (the newer transport behind HTTP/3 that some apps try first).

That difference is the whole story here. A standard proxy — ours included, and virtually every SOCKS5/HTTP proxy on the market — relays TCP. That's not a limitation for account work; it's the correct tool. The friction only appears when an app insists on pushing UDP through a proxy that was never meant to carry it.

Why our proxies speak HTTP and SOCKS5

When you buy a mobile proxy from us, you get an ip:port with a username and password, and you connect to it as either an HTTP proxy or a SOCKS5 proxy. Both ride TCP. The difference is reach:

• HTTP(S) proxy — purpose-built for web traffic. Your browser or tool sends its HTTPS requests through it. This is all most account and scraping work ever needs.
• SOCKS5 proxy — lower-level and more general: it forwards *any* TCP connection, not just web requests, so it works with a wider range of software (anti-detect browsers, phone-farm tools, custom clients). Same mobile IP, same line — just a more flexible way to plug in.

Use whichever your software asks for — many customers use socks5:// or socks5h:// (the h sends DNS through the proxy too, which avoids a DNS leak). Both are TCP, both exit on the same real mobile IP.

The UDP trap that looks like a broken proxy

Here's the exact scenario we see most. A customer sets up a tool like Shadowrocket (or another advanced client) that has a "UDP Relay" toggle, and leaves it switched on. With that on, the app tries to force UDP — QUIC, mainly — through the proxy. A TCP proxy correctly refuses it. A well-behaved app then falls back to TCP and everything works; but some apps stall, retry, or half-load instead of falling back cleanly. On plain browser tests the proxy looks fine, but a QUIC-heavy app like Instagram or TikTok acts up — which reads exactly like "the proxy is broken" even though it's carrying your other traffic without a hitch.

Switching UDP Relay off costs you nothing for account work. QUIC always has a TCP fallback — huge swaths of corporate and hotel Wi-Fi block UDP entirely, so every serious platform treats TCP-only as completely normal and it raises no flags. The only things that genuinely need UDP are live voice/video and some game clients — not social media.

When you actually need UDP: the VPN tier

Some workloads really do need the whole device tunnelled, UDP and QUIC included — full-device setups, apps that won't fall back, or anything where you want *everything* routed through the mobile IP without per-app proxy settings. That's exactly why we offer mobile proxies over VPN: a full-device tunnel using WireGuard or OpenVPN, where your traffic — TCP *and* UDP — exits a real mobile IP.

• WireGuard — modern, fast, low-overhead; the default choice for most. Connects almost instantly and handles UDP/QUIC natively.
• OpenVPN — the battle-tested option with the widest client support and the friendliest behaviour on restrictive networks.

So the line-up is deliberate, not a gap: the HTTP/SOCKS5 proxy tier is TCP — clean, predictable, and right for account work; the VPN tier is the full-device tunnel for when you truly need UDP/QUIC. If your setup depends on UDP, you want the VPN line, not a proxy with a UDP toggle forced on. For a deeper comparison of the two tunnels, see WireGuard vs OpenVPN for a mobile line.

The 60-second "is it actually broken?" checklist

Before assuming the line is down, run these in order — they resolve almost everything:

1. 01Check the exit IP. Route the proxy to an IP-check site (or https://api.ipify.org). If it returns a mobile IP, the proxy is up — the issue is above the connection.
2. 02Turn UDP Relay OFF on every server entry, then force-close and reopen the app. This is the single most common fix.
3. 03Confirm HTTP vs SOCKS5. Use the mode your software expects; if DNS matters, prefer socks5h:// so lookups go through the line.
4. 04Don't rotate mid-session. Firing the rotation link while you're logged in throws away the IP your session was bound to and trips an "unusual activity" check. Rotate *between* tasks, not during one. See how to test a proxy before you trust it.
5. 05Blame the right layer. If the exit IP is live and UDP is off but one specific site or account still misbehaves, that's usually the platform reacting to the account — not the proxy. Note the exact app and time.