Android Proxy Settings: Wi-Fi, PAC and 407 Fixes

Stock Android ties the proxy you set in Settings to one saved Wi-Fi network, not to the whole phone. Google's Pixel Phone Help gives the path: Settings, Network & internet, Internet, tap the network, tap Edit, open Advanced options, then pick a configuration type under Proxy. Device makers rename these screens, so if yours differ, search Settings for proxy, as Google's Android Help advises for any setting you cannot find.

The per-network design has four consequences for a Databay route:

• Scope. The proxy applies only while the phone uses that Wi-Fi network; mobile data and other networks keep their own routing.
• Credentials. The form has no username or password field, so the Databay credential can be supplied only where an app asks for it.
• Protocol. The form offers no SOCKS5 choice; use the gateway's HTTP mode on port 8888.
• Coverage. Google's emulator documentation says browsers and most applications use the system proxy, but some apps may ignore it.

Use the route only for destinations you own or are permitted to test, such as your own site, your app's backend or ad placements you are authorized to verify, and follow each destination's terms. A proxy changes the network path, not what an account or site allows.

In the Android Open Source Project's Wi-Fi network dialog, the Proxy dropdown offers None, Manual and Proxy Auto-Config. Manual adds a hostname, a port and an exclusion list for hosts that should connect directly; Proxy Auto-Config adds a PAC URL. Vendor builds may relabel these controls; match them by purpose.

Before touching the phone, prove the credential from a laptop on the same Wi-Fi with the cURL proxy setup guide; if cURL fails there, no phone setting will fix it.

Choose Proxy Auto-Config when only some destinations should leave through Databay. Android's ProxyInfo reference describes a PAC configuration as one that downloads and runs the script at the given URL. The script returns routing decisions, not credentials, so Manual mode's authentication limits still apply.

function FindProxyForURL(url, host) {
  // The verification page and approved test hosts use the gateway.
  if (host === "databay.com" || shExpMatch(host, "*.example.com")) {
    return "PROXY gw.databay.co:8888";
  }
  return "DIRECT";
}

Host the file on an HTTPS server you control, keep secrets out of it, and replace the example.com pattern with destinations you are permitted to test. Keeping databay.com in the rule lets the verification page share the work's path; everything else connects directly, off the per-GB route.

Because the Wi-Fi form stores no credential, an app's first request to gw.databay.co:8888 arrives without one. Under RFC 9110, a proxy that requires authentication answers 407 Proxy Authentication Required with a Proxy-Authenticate challenge, and the client may repeat the request with a Proxy-Authorization header. Whether that retry happens depends on the app's own network code, not on Android:

• The app shows a proxy sign-in prompt. Enter the complete Databay username and password there, after checking that the prompt names the proxy at gw.databay.co:8888; a website login form is not a proxy prompt.
• The app fails with a connection or tunnel error while the browser works. It most likely received the challenge and cannot answer it; use the emulator route for QA, or an in-app proxy setting only where the app's developer documents one.
• The app keeps working from your normal IP. It is not following the system proxy; see the troubleshooting table.

Type the password only into that prompt: paste it from a password manager or secret store, keep screenshots and screen recording off while the prompt is open, and never paste it into tickets or chat. Let an app remember it only on a phone you control with a screen lock, since anyone holding the device can reuse the route, and rotate the credential if it appears in a capture or log.

1. With Proxy set to None, open Databay's What Is My IP page in the phone browser and note the direct address and location estimate as your control.
2. Edit the same network to Manual with gw.databay.co and 8888, save, and reload the page. Answer the proxy prompt if the browser shows one.
3. Record the observed IP; the country, region and timezone estimate; the network name; the username's routing segments without the password; and the UTC time.
4. Compare the observation with the route requested in the username. A matching country is evidence for that request only.
5. Repeat the check inside each app that matters, against a destination you control that logs the source address, before the app opens its real backend.

The page reports the address one destination observed for one request. It is not proof of anonymity, of future routing, or that every app on the phone follows the same path. For machine-readable evidence, cURL on a laptop on the same network can request https://databay.com/what-is-my-ip/json with the credential.

Android does not choose the exit; the username does. Copy the complete username from the Databay dashboard instead of composing its grammar by hand. The documented pattern carries pool and country, as in USER-zone-residential-countryCode-us; a sticky session adds a sessionId segment, as in USER-zone-residential-countryCode-us-sessionId-abc123. Choose the pool from the test requirement, not the device type: Premium Residential targets one of country, state, city, ZIP, coordinate or ASN at a time, while Residential Flex, Datacenter and Mobile each target a country or continent.

All pools are shared, and none reserves an address for one customer. A sticky session requests continuity for up to 1440 minutes on Premium Residential and Residential Flex where available, or up to 120 minutes on Datacenter and Mobile. The IP can change before the window ends. Without one, a new proxy connection may select an available exit while a reused connection or tunnel may keep the same one; a different IP is not promised. Because browsers typically reuse connections, two page loads can show one exit and a later reconnect another, so for multi-page checks use a sticky username and re-verify at each checkpoint. Traffic is billed per GB and every app that honors the Wi-Fi proxy adds to it, so set the network back to None when the session ends.

On devices managed with the Android Management API, administrators can set the proxy by policy. The Policy resource's recommendedGlobalProxy field takes a ProxyInfo object, which Google describes as configuration for an HTTP proxy: host, port and excludedHosts for a direct proxy, where host names may use wildcards such as *.example.com, or pacUri for a PAC script.

{
  "recommendedGlobalProxy": {
    "host": "gw.databay.co",
    "port": 8888,
    "excludedHosts": ["*.corp.example.com"]
  }
}

Treat Google's caveats as stop conditions. The field description says proxies should typically be configured per network in openNetworkConfiguration, that network access may break if the proxy is not accessible, and that the global proxy is only a recommendation some apps may ignore. Google's network configuration guide adds that per-network ProxySettings is optional and supports only Manual and PAC. Neither shape has a credential field, so apps that follow the proxy but cannot answer a 407 will fail on every device that receives the policy. Pilot one test device, prefer pacUri when only approved hosts should use the gateway, and keep a policy version without the proxy ready for rollback.

For repeatable app QA, the Android Emulator offers a mechanism that can carry the credential. Google's emulator proxy guide separates the Android System Proxy, the Wi-Fi setting inside the virtual device, from the Emulator Proxy, which routes all of the virtual device's TCP traffic through a proxy set with the -http-proxy flag or Extended controls. The command-line reference accepts http://server:port or http://username:password@server:port; this is the only place this guide shows a credential inside a URL, and the pattern does not belong in scripts or documentation:

# QA workstation only: both variables come from a secret store at launch
emulator -avd QA_Device \
  -http-proxy "http://${DATABAY_PROXY_USER}:${DATABAY_PROXY_PASS}@gw.databay.co:8888"

The expanded URL can be visible to other local users in process listings, and reserved password characters can break URL parsing, so run it only on a workstation you control, with shell tracing off and the line out of committed scripts and build logs; rotate the credential if it leaks. Google documents the two mechanisms as mutually exclusive, so leave the virtual device's Wi-Fi proxy at None. The Emulator Proxy tunnels HTTPS without decrypting it, has no exclusion list, does not redirect UDP, and needs a restart after Extended controls changes. Verify the exit in the emulator's browser before the app under test reaches its real backend.

Change one variable at a time, keep each failed observation, and start from the first layer that failed:

For background on the missing SOCKS5 option, see HTTP versus SOCKS5 proxies.