Windows from Scratch: Install the Client and Enable Startup Launch

This complete Windows client guide is for anyone configuring a subscription service for the first time. The goal is not simply to see “Connected” in the app, but to confirm that the subscription was imported correctly, the route connects, browsers and everyday apps use the proxy as expected, and the client returns to a usable state after the next system startup.

Button names vary slightly between clients, with options such as “Configuration,” “Subscription,” “Proxy Groups,” “System Proxy,” and “Service Mode.” The underlying process is much the same: the client reads nodes and rules from the subscription, you choose a route and proxy mode, and the client then manages the system proxy or handles broader traffic through TUN mode. Once you understand this flow, you can find the next step even after the interface changes.

Check the Source and Core Before Installing the Client

The client only reads configuration and establishes connections; it is not the same thing as the subscription service. Get the Windows version from 70VPN’s client download page, then obtain the subscription after signing in. Avoid modified builds from unknown reposting sites, and do not run installers made for other platforms on Windows.

After downloading, determine whether you have an installer or an archive. Installers usually create a Start menu entry and provide a more complete uninstall process; portable versions can run after extraction, but their configuration files are generally stored in the application folder or a user-data directory. With a portable version, do not launch it from inside the archive or place it in a restricted temporary folder that may be cleaned regularly.

Some Windows clients use Mihomo, sing-box, or another networking core. An interface showing a protocol does not guarantee that the active core can connect with it. If the subscription contains nodes but startup reports “Unsupported,” check the client documentation and core version first instead of repeatedly switching routes. Key points for common protocols are listed below.

• ✅ Get the Windows version from the client download page in the service dashboard.
• ✅ Close other similar tools that control the system proxy or virtual network adapter.
• ✅ Fully extract the portable version to a fixed folder before running it.
• ✅ When starting for the first time, allow the trusted client through Windows Firewall.
• ❌ Do not paste the subscription URL into search engines, public chats, or screenshots.

Import the Subscription URL Correctly

After signing in to the service dashboard, find the subscription section and copy the URL for your current client. A subscription URL is not an ordinary information page; it usually lets the client retrieve nodes, proxy groups, and rules, so treat it like account credentials. Return directly to the client after copying it. Do not open it in the browser address bar or send it to anyone else just to “check the contents.”

A typical import flow is to open the “Configuration” or “Subscription” page, choose “Import from URL,” “Create Remote Configuration,” or a similar option, paste the URL into the address field, give the configuration a recognizable name, and then download or update it. After a successful import, the configuration list should show the new entry, and the proxy page should display groups organized by region or purpose.

If the client offers automatic subscription updates, enable a sensible update schedule if needed. An update only retrieves the current configuration from the service; it does not automatically choose the best route for you. If proxy groups change after an update, review the selected node again so an outdated name does not leave you on an unavailable entry.

1. Sign in to the dashboard and copy the subscription URL for the Windows client.
2. Open the Configuration or Subscription Management page in the client.
3. Choose to import a remote configuration from a URL and paste the complete link.
4. Save it, run an update once, and wait for the configuration to finish parsing.
5. Open the Proxy or Nodes page and confirm that route groups are listed.

If the download fails, fully quit the client and check Windows proxy settings for a leftover manual proxy. After an abnormal exit, Windows may still point to the old local port even though no program is listening there, causing both browsers and subscription updates to fail. Disable the leftover proxy, restart the client, and run the update again to determine whether the issue was caused by the local proxy state.

Choose a Route and Proxy Mode by Purpose

Once the route list appears, do not look only at region names. Consider the target service’s location and your intended use first, then factor in the route type. A direct route connects locally to the remote server with a simpler path, but it can be more affected by fluctuations at the local carrier’s international exit. A relay route first enters a relay node and then continues to the target region, which can improve the path in some cases; actual performance still depends on the quality of both the entry and exit.

The main difference between an IEPL private line and ordinary public-internet direct or relay routes is the underlying transport path. Private lines are generally used for cross-border transfers where stability matters, but “private line” should not be understood to mean the fastest option at every moment. Web browsing, file transfers, video playback, and real-time interaction have different priorities: browsing depends more on smooth connection setup, sustained transfers on bandwidth and jitter, and real-time interaction on avoiding sudden latency changes.

For an initial setup, choose a nearby route that matches your purpose and confirm that the basic connection works before comparing other regions. If a target website requires a particular region, choose that region instead of simply chasing the lowest latency shown by the client. A client’s latency test usually reflects only a probe request, not the complete path to the target service, and it cannot be treated as download speed.

Choosing Between System Proxy and TUN Mode

System proxy mode is a good place to start basic verification. It changes Windows proxy settings, so browsers and apps that follow the system proxy can use it, while some games, command-line tools, and apps with their own networking stack may bypass it. If a browser works but a particular app cannot connect, the route is not necessarily at fault.

TUN mode uses a virtual network interface to handle a broader range of traffic. It is useful for software that does not read system proxy settings and makes it easier to apply split-tunneling rules consistently. It usually requires administrator permission and may conflict with other virtual adapters, corporate network clients, or security software. For a first setup, verify the subscription and route with system proxy mode, then enable TUN only if needed to avoid introducing too many variables at once.

Choosing Between Global Proxy and Split Tunneling

Global proxy mode sends more traffic through the current route, making it useful for checking whether an app works through the proxy, but it is not ideal as the long-term default for every situation. Split tunneling uses domains, IPs, processes, or rule sets to decide between direct and proxied connections. Local services can remain direct while requests that need international routes use the proxy. Rule mode is better suited to everyday use, but outdated rules or an incorrect match order can send a target website through the wrong route.

