V2Ray Setup for Every Platform
Installation and Configuration

Before You Start: Check Your Configuration Source and Traffic Routing

What the Client, Core, and Nodes Do

The client stores subscriptions, displays nodes, builds configurations, and controls connections. The core handles protocol handshakes, routing rules, and traffic forwarding. A node is the remote server your client connects to. Installing v2rayN or v2rayNG does not provide usable nodes automatically. And even when two configurations use the same protocol, their addresses, identity fields, and transport settings may not be interchangeable. Before you begin, make sure you have a subscription URL or complete node details you’re authorized to use, then choose a client for your platform.

For desktop, v2rayN offers a similar setup across Windows, macOS, and Linux. On Android, v2rayNG with the Xray core is the usual first choice; consider v2flyNG when you need the V2Fly ecosystem. Supported protocols depend on the actual core and client implementation, not just the app’s name. Before importing a configuration, confirm its share format, transport type, and TLS requirements with the provider. Otherwise, unsupported fields can look like a network problem.

Check Your System Architecture and Install Location

On Windows, check Settings → System → About for your system type. On macOS, open About This Mac from the Apple menu to identify the processor. On Linux, check the distribution and processor architecture in the system’s About page. On Android, find your device model in Settings → About phone and check its specifications. The package must match your device; file size alone isn’t a reliable guide. Find installers for every platform on the download page. Select your operating system first, then choose the matching architecture and package format.

Also check that your user directory is writable, you have enough disk space, and the system date and time zone are correct. Certificate validation depends on accurate time, and clock skew can affect protocols with time-based requirements. If you already have an older client, note your node groups, routing mode, listening ports, and subscription update method. Don’t overwrite a new installation with every file from the old directory. Configuration formats can change between clients and cores, so make a backup and migrate settings one by one.

System Proxy, App Proxy, and TUN: What’s the Difference?

A system proxy advertises a local proxy address to apps that follow the system settings, but not every app does. An app proxy is configured separately inside a specific app. TUN receives traffic through a virtual network interface, usually covering more traffic but relying on permissions, routing, and DNS working together. These are ways for traffic to enter the client. The client’s Global or Bypass routing mode determines where traffic goes next. Don’t confuse the two.

Prepare Your Subscription and Backup

A subscription is an updateable list of node configurations, not an account sign-in page. Copy the entire URL, including its path and query parameters, without adding spaces, line breaks, or punctuation from the end of a message. Subscription URLs that contain account identifiers are sensitive: don’t include them in public screenshots, online decoding tools, or shared documents. Create a dedicated subscription group and manage updates, replacements, and deletions there to keep manually added nodes separate.

For your first setup, enable only one traffic-routing method and note the system proxy’s original state. Once the connection is verified, add TUN, advanced routing, or custom DNS as needed. This makes it clear what to undo if something goes wrong. If your device is managed by an organization, check its network permissions first. Follow the device management rules if you can’t change the system proxy or create a virtual interface; permission limits don’t mean the client failed to install.

Windows: Install v2rayN and Configure the System Proxy

Choose Between the Desktop and Classic WPF Editions

The Windows download options for v2rayN include a desktop edition and a classic WPF edition. The desktop edition uses a cross-platform interface, while WPF retains the traditional Windows layout. Both need a valid node configuration and a working core; interface differences don’t indicate a difference in node quality. For a first installation, consider the desktop edition. If you’re used to WPF, back up your existing configuration before deciding whether to switch. There’s no need to run both editions at once.

Run the installer and follow the setup wizard. If the app reports a missing runtime on first launch, install the system component specified for that release. Don’t copy runtime files at random from another app’s directory. After installation, open the main window and check that the log isn’t showing persistent startup errors. A standard system proxy usually doesn’t require administrator privileges. Grant the permissions requested by the client only when using TUN, a service, or network interface management.

Add a Subscription to a Group

In the main window, open Subscription Groups → Subscription Group Settings, add a group name and subscription URL, then save and return to the main screen. From the Subscription Groups menu, select Update Current Subscription (Direct) if your network can reach the subscription server without a proxy. If it’s only accessible through an existing working proxy, choose the update option that uses a proxy. Menu labels may vary by version, but distinguish the current group from all groups to avoid updating unrelated sources.

After updating, check the server list in the relevant group. If it’s empty, review the update log to tell a failed request from a login page or a parsing error. To import shared links, use Server → Import batch URLs from clipboard; use the appropriate scan option for QR codes. Subscription URLs, single-node share links, and native core JSON are different input formats. Don’t paste them all into the same field. See subscription and share-link formats compared for details.

