Windows VPN from Scratch: Installation, Importing, and Connecting

Setting up a Windows VPN from scratch involves more than installing an app and clicking Connect. To get predictable results, you also need to match the client to the subscription format, understand the scope of system proxy and TUN mode, choose a suitable protocol and route, and check your exit IP, DNS, and individual apps after connecting. This guide follows the practical workflow and explains what the key settings do.

Understand clients, subscriptions, and routes first

A client is the connection tool that runs on Windows. It reads node configurations, creates encrypted connections, and applies split-tunneling rules. A subscription link is an updateable configuration source that typically contains server addresses, ports, protocol parameters, and route names. A route is the path that carries your traffic, such as a direct connection, relay, or dedicated line. All three matter, but they are different concepts.

Windows’ built-in VPN settings are mainly designed for tunnel protocols supported natively by the operating system. They cannot directly recognize Shadowsocks, VMess, Trojan, VLESS, Hysteria2, or TUIC subscriptions. For these subscriptions, use a client recommended by the service and compatible with the format instead of pasting the subscription URL into the Server name field in Windows settings.

Before you begin, have your service panel login details and subscription entry ready. UyVPN registration requires only a username and password—no email address. Treat the subscription link like an access credential: do not publish it on a public webpage, in a screenshot, or in a shared document. If it is exposed, reset it in the service panel rather than simply deleting the local configuration.

Get and install the Windows client

Download the client from the download link provided in the service panel. Do not treat a reposting site in search results as the default source: its version may be outdated or missing the protocol core required by the service. After downloading, check the filename, version notes, and supported architecture against your system before installing or extracting it.

An installable client usually adds entries to the Start menu and installs a virtual network adapter when TUN mode is enabled. A portable client can run from its extracted folder, but configuration files, logs, and caches are often stored there as well. If you use a portable version, place it somewhere your current account can read and write normally instead of launching it directly from inside an archive.

On first launch, Windows may ask for network access permission. Whether you should allow it depends on how the client works. If the software needs to listen on a local proxy port and access is completely blocked, browsers and other apps may be unable to send traffic to the client. Enabling TUN may also prompt you to install a driver or confirm permissions; that is part of creating the virtual network adapter.

1. Open the Windows download section in the service panel and confirm the recommended client and subscription format.
2. Install or extract the client, then place it somewhere that can be read and written to reliably.
3. After the first launch, do not enable startup yet. Complete the subscription import and connection checks first.
4. If you need TUN mode, follow the client’s prompts to configure the virtual network adapter.

After installation, avoid changing a large number of advanced options at once. Keep the client’s recommended values, confirm that the basic connection works, and then adjust DNS, split tunneling, and startup behavior one at a time. This makes it easier to tell whether a problem comes from the subscription, the route, or a custom setting.

Import the subscription and identify the protocol

In the UyVPN panel, copy the subscription link for Windows, then return to the client and look for “Add subscription,” “Import from URL,” or a similarly named option. Paste the link, give the subscription an easy-to-recognize name, and update it. The client will normally expand the nodes into a list. If the list is empty, first check that the link is complete, then confirm that the client supports the subscription format.

Some clients offer “Import nodes from clipboard.” This is useful for a single configuration, but it is not necessarily the same as importing a subscription. The key benefit of a subscription is that route information can be refreshed later. If you copy the current nodes one by one into local storage, the local configuration will not update automatically when the service changes its entry points.

No protocol has a fixed advantage independent of the network environment. An Hysteria2 route may work well where UDP is permitted but time out completely on an office network that restricts UDP. Trojan and VLESS can also behave differently depending on transport parameters, entry quality, and the carrier path. When starting out, connect with the subscription’s default node first, then switch protocols based on the symptoms instead of changing several fields at once.

How to choose direct, relay, and IEPL routes

A direct route connects your device straight to an overseas server, with the path determined largely by your local carrier and public routing. Its structure is simple, but congestion between networks, changes at international gateways, and evening route adjustments can affect performance. The same node may behave very differently across regions and access networks, so someone else’s experience cannot replace testing on your own device.

A relay route first connects to a nearby entry point, then forwards traffic to the exit node through a relay path controlled by the service provider. This can reduce some uncontrollable public cross-border routing, but the connection between you and the entry point still depends on the local network. A relay is not automatically faster just because the distance is shorter; entry capacity, the downstream route, and the target website’s location all matter.

IEPL is a type of international Ethernet private-line service. A route for ordinary clients usually still reaches the service provider’s entry point before entering a dedicated or controlled backbone segment; it does not mean the user’s device has an exclusive physical line. Its main value is a more controllable cross-border backbone path, while the final experience still depends on local access, entry status, exit load, and the target service’s response.

When choosing a route, narrow the options by the region where the target service is located, then compare the real connectivity of direct, relay, and dedicated-line entries. For web browsing, a stable handshake and working DNS are usually more useful than “high-speed” in a node name. For live meetings or sustained downloads, check whether the connection stays stable over time instead of relying only on the latency shown momentarily by the client.

System proxy vs. TUN mode

A system proxy writes the proxy address into Windows network settings. Browsers and desktop apps that follow the system proxy send requests to the client, but some games, command-line tools, Store apps, and software with its own networking stack may ignore it. So a client showing Connected does not mean every program is using the route.

TUN mode uses a virtual network adapter to take over a broader range of IP traffic, then lets the client decide between direct access and proxying according to routing rules. It is better suited to apps that do not support the system proxy and feels closer to a whole-device connection. However, TUN can interact with other virtual adapters, security software, container networks, and enterprise policies, making it generally harder to troubleshoot than a system proxy.

If your main needs are browsing and a few desktop apps that support proxies, start with the system proxy. If a particular app still shows your local exit or you need to handle UDP and apps that ignore proxy settings consistently, try TUN. Restart the target app after switching modes because existing connections may continue using sessions created before the switch.

