Most guides on how to set up a proxy on Android stop at “open Wi-Fi settings, type the IP, done.” Then your traffic leaks, half your apps ignore the proxy, and the connection dies the moment you switch from Wi-Fi to mobile data. The setup itself takes ninety seconds. Understanding why it breaks is the part that matters.
This guide is written for people who run real workloads on Android – mobile data collection, ad verification across markets, SEO and SERP monitoring on handheld devices, and QA against cellular environments. The mechanics are the same whether you configure one device or a fleet of them. The mistakes are also the same, which is why most of this article is about the failure modes nobody warns you about.
How proxy routing really works on Android
The first thing to unlearn: Android does not have a true system-wide proxy in the way a desktop does. When you set a proxy in Wi-Fi settings, you are setting it for that Wi-Fi network only, and even then it is a polite request, not a hard rule. Apps that use the standard HTTP stack honor it. Apps that ship their own networking layer quietly route around it.
That single fact explains most “my proxy isn’t working” tickets. The proxy is applied correctly; the app simply never asked the system where to send packets. Chrome obeys the Wi-Fi proxy. Many native apps do not. This is by design, not a bug.
There are three layers where you can intervene, and choosing the right one before you touch any settings saves the most time:
The Wi-Fi layer is per-network and HTTP-only. The APN layer routes mobile data. The application layer – a per-app routing client – sits on top of Android’s VpnService interface and captures traffic from apps that ignore everything else. Pick the layer that matches your traffic, then configure it.
Method 1: Set up a proxy on a Wi-Fi network
This is the fastest path and covers browser-based work, lightweight scraping from a mobile browser, and quick IP checks. On a Pixel running Android 14 the path is Settings → Network & internet → Internet, then the gear icon next to your connected network. Steps for setting up a proxy on Android this way:
- Tap the gear (or pencil) icon beside your active Wi-Fi network, then expand Advanced options.
- Find Proxy – it defaults to None – and switch it to Manual.
- Enter the Proxy hostname (your IP) and Proxy port exactly as your provider gave them.
- Leave Bypass proxy for blank unless you need specific domains to connect directly.
- Save (the checkmark at the top), then open Chrome and load any page to confirm it routes.
Manufacturer skins move things around – Samsung One UI and Xiaomi HyperOS bury the proxy field under “Advanced” or “Manage network,” but the field is always there on non-rooted devices. No root, no extra app.
The credentials gap you will hit immediately
Here is the catch the official docs gloss over: the Wi-Fi proxy UI has no username and password fields. If your proxy uses login authentication, the first request in a browser triggers a sign-in pop-up where you enter credentials manually. Native apps usually will not show that prompt, so they fail silently.
Two clean ways around this. Use IP whitelist (allowlist) authentication instead of login/password, so the proxy recognizes your device by its real egress IP and needs no credentials at all. Or move authentication up to a per-app client (Method 3) that does accept a login and password. For browser-only tasks, whitelisting is the least painful option by a wide margin.
Method 2: Route mobile data through an APN
When the device is on cellular – field testing, QA against a 4G/5G path, or data collection that has to originate off Wi-Fi – the Wi-Fi proxy does nothing. You configure the proxy inside the Access Point Name instead.
- Open Settings → Network & internet → SIMs, tap the active SIM, then Access Point Names.
- Tap your current APN, scroll to the Proxy and Port fields, and enter your proxy host and port.
- Add the proxy username and password in the APN fields if your provider supplies them.
- Save from the three-dot menu, then toggle mobile data off and back on to apply.
A practical warning: some Android builds reset the APN to carrier defaults after a reboot or a network change. Do not edit the carrier’s default APN – duplicate it, give the copy a distinct name, put your proxy values there, and switch to it manually. When the OS resets, your clean copy survives.
Method 3: Per-app routing for everything the system ignores
When you need apps that bypass the system proxy to actually use one, you need a routing client. These apps register a local tunnel through Android’s VpnService API and forward selected apps’ traffic to your upstream proxy. Android shows a small key icon in the status bar while the tunnel is active.
Super Proxy is the simplest for HTTP and SOCKS5 with a clean per-app selector. V2rayNG and NekoBox are actively maintained, support multiple upstream protocols, and let you scope routing to specific apps – useful when you only want one workload proxied and the rest of the device on its normal connection. On rooted devices, ProxyDroid uses iptables for genuine system-wide routing without the tunnel layer.
The setup is consistent across all of them: install, create a profile with host, port, protocol and credentials, choose which apps to route, then connect. The trade-off worth stating plainly – the routing app sees every byte it forwards, so use maintained, open-source clients rather than whatever ranks first in the Play Store.
One failure mode burns hours if you miss it: Android’s battery optimizer kills background tunnels when the screen sleeps. For any long-running session, open Settings → Apps → your client → Battery and set it to Unrestricted. Skip this and your automation dies overnight with no error.
SOCKS5 on Android
The native Wi-Fi proxy field is HTTP/HTTPS only. Paste SOCKS5 details into it and authentication simply fails – the OS does not speak SOCKS at that layer. SOCKS5 matters because it carries both TCP and UDP and sidesteps the HTTPS-tunneling overhead of an HTTP proxy, which is why scraping and automation toolchains often prefer it.
To run SOCKS5 you go through a routing client (Method 3) or a rooted ProxyDroid setup. There is no native, non-rooted way to put SOCKS5 into the system Wi-Fi settings, and any guide that tells you otherwise is describing a different protocol.
| Method | Routes | Auth support | Best for |
| Wi-Fi (Manual) | Browser + HTTP-aware apps on that network | None (browser pop-up only) | Quick browser tasks, IP checks |
| APN | Mobile data traffic | Username/password in APN fields | Cellular field testing, off-Wi-Fi collection |
| Per-app client | Any selected app, TCP + UDP | Full, in-app | SOCKS5, apps that ignore the system proxy |
| ADB (global) | System global HTTP setting | IP allowlist only | QA, CI, device farms at scale |
Verify the proxy is actually live
Never trust the green icon. Open Chrome, hit an IP checker such as browserleaks.com/ip, and confirm both the IP and the country match what you configured. If your real IP shows up, the app you tested is bypassing the proxy – that is the single most common tell, and it points you straight back to Method 3.
Run a DNS leak test too. A proxy can mask your IP while your device still resolves DNS through the carrier, which quietly reveals location to anything checking. If the resolver doesn’t match the proxy’s region, your setup is leaking even though the IP looks correct.
Setting proxies at scale with ADB
For QA pipelines, device farms, and CI you do not touch a UI at all. ADB writes to the same global setting the OS honors after a network change:
adb shell settings put global http_proxy host:port
Disable it just as fast with adb shell settings put global http_proxy :0, which takes effect without rebooting – that speed is exactly why test scripts use it for teardown. There is no reliable ADB command for credentials, so for authenticated upstreams use an IP-allowlisted endpoint or chain through a local proxy on the test runner that handles auth and forwards plain HTTP to the device. Inject the proxy at job start, run the suite, clean up at the end, and keep credentials out of the device image.
Picking a provider for Android workloads
The setup method constrains your provider choice more than people expect. If you rely on Wi-Fi-only configuration, you need IP-allowlist authentication because the UI can’t pass a password. If you run per-app clients or APN routing, login/password works fine. And SOCKS5 demands a provider that actually offers it on the plan you buy.
Three attributes decide it for mobile work: protocol coverage (do you get SOCKS alongside HTTP/HTTPS), authentication options (allowlist and credentials), and IP type – datacenter for raw speed on tolerant targets, residential or mobile IPs where the target scrutinizes the connection’s reputation.
| Provider | IP types | SOCKS5 | Auth options | Entry price | Best fit |
| Proxys.io | Datacenter, residential, mobile, IPv6 | Yes (HTTPS/HTTP/SOCKS) | Allowlist + login/password | from $1.47/mo (foreign IPv4), $0.13/mo (IPv6) | Wi-Fi, APN and per-app on one account |
| Webshare | Datacenter, residential | Yes | Login/password | Free tier (10 proxies) | Testing the workflow before scaling |
| Oxylabs | Residential, mobile, datacenter | Yes | Allowlist + login/password | Premium / usage-based | High-scrutiny targets, large budgets |
The practical read: a free tier is the right place to confirm your method works before committing, and premium residential pools earn their cost only when targets are genuinely hard. For the broad middle – steady mobile data collection, ad verification, SEO monitoring – protocol flexibility and a low per-IP cost matter more than brand. Proxys.io covers all three Android layers from one account, with HTTP, HTTPS and SOCKS on the same IPs and both authentication styles, which removes the most common reason a setup fails before it starts.
Common failures and the fix for each
The proxy “works” but the IP never changes – the app under test owns its network stack; route it through a per-app client. Mobile data dies after a reboot – the APN reset to carrier defaults; switch back to your named duplicate. The tunnel drops when the screen sleeps – battery optimization killed it; set the client to Unrestricted. A browser keeps asking you to sign in – that is the Wi-Fi UI’s missing credential fields surfacing; switch to allowlist auth or move to a client. Connection refused on every request – almost always wrong credentials or a port typo, not a dead proxy; re-check both before you blame the provider.
Frequently asked questions
Does a proxy on Android cover all apps?
No. Android applies proxy settings per network and on a best-effort basis. Browsers and HTTP-aware apps follow the Wi-Fi or APN proxy, but apps with their own networking stack ignore it. For full coverage of a specific app, use a per-app routing client rather than the system settings.
Why does my Android proxy work in Chrome but nothing else?
Chrome respects the system HTTP proxy; many native apps do not. They use independent connection code that never reads the Wi-Fi setting. Route those apps through a per-app client built on Android’s VpnService, which captures their traffic regardless of what the system proxy says.
Can I use SOCKS5 in Android’s native settings?
No. The built-in Wi-Fi proxy field handles HTTP and HTTPS only, so SOCKS5 credentials fail there. Use a routing app such as Super Proxy, V2rayNG or NekoBox, or ProxyDroid on a rooted device. Our step-by-step Android proxy walkthrough covers the app-based SOCKS5 path in detail.
How do I confirm the proxy is actually working?
Open a browser, visit an IP-checking page, and verify the IP and country match your configuration. Then run a DNS leak test to be sure the device isn’t resolving DNS through the carrier. If your real IP or local resolver appears, the proxy is being bypassed somewhere.
The setup that actually holds up
Learning how to set up a proxy on Android is less about the menu taps and more about matching the right layer to your traffic: Wi-Fi for browser work, APN for cellular, a per-app client for everything that ignores the system. Get the authentication style right for your method, disable battery optimization on long jobs, and verify with an IP and DNS check before you trust a single result. Do that and the connection stays up; skip it and you will spend more time debugging the proxy than doing the work it was meant to enable.