Select an Active Node and Enable the System Proxy

Select a node in the server list, then use the right-click menu’s Set as Active Server option or the equivalent control in your version. Check the log for a successful core startup. Next, right-click the tray icon, open System Proxy, and select Automatically Configure System Proxy. In Windows Settings → Network & Internet → Proxy, check that the manual proxy address points to the address the client is actually listening on. Use the port shown in v2rayN’s settings and logs; don’t copy a value from another device.

If your browser has an extension that manages proxy settings, disable its rules first so they don’t override the system proxy. If your workplace network uses an automatic configuration script, note its URL before changing system proxy settings, as the change may disrupt your usual route. When you’re done, clear the proxy in v2rayN’s System Proxy menu before quitting. If you force-close the process, the system may still point to the now-closed local port, leaving the browser unable to connect.

TUN Permissions, Ports, and Common Conflicts

Once the system proxy works, turn on TUN from the main window. If the client reports insufficient permissions, exit and relaunch with administrator privileges if needed, then confirm the active node. When TUN fails to start, check the log for virtual interface, routing, and permission errors instead of reinstalling the client repeatedly. Other VPNs, virtual machine networks, and security software can also change routes. Use only one traffic-routing tool at a time until you’ve identified the conflict, then consider how to run them together.

If the log reports a port binding error, open Settings → Parameters and check the local listening port. Stop any older process using the same port. Don’t enable Allow connections from the LAN to fix a local binding issue; that setting changes who can access the listener. Before switching TUN on during a remote desktop session, have a recovery plan ready, since routing changes may disconnect you. Finally, restart the client and confirm the subscription is still there, the correct node is active, and the system proxy can be restored when you exit.

macOS: Choose the Right Chip Build, Grant Permissions, and Restore Proxy Settings

Install v2rayN for Your Mac’s Processor

Open About This Mac from the Apple menu. If it shows an Apple chip, choose the Apple Silicon download; if it shows an Intel processor, choose the Intel version. Find both under the macOS download options. Open the disk image and follow the installer to move the app into Applications, then launch it from there. Don’t keep running it from a temporarily mounted image; upgrades, path references, and permission records may not match the installed location.

If macOS blocks the app on first launch, confirm the file source and installation steps, then check the message under System Settings → Privacy & Security. Use the system’s one-time approval option only if you’re sure the app is expected. Don’t disable system security as a whole. If macOS says the app is damaged or can’t be opened, download the build for your processor again and check that your system meets its requirements. Changing node settings won’t fix this kind of error.

Import a Subscription and Confirm the Active Server

In v2rayN, open Subscription Groups → Subscription Group Settings, create a group, save the subscription URL, then update the current subscription. If you haven’t established a proxy connection yet, try updating directly first. Use a proxy only if you already have a working connection and the subscription source requires it. When the update finishes, check the log for request and parsing results, then make sure the server list shows the expected nodes. The group name is a local label; it doesn’t change which nodes the subscription server returns.

Select a node and set it as the active server, then check that the core starts successfully. When moving to another computer, reimport the subscription rather than copying the entire program directory. Desktop settings may include system-specific paths, window state, and core file locations that won’t work on another system. For manually added nodes, compare the port, identity, TLS, SNI, and transport path field by field. Matching labels don’t mean the configurations are identical.

Check the Proxy Status for Your Current Network Service

After enabling the system proxy in the client, open System Settings → Network, select the Wi-Fi or Ethernet service you’re using, then go to Details → Proxies. Check that the web proxy, secure web proxy, or SOCKS proxy matches the client settings. Labels vary slightly across macOS versions; make sure you’re checking the active network service, not a disconnected interface. The address, port, and protocol must match the actual listener.

If browser behavior changes after switching Wi-Fi, plugging in Ethernet, or changing network locations, check the active service’s proxy settings again. Some apps have their own network settings and may not follow the system proxy; confirm that they’re set to use it. Also check whether a browser extension is taking over proxy control. To rule out extension interference, use a clean profile or a window with extensions temporarily disabled. There’s no need to delete all browser data.

TUN, Sleep, and Restoring Network Settings on Exit

Try TUN if you need to route traffic from apps that don’t follow the system proxy. Grant the permissions requested by the client, then check the log to confirm the interface and routes were created. If no traffic flows after enabling TUN, turn it off and confirm the regular system proxy still works. Then check permissions, other VPNs, and DNS settings. Avoid repeatedly switching every system proxy and TUN option at once; it makes it hard to tell which route changed.

