Windows VPN Setup from Scratch: Install a Client and Configure It to Launch at Startup

Before you install: check the client and subscription type

First, distinguish between two types of software. The built-in VPN in Windows Settings uses tunneling protocols supported by Windows; it is not a general-purpose subscription importer. Configurations for Shadowsocks, VMess, Trojan, VLESS, Hysteria2, or TUIC provided in a service panel usually require a compatible proxy client. Just because both are called VPNs doesn’t mean you can enter those configurations in the server address field for Windows’ built-in VPN.

The protocols a client supports depend on its core, version, and build. Don’t rely on the app’s name alone, and don’t treat a subscription link as a server address. Subscription links are generally used to fetch route and rule configurations and may contain access credentials, so protect them like passwords.

1. Open the service panel’s download or guide page. Check which Windows client and subscription format it recommends, then download the matching file.
2. In Windows, go to Settings → System → About to check your system type and choose the matching installer. The names of these options may vary slightly between Windows versions.
3. Check the download source, filename, and release notes. If a checksum is provided, use it to verify the file. Don’t disable system protection just to run software from an unknown source.
4. After launching the app for the first time, look for a “Config” or “Subscription” page. An empty configuration list is normal: it means no routes have been imported yet, not that the installation failed.

Import a subscription: from link to available routes

In the panel, choose the subscription option for your client and copy the full link. In the client, open “Config” or “Subscription” and look for an option such as “Import from URL” or “Add remote config.” Paste the link and confirm. Some clients can import from the clipboard or open through a browser link. If that doesn’t work, pasting it manually makes it easier to check the link.

After importing, a new entry should appear in the configuration list. Select it as the active config, then open “Proxy” or “Routes” and check that routes or proxy groups are listed. Seeing a config name doesn’t mean its contents downloaded successfully. Also check the update time, error messages, and whether the config is actually enabled.

If the download fails, check that the link is complete, has no leading or trailing spaces, and that your current network can reach the subscription URL. If parsing fails, check whether you selected the wrong subscription format or whether the client core supports the protocols in the config. Pasting the same incompatible link repeatedly won’t fix a format mismatch.

• ✅ Get the subscription from your own service panel and use the import option that matches your client.
• ✅ The active config is enabled, routes are listed, and parsing errors aren’t recurring.
• ✅ Before sharing a screenshot, hide subscription URLs, access tokens, QR codes, and account details.
• ❌ Don’t paste a full subscription link into an unfamiliar conversion site, public forum, or group chat.

If you think a link has been exposed, look for an option in the service panel to reset subscription credentials, or ask support how to proceed. Then update your client. Deleting the local config only removes the copy on that device; it does not revoke exposed credentials.

Choose a route: pin down your exit before enabling split tunneling

Start by manually selecting a route in the proxy group that suits the target service’s region, and note its name. For the initial setup, avoid combining automatic switching, complex rules, and multiple traffic-routing tools. Otherwise, when something goes wrong, it’s hard to tell whether the cause was a change in exit IP or a rule match. If the group contains nested groups, confirm the final route—not just the group name.

“Direct” depends on the context. In client routing rules, it usually means a request bypasses the proxy. In a route description, it may refer to the network path from the entry point to the exit. A relay typically forwards traffic through an intermediate entry point, while an IEPL private line describes how a dedicated link is used. None of these labels alone can guarantee smooth performance on your home network, for a particular website, or during evening hours.

For an initial check, enable the system proxy and use the client’s rule mode. If an app doesn’t follow the system proxy, consider its own proxy settings or TUN mode. Don’t run multiple tools that change system proxy or routing settings at the same time. On company devices or managed networks, check the applicable policies first.

Verify your exit: check the page, connection log, and DNS separately

Before routing traffic through the client, check your current exit IP and note the result. Then enable the proxy and revisit the same test page. The site’s network check can help, but confirm whether the test page itself is using the proxy. In rule mode, the test site may be routed directly, so an unchanged exit IP doesn’t necessarily mean all routes have failed.

