How to Set Up a Proxy on iPhone and iPad (Wi-Fi)

The proxy you type into iOS Settings is an HTTP proxy attached to a single saved Wi-Fi network. Most "my iPhone proxy isn't working" reports come down to one of the rows below.

The URLSession row comes from Apple's connectionProxyDictionary reference: "The default value is nil, which means that tasks use the default system settings." That's why most mainstream apps follow your proxy and a minority don't. An app that pins its own proxy configuration, or sets an empty one, routes around you, and nothing in Settings can force it.

There is no SOCKS option. The Settings screen offers Off, Manual and Automatic, and Apple's Wi-Fi configuration payload exposes only ProxyType (None, Manual, Auto), ProxyServer, ProxyServerPort, ProxyUsername, ProxyPassword, ProxyPACURL and ProxyPACFallbackAllowed. SparkProxy's SOCKS5 port (13000) is for desktop tools. On the phone you use the HTTP ports.

HTTPS still works through an HTTP proxy. Safari asks the proxy to open a tunnel with CONNECT, and TLS runs end to end inside it, so the proxy sees the hostname but not the page.

If your end goal is a QA programme rather than one phone, our guide to proxies for mobile app testing teams covers where to insert a proxy across simulators, emulators and device farms. This post stays on a real iPhone or iPad.

Typing credentials on a phone keyboard is where most failed setups begin, so get the values right on a laptop first.

Country selection rides on the credential. The sample credential on the SparkProxy homepage shows a country suffix in the username (user-country-us). Copy the exact username your dashboard issues for the country you want rather than editing it by hand, because one wrong character produces the same 407 as a wrong password.

Then test that credential from any computer on the same Wi-Fi. This curl call goes through the gateway and prints the exit IP and country:

curl -s -x "http://YOUR_USERNAME:YOUR_PASSWORD@gateway.sparkproxy.io:11000" https://ipinfo.io/json

A good result is a JSON object whose ip is not your office IP and whose country matches the one you chose. A bad credential fails before any page loads. We sent a request with no credentials to the gateway on 2026-10-30, and it answered:

HTTP/1.1 407 Proxy Authentication Required
X-Squid-Error: ERR_CACHE_ACCESS_DENIED 0
Proxy-Authenticate: Basic realm="SparkProxy"
Via: 1.1 gateway.sparkproxy.io (squid/7.3-VCS)

Remember that realm, SparkProxy. It's the name you'll see if the iPhone ever shows a sign-in sheet for the proxy. If you prefer Python, this does the same check and turns the failure into a readable message:

import sys

import requests

USER = "YOUR_USERNAME"
PASSWORD = "YOUR_PASSWORD"
PORT = 11000  # 11002 for Sticky Sessions

proxy = f"http://{USER}:{PASSWORD}@gateway.sparkproxy.io:{PORT}"
proxies = {"http": proxy, "https": proxy}

try:
    resp = requests.get("https://ipinfo.io/json", proxies=proxies, timeout=20)
except requests.exceptions.ProxyError as exc:
    if "407" in str(exc):
        sys.exit("Proxy rejected the credential (407). Fix it here before typing it on the phone.")
    sys.exit(f"Could not reach the proxy: {exc}")

data = resp.json()
print(f"exit IP {data.get('ip')}  country {data.get('country')}  network {data.get('org')}")

With requests 2.32.5 on Python 3.14.2, a bad credential raised ProxyError containing Tunnel connection failed: 407 Proxy Authentication Required, which is what the "407" in str(exc) test matches. If this script prints an IP and country, the credential is good and anything that goes wrong later is on the phone side.

The path is the same on iPhone and iPad. Apple's Setup Assistant article (published 2025-03-21) lists "Set up an HTTP proxy" among the options on a network's info screen, and the same screen is reachable from Settings at any time.

1. Connect to the Wi-Fi network you'll test on. The setting attaches to the network you open, so join the right one first.
2. Open Settings > Wi-Fi and tap the info button next to the connected network.
3. Scroll to the bottom and tap Configure Proxy.
4. Choose Manual.
5. Server: gateway.sparkproxy.io. No http://, no trailing slash.
6. Port: 11000 or 11002.
7. Turn on Authentication and enter the username and password exactly as the laptop test used them.
8. Tap Save, then go back one screen so the network reconnects with the new settings.