The network interface may be recreated after your Mac wakes from sleep. If the connection fails after waking, first confirm the network is back, then restart the connection or re-enable your routing method. If the issue occurs only on a particular Wi-Fi network, check whether it requires a sign-in page; you may need to pause the proxy to authenticate normally. Your subscription and node settings usually don’t need to be removed. Narrow the issue down to network recovery before importing anything again and creating duplicate groups.

Android: Import Subscriptions and Route Traffic Through the VPN

Choosing Between v2rayNG and v2flyNG

On the Android download options page, v2rayNG is the recommended first choice and uses the Xray core. Use v2flyNG as an alternative when you need the V2Fly ecosystem. Most recent mainstream phones use arm64; if you’re unsure of your device’s architecture, consider the universal build. It supports more architectures but can’t bypass Android version or hardware requirements. The clients may support different node formats, so don’t assume they support every protocol just because both can scan QR codes.

When opening the installer, Android may ask you to allow app installation from your current file manager or browser. Grant permission only to the source you need, and revoke it in Settings after installation if you prefer. If the package conflicts with an existing app, first check whether you’re updating the same app and using the same source. Don’t uninstall the old app right away; that may erase local nodes, per-app rules, and subscription groups. Back up your configuration before resolving the installation conflict.

Add a Subscription or Import from the Clipboard

In v2rayNG, open Subscription Group Settings from the side menu, tap Add, enter a label and the complete subscription URL, and save. Return to the main list and select Update Subscription from the menu. To import a single share link, use Import from Clipboard in the main screen’s add menu; use the scan option for QR codes. The v2flyNG layout may differ. Look for Subscription Group Settings and the subscription update action rather than relying on another client’s button locations.

If an update returns no nodes, make sure you copied an actual subscription URL, not an account management page. Some sources return content that requires additional request settings that a mobile client may not recognize. Check the log to distinguish a network error from a parsing error, then confirm the format with the configuration provider. Never post a full subscription URL in a public help screenshot. Even if you blur node addresses, account identifiers in the query parameters may still be usable by others.

Start a Connection and Approve the Android VPN Request

Tap a node in the main list and confirm it’s selected, then tap the Connect button in the lower-right corner. The first time you connect, Android asks for permission to establish a VPN connection. Allow it so the client can create a local traffic-routing interface. This permission routes device traffic through the client; it doesn’t mean the remote node is connected. A VPN icon only shows that the routing service is running. Check the log and test a connection to confirm that the remote handshake and routing work.

Other VPN apps may compete for Android’s VPN service. If starting the client stops another connection, check whether both are trying to use the VPN service. To route only selected apps, open Settings → Per-app proxy and check whether the selected apps will be proxied or bypassed. After changing the list, reconnect and test the target app. Don’t infer how the rule works from whether an app is checked; read the selected mode carefully.

Background Limits and Network Changes

If the app frequently disconnects in the background, open Android Settings → Apps → v2rayNG → Battery and check background restrictions. Depending on the manufacturer, the controls may be under battery optimization, background management, or auto-start. Allow background activity as needed so Android doesn’t stop the service when the screen is locked. Don’t remove restrictions for every app; change settings only for clients that need a persistent connection, then keep an eye on battery and data use.

Switching between Wi-Fi and mobile data changes the local address, routes, and DNS environment. If the connection stalls after a switch, stop and restart it, then check whether the node address resolves again. If only one app fails, check per-app rules, the app’s own proxy settings, and its background data permissions. If every app fails, check the active node and basic connectivity. A connection icon with no new requests in the log usually means you should first check whether traffic is reaching the client, not immediately change protocols.

When moving to another phone, add the subscription again first, then restore per-app rules separately. App lists depend on what’s installed on the new device, so copying an old list directly may omit the apps you want. QR codes and share links transfer a specific node, but may not include the subscription URL, DNS, or routing settings. For multi-device setup, see how to sync nodes and settings across devices.

Linux: Package Formats, Desktop Proxy, and Permissions

Choose a Package for Your Distribution and Architecture

For a Linux desktop, use v2rayN. Check your distribution and processor architecture in the system’s About page, then choose a package from the Linux download options. Debian-based systems typically use deb packages; distributions that use RPM package management need rpm packages. These are not interchangeable archives that you can convert by changing the file extension. Most desktop PCs use x64, while ARM devices need the matching arm64 build. The distribution, architecture, and desktop runtime all need to match.

