How to Setup Proxy on Android

An Android phone can be in two states after you configure a proxy, and they look identical from the settings screen. In the first, traffic genuinely egresses through the proxy. In the second, the configuration is stored, the field reads Manual, and a meaningful share of your traffic still leaves over the phone’s own path.

The second state is the expensive one. A price-monitoring pass or a localized SERP snapshot collected from a handset that quietly used its real IP is not partial data – it is wrong data, and nothing in the interface warns you.

This guide covers how to setup proxy on Android across all three configuration surfaces, what each one controls at the network layer, and how to verify the result in about three minutes. Menu paths are given for stock Android 17, Samsung One UI and Xiaomi HyperOS. The labels differ between skins; the underlying behavior does not.

What Android actually stores when you save a proxy

Most published answers to how to setup proxy on Android end at the save button. That is the easy part, and it is not where things go wrong.

The Wi-Fi proxy is not a route. Android saves it inside the configuration object for that specific SSID, and exposes it to applications as a ProxyInfo declaration through the default ProxySelector. The kernel forwards nothing. Every app decides independently whether to read that declaration and honor it.

Three consequences follow immediately, and they explain most of the support tickets in this area. The setting is bound to one network, so switching SSIDs or dropping to cellular silently disables it. The interface offers no username and password fields, so credential-based proxies fail at the first request. And the field expects an HTTP(S) proxy – entering a SOCKS5 endpoint there produces a connection that never completes.

Method 1: Wi-Fi proxy settings

This is the standard answer to how to setup proxy on Android, and the only path that needs neither root nor a companion app.

1. Connect to the Wi-Fi network first, then open its detail screen – the gear icon on Pixel, then the pencil in the top right; Settings → Connections → Wi-Fi → gear → View more on One UI; a long press on the network name on HyperOS.
2. Expand Advanced options and change Proxy from None to Manual.
3. Enter the proxy host in Proxy hostname and the port in Proxy port, exactly as issued.
4. Leave the exclusion field empty unless specific hosts must connect directly – every entry there is a documented hole in your egress path.
5. Save, then forget and rejoin the network. Android applies proxy changes on association, and a stale association is the single most common reason a correct configuration appears to do nothing.

The authentication wall

Here is what the vendor tutorials skip. The Wi-Fi proxy screen has no credential fields at all. If your proxy expects user:password, the server answers 407 Proxy Authentication Required and stops there. Chrome sometimes surfaces a login dialog; native apps almost never do, and they fail quietly instead.

There are exactly two clean ways past this. Either switch the proxy to IP whitelist authentication in the provider dashboard, so the endpoint recognizes your egress address and asks for nothing, or move authentication into a per-app client that accepts credentials.

Whitelisting is the better option – with one hard limit. It authenticates the address your phone leaves from, which is stable behind an office or lab Wi-Fi and effectively random on cellular, where carrier-grade NAT reassigns your public address without notice. Whitelist for fixed-egress Wi-Fi. Never build a mobile-data workflow on it.

Method 2: APN proxy on mobile data

When the device is on cellular – field testing, QA against a real 4G/5G path, collection that must originate off Wi-Fi – the Wi-Fi proxy is simply absent from the picture. The nearest equivalent lives in Settings → Network & internet → SIMs → Access Point Names, inside the active APN, where Proxy and Port fields exist.

Two warnings before you touch that screen. The Username and Password fields on the APN belong to the carrier’s authentication, not to your proxy; putting proxy credentials there is a reliable way to lose mobile data entirely. And on most modern LTE and 5G profiles those proxy fields are vestigial – carriers lock APN editing, ignore custom values, or overwrite the profile on the next configuration push.

Treat APN configuration as an experiment worth ten minutes, not a production method. Photograph the original APN values before editing so you can restore them. If it does not take on the first try, move to a per-app client rather than debugging a field your carrier controls.

Method 3: ADB global proxy and per-app clients

For test benches and device farms, the global setting is a better tool than the Wi-Fi screen. One command applies a proxy that survives reboots and network changes:

adb shell settings put global http_proxy 203.0.113.10:8000

Clearing it takes adb shell settings put global http_proxy :0. Granting WRITE_SECURE_SETTINGS to a toggle app lets non-root devices flip the same value on-device. The failure mode is worth knowing in advance: uninstall a toggle app while the proxy is active and the value persists with no interface left to change it.

Per-app proxy clients are the other route, and the only one that closes every gap at once. Registering through Android’s local tunneling API, they accept SOCKS5, accept credentials, and let you route selected packages while everything else stays direct. The cost is the device’s single tunnel slot, some battery, and one more component sitting in your traffic path. For app-level QA and automation on cellular, that trade is usually worth taking.