Verify the exit IP, DNS, and app traffic after connecting

After importing the subscription, select a node and start the connection. Do not rely only on the client icon or a Connected message: that status usually means only that the local core has started. It does not necessarily confirm a completed remote handshake or prove that the target app is using the connection.

1. Record your current public exit region before connecting, then reopen the detection page and refresh the results afterward.
2. Close test tabs that are already open in the browser, then check in a new tab to avoid reusing an old connection.
3. Run a DNS test and confirm that queries are not still being sent entirely through an unexpected local resolver path.
4. Open the app you actually need to use and check that sign-in, content loading, and ongoing requests work normally.
5. Repeat the checks after switching routes so that browser access is not mistaken for access from every app.

A DNS leak occurs when app traffic passes through a proxy or tunnel but domain queries are still sent through an unexpected local resolver path. This can expose the domains you visit or cause sites to fail when local DNS returns unsuitable addresses. Possible fixes include letting the client handle DNS, resolving domains on the proxy side, and ensuring split-tunneling and DNS rules use consistent regional logic.

A detection page listing multiple DNS servers does not automatically indicate a leak. The key question is whether the results match the intended configuration. In split-tunnel mode, local domains may be expected to use local DNS, while proxy domains should use the resolver path specified by the client. Judge the result against your rules rather than trying to make only one entry appear in the test.

If the browser’s exit has changed but one app still shows the original region, check whether the app ignores the system proxy, retains a connection cache, or has a split-tunneling rule that sends its target domain direct. If enabling TUN fixes the issue, the app probably does not read the system proxy; the node itself has not necessarily failed.

Set split-tunneling rules instead of forcing global proxying

Split tunneling sends requests that need international routes through the proxy while keeping local services, LAN devices, and apps that should not change exit regions on a direct connection. A sensible split keeps unnecessary detours to a minimum and can prevent local websites from triggering extra checks when the exit region changes.

Common rule criteria include domains, IP ranges, app processes, and rule sets. Domain rules work well for websites and APIs, process rules for a specific desktop app, and IP rules for services with stable addresses. Rule sets depend on regular updates; if they are left outdated, new domains may fall under the default rule.

Start by defining the default policy. With direct access as the default, add domains and apps that need the proxy to proxy rules. With proxying as the default, add direct rules for LANs, local services, and sensitive workloads. Rule priority differs between clients. When rules conflict, consult the client’s documentation to confirm whether matching runs top to bottom, by category, or according to built-in priorities.

DNS must follow the split-tunneling design as well. Changing traffic rules without changing the resolver path can return addresses unsuitable for the current exit. After enabling the client’s built-in DNS, check that local domains still resolve, LAN device names remain reachable, and proxy domains are handled by the intended resolver.

Startup, subscription updates, and routine maintenance

Enable startup only after confirming that the connection, DNS, and split tunneling work properly. These settings are usually split into “Start the client with Windows” and “Connect automatically after startup.” Enabling only the first runs the program in the background but may not establish a route; relying only on auto-connect means the program will not run after the next sign-in unless startup is also enabled. Check both according to your usage.

After a laptop wakes from sleep, switches Wi-Fi, or joins a new office network, an existing connection may have failed while the client interface has not updated yet. If webpages suddenly stop loading, disconnect and reconnect first, then check that the system proxy still points to the current client. Devices that change networks frequently may benefit from the client’s reconnect-on-network-change option, but watch for conflicts with captive login pages on managed networks.

Subscriptions should be updated regularly, but avoid repeatedly clicking Refresh when the connection is failing. A failed refresh may simply mean that the current route cannot reach the subscription endpoint; repeated attempts can overwrite local state. A safer approach is to keep the current working configuration, switch networks or temporarily disconnect, and then update the subscription. Afterward, check for node changes and select the route you need again.

The client core, rule sets, and virtual network driver also need maintenance. Before updating the client, confirm where its configuration is stored. With a portable version, back up the entire configuration folder; with an installed version, use the software’s export feature. After updating, verify the basic connection first, then restore complex rules so you can identify behavioral differences between versions.

Troubleshoot connection failures by symptom

Every node times out

First check whether the device can access ordinary websites normally, then confirm that automatic system time synchronization is enabled. Close other proxy tools and check whether security software or a managed network is restricting the client. If Hysteria2 and TUIC fail while other transport methods work, the issue may involve UDP availability on the current network. Switch transport types instead of editing authentication fields supplied by the subscription.

Only some nodes fail

This usually means the client and subscription import process are basically working. The problem is more likely a particular entry point, protocol compatibility, or route status. Update the subscription, then test another entry point in the same region. Do not manually replace the server name, port, or TLS parameters; these fields must match the server configuration.

It says connected, but webpages will not load

Exit the system proxy or TUN first and check whether ordinary connectivity returns. If it does, reconnect and inspect the local proxy port, DNS handling, and split-tunneling rules. An independent proxy extension enabled in the browser may also override system settings, so disable it temporarily and try again. If only domain names fail while a known address responds directly, focus your investigation on DNS.

The browser works, but desktop apps do not

This is usually because the app does not read the system proxy. Fully exit the target app, enable TUN, and reopen it. If it still fails, check process rules, virtual adapter routes, and the app’s own network settings. Enterprise-managed devices may also restrict virtual network drivers; follow the device policy instead of repeatedly installing different drivers.

The local network still does not recover after disconnecting

After exiting the client, check that the Windows system proxy is off and look for any other running proxy processes. If TUN was enabled, disable it normally inside the client before closing the program so that virtual routes can be cleaned up. If the network still has not recovered, reconnecting to the current network is usually more helpful for rebuilding local routing and DNS state than continuing to switch nodes.