Open the package with your system’s software installer, review any dependency warnings, and complete the installation using your distribution’s normal process. If the installer reports missing dependencies, first confirm that your system repositories are available. Don’t copy shared libraries from another machine into the app directory. After installation, launch v2rayN from the app menu and check that the window and log display correctly. Headless remote systems are outside this desktop app workflow; don’t apply desktop system proxy settings to a background service.

Import a Subscription and Check Configuration Directory Permissions

Open Subscription Groups → Subscription Group Settings, add the URL, save, and update the current subscription. Then select an active server from the list. On first launch, run the client as a regular user so it writes configuration to a location you can manage. If you previously ran it as an administrator and now can’t save settings or update subscriptions, check the owner and permissions of the configuration directory. Don’t use elevated privileges every time to hide a directory permission problem.

When an update fails, check the request error in the log. If the basic network works but the subscription can’t be reached, the client may be fine; the URL could have expired, the response may not contain a node list, or the update may require an existing proxy. After a successful import, check that the transport and TLS fields were recognized. A desktop window opening only proves that the interface runs. Core startup, configuration generation, and the remote handshake still need separate checks; don’t collapse them into a single “installation succeeded” result.

GNOME, KDE, and App Proxy Boundaries

In GNOME, manual proxy settings are usually under Settings → Network → Network Proxy. In KDE Plasma, check System Settings → Network → Proxy; names and categories vary by desktop version. Match the proxy protocol, address, and port to the v2rayN listener. HTTP and SOCKS are not interchangeable just because their ports look similar. If the client’s automatic system proxy setup doesn’t work, check the desktop proxy page before entering values manually.

A desktop proxy setting may not carry over to terminal programs, and environment variables may not affect graphical apps that are already running. If a program has no requests in the log, check its own network settings or proxy documentation. Sandboxed apps may also have a separate network environment; a loopback address inside a container isn’t the same as the host’s loopback address. To reach the host proxy, account for network boundaries and access controls rather than exposing the listener on every interface.

Using TUN Alongside Existing Network Tools

Before enabling TUN, confirm that the regular proxy can access websites, then follow the client’s instructions for virtual interface and permission setup. Permission management varies across distributions, so use the actual error and package documentation as your guide. If the log reports that an interface can’t be created, permissions are insufficient, or a route can’t be added, resolve that specific step first. Don’t switch your entire desktop session to an administrator account or grant network management privileges to unrelated apps.

Virtual machines, container networks, and other VPNs add routing complexity. If LAN devices become unreachable with TUN enabled, check whether private addresses are set to bypass the proxy as expected, then look for overlapping subnets. Save the original rules before changing routes, and change one thing at a time. DNS may also be managed by the system network manager, which can overwrite manual edits to resolver files. Identify the active DNS management interface before deciding whether the client or the system should handle name resolution.

Before quitting, turn off TUN, restore the desktop proxy, and confirm that a regular browser can connect directly. If only terminal apps are affected, check for proxy environment variables in the current session. If all apps are affected, check the system proxy and routes. Back up subscriptions and custom rules before upgrading. After the upgrade, test the original simple setup first. Changing the core, DNS, and routes all at once makes it impossible to compare results with a known baseline.

Routing and DNS: Check Traffic Entry and Exit Separately

Global Proxy Doesn’t Route All Device Traffic

First check whether a request reaches the client, then check which outbound route it takes. A system proxy affects only apps that follow proxy settings. Selecting Global in the routing menu won’t capture traffic that never enters the client. Conversely, with TUN enabled, routing rules can still send LAN traffic and specific domains directly. When a global proxy seems ineffective, note the traffic-routing method, active routing rules, and target app rather than relying on a mode label alone.

In v2rayN, change the routing preset from the main window and review rules under Settings → Routing Settings. On Android, check the routing options under Settings. Preset names may differ across clients; expand the settings to see the actual match conditions. Rules are typically evaluated in order, so a broad rule near the top can override a more specific one below it. Adding an exception after a rule that already matches all traffic usually won’t work.

Understand Domain Rules and Outbound Tags

The snippet below shows the structure of core routing settings to explain how the fields relate; it isn’t a complete, standalone configuration. It relies on available geosite data and requires a direct outbound with the tag direct in the full configuration. The proxy outbound must be defined by the actual node configuration. Clients generate their own complete configurations. Before editing, confirm whether you’re working in the routing rules section or a custom configuration file; don’t paste this snippet into a subscription URL or node share-link field.

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      }
    ]
  }
}