1. Open the target website and confirm its content loads properly—not just a cached page shell in your browser.
2. In the client’s “Connections” or “Logs” view, find the relevant domain and check the matched rule, proxy group, and final route.
3. Check whether the exit region suits your needs. Geolocation databases can be out of date, so a city label alone isn’t a reliable measure of route quality.
4. Open the desktop app you actually need and test it separately. A successful browser test doesn’t mean other apps use the same route.

A DNS leak check is about whether domain lookups are taking an unexpected path. A changed exit IP doesn’t prove DNS queries are being handled as intended. Conversely, seeing a particular resolver name doesn’t by itself prove there’s a leak; check it against your configuration. Browser Secure DNS, the client’s built-in DNS, and Windows DNS settings may all affect the result.

To troubleshoot, first check how the client handles DNS, then see whether your browser uses a separate resolver. Don’t enter unfamiliar addresses in every DNS setting or disable all security features just to get one test to pass. IPv6, app-specific proxies, and TUN exclusions can also give different apps different exit routes, so check each one separately.

Configure startup: distinguish launching the app from routing traffic

First, make sure the manual connection is stable. Then, in the client’s “Settings,” look for “Launch at startup” or “Start with Windows.” Enable “Start minimized to tray” if you prefer. This usually launches the app after you sign in to Windows; it doesn’t necessarily route traffic before sign-in.

Next, look for options such as “Enable system proxy on startup” or “Restore last config.” Starting the app, loading the config, and enabling the proxy are separate steps. If you use TUN, check the client documentation for the background service’s installation and startup behavior; system proxy startup instructions may not apply.

1. Save the current config and route selection in the client, and make sure the subscription isn’t still waiting to be applied.
2. In Windows, open Settings → Apps → Startup or the Startup Apps page in Task Manager. Check that the client is allowed to launch.
3. Restart Windows and sign in. Once the network is up, check that the client is in the system tray, the correct config is active, and traffic routing is enabled.
4. Repeat the checks for the target page and connection log. Confirm that it’s not just the app window opening automatically.

Don’t add the client to the Startup folder, Task Scheduler, and its own startup option all at once; doing so can launch it multiple times. If a background service handles traffic routing, closing the app window may not stop the service. Check the client’s status indicators.

Common issues: troubleshoot in order

Subscription updates, but no routes work

A successful subscription download only confirms that the config retrieval path is reachable. Next, check the client core, protocol support, system time, and account status. Then inspect the connection log for parsing errors, authentication failures, or connection timeouts. When contacting support, include the client version, error text, and what you were doing—not just a screenshot saying “Connection failed.”

Browser works, but desktop apps are unaffected

First check whether the app follows the system proxy, has its own proxy settings, or needs to be fully closed and reopened. Don’t switch every route right away. If you need TUN, configure it according to the documentation, verify the routes, and then check the app’s actual exit route.

Works during the day, but loads slowly in the evening

Keep the client, target page, and local network conditions as consistent as possible while comparing routes. Wi-Fi signal, background downloads, your local carrier’s route, congestion at the entry point, and load on the target service can all affect performance. A latency reading in the route list is not download bandwidth and can’t replace a real test on the target website.

Manually selected route changes after a subscription update

If the service changes route names or config structure, your previous selection may not carry over. First check the active config and proxy groups; don’t immediately overwrite all your local settings. Automatic updates refresh the config, but they don’t guarantee that old route names, rules, and personal selections will remain unchanged.

Keep a verified baseline for everyday use: a trusted client source, a matching subscription format, a clear routing mode, a verifiable exit route, and startup tested after a restart. Change one setting at a time and record the result. This usually makes issues easier to isolate than reinstalling the app, changing routes, and editing DNS all at once. If you still can’t find the cause, use the Help page to describe the issue and submit the relevant details.