Troubleshoot by changing one condition at a time: fix the route and test the connection first, then switch proxy modes; confirm that the system proxy works before trying TUN; verify global mode before deciding whether split-tunneling rules are causing the access issue.

Verify the Proxy Is Working and Check DNS

A green status or “Connected” message only means the local core has started; it does not prove that every app is using the selected route. Verify in layers: check the client logs for recurring errors, confirm the Windows system proxy status, then visit the site’s IP lookup page and compare the outbound connection details before and after enabling the proxy.

Next, test your browser and frequently used apps separately. If the browser works but another app fails, first check whether that app ignores the system proxy. If every app fails, inspect the current configuration, route, and local port. If only one website is affected, the cause is more likely to be the selected region, split-tunneling rules, DNS resolution, or restrictions imposed by the target service.

A DNS leak occurs when application traffic is sent through the proxy while domain lookups are still handled directly by the local network. This can expose the destinations being queried and may resolve domains to addresses unsuitable for the current exit region. The key is not to switch randomly between public DNS services, but to check whether the client’s DNS mode, rule matching, and TUN configuration form a complete path.

When enabling the client’s encrypted DNS, remote DNS, or proxy DNS, follow the configuration requirements for rule mode in its documentation. Some clients resolve local domains locally and send domains requiring a proxy to remote DNS; others use virtual address mapping together with rule evaluation. Do not combine these mechanisms casually, and avoid letting multiple network tools modify DNS and virtual adapters at the same time.

• ✅ The client logs show no recurring timeout, handshake, or authentication errors.
• ✅ The Windows proxy status matches the client’s toggle state.
• ✅ The IP lookup result matches the selected route’s region and expected exit.
• ✅ Both the browser and the desktop apps you actually need have been tested.
• ✅ In rule mode, local services and international websites follow the expected paths.
• ❌ Do not use the client’s “Connected” status as your only verification.

Configure Startup Launch and Auto-Connect

Handle startup launch only after the current configuration is stable. Client settings commonly separate “Launch at startup,” “Start minimized,” “Enable system proxy on startup,” and “Restore last configuration” into different toggles. Enabling launch at startup merely runs the program with Windows; it does not necessarily enable the proxy. Enabling the system proxy alone can also leave an unusable state if the program fails to start.

A safer order is to save the current subscription and proxy-group selection, enable the client’s own startup launch, and then enable system-proxy restoration after startup if needed. If you normally use TUN mode, confirm that the client can obtain the required permissions during startup. Some environments allow user apps to finish starting only after sign-in, so a brief lack of proxy access just after reaching the desktop may be a startup-order issue, not something to fix by repeatedly clicking multiple toggles.

After completing the settings, perform a real restart test. Once the desktop appears, wait for the client to finish loading, open its interface to confirm that the subscription configuration, current route, and proxy mode were restored, and then run an IP lookup. Do not consider the setup successful merely because a process appears in Task Manager: a running process, a started core, an enabled system proxy, and a reachable route are separate states.

If the client’s startup setting does not work, open Windows Startup Apps and confirm that the entry has not been disabled. After moving a portable version, the existing startup entry may still point to the old path. Disable startup launch in the client, quit it, reopen the program from its new folder, and enable startup again instead of keeping multiple broken entries.

1. Save the current subscription configuration and confirm that a working route is selected.
2. Enable launch with Windows in the client settings.
3. If needed, enable system-proxy or TUN restoration after startup.
4. Quit and reopen the client to confirm that the settings are retained.
5. Restart Windows and verify that the program, proxy status, and route connection are restored.

Common Troubleshooting: Start with Local Status

The Client Starts, but No Websites Open

First disable the system proxy in the client, then check whether Windows still has a manual proxy address configured. If the network recovers after disabling it, the issue is likely with the local proxy port, core process, or current route. Restart the client and review its logs. Do not repeatedly update the subscription while the network is already down, because the update request may also be blocked by the inactive proxy.

The Subscription Updates, but Every Node Fails to Connect

A successful subscription update only proves that the configuration URL is reachable. If every node fails, first check the system time and time zone, then confirm that the client core supports the protocols in the subscription. If different protocols such as Shadowsocks and Trojan all fail, inspect the local firewall, corporate network restrictions, and other virtual adapters. If only Hysteria2 or TUIC fails, focus on whether the current network supports UDP.

The Browser Works, but Games or Desktop Apps Do Not

This is usually related to whether the application reads the system proxy. Check whether the client offers process-based rules; if the app bypasses the system proxy entirely, try TUN mode after confirming that the basic connection works. Before enabling it, quit other virtual networking software. Afterward, check that routing and DNS are managed by the same client.

Rule Mode Fails, but Global Mode Works

This suggests that the route itself is probably working, so focus your investigation on the rules. Check whether the target domain matched a direct, proxy, or reject rule, confirm that the proxy group is not pointing to an inactive node, and update the remote rule set. If the client supports connection logs, use the match result for the target domain to determine which rule took priority.

Ordinary Network Access Does Not Return After Closing the Client

First disable any leftover manual proxy in Windows proxy settings, then check whether the client exited abnormally. When using TUN, also turn off TUN normally and quit the client so the virtual routes can be cleaned up. Do not delete system network adapters at random, as this may affect the normal network adapter and other software.