Two small things trip people up. Autocorrect and auto-capitalisation can alter a username as you type it, so paste it from a note or a password manager instead. And a trailing space copied with the password is invisible in the field but enough to fail authentication.

To turn the proxy off later, return to the same screen and set Configure Proxy back to Off. The values aren't kept, so save them somewhere if you switch often.

The single most common complaint about iPhone proxies is a sign-in sheet that keeps coming back, sometimes over Safari, sometimes over an unrelated app. It appears when a request reaches the gateway without credentials the gateway accepts, and the gateway answers with the Basic realm="SparkProxy" challenge shown above.

Work through the causes in this order, cheapest first:

1. Authentication toggle is off. Reopen Configure Proxy. If the switch is off, the phone sends nothing and every request is challenged.
2. The stored value is wrong. Re-enter the password from scratch rather than editing it. Check for a trailing space and a capitalised first letter.
3. The credential changed upstream. A password reset in the dashboard, an expired trial or a username with a different country suffix all produce the same prompt. Run the laptop test from the previous section; if it fails there too, the phone isn't the problem.
4. A background process doesn't use the saved credential. User reports describe prompts that appear while no app is open, which points at system services or apps that send their own requests without the credential stored on the Wi-Fi network. Apple doesn't document which processes behave this way, so treat it as observed behaviour rather than a rule. Retyping the password doesn't help with this one.

Cause 4 is the one with a clean fix: remove the challenge altogether with IP whitelisting. SparkProxy supports both whitelist and user:pass authentication on every plan. On a Wi-Fi network, every device leaves the building through the router's public IP, so whitelist that address and the gateway stops asking anybody on that network for a password.

Find the network's public IP with the proxy turned off. Open this in Safari on the phone, or run it from a laptop on the same network:

curl -s https://api.ipify.org

Add that IP to the whitelist in your SparkProxy dashboard, then go back to Configure Proxy on the phone, keep Server and Port, and turn Authentication off. The prompts stop because there is no longer a challenge to answer. Our explainer on IP whitelisting for proxies goes through the trade-off in more depth, and how proxy authentication works covers the 407 handshake itself.

Know the costs before you choose it:

• Whitelisting authorises every device on that network, not just your test phone.
• Home and many office connections get a new public IP from the ISP now and then. When it changes, the proxy starts refusing again until you update the whitelist.
• Behind carrier-grade NAT, the public IP is shared with strangers. Don't whitelist an address you can't be sure is yours alone.

Whitelisting pairs well with the per-network design of the iPhone setting: the proxy only applies on one Wi-Fi, and the whitelist only trusts that Wi-Fi's exit. Leave the phone and both stop applying together.

The proxy is a property of the Wi-Fi network. The moment the phone sends traffic over cellular, that traffic goes direct, with your carrier's IP and your real country. There are three ways this happens during a test, and only the first is obvious.

You walk out of range. The phone drops the Wi-Fi network and everything moves to cellular.

Connectivity Assist borrows cellular. Apple's support article on it (published 2026-09-14) says Connectivity Assist "replaces and supersedes Wi-Fi Assist, previously found in Cellular settings" and "uses cellular data to improve your connection when Wi-Fi is slow or unusable." If Wi-Fi Assist was on before you updated, Connectivity Assist starts on. The switch is now under Settings > Wi-Fi, and Apple says it can also be turned off for a single network. A slow proxied page is exactly the case it's built to rescue, which is why a geo test can quietly finish loading over the carrier.

The app picks cellular itself. Apps can ask for cellular explicitly, and some do for real-time features.

For any test where the country matters, turn Cellular Data off for the duration (Settings > Cellular, or Mobile Data in some regions) and switch off Connectivity Assist. A Wi-Fi-only iPad doesn't have this problem, which makes it the easier device for geo checks.

