Shadowrocket Proxy Setup: The iPhone Guide

Shadowrocket is a rule-based proxy client for iPhone and iPad, not a VPN subscription. You supply the proxy; the app decides, connection by connection, what goes through it. Adding a server takes four values and about two minutes. The routing rules are the part that decides whether the app was worth buying.

What Shadowrocket actually is

The App Store listing describes it plainly: a rule based proxy utility client that captures all HTTP, HTTPS and TCP traffic from any application on the device and redirects it to a proxy server. It is published by Shadow Launch Technology Limited, costs $2.99, needs iOS 13 or later, and carries a 4.5 rating over roughly 12,000 ratings. The documented feature set is what separates it from the proxy fields buried in iOS Settings: rules by domain match, domain suffix, domain keyword, CIDR range and GeoIP lookup, rule files imported from a URL or iCloud Drive, local DNS mapping, per-connection traffic accounting, and DNS over HTTPS, TLS or QUIC.

Two things it is not. It is not an encrypted tunnel to a provider you subscribe to, because the security of the hop depends entirely on the proxy you point it at. And despite the prompt you will see in a moment, it is not a VPN app either. iOS only lets an app capture another app's traffic through the Network Extension framework, and that framework requires an installed VPN profile. The profile is the delivery mechanism, not the product.

What you need before you open the app

Four values, all of which come from your proxy dashboard:

• Address, the gateway hostname of your provider.
• Port, which usually differs between the HTTP and the SOCKS5 entry point.
• User, which on residential and mobile networks often carries the targeting parameters as well.
• Password.

Pick the network before the protocol. A phone is a browsing client, so residential exits behave best on consumer sites, and mobile exits are the right choice when the target expects carrier traffic. Datacenter ranges are cheaper and faster but are recognised as datacenter ranges by exactly the apps people install Shadowrocket to reach. On protocol, HTTP is the safer default on iOS; SOCKS5 carries anything TCP rather than only web traffic, which matters for messaging apps, and it is also the protocol that fails in the most confusing ways, as the troubleshooting section below explains.

One warning that costs people an afternoon: do not plan on IP whitelist authentication. A phone moves between Wi-Fi and cellular and its public address changes with it, so an allowlist entry goes stale the moment you leave the house. Use username and password authentication and keep the allowlist for fixed machines.

Adding the server, step by step

1. Install Shadowrocket from the App Store and open it. The main screen shows a connection toggle, a Global Routing selector and the list of servers, which starts empty.
2. Tap the plus icon, or Add Server.
3. Set Type to HTTP, HTTPS or SOCKS5, matching the port you were given.
4. Fill in Address and Port.
5. Fill in User and Password. On a residential or mobile plan the targeting parameters usually live inside the username, appended to it with dashes, so paste it exactly as the dashboard prints it.
6. Tap Save. The server appears in the list with a latency figure once you test it.
7. Set Global Routing to Proxy for a first test, so that nothing is decided by rules yet.
8. Flip the connection toggle. iOS asks permission to add a VPN configuration: allow it and confirm with your passcode or Face ID. This happens once, and it is the Network Extension profile rather than a subscription to anything.

If the toggle flips back by itself, the app never established the tunnel. That is a proxy failure, not an iOS one, and the causes are below.

Verify the exit, and know what a good one looks like

Open a browser and load an IP echo. The address it reports should be the proxy, and the network behind it should look like a household rather than a server farm. To show what that means we queried an IP echo through country-targeted residential exits on 12 September 2026, using the QuanticData MCP server, and recorded what the site saw:

Country requested	Exit seen by the site	Network behind the address
United States	Orlando, Florida	AS33363 Charter Communications
United Kingdom	Harpenden, England	AS13285 TalkTalk Communications
Japan	Tokyo	AS17676 SoftBank
Brazil	Sumare, Sao Paulo	AS28649 Desktop Sigmanet

All four landed in the country requested, and all four resolved to consumer broadband operators with residential reverse-DNS names. That is the shape you are paying for: if your echo instead returns a hosting company, you are on a datacenter range, and the sites that care will treat you accordingly. The proxy tester runs the same check from a desktop browser when you want to confirm credentials before typing them into a phone.

Why your IP keeps changing, and how to stop it

