Android does have proxy fields, but they are attached to a single Wi-Fi network, they cannot hold a username and password, and a lot of apps ignore them. Here is what the built-in setting really does, and the two methods that work when it does not.
Android has no global proxy switch. What it has is a proxy configuration stored inside each saved Wi-Fi network. Open Settings → Network & internet → Internet, tap the gear or pencil beside the network you are joined to, expand Advanced options, and set Proxy from None to Manual. Three fields appear:
gw.pyproxy.com.1111.Save, and Android writes those values into that Wi-Fi profile. The other choice in the same menu, Proxy Auto-Config, takes the URL of a PAC file instead and lets a script decide per request. That is all the operating system exposes. There is no SOCKS option and, importantly, no place to put a username or a password.
Because the setting lives inside a Wi-Fi profile, it applies to exactly that one network. Walk out of the building and the phone falls back to mobile data with no proxy at all — the fields are simply not part of the mobile network configuration, and stock Android gives you nowhere to enter them for a SIM connection. Join a different Wi-Fi network and you start again from None.
The second half of the limitation is worse. The Wi-Fi proxy is a hint published to the system, and it is up to each application to read it. Chrome and most apps built on Android's own HTTP stack do respect it. Apps that open raw sockets, ship their own networking layer, or use certain cross-platform frameworks do not, and there is no way to force them. So the honest description of the built-in setting is: it proxies some of your traffic, on one network, until you move.
Commercial proxies almost always authenticate. The usual mechanism is HTTP proxy authentication: the
client sends a Proxy-Authorization header, or you embed the credentials in the proxy URL
like http://user:pass@host:port. Android's Wi-Fi dialogue has no field for either, and on
most versions there is no hidden way to add one. Point it at an authenticated gateway and every request
comes back 407 Proxy Authentication Required, usually surfacing as a blank page or a
generic connection error.
Some providers work around this by authorising an address instead of a password, so that connections arriving from your own public address are accepted without credentials. Where that is offered it makes the stock Wi-Fi dialogue usable, with the catch that your public address has to stay the same — and on mobile data it changes constantly, which defeats the idea. PyProxy is not one of those providers: its gateway authenticates with a username and password, so the Android Wi-Fi fields cannot reach it at all.
That leaves the answer most people should use anyway, which is to stop involving the operating system.
Any app that has its own proxy settings can authenticate properly, because it builds the request itself. This is how scraping tools, automation apps, download managers, API clients and most browsers aimed at power users handle it. You enter four things — host, port, username, password — and that app's traffic goes through the proxy while the rest of the phone is untouched.
For a PyProxy residential gateway the values are:
Type: HTTP (residential is HTTP/HTTPS only, not SOCKS5) Host: gw.pyproxy.com Port: 1111 Username: USERNAME-country-us Password: PASSWORD
The username is where the options live. -country-us pins the exit to the United States;
adding a session token holds one exit address for about thirty minutes instead of rotating on every
request, which matters if the app has to stay logged in to something. If you have a terminal app such as
Termux on the phone, the fastest way to confirm the credentials before touching any GUI is:
curl -x http://USERNAME-country-us:PASSWORD@gw.pyproxy.com:1111 https://httpbin.org/ip
If that prints an address in the United States, the gateway and your credentials are fine and anything still failing afterwards is the app's configuration.
Most apps have no proxy fields. To route those, you need something that intercepts traffic at the device level. On Android that means a client which registers itself as a VPN service — not to connect to a VPN, but because the VPN API is the only supported way for an app to capture other apps' packets. Such clients accept a normal HTTP proxy with a username and password, then apply per-app rules: this app through the proxy, that app direct, everything else direct.
These are third-party tools that this shop does not publish, so evaluate whichever you choose on its own terms. Two things are worth checking before you trust one: that it supports HTTP/HTTPS proxies with authentication and not only SOCKS5 or VPN protocols, and that it lets you pick applications individually. Note also that Android allows only one active VPN service at a time, so a per-app proxy tool and an actual VPN cannot both run.
Do not trust the settings screen. Check the address the far end sees, inside the app you care about:
https://httpbin.org/ip
Load that in the configured browser or fetch it from the configured app. If it returns the gateway's exit address, the traffic is proxied. If it returns your own address, it is not — and the most common reasons, in order, are that the app ignores the system Wi-Fi setting, that the phone silently moved to mobile data, or that authentication is failing because the credentials never reached the proxy.
A useful second check is to run the same page twice through a rotating gateway. Two different exit addresses confirm you are going through a pool rather than a single cached route. Then, and only then, test what you actually wanted to do.
No. The proxy fields live inside the saved Wi-Fi network, so they apply only while you are joined to that one network. Switch to another Wi-Fi network or to mobile data and the phone connects directly again.
The stock Wi-Fi proxy dialogue on most Android versions offers only hostname, port and a bypass list. There is no credentials field, so an authenticated gateway cannot be used there. PyProxy authenticates with a username and password, so configure the proxy inside an app that accepts credentials itself rather than in the Wi-Fi settings.
No. It is a system hint that well-behaved HTTP clients read. Plenty of apps open their own sockets and ignore it completely, which is why traffic you expected to be proxied often is not.
Open a page that reports the address the request arrived from, such as httpbin.org/ip, in the app you configured. If it shows the proxy exit address rather than your own, the traffic is going through. Check it inside the app that matters, not only in a browser.