100+
Countries and regions covered
iOS VPN from Scratch: Client Setup, Subscription Import and Verification
From getting a working client and importing a subscription to approving the configuration and verifying it works, follow these steps in order to make your first connection on iOS.
When a first VPN setup on iOS goes wrong, the blocker is rarely the account — it's the layers of system permission: where the client comes from, which field the subscription link goes into, whether to tap Allow on that prompt, and how to confirm traffic really takes the route once you're connected. This guide walks the whole first-time iOS VPN flow in order — get the client, import the subscription, approve the configuration, verify it works — and gives you something you can check yourself at every step, so you know exactly where you got stuck.
One thing to settle first: the VPN entry in iOS Settings only understands standard tunnels such as IKEv2, IPSec and L2TP over IPSec. It has no built-in support for the protocols subscription services commonly use — Shadowsocks, VMess, Trojan, VLESS, Hysteria2, TUIC. To use subscription-based international routes on an iPhone or iPad you need a client built on Network Extension, which takes over protocol handling, routing and subscription updates.
First, the three connection types on iOS
There are three entry points that can build a tunnel on iOS. Choose the wrong one and none of the later steps will line up.
| Connection type | Typical source | Supported protocols | Best for | Watch out for |
|---|---|---|---|---|
| Client app | App Store, the provider's official channels | Shadowsocks, VMess, Trojan, VLESS, Hysteria2, TUIC and more | Subscription-based international routes, rule-based routing | The first configuration needs approval; after iOS reclaims the background extension you have to reconnect from the app |
| System VPN configuration | Entered manually, or parameters supplied by the provider | IKEv2、IPSec、L2TP over IPSec | Corporate intranet, self-hosted standard tunnels | No subscription links; every server change means editing fields by hand |
| Configuration profile | Delivered by the provider | Depends on what the profile contains | One-off deployment, identical settings across many devices | The source must be trustworthy; once installed it appears under device management |
The rest of this guide follows the client app, because subscription import, routing rules and verification only exist inside a client. Built-in system configurations and configuration profiles are closer to one-off tunnels, suited to fixed targets.
Getting the client: App Store and official channels
iOS clients come from two places only: apps published on the App Store, and installers distributed by the service provider itself. The first is bound by App Store review and updates through the App Store; the second is often enterprise-signed, and when the certificate is revoked the app simply won't open.
Installing from the App Store
When you search for a client by name, check the developer field first — plenty of apps share a name. Once installed, open it and confirm the protocol list includes the protocols your subscription uses, such as Shadowsocks, Trojan, VLESS or Hysteria2; otherwise you'll import the subscription and find nodes that exist but won't connect.
Regional availability and Apple ID
Some clients are only listed in certain regional App Stores. If your region doesn't have it, you have to change the Apple ID's country or region: spend any account balance and finish open subscriptions first, and note that existing purchases don't move with you. That's an expensive move — don't do it repeatedly just to try one client.
Provider channels and configuration profiles
Some services provide a client download entry and subscription link in their dashboard, available once you log in. When downloading from such a page, check whether the installer asks you to install a root certificate on the system: who issued it and what it's for both need to be clear before you proceed, and never install a root certificate from an unknown source.
Importing a subscription: link, QR code and manual entry
A subscription link is a URL. When the client requests it, it receives a node list — commonly Base64-encoded ss://, vmess://, trojan:// or vless:// links, or a client-specific format such as Clash YAML or sing-box JSON. The client then refreshes the subscription on a set schedule, so nodes added or removed on the server side need no manual edits.
| Method | What you do | Best for | Where it goes wrong |
|---|---|---|---|
| Subscription link | Copy the URL, add it in the app's subscription field and update | Works on phone and desktop; nodes follow server-side changes | Link truncated by a chat app, stray spaces, wrong protocol prefix |
| QR code | Generate the code in the dashboard, scan it in the app | Less typing on a phone, handy for quick additions | A forwarded screenshot is a public credential; codes can expire |
| Manual entry | Fill in server, port, password, transport and obfuscation parameters one by one | Single node only, or troubleshooting | Many fields; miss one and the handshake fails; re-enter everything when you switch nodes |
Run a manual update right after importing
After pasting the subscription link, tap Update Subscription once and confirm the node list actually arrives. An empty list usually means the link was incomplete, had extra spaces around it, or the subscription domain can't be reached on your current network.
Nodes and latency tests
The latency number in a client is measured by its own probe packets. It reflects one round trip from this device to that node at that moment, changes with time of day and local network, and is not a service commitment. Treat it as a hint when picking nodes, not as a metric.
A subscription link is the same thing as an account credential: whoever has it can use your traffic. Posting it in a group chat, committing it to a public repo, or forgetting to blur it in a screenshot all count as a leak. If it leaks, reset the subscription address in the dashboard — the old link stops working immediately — then import it again in the client.
Approving the configuration: handling iOS permission prompts
The first time you tap Connect in the client, iOS shows a system-level confirmation along the lines of "a client wants to add VPN configurations". This isn't the app's own dialog; the system is checking on your behalf. Only after you allow it does the configuration get written into iOS.
What happens after you tap Allow
The system confirms your identity with the device passcode, Face ID or Touch ID, then writes the VPN configuration into Settings → General → VPN & Device Management. A VPN indicator in the status bar means the tunnel is up.
If you tapped Don't Allow by mistake
Nothing is written, and the client stays stuck at disconnected. Tap Connect again in the app and the system prompt reappears; if it doesn't, deleting and reinstalling the client usually restores it. Leftover configurations in device management can be deleted and recreated on the same screen.
On Demand and background reclamation
With On Demand turned on in the client, it reconnects automatically when you switch between Wi-Fi and cellular or wake the device; with it off you connect manually. iOS also reclaims background network extensions after long periods of disuse, so finding the app disconnected when you return is normal — just tap Connect again. Low Power Mode limits background refresh, so On Demand reconnects may be slower.
Verifying it works: confirming traffic really takes the route
The client showing Connected only means the tunnel is up; it doesn't mean DNS and routing are correct. Each of the checks below can be done directly on the device.
- ✅ Egress IP and location: once connected, open an IP lookup page — the country and city you see should match the route you selected, and should return to your local ISP after you disconnect. You can check your current egress on this site's network check page.
- ✅ Where DNS resolution happens: use a DNS leak test to confirm queries come from the route side rather than your local ISP. If resolution still happens locally, DNS isn't going through the tunnel and results will follow local resolution.
- ✅ Rule matching: visit a site that a rule sends direct and one that goes through the route, then check the app log for the rule names that matched — make sure not everything is routed or everything direct.
- ✅ Recovery after a network switch: switch from Wi-Fi to cellular and back, and watch whether On Demand reconnects. If it doesn't, connect manually in the app and check the On Demand switch.
- ❌ Trusting the word Connected: it says nothing about DNS or routing, and it's the most common cause of "connected but pages won't load".
- ❌ Judging route quality from a single speed test: one test depends on your local network, time of day and the target server; repeat it a few times before drawing conclusions.
Conclusion
A successful connection needs three things at once: the egress IP sits in the location of the route you picked, DNS resolution happens on the route side, and routing rules match as expected. When all three line up, the first iOS setup is genuinely complete.
Routing rules: global, rule-based or direct
Clients generally offer three modes: Global sends all traffic through the route; Rule (routing) decides per domain, IP range and GeoIP whether traffic takes the route or goes direct; Direct sends nothing through the route at all. Use Rule mode day to day so international sites and local services both work.
How rules match
Rule sets are usually built from domain suffixes, domain keywords, IP-CIDR and GEOIP conditions, matched top to bottom and stopping at the first hit. Order therefore matters: put the domains that should take the route first and local services later, so a broad GEOIP rule doesn't swallow all your traffic.
Three common misjudgements
First, a site that should go direct gets caught by a rule and routed, which shows up as slow page loads; second, banking and payment apps detect a proxy environment and trigger risk controls, so they need a direct rule of their own; third, an app's web and API domains differ, so one rule still leaves it unable to connect — add all the related domains.
Keep rules updated
Domains change and rule sets go stale. Update the rule subscription in the client on the same schedule as the service subscription; for a direct-connection list you maintain yourself, add an entry whenever a new problem appears — less hassle than switching to Global every time.
Put the office, meeting and code-hosting domains you use most into a list of your own, marking which take the route and which go direct. Copy it when you change devices — far faster than digging through logs every time something breaks.
Common problems and a final checklist
Connected but pages won't load
Work through it in order: is DNS going through the route, is a rule sending the target direct, is the route itself working. If all three look fine, switch to another route and try again — that quickly separates a local configuration problem from a single bad route.
Drops after a while
It's usually background reclamation or On Demand being off. Granting the client background refresh permission and turning on On Demand generally fixes it; disconnects in Low Power Mode are system behaviour, so there's no need to reinstall over and over.
Doesn't work on cellular
First check that the client's Wireless Data switch is on under Settings → Cellular. On public Wi-Fi, complete the captive portal sign-in before connecting — otherwise the tunnel comes up but you get no usable egress.
Subscription update fails
The usual causes are a truncated link, a subscription address that has been reset, or a rule sending the subscription domain through the route while the route isn't connected yet. Put the subscription domain in the direct rules, or connect first and then update — that solves most cases.
If you're still choosing a subscription service, the items below are facts you can check before buying, independent of how the client is configured.
170+
Routes available
30 days
No-questions-asked refund
Unlimited
Simultaneous devices
ZaraVPN covers 100+ countries and regions with 170+ routes, accounts are not limited by device count, monthly plans start at ¥9.9 and include 60GB, there's a 30-day no-questions-asked refund, and signing up needs only a username and password — no email address required. Log in to the dashboard to get the client download entry and your subscription link.
Finally, the whole chain in four steps — run through it once after setting up a device.
-
Install the client
Install from the App Store or the provider's official channel, then open it and confirm the protocol list includes the protocols your subscription uses.
-
Import the subscription
Paste the subscription link into the app's subscription field, update once manually, and confirm the node list appears.
-
Approve the configuration
On the first connection, tap Allow in the system prompt and confirm with your device passcode or biometrics; the VPN indicator appears in the status bar.
-
Verify it works
Check the egress IP location, where DNS resolves, and which rules matched — all three correct before you start using it day to day.
Check
The hard parts of an iOS VPN setup are approval and verification: install the right client, import the subscription completely, tap Allow on the system prompt, then confirm with egress IP, DNS and routing. That flow holds on any iPhone or iPad.