Setting up a Windows VPN is about more than finding a Connect button. The client, subscription profile, and app traffic route all need to work together. Install the client, import the subscription, choose a route, verify the connection, and then enable startup. Confirm each step before moving on to make problems easier to pinpoint.

This guide is for Windows users connecting to international routes with a subscription profile. Menu names vary by client, so follow the instructions on the download page. Visit the download section in the VPNOB user panel to find a compatible client. Don’t rely on screenshots from other apps as instructions for the current version.

Before You Install: Understand the Client, Subscription, and System Proxy

The client reads configuration and handles network connections. A subscription link provides routes, connection parameters, and sometimes rules. Your account password is for signing in to the panel; it isn’t a connection password and can’t replace the subscription URL. You usually don’t need to enter your panel password on the client’s node-editing screen.

The VPN section in Windows Settings is mainly for VPN connection types supported by Windows. Subscriptions using proxy protocols such as Shadowsocks, VMess, and Trojan usually need to be parsed by a compatible client; you can’t paste them directly into the server address field in Windows VPN settings. Services commonly called VPNs may use different connection methods.

What each setting controls
Setting What it does Common beginner misconception
Subscription profile Provides routes and related connection settings to the client A successful import doesn’t mean app traffic is being routed through the client
System proxy Routes traffic through a proxy for apps that follow system proxy settings Not every app follows this setting
TUN mode Routes eligible traffic through a virtual network interface Still affected by exclusions, routing, and DNS settings
Rule mode Chooses direct or proxy connections based on domains, addresses, and other rules Selecting a route doesn’t mean every request uses it

Install the Client: Check the Source and System Architecture

Use the panel’s instructions to find the official download channel, then verify the app name, publisher, and supported system. Don’t download installers from search ads, file-sharing mirrors, or attachments from unfamiliar chats. If the official source provides a checksum, verify the file as instructed. Get the checksum from a trusted release channel, not from text forwarded alongside the file.

Check your system type under System and About in Windows Settings, then download the version for the matching architecture. Installed and portable versions may differ in how they update, where they store files, and how startup works. If you’re new to the client, follow the download page’s recommendation. Keep a portable version in a fixed folder after extracting it; don’t run it long-term from an archive or temporary downloads folder.

If Windows displays a security warning, verify the download source and the official instructions first. Don’t disable system protection just to continue the installation. Standard proxy mode may not require administrator privileges; installing a virtual network component, enabling TUN, or running a background service may require approval. Requirements depend on the client, so “always run as administrator” isn’t a universal rule.

On first launch, leave startup disabled and don’t run another proxy or VPN at the same time. Multiple programs changing system proxy, routing, or DNS settings make it harder to identify the cause of a problem.

Import a Subscription: Check Routes and Confirm Updates

Sign in to the user panel and find the subscription option for your client. If the panel offers multiple formats, choose one compatible with the client. “Copy subscription” and “Import into client” are usually different actions: the first copies a URL, while the second may try to open an installed app.

  1. Copy the subscription URL from the panel. Don’t copy the page URL, sign-in link, or route name.
  2. In the client, look for Subscription, Configuration, or Profiles, then add a remote profile and paste the URL.
  3. Save and update the profile. Check that a route list appears rather than just confirming that a profile name was added.
  4. Set this profile as the active one, and make sure the client isn’t still using an old or sample profile.
  5. If the client supports manual refresh, try it and confirm the update completes successfully.

If the update fails, first check that the URL is complete and has no spaces at either end. Then check your local network and system date and time. If the error points to a parsing issue, verify that the client and subscription formats are compatible. If it mentions authentication or permissions, check the subscription status in the panel. Repeatedly pasting the same URL usually won’t fix a format mismatch.

Updating a subscription may replace routes and rules, and local overrides can affect the result. While you’re getting started, use the service’s compatible configuration. Consider custom rules only after the basic connection works.

Choose a Route: Start by Testing Rule Mode

Select an available route in the client, then start the connection or core as instructed and enable the required traffic-routing method. In some clients, starting the core and enabling the system proxy are separate controls. A “Running” status only means the program has started; it doesn’t confirm that your browser is sending requests through it.

For your initial setup, try rule mode with the system proxy and choose a route suited to the region your target site requires. Global mode usually means requests handled by the client are sent through the selected proxy; it doesn’t mean every app is covered. If local apps stop working, check which rules match before changing all your connection settings.

