Windows client setup from scratch: install, import your subscription, and enable auto-start

Getting international routes working on Windows follows a fixed five-step order: install the client, import the subscription, choose a route, verify it works, set up auto-start. Skip any one of them and the problem resurfaces later as “won't connect”, “connects but slow”, or “only the browser works”. This guide takes the five steps one at a time, flags the usual snags at each, and takes about ten minutes to follow end to end.

First, what you need. The Windows client is only a shell — what actually decides whether you connect is the configuration inside your subscription, so before installing anything, confirm you have three things to hand.

Before you start: account, subscription link and admin rights

• Account: username and password. No email address is needed to sign up and there's no verification email to wait for — two fields and you're into the panel.
• Subscription link: an HTTPS address carrying a token, holding your route list and connection parameters. It isn't your password, but it carries the same authority.
• One admin approval: needed during installation, and again at every launch if you want TUN mode to take over all traffic.

Once the subscription is in hand, take a quick look at its scale — it saves a lot of guessing later.

One account covers unlimited devices online at once, so there's no second subscription for a second machine — handy when you're setting up several computers at home: copy the subscription link across and the setup is identical. If you only want to test the waters first, the 60-day money-back window leaves you a way out — get the routes working, then decide whether to stay.

Download and install: put the client in the right place

1. Get the Windows installer from the download entry in your panel. Installer and account live behind the same entry, so avoid repackaged builds of unknown origin — the usual problems with them are a baked-in subscription belonging to someone else, or altered default ports.
2. Double-click to install and keep the default path. Installing to a non-system drive may need extra write permissions for automatic updates later.
3. On first launch Windows shows a firewall prompt — tick private networks and allow. Decline it and the symptom is “connected, but no traffic at all”.
4. If you plan to use TUN mode (a virtual adapter taking over all traffic), set the shortcut to run as administrator, or tick the matching option in the client settings.
5. Quit the old version before upgrading. Two versions running at once fight over the local listening port, and the new client just sits at disconnected.

Only two things really go wrong at the install stage: firewall permission and port conflicts. The first is asked on first launch; the second only appears on an over-the-top install or when two clients are installed. Don't rush to hit connect — finish the subscription import and verify everything together, and the order flows much better.

Importing the subscription: link, updates and protocol differences

The subscription link is an HTTPS address whose query string carries a token; the server returns your route list and connection parameters based on that token. The client only recognises that exact string, so copy it in full and paste it without stray spaces.

1. Copy the full link. Links forwarded through chat apps are often broken across lines — a few missing characters at the end and the import fails.
2. Open the client's subscription or profile page, create a new subscription, paste the link in and save.
3. Click “Update” once by hand and wait for the route list to refresh. The first import doesn't fetch automatically — skip this and the interface stays empty.
4. Turn on automatic subscription updates in settings; once a day is plenty. When routes change, this is what keeps your local list in sync.

Protocol and transport differences

The client picks the protocol from your subscription automatically, so day-to-day use needs no manual choice. But knowing the differences pays off when troubleshooting: the same “won't connect” has different causes depending on the protocol.

Choosing a route: direct, relay or dedicated line

Route lists usually come in three kinds: direct, relay and IEPL dedicated. The names sound like marketing, but they describe how data travels from your machine to the exit data centre. Once that's clear, picking a route stops being guesswork.

Judge in this order and you'll rarely go wrong:

• Region first: if you need content from a particular region, pick an exit there. Get the region wrong and no amount of tweaking helps.
• Then the type: relay for daily browsing and video; switch to a dedicated line for meetings and uploads where stability matters.
• Don't fixate on latency: low latency only means a fast round trip — it doesn't mean enough bandwidth, and it doesn't mean a steady peak hour. What you actually feel is packet loss and jitter.
• Pin two or three: more routes doesn't mean every one suits you; remembering two or three that are stable on your network beats picking at random each time.

The full country and route list can be filtered by country on the global servers page — no need to scroll through them one by one in the client.

Verify it works: proxy mode, DNS and exit IP

A “connected” status in the client doesn't mean traffic actually takes the route. Windows has two ways of taking over traffic, they behave very differently, and they're verified differently too.

• System proxy mode: the client rewrites the system proxy settings, and software that honours them (browsers, some desktop apps) goes through the route; programs that ignore the system proxy — some games, command-line tools and certain store apps — still connect directly.
• TUN mode: the client creates a virtual adapter and takes over all IP traffic, including programs that ignore the system proxy. It needs administrator rights and may conflict with other virtual adapters (virtual machines, container tooling, other network software); the symptom is connected but no traffic.

Work through the checklist below and you'll pin down the vast majority of problems:

• ✅ Open the IP lookup page; the exit region shown matches the route you picked.
• ✅ Common sites load normally on first paint, with no long white screens or repeated reconnects.
• ✅ Command-line tools (package managers, git and so on) also go through the route, which means TUN mode is active or they've been configured separately.
• ❌ The exit IP is still your local ISP, which means the proxy isn't taking over traffic.
• ❌ Only the browser is affected and other programs connect directly, which means you're still in system proxy mode.
• ❌ The IP looks right but content platforms still treat you as local — most likely a DNS leak.

Two commands in the terminal quickly confirm whether the system proxy has been rewritten and whether an old DNS cache is still interfering:

:: flush the DNS cache to rule out stale resolution results
ipconfig /flushdns

:: check the system proxy switch; ProxyEnable = 1 means the client has taken it over
reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings" /v ProxyEnable

DNS leaks are the easy thing to overlook. In system proxy mode, domain resolution often still goes through the local recursive resolver, so the exit IP changes to the route's while content platforms still see a local resolution source — region detection goes wrong and some content stays out of reach. There are two fixes: turn on the client's DNS takeover (or TUN mode, where the client handles resolution), or point the adapter's DNS at the local resolver address the client provides. Refresh the cache once after the change, then test again.

Auto-start and always-on settings

Once verification passes, the last step is to have it ready when Windows boots, so you don't click through it every time. There are two switches here, and missing either gives you “booted, but not connected”.

1. Launch at startup: starts the client process with the system.
2. Connect on launch: connects to the last used route as soon as the process starts. With only the first switch on, the process sits in the tray but the network isn't taken over.
3. Run as administrator: required for TUN mode; otherwise the process is there after boot but the virtual adapter never comes up — the same symptom as not starting at all.
4. Minimise to tray on close: stops a stray click on close from dropping the connection.

Automatic subscription updates and client auto-start are two different things: the first keeps the route list current, the second keeps the process running. Turn both on and the local list syncs after route changes without you remembering to update by hand. If you'd rather not have it always resident, at least give it a few seconds to connect and load rules before you judge — don't start deciding it's broken the same second you open a page.

Common snags at a glance

The table below covers the six situations that come up most often between installation and auto-start; match on the symptom.

Wrap-up: don't skip the five steps

Back to those five steps: install the client, import the subscription, choose a route, verify it works, set up auto-start. Most “won't connect” cases aren't the route's fault — the subscription wasn't updated, the system proxy never took over, or auto-start was only half enabled. Finish the verification step properly, get a definite exit IP and a clear picture of which programs are covered, and only then decide whether to change routes; troubleshooting gets far faster.