Could you proxy cellular instead? Apple's Cellular payload does have APN proxy fields, and it doesn't require supervision. Its APN entry offers ProxyServer and ProxyPort, and the only Username and Password keys belong to the APN login, not the proxy. So a cellular APN proxy has no way to carry SparkProxy credentials, which leaves IP whitelisting, and the IP you'd have to whitelist is your carrier's shared, changing exit. In practice it's a dead end for a commercial proxy. The supported route for "everything, on every interface" is the global proxy covered below.

Don't trust the saved setting. Ask a server what it sees. In Safari on the phone, open:

https://ipinfo.io/json

You get a small JSON page. Read three fields: ip (should be a SparkProxy exit, not your router's address from the whitelist step), country (should match the credential you chose) and org (the network that owns the exit IP). Then turn Wi-Fi off and load the page once more over cellular. You should see your carrier and real country, which proves the comparison is working and not cached.

If Safari shows your own IP while the proxy is set, check Private Relay before anything else. Apple's developer note says Private Relay "protects users' web browsing in Safari, DNS resolution queries, and insecure http app traffic," and Apple doesn't document how it interacts with a manual HTTP proxy. Remove the doubt by turning it off for the test network: Apple's article on managing Private Relay (published 2026-10-01) gives the path as Settings > Wi-Fi, the More Info button next to the network, then Limit IP Address Tracking. The same Apple page mentions geo-IP annotation fields such as is_relay for marking relay addresses, so an org you don't recognise is worth checking.

For a quick rotation check, reload the page a few times on port 11000 and watch ip change. On 11002 it should hold steady. Deeper testing (latency, HTTPS versus HTTP, health scripts) is covered in how to test if your proxy is working, so we won't repeat it here.

What the IP check can't tell you: Safari still reports the phone's own time zone and language to every site, Location Services still reports GPS, and the App Store storefront is an Apple Account setting (Apple's guide to changing country or region, published 2026-10-05, asks for a payment method valid in the new country). A proxy changes the IP address and nothing else on that list. If a site still shows your home country with a correct exit IP, compare against those signals before blaming the proxy.

The port decides how often the exit IP changes, and on a phone the wrong choice looks like a broken app.

A browser loading one page opens many connections, so on Random Rotation the page's assets can arrive from several IPs. For "does this page show the German price" that's harmless. For an app login, the server sees the session hop countries between requests, and many will kill it. Use Sticky Sessions for anything with a sign-in, and see what a sticky session proxy is for how the window behaves.

Concurrency matters less on one phone than on a scraper, but it adds up when a team shares a plan across several devices. SparkProxy plans are packs, starting from $75/month (USD, read from sparkproxy.io on 2026-10-09), with unlimited bandwidth included. The billing unit is the plan and its concurrency, not gigabytes, so streaming test video through the proxy doesn't run up a traffic bill. The 24-hour free trial needs no credit card, which is enough time to run the whole checklist in this guide on a real device before buying.

Typing the setting by hand on five test phones invites five different typos. A configuration profile carries the Wi-Fi network and its proxy in one file. Apple's Wi-Fi payload (com.apple.wifi.managed) allows manual install on iOS and doesn't require supervision, so any iPhone or iPad can take it.

This script writes the profile with Python's standard library:

import plistlib
import uuid

SSID = "QA-Lab-5G"
WIFI_PASSWORD = "wifi-passphrase"
PROXY_USER = "YOUR_USERNAME"
PROXY_PASS = "YOUR_PASSWORD"
PROXY_PORT = 11002  # Sticky Sessions; use 11000 for Random Rotation


def new_uuid() -> str:
    return str(uuid.uuid4()).upper()


wifi_payload = {
    "PayloadType": "com.apple.wifi.managed",
    "PayloadVersion": 1,
    "PayloadIdentifier": "io.sparkproxy.qa.wifi",
    "PayloadUUID": new_uuid(),
    "PayloadDisplayName": f"{SSID} through SparkProxy",
    "SSID_STR": SSID,
    "EncryptionType": "WPA2",
    "Password": WIFI_PASSWORD,
    "AutoJoin": True,
    "ProxyType": "Manual",
    "ProxyServer": "gateway.sparkproxy.io",
    "ProxyServerPort": PROXY_PORT,
    "ProxyUsername": PROXY_USER,
    "ProxyPassword": PROXY_PASS,
}

profile = {
    "PayloadType": "Configuration",
    "PayloadVersion": 1,
    "PayloadIdentifier": "io.sparkproxy.qa",
    "PayloadUUID": new_uuid(),
    "PayloadDisplayName": "SparkProxy QA Wi-Fi",
    "PayloadContent": [wifi_payload],
}

with open("sparkproxy-qa-wifi.mobileconfig", "wb") as fh:
    plistlib.dump(profile, fh)

print("wrote sparkproxy-qa-wifi.mobileconfig")

Every key there comes from Apple's Wi-Fi payload reference. Drop the two credential keys if you've whitelisted the network instead. To get the file onto the phone, serve it from a laptop on the same network and open it in Safari:

python3 -m http.server 8000
# then on the phone: http://<laptop-LAN-IP>:8000/sparkproxy-qa-wifi.mobileconfig

Apple's install article (published 2026-04-14) gives the rest: open Settings, tap Profile Downloaded, then Install. Two details from that page matter here. "If a profile is not installed within 8 minutes of downloading it, it is automatically deleted," and Stolen Device Protection must be turned off before installing a profile unless you're in a familiar location. Turn it back on afterwards. The file holds the proxy password in plain text, so stop the web server and delete the file once the phones are done.

When a test genuinely needs all traffic proxied, on Wi-Fi and cellular alike, Apple has a payload for it: Global HTTP Proxy (com.apple.proxy.http.global). It accepts ProxyServer, ProxyServerPort, ProxyUsername and ProxyPassword, so SparkProxy credentials fit. The catch is in Apple's availability table: it "Requires supervision" on iOS. Supervision is set when a device is prepared in Apple Configurator for Mac or enrolled through Automated Device Enrollment, and preparing an existing phone for supervision means erasing it. That's fine for a dedicated test device and wrong for your own phone.

The payload body, inside the same outer profile structure as the Wi-Fi example:

<dict>
    <key>PayloadType</key>
    <string>com.apple.proxy.http.global</string>
    <key>PayloadVersion</key>
    <integer>1</integer>
    <key>PayloadIdentifier</key>
    <string>io.sparkproxy.qa.globalproxy</string>
    <key>PayloadUUID</key>
    <string>REPLACE-WITH-A-NEW-UUID</string>
    <key>ProxyType</key>
    <string>Manual</string>
    <key>ProxyServer</key>
    <string>gateway.sparkproxy.io</string>
    <key>ProxyServerPort</key>
    <integer>11002</integer>
    <key>ProxyUsername</key>
    <string>YOUR_USERNAME</string>
    <key>ProxyPassword</key>
    <string>YOUR_PASSWORD</string>
    <key>ProxyCaptiveLoginAllowed</key>
    <true/>
</dict>

ProxyCaptiveLoginAllowed is worth setting to true on a device that travels. Apple's description: it "allows the device to bypass the proxy server to display the login page for captive networks." Without it, a hotel or airport sign-in page can't load, because the phone sends it to the proxy before it has internet access. Apple also allows only one payload of this type on a device at a time.

If you build the app under test, you can confirm from inside it what the system thinks the proxy is. This Swift snippet reads the effective settings with CFNetwork:

import CFNetwork

if let settings = CFNetworkCopySystemProxySettings()?.takeRetainedValue() as? [String: Any] {
    let host = settings[kCFNetworkProxiesHTTPProxy as String] ?? "none"
    let port = settings[kCFNetworkProxiesHTTPPort as String] ?? "-"
    print("System HTTP proxy: \(host):\(port)")
}

If that prints none while Settings shows a proxy, the device is on a different network from the one you configured, or on cellular.

Read across from the symptom. The last column says plainly whether a proxy change can fix it.

The "Cache Access Denied" title is what we got back from the gateway on 2026-10-30 for a plain-HTTP request without credentials. HTTPS sites don't show it: a refused CONNECT fails before any page exists, so Safari shows its own error instead.