IEPL dedicated lines, relay routes, and direct connections describe how routes are organized; Trojan and VLESS describe connection protocols. They’re different things. A dedicated-line label alone doesn’t prove a site will work, and a protocol name doesn’t tell you the actual speed. See the network routes page for route types, and test the connection with your local network and target app.

Don’t choose a route based on latency alone. A lower latency means the test destination responded faster; it doesn’t guarantee smoother downloads, video playback, or access to a particular site. When comparing routes, keep other settings unchanged and test the same destination each time.

Verify the Connection: Check Websites, Apps, and DNS Separately

First, confirm your local network works before connecting. Start the client and open a target site that requires an international route. Then visit a familiar local site to check that split tunneling behaves as expected. Finally, test the desktop app you actually need; a successful browser test alone isn’t enough.

If a site works in your browser but a desktop app doesn’t, the app may ignore system proxy settings, use its own proxy settings, or still have an existing connection. Fully quit and reopen the app, then check its network options. Try TUN only if you’ve confirmed that the app’s traffic needs to be routed that way. Check for compatibility issues with other virtual network adapters or security software.

DNS translates domain names into addresses. Routing web requests through a proxy doesn’t necessarily mean DNS queries follow the same route. Browser secure DNS, system resolution, and the client’s DNS settings may each apply separately. A DNS leak usually means a lookup that should follow the proxy policy took an unintended path; simply detecting a local resolver doesn’t automatically indicate a problem.

Use client logs, rule-match records, and trusted test pages to check your exit IP and DNS route. Split-tunneling rules may intentionally resolve local domains directly, so assess the behavior for the domain you’re testing. An IP test page shows the exit route for that page’s request; it can’t tell you how every connection on your computer is routed or replace a privacy risk assessment.

  • ✅ The target international site loads, and the features you need work.
  • ✅ Local sites and everyday apps work, with direct and proxy connections following the expected rules.
  • ✅ You tested the desktop app separately rather than checking only the browser.
  • ✅ You checked DNS behavior against your split-tunneling rules instead of copying unfamiliar settings blindly.
  • ✅ After disconnecting, your local network works again and no broken system proxy address remains.

Set Up Launch at Startup: Distinguish Startup from Auto-Connect

Once the basic connection works, enable the client’s “Start with system” option. This usually launches the app after you sign in to Windows; it doesn’t necessarily establish a connection before sign-in. If you also want it to connect automatically, check whether the client has a separate option and whether it remembers the active profile, route, and system proxy state.

Check that the app is allowed to launch in Windows Settings under Apps and Startup, or in Task Manager’s Startup apps list. The client’s built-in option is usually sufficient; avoid also adding a Startup folder shortcut and a scheduled task, which can launch duplicate instances. If you move a portable version, its existing startup path may no longer work, so update the setting.

After saving your settings, restart the computer. Confirm in order that the client has launched, the profile has loaded, and the required traffic-routing method is enabled; then test the target site. Also test the connection after unlocking the screen or waking from sleep. The client appearing in the system tray doesn’t mean the old connection is still working.

If the client can’t connect right after startup, the network may not be ready yet. Wait for the local connection to come back, then reconnect manually and check the retry settings in the client’s documentation. Don’t mask startup issues by weakening system protection or dismissing permission prompts.

Common Issues: Troubleshoot the Connection Path

Routes are listed, but no websites will load

Quit the client and turn off the system proxy first, then confirm that your regular network works. Once it does, restart the client and check the core status, active profile, and selected route. If the logs report that a local listener failed to start, check for another proxy app using the same port or causing a conflict. Avoid changing DNS, rules, and protocol settings all at once, or it’ll be hard to tell what helped.

The computer loses internet access after I quit the client

Check Proxy settings under Network & Internet in Windows and see if they still point to a local proxy that has already quit. Note the original settings before changing them. If your computer is managed by work or school, don’t overwrite organization settings. If TUN or routing doesn’t reset correctly, follow the client documentation to disable the relevant components and restart the system if needed.

An app that worked before stopped working after a subscription update

Check whether the active profile changed, whether the route is still available, and whether local rule overrides were preserved. When contacting support, include the client name, system type, step where the issue occurred, and error details with sensitive information hidden. Don’t send your full subscription URL or account password. Continue troubleshooting in the FAQ, or get help through the contact page.

Success means you can connect and explain how your traffic is routed. A route appearing in the list only confirms that the subscription was imported. Enable startup only after the target app works, split tunneling behaves as expected, and your local network works after disconnecting. Keep this verification sequence for future changes of computer or client.