Shadowrocket Proxy Setup 2026: SOCKS5 on iPhone and iPad

What this guide covers

Use this guide when you already have an HTTP or SOCKS5 endpoint and want to use it through Shadowrocket on iPhone or iPad. The publisher's App Store listing describes a rule-based networking client and explicitly says it does not include a proxy service.

Check the listing for your Apple ID's region, supported devices and current price. Prices and availability vary between storefronts, so a US listing is not a worldwide availability promise. Avoid similarly named downloads offered through unrelated configuration profiles or certificates.

If all you need is a Wi-Fi HTTP proxy, the existing iPhone and iPad setup guide covers that narrower method. Shadowrocket is relevant when you need its routing controls or want a client that can operate beyond one Wi-Fi network.

An exit IP does not replace GPS, Apple ID region or application account state. Define the network behavior you want to test before changing other device settings.

Prepare one endpoint and a direct baseline

Collect the proxy host, port, protocol and authentication method. HTTP and SOCKS5 may use different ports even when they come from the same order. If the provider exports host:port:user:password, put those values into separate fields rather than treating the export as a subscription URL.

Open what is my IP before connecting and record the direct result. Then verify that the endpoint works with a supported client or our proxy checker. An unreachable server will not become reachable because you import a more elaborate rule set.

Keep a copy of any existing Shadowrocket configuration you need. For the first test, avoid third-party rewrite scripts, HTTPS interception and unfamiliar subscription packs. Ordinary forwarding does not require decrypting website traffic on the device.

If another VPN or managed network profile is active, establish which configuration owns the connection. Do not remove work or school profiles to follow a consumer setup example. Test with the administrator's approved configuration where the device is managed.

Add an HTTP or SOCKS5 server

Shadowrocket's field labels can vary with version and language. The core sequence is to add a server, select the correct type and provide its connection details.

1. Open the server list and use the add action, commonly shown as a plus button.
2. Select the endpoint type. Choose SOCKS5 only for a SOCKS5 listener; use HTTP for an HTTP proxy.
3. Enter the address and port. Enter the username and password when the endpoint requires them.
4. Give the entry a recognizable name that describes its purpose or location without exposing the password.
5. Save and select the entry. Enable the connection and approve the iOS VPN configuration prompt if it identifies the app you installed.
6. Open an IP-checking page through Safari and inspect the client's connection information. Compare the result with the direct baseline.

These are configuration steps, not a claim that every release has identical screens. Use the installed client's labels and the publisher's linked help when a menu differs.

If authentication fails, check the protocol and port before regenerating credentials. Watch for whitespace added by copying. A password that contains punctuation should remain literal in separate fields. URL encoding is relevant only when a configuration format actually requires a URL.

Choose a routing mode you can verify

A rule-based client can send some destinations through the proxy and others directly. A broad proxy mode is useful for an initial controlled test, while a configuration-based mode applies the rules in the selected profile. Direct mode is useful for comparison and rollback.

Inspect the effective route for the IP-test request. If it is excluded by a domain rule, a direct result may be correct for that rule even though the proxy is active. Conversely, a proxied IP result does not establish that every destination uses the same path.

Once the endpoint works, add only the exceptions you need. Local-network devices, internal services and captive portals can require direct access. Record why a bypass exists, because broad exceptions can also invalidate a location-specific test.

For account sessions, keep the chosen route stable during the task. Switching upstreams or rotating an exit IP can interrupt active connections. Use dedicated mobile proxy session behavior as a service-selection question rather than assuming the client can keep a disconnected upstream alive.

DNS, HTTPS and the VPN indicator

The VPN indicator tells you that iOS has an active VPN configuration. It does not describe the encryption used between the client and the upstream proxy. A packet tunnel feeding a plain SOCKS5 endpoint still needs separate transport protection if confidentiality on that hop is required.

For HTTPS websites, keep certificate validation enabled. A certificate-installation prompt deserves an explanation: interception is a separate feature from forwarding through a proxy. You do not need to install a root certificate just to change the exit IP of ordinary HTTPS browsing.

Check the selected DNS policy and run a DNS leak test from the same browser. Domain rules and resolver choices can affect each other. A resolver located outside the proxy country is not, by itself, proof of a leak; inspect how the query reached it.

SOCKS5 can support UDP, but both the endpoint and client configuration must support the relevant use. Calls, games and other real-time traffic are separate tests from loading an HTTPS page. Read the SOCKS5 guide for the protocol and authentication limits.

Test Wi-Fi, cellular and reconnection

Run the same small request on Wi-Fi and then cellular. If the proxy uses source-IP allowlisting, the source reaching the proxy can change when the network changes. Username/password authentication removes that particular dependency, provided the client supports it.

Lock the screen, wait through an ordinary idle interval and retry. Repeat after reconnecting the network. Check whether the client reconnects automatically and whether the target app preserves its session. A speed result while the screen is on does not establish reliable background behavior.

If the IP check changes but your target app behaves the same, that may be expected. The app can use account region, location permission, cached data or another service. Inspect the actual requirement rather than cycling through proxies until a screen happens to change.

For permitted mobile-app testing, record device version, client configuration and account state alongside the network location. That makes the result reproducible.

AI apps and remote browsers remain separate

Opening an AI service through a proxied iPhone browser can change that browser request's network path. It does not change the network used by a remote browser or tool that the service operates elsewhere.

If an automation platform runs a cloud phone, browser or MCP server, configure egress in that environment. The iPhone may only display the control panel. The browser setup guide explains this boundary for Browser Use and Browserbase workflows.

Keep credentials in connection settings rather than chat messages or task descriptions. A redacted screenshot can show a wrong port or protocol without exposing a working username and password. Review the permissions of any extra profile or automation integration before giving it access to the device.

Fix the first failing layer

If the client cannot connect, confirm ordinary internet access first. Then check endpoint reachability, authentication and the selected upstream. A hostname typo, expired order or changed allowlisted source needs a different fix from a routing rule.

If Safari shows the direct IP, inspect the rule for the test destination and the selected routing mode. If Safari works but another app fails, check whether that app requires another protocol or is excluded. If everything stops after disconnection, restore any Wi-Fi proxy setting you added and review the active VPN configuration.

To roll back, disconnect Shadowrocket and restore the prior network configuration. Remove only the client profile you created, then verify direct connectivity. Keep a known-working minimal profile so the next update can be tested without reconstructing the whole setup.

Frequently asked questions