A rotating endpoint gives you a new exit per connection. We sent four consecutive requests to the same echo through a rotating United States endpoint, roughly twenty seconds apart in total, and got four different households: Charter in Orlando, Comcast in Fresno, Cablevision in New York, Verizon in Clifton, New Jersey. Four requests, four addresses, four operators.

That behaviour is ideal for collection and fatal for a session. If an app holds a login, a cart or a one-time code, an address that changes mid-flow reads as account takeover and you will be logged out or challenged. The fix is a sticky session, requested through the username with a session identifier your provider documents, so the same exit is held for a set number of minutes. Rotating and sticky are the same endpoint with a different username; the difference between rotating and sticky behaviour is a decision you make per use case, not per plan.

Global Routing and the rules that justify the app

Global Routing has three settings. Proxy sends everything through the exit. Direct sends nothing. Config hands each connection to your rule list, which is the only mode that makes the purchase worthwhile. Rules are evaluated top to bottom, first match wins, and the last line decides everything that matched nothing.

The configuration is a plain text file you can write on a computer and import from a URL or iCloud Drive. A minimal, readable skeleton looks like this:

[General]
bypass-system = true
skip-proxy = 192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12, localhost, *.local
dns-server = 1.1.1.1, 8.8.8.8
ipv6 = false

[Rule]
DOMAIN-SUFFIX,icloud.com,DIRECT
DOMAIN-SUFFIX,apple.com,DIRECT
IP-CIDR,192.168.0.0/16,DIRECT
DOMAIN-KEYWORD,analytics,REJECT
DOMAIN-SUFFIX,example-target.com,PROXY
GEOIP,IT,DIRECT
FINAL,DIRECT

Read it as a policy rather than as code. Apple services and the local network go out untouched, so push notifications and AirPlay keep working. Anything whose hostname contains a tracking keyword is dropped before it leaves the device, which is also the cheapest possible optimisation because rejected bytes are never billed. One target domain is proxied. Addresses that GeoIP places in your own country stay direct. The final line then chooses the default posture, and this is the line that decides your bill: FINAL,DIRECT means only what you named goes through the proxy, while FINAL,PROXY means everything does, including background chatter from apps you were not using.

Two subtleties worth knowing before your rules misbehave. A rule that matches on IP forces a DNS lookup unless you append no-resolve, which is why published rule sets carry that suffix on their IP-CIDR lines. And a hostname on a shared CDN is not owned by the site that uses it, so a broad REJECT on a CDN domain will silently break images and scripts on pages you wanted to keep.

When it does not connect

The failures are few and each has a signature.

• The toggle flips back immediately. The tunnel never came up. Check the address and port pair first, then whether another VPN or content blocker already holds the Network Extension slot, since only one can be active.
• Connected, but every page times out. Usually authentication. A proxy that rejects your credentials answers with 407 rather than a friendly message, and the app shows you nothing at all; our 407 guide walks the same failure on a desktop client where the error text is visible.
• HTTP works and SOCKS5 does not. This is the most reported Shadowrocket-specific problem. Providers document a workaround in the server settings: change the connection method from auto to random and reconnect. Where a firewall is actively fingerprinting protocols, plain SOCKS5 may be blocked outright and an encrypted transport is the only reliable answer.
• It works on Wi-Fi and dies on cellular. Almost always IP allowlist authentication that no longer matches your carrier address. Switch that server to username and password.
• The exit is right but one app still sees your real location. That app is probably resolving names or geolocating outside the proxied path. Check your DNS setting and confirm the app's domains actually match a PROXY rule rather than falling through to a DIRECT final line.

What it costs to run a phone through a proxy

Metered proxies bill bytes, and a phone in FINAL,PROXY mode sends far more of them than you would guess, because a single page drags dozens of subresources behind it, as we measured in a recent teardown of browser page loads. Residential traffic starts at $0.80 per GB and mobile at $2.30 per GB, so the difference between routing everything and routing one app is the difference between a plan that lasts a month and one that lasts a weekend. If you are unsure which plan size to buy, the sizing walkthrough converts real workloads into gigabytes.

The practical setting for most people is FINAL,DIRECT with a short list of PROXY rules for the domains that actually need a different exit, plus a handful of REJECT lines for telemetry. You get the exit where it matters, your bank app keeps working, and the meter moves slowly.