Which apps actually honor the proxy

Almost every guide on how to setup proxy on Android treats the setting as system-wide. It is not, and this is where a configuration that looks correct starts producing wrong data.

Browsers respect the system proxy reliably. So does anything built on HttpURLConnection, OkHttp or Retrofit, because those resolve through the default ProxySelector – which covers most Android networking code.

The exceptions are real. Applications embedding their own QUIC stack can carry traffic over UDP/443, where an HTTP proxy declaration has no meaning; Chrome falls back to TCP when a proxy is set, but a third-party Cronet build need not. Anything opening raw sockets from native code ignores the setting completely. And DNS is a separate path: for proxied apps the hostname is resolved by the proxy inside the CONNECT, but Private DNS queries and any app that skipped the proxy resolve on the phone’s own connection, which is exactly the leak that corrupts location-sensitive results.

Verify in three minutes

Never trust a saved configuration. Three checks catch nearly every failure:

1. Open an IP echo endpoint in Chrome and confirm both the address and the country match what you purchased – country is the check people skip, and a right-address-wrong-country result usually means you hit a shared pool rather than your assigned endpoint.
2. Toggle Wi-Fi off and on, then repeat check one. A configuration that only works before reassociation will not survive a working day.
3. Run the same check inside the actual target app or automation stack, not just the browser. If the browser shows the proxy address and the app shows your own, that app is in the ignore list from the previous section and needs a per-app client.

When something breaks, the error usually names the cause. A 407 means the authentication path is wrong – wrong credentials, or whitelist authentication with an egress address that has since changed. ERR_TUNNEL_CONNECTION_FAILED means the proxy answered but refused the CONNECT, typically a port mismatch or a SOCKS5 endpoint entered in an HTTP field. Connected, no internet with a login-page loop means Android’s own connectivity check is being sent through the proxy while the network still wants a captive-portal sign-in.

Choosing a provider for Android work

Provider selection changes with the method you settled on. If the phone runs the native Wi-Fi or ADB proxy, whitelist support is not a nice-to-have – it is the only thing that makes the setup function, and the number of whitelist slots caps your fleet size. If you standardized on a per-app client, credentials work fine, and SOCKS5 becomes available, which shifts the decision back to price and exit quality.

Billing model matters more than headline price. Per-IP monthly pricing gives you the same exit address across an entire test cycle, which is what you want when comparing runs. Per-GB residential billing is the right shape for rotating collection and the wrong shape for a handset that idles between tests.

List prices as of July 2026; volume tiers and promotional rates move these numbers considerably. The Oxylabs row is the one to read twice – SOCKS5 and IP whitelisting are mutually exclusive there outside enterprise dedicated plans, which quietly rules out a common Android configuration.

When switching providers is the right call

Four signals, in rough order of how often they turn out to be the actual cause. Authentication errors that appear without any configuration change usually mean your egress address rotated out of a whitelist. Rising block rates at a constant request profile point at pool reputation rather than your setup. A whitelist slot cap below your device count is a hard ceiling. And no per-IP option at all forces per-GB billing onto a workload that does not fit it.

Proxys.io covers the awkward middle here: static IPv4 from $1.47 per address per month across eleven core locations, HTTP(S) and SOCKS on the same endpoint, both authentication methods available on one plan, and card payments through Stripe for teams billing outside the CIS. IPv6 from $0.13 per address is worth a look for high-volume collection against targets that support it.

Going deeper

Single-handset configuration is the easy half. Once the same proxy has to serve an emulator grid or an automation stack, endpoint format, session control and rotation logic become the real work – the residential proxy implementation guide covers session IDs, sticky sessions and the error codes that matter in that context.

FAQ

Does the Wi-Fi proxy cover every app?

No. It is a declaration, not a route. Browsers and anything using OkHttp or HttpURLConnection follow it; apps with an embedded QUIC or native networking stack can ignore it entirely. Verify per app rather than assuming system-wide coverage.

Can I configure a proxy on Android without root?

Yes, all three methods work unrooted. The Wi-Fi and APN screens need nothing extra, and the ADB global setting only requires a USB connection. Root becomes relevant only for transparent redirection at the firewall level, which is rarely necessary.

Why does the proxy stop working when I leave the office?

Because Wi-Fi proxy settings are stored per network, and because whitelist authentication keys are on your public egress address. New network, no proxy; cellular, new address, failed authentication. Use the ADB global setting or a per-app client for anything mobile.