geosite:cn references a domain set; it doesn’t perform a live geographic lookup for every Chinese IP address. The set depends on its data file, and a site may load content from aliases or other resource domains. outboundTag must match an existing outbound tag, not just a name that looks suitable. Test a few specific domains first, then expand to a larger set. A page’s language doesn’t tell you whether a routing rule is working.

System DNS vs. Core DNS

DNS translates domain names into IP addresses, but requests may be made by the system, an app, the core, or a remote proxy. If an app resolves a domain itself and sends an IP address, the client may no longer see the original domain. If it passes the domain to the proxy, resolution can happen later in the connection chain. Encrypted DNS in the browser can also change the resolution path. So “change DNS” isn’t one universal action: specify whether you mean system network settings, browser settings, or the core DNS generated by the client.

Before changing local or remote DNS in v2rayN under Settings → DNS Settings, or in an Android client’s Settings, keep the default setup and establish a baseline. Then change one resolution path at a time. Remote DNS that depends on a proxy you haven’t connected to yet can create a startup dependency loop if the node’s hostname also needs to be resolved. Make sure there’s a working way to resolve the node address initially; don’t send every DNS request through the proxy by default.

LAN, IPv6, and Verification Limits

LAN devices, printers, and local services usually need direct access. If external websites work but you can’t open your router’s admin page, check private address routing and local DNS instead of disabling all routing rules. Check IPv6 separately as well: having an IPv6 address doesn’t mean the node, TUN setup, or DNS configuration supports the same route. A successful IPv4 test doesn’t prove that every request in a dual-stack network follows the same rules.

For complex issues, restore the client’s default routing preset and add custom rules one at a time. Record the target domain, actual DNS result, matched outbound, and failure stage; that’s more useful than repeatedly changing DNS servers. If only UDP-based apps fail, check whether the node protocol, transport, and traffic-routing method support them rather than adjusting only the web proxy. Find more answers in the FAQ. Keep field names in troubleshooting notes, but don’t share personal information.

Verify Connections: Logs, Speed Tests, and Device Migration

Check the Network, Core, and Requests in Order

First disable traffic routing and confirm the device can access ordinary sites allowed on its current network. Hotels, campuses, and guest Wi-Fi may require a sign-in page; don’t mistake an unauthenticated network for a node timeout. Then start the client, set one active node, and check that the core starts successfully. Finally, open a single target app and make a request, then look for it in the log. This sequence separates basic connectivity, configuration generation, and proxy forwarding so you don’t change too many settings at once.

If the target request isn’t in the log, check the traffic entry point first: another tool may have overridden the system proxy, the app may use its own proxy, or the per-app list may be set to the wrong mode. If the request appears but the handshake fails, check the node settings, system time, TLS, and network reachability. If it forwards successfully but the page is incomplete, check routing and DNS for the page’s other resource domains. A page load uses multiple connections; seeing the homepage title doesn’t mean every resource loaded correctly.

Port Checks, Real Connection Latency, and Download Speed Tests

A TCPing-style test mainly checks whether a connection can be established to a target port; it doesn’t prove the full proxy protocol works. Real connection latency includes the proxy handshake and a request to a test target, making it a closer measure of the actual connection path. A download speed test measures throughput over a period of time. Each test answers a different question, so don’t rank nodes by comparing their numbers directly. If a port is reachable but a real connection fails, check identity, transport, and TLS rather than treating the port test as proof that the node works.

Speed test results depend on your local network, test target, node exit, and concurrent load. Results from different devices, times, or test servers aren’t directly comparable. To reduce noise, test a few candidate nodes at a time and stop other bandwidth-heavy tasks. When choosing a node, first confirm that the target app can make requests reliably, then consider latency and throughput. See TCPing, real connection latency, and download speed tests explained for background. A single test isn’t a guarantee of long-term performance.

Read the Failure Stage, Not Just the Last Log Line

A port binding error usually occurs during local startup. A connection timeout may occur during network setup or a later handshake. For certificate errors, check the hostname, system time, and validation requirements. Read a few lines before and after the error to identify the active node and outbound. Logs can contain old connection errors; after switching nodes, note the time before testing so you don’t use a previous node’s failure to explain the current one.

When asking for help, include the client name, operating system, traffic-routing method, error keywords, and steps to reproduce. Remove subscription URLs, identity fields, sensitive domains, and account details. Don’t show your entire configuration file just to make a screenshot easier to read; the relevant fields and error lines are usually enough. For repeatable node timeouts, follow the troubleshooting order for system time, port, TLS, and routing and record the result of each check instead of saying you “tried everything.”

Sync Subscriptions and Migrate Local Settings

To keep nodes consistent across devices, add the same subscription source you’re authorized to use on each device, then update them separately. A subscription syncs the node list returned by the server; it doesn’t sync the active node, system proxy, TUN, per-app list, or custom DNS. Computers and phones may have different network conditions and need different routing. Share the subscription source, but verify traffic routing on each device; there’s no need to make every setting identical.

Sharing an individual node is useful for a quick transfer. A full backup preserves your local organization; they serve different purposes. Before restoring a backup, save your current configuration and check file paths and platform-specific options. After changing clients or cores, import a few nodes first and confirm that all protocol fields are present before migrating every group. Subscription updates can overwrite nodes managed by that source, so save a separate copy before editing them. Restoring an old backup won’t restore a remote account that has expired.

Common Setup Questions: Troubleshoot by Failure Point

The Subscription Updates, but Why Won’t the Nodes Connect?

The subscription server and node server may be at different addresses. A successful update only means the client retrieved and parsed the configuration; it doesn’t prove that a node’s port, account, or transport works. Confirm that the expected node is active, then test a real connection and check the log. If every node fails, start with the basic network, system time, core startup, and common routing settings. If only certain nodes fail, check their addresses, account status, and server parameters instead of reinstalling the client.

Subscription fields may also be unsupported by your current client or core. Successful import doesn’t mean every extended field took effect, especially for transport, TLS, and security settings. Don’t delete unfamiliar fields and assume the configuration is compatible just because it saves. Confirm the requirements with the provider, then choose a matching client and core. If a subscription update replaces manually added nodes, keep them in a separate group rather than repeatedly editing the subscription group.

The Port Is Reachable, but TLS or a Real Connection Fails

Start TLS troubleshooting with the system time, server name, and certificate requirements. The connection address can differ from the name used for verification, and SNI shouldn’t be set to the website you want to visit. Check the original node details instead of guessing from the address. If the server requires a transport path or Host value, match those fields exactly. Checking only the port and identity can miss the setting that’s actually causing the handshake to fail.

Don’t disable certificate verification as a routine fix. It changes the security boundary and may only hide a misconfiguration. If the time is correct but the name still doesn’t match, check for outdated settings, a connection to the wrong server, or a network sign-in page interfering with the connection. If the original configuration is wrong, get the correct parameters before testing again. Changing multiple settings at once makes later logs hard to compare. Keep the original and check one field at a time.

Websites Work, but LAN Access Changes After Connecting

If the browser works but other apps don’t, first check whether those apps follow the system proxy instead of changing nodes right away. If only LAN access fails with TUN enabled, check the private network bypass and local DNS. If one site fails while others work, check whether its resource domains use different routing rules and whether the app has cached an old DNS result. Restart the target app to test again; there’s no need to clear all settings or delete every subscription.

If both external sites and LAN access fail, turn off TUN and compare with a simple system proxy setup. If the simple setup works, narrow the issue down to TUN permissions, routing, DNS, or a conflict with another network tool. Take extra care when managing a device remotely; changing the default route can disconnect your session. Prepare a local recovery method or keep an existing session open before changing settings that affect all device traffic. Don’t change multiple network settings at once if you can’t recover access.

Why Can’t I Connect to the Internet After Quitting the Client?

First check whether the system still points to the client’s local listening port. On Windows, check network proxy settings; on macOS, check the Proxies page for the active network service; on Linux, check the desktop proxy and app environment. When the client is stopped, nothing is listening on that port, so apps using the proxy can’t connect. Restart the client and clear its system proxy, or restore the original settings manually using your notes. Don’t remove a workplace proxy script that was already part of your network configuration.

On Android, check whether the VPN has stopped and review Always-on VPN or Block connections without VPN in the system’s VPN settings. If a blocking option is enabled, Android may restrict regular connections after the service stops. Restore the settings to suit your needs, then verify basic connectivity. If a computer still has a virtual interface or routing problem, close other network tools normally and restart the connection. Don’t delete every network adapter to solve an issue with one client.

When Should You Go Back to a Simple Setup?

If the logs, proxy status, and app behavior don’t agree, save the current setup and return to one node, one traffic-routing method, and the default routing rules. Once that baseline works, restore DNS, routing rules, per-app settings, and TUN one at a time. See the getting started guide for the basic workflow and the client comparison to choose an app. When asking for more help, describe the specific failure stage, such as a failed subscription request or TLS handshake, rather than saying only that the software doesn’t work.