01 / PREPARATION
Before you begin
Understand the client, core, and server configuration
The client displays nodes, stores subscriptions, lets you choose routing options, and starts connections. The core handles protocols, encryption, and traffic forwarding. Server configuration supplies the remote address, port, and authentication details. Installing a client does not give you a working connection by itself. Before you start, get a valid subscription URL or a complete set of node details, and make sure your network can access ordinary websites.
For desktop platforms, v2rayN is the usual choice. On Android, v2rayNG with the Xray core is generally a good starting point. Consider v2flyNG if your existing configuration specifically depends on V2Fly. VLESS, VMess, and Trojan are different protocols; REALITY is a transport security configuration. Similar names do not mean their fields are interchangeable. Core support also depends on the specific build, and a successful import does not guarantee that every parameter will work.
Check your OS, architecture, and permissions
Check your processor architecture in system information, then choose a package on the client downloads page. The OS and architecture must both match: even desktop systems may use either x64 or arm64. File size is not a reliable way to judge compatibility. Before installing, check available disk space and make sure your account can install apps. TUN also requires the appropriate administrator permissions.
First, set your system to sync the date, time, and time zone automatically. An incorrect clock can interfere with certificate verification or protocol authentication that relies on time. This is especially worth checking if the device has been asleep for a long time, has just resumed from a system snapshot, or has been stored offline. Then make sure the network is not waiting for a sign-in page; if the network itself is not connected, repeatedly changing node settings will not help.
Before your first setup, quit any other proxy or tunnel software that is routing network traffic. Multiple apps may compete for the same local listening port or change system proxy, default route, and DNS settings at the same time. Keeping just one client running makes it easier to match logs to actual traffic. If your workplace network has a managed policy, confirm what is allowed before making changes; do not bypass those requirements by altering system settings.
Start with a minimal, testable setup
Get a connection working through the system proxy before trying TUN. The system proxy typically affects only apps that honor the system settings, so there are fewer variables to troubleshoot. TUN routes more traffic and adds virtual network adapters, permissions, and routing to the mix. Both require a working remote node. Enabling every advanced option before establishing a basic connection only makes it harder to find the cause of a problem.
Note the local address and listening port shown by the client, and distinguish between HTTP, SOCKS, and mixed-protocol endpoints. Use the port shown in your own settings rather than copying it from a screenshot of another device. A loopback address is for local use; a LAN address allows other devices to connect. They serve different purposes. For your first setup, keep the listener local and leave “Allow connections from the LAN” off.
When testing, check three things: whether the client can start the core, whether the app sends traffic to the local proxy, and whether the remote request gets a response. A tray icon, an enabled connection toggle, or a speed test alone does not prove the whole connection is working. Change one setting at a time, and note the previous value and how to reproduce the issue so you can revert if needed.
If you already have a working setup, export the configuration or back up the app data before installing or updating. Backups may contain subscription links and node credentials, so store them somewhere secure. This guide describes settings by function; menu layouts may vary between builds. If the interface looks different, look for the relevant setting rather than an exact button in the same position.
02 / WINDOWS
Windows setup
Choosing between the Desktop and classic WPF editions
Open the Windows downloads section and choose either the Desktop or classic WPF edition from the v2rayN card. The Desktop edition uses a cross-platform interface; WPF retains the classic Windows interface. Both handle nodes, subscriptions, and proxy settings. If you are new to v2rayN, start with Desktop. If you already know the WPF workflow, stick with it. There is no need to run both versions just to try a different interface.
After downloading, follow the installer prompts to choose a folder. Make sure your account can write to it, and avoid temporary download folders or locations that sync software may move frequently. If startup reports a missing runtime, check the component name and architecture in the message, then follow the downloads page instructions. Do not guess the version from a screenshot or copy random runtime files from another computer into the installation folder.
Import a subscription and select an active node
Launch v2rayN, open “Subscription Group Settings,” add a group, and enter a note and subscription URL. The note helps identify the source; it is not used for authentication. Save the group and select “Update Subscription (without proxy)” if the current network can access the URL directly. If the provider says updates must go through an existing proxy, first restore a working connection, then change the update method.
When the update finishes, check the subscription log and node list to make sure the new entries belong to the group you just added. Select a node and set it as the active server, then check whether the core starts successfully. Do not stop at the “subscription updated” message: it usually means the content was fetched and parsed, but the node’s remote address, transport settings, and server status still need to be tested with an actual request.
Set up the system proxy, then handle app-specific settings
Select “Set system proxy” from the tray menu, then test in a browser. If the browser was already running, close its windows and relaunch it to minimize the effect of existing connections and cached settings. The system proxy does not force every app to use the same route. Some command-line tools, download managers, and apps with their own network stacks need a proxy configured separately or may require TUN.
To test another app independently, enter the loopback address and corresponding port shown in v2rayN settings, and choose the right proxy type. Entering a SOCKS port in an HTTP proxy field may result in an immediate failure after the connection is established. If the app supports “Use system proxy,” start with that option to avoid conflicting rules between system settings and a manually configured app proxy.
TUN permissions and Windows-specific issues
Enable “TUN mode” only when you need to route traffic from apps that do not use the system proxy. Grant the permissions requested by the client, then check that the virtual network adapter and routes are created. After enabling TUN, repeat a browser test that worked before, then test the target app. If the basic connection stops working, turn TUN off to restore the previous setup, then check the logs for permission errors, adapter creation failures, or address conflicts.
Security software may block the client from starting the core or creating a network adapter. If you see a warning, verify the installation source and the specific action being blocked, then follow your organization’s policy. Do not disable system protection altogether. Windows Firewall rules should also distinguish local use from inbound LAN access. If you only use the proxy on this computer, do not allow inbound traffic on every network type just to troubleshoot.
If the connection does not recover after waking from sleep or switching between Wi-Fi and Ethernet, stop and restart the proxy, then check the local listener and default route. Test startup behavior after a full reboot: the desktop app appearing automatically does not mean TUN, which may require elevation, is enabled. For unattended use, configure the startup method supported by the client; do not treat a startup prompt as proof of a working connection.
Back up your configuration and quit the running client before updating. If Windows says a file is in use, check whether an instance is still running in the tray instead of repeatedly launching the installer. After updating, confirm the active node and proxy mode before restoring custom routing rules. For core startup issues, see Troubleshooting v2rayN core startup failures and start with the first actionable error in the log.
03 / MACOS
macOS setup
Choose the installer for your processor
Open “About This Mac” and check the “Chip” or “Processor” field, then visit the macOS downloads section. Choose the arm64 option for Apple Silicon or x64 for an Intel processor. Prefer an installer built for your Mac’s architecture rather than relying on compatibility mode. Architecture mismatches can produce different errors, including startup failures and core subprocess errors.
Open the downloaded disk image and follow the prompts to move v2rayN to Applications, then launch it from there. Avoid running it long-term from a temporarily mounted image; this can make update paths, write permissions, and login items inconsistent. Quit any older instance before launching it for the first time. If you moved the app, check that the Dock and login items do not still point to the old copy.
If macOS blocks the app from opening, verify the download source and read the exact warning, then check Privacy & Security in System Settings. Proceed only after confirming the source, using the option provided by macOS. Recursively changing system permissions or disabling security features altogether is not a standard installation step. If the error specifically mentions an architecture or runtime component, resolve that dependency instead of treating every error as a security block.
Import a subscription and configure network service proxies
Enter the subscription URL in “Subscription Group Settings,” save it, and update using a method that works on your current network. Once nodes appear, select an active server and check the core logs. If the subscription updates but nodes do not work, troubleshoot the subscription download and node connection separately. They may use different domains, ports, and network paths, so success in one does not prove the other is working.
When enabling the system proxy, watch for authorization prompts. macOS proxy settings are associated with network services, and Wi-Fi and Ethernet may each retain different settings. If only some apps stop working after you switch networks, open the proxy settings for the current network service and check that the address and port still point to v2rayN’s local listener, not another copy of the app you previously installed.
After a browser test succeeds, check whether the target app reads the system proxy. For apps that need manual settings, enter the loopback address and actual port, using a supported proxy type. If the proxy settings look right but the app still cannot connect, restart it to clear existing connections. Avoid setting different ports in the system proxy, app settings, and environment variables at the same time; results could vary depending on how the app was launched.
Checking TUN and network changes
Save your current configuration and make sure the regular proxy connection works before enabling TUN. TUN creates a virtual network interface and routes, and requires different permissions from ordinary app use. Grant permissions as requested by the client. If the interface says TUN is on but the logs still show permission errors, traffic is not being routed successfully; do not judge by the toggle alone.
If even ordinary websites stop loading after you enable TUN, turn it off and restore the previously working system proxy setup. Then check route creation, DNS handling, and conflicts with other tunnel apps. Corporate networks and remote-work VPNs may use special routes; configure around them only with approval. Do not delete unfamiliar network services, as that could disrupt the existing setup.
After waking from sleep, existing connections may still point to a network interface that is no longer active. Stop the connection and restart the core; if necessary, restart the target app and check whether new requests appear. If only one browser has a problem, check its Secure DNS, proxy extensions, and independent settings. There is no need to reinstall the entire client if the system-level connection is working again.
Before updating or migrating, export subscriptions and custom rules, and note the current listening ports. After installing the new version, confirm it can read the configuration before restoring auto-start and TUN settings. Do not copy Windows file paths or startup commands to another platform. Node parameters may be reusable across platforms, but app directories, elevated permissions, and network interfaces are local settings that must be checked again.
04 / LINUX
Linux setup
Package format, architecture, and desktop session
Open the Linux downloads section. First choose deb or rpm based on your distribution’s package system, then choose x64 or arm64 for your processor. Package format and architecture are separate requirements: even if the architecture matches, your package manager may not accept the wrong package format. The desktop client also requires a graphical session; a server terminal is not a desktop environment.
Before installing, check your machine architecture and OS details in a terminal. These commands only identify your environment; they do not change network settings. In common output, x86_64 corresponds to x64 and aarch64 usually corresponds to arm64. Distribution details help identify package formats and dependencies, but do not use them to guess the client’s minimum supported OS version. Check the downloads page and any installer errors for actual requirements.
uname -m
cat /etc/os-releaseInstall the package using a desktop software installer or your distribution’s package manager. If dependencies are missing, let the local package manager handle the appropriate packages. Do not copy shared libraries from another distribution or mix files for different architectures in system folders. After installation, launch the app as a regular desktop user. Check that the window and core work before configuring additional network permissions.
Import a configuration and set up the desktop proxy
Open “Subscription Group Settings” in v2rayN, create a group, enter the URL, and update it. Select an active node and check the logs to confirm the core starts. If the interface works but the subprocess fails to start, check dependencies, execute permissions, and the working directory. A failure when starting the graphical interface calls for different troubleshooting than one during a core connection; keep the exact error message to distinguish them.
System proxy support varies across Linux desktop environments. After the client changes proxy settings, some desktop apps will use them while others will continue using their own configuration. First test with a browser or tool where you can explicitly choose a proxy, then check whether the system proxy is working. A terminal command connecting directly does not prove the node has failed; command-line programs may also need proxy environment variables.
To configure a proxy for command-line tools, check which variables and proxy protocols they support, then use the actual local listening port. Do not copy a fixed port from an online example into a global startup file. Test it with a single process first and make it persistent only after it works; otherwise, tools inheriting the variable may point to a local service that is not running.
TUN permissions and listening ports
TUN usually requires permission to access the tunnel device and change routes. First confirm that the regular proxy works, then configure permissions using a method supported by the client. Permission policies and desktop authorization tools vary between distributions; running the entire graphical session as an administrator is not the default solution. If the logs report insufficient permissions, identify the operation that failed rather than repeatedly changing remote nodes.
To check for a local port conflict, use the command below to list TCP listeners, then compare them with the address and port in v2rayN settings. How much process information you can see depends on your account permissions. This check tells you only which process is listening; it does not prove the remote server is available or that the app sent a request to this endpoint. Use request logs to trace the full connection.
ss -ltnpIf domain names fail after enabling TUN but direct requests to a known address get a response, check the DNS route and how it interacts with the system resolver. A network manager may control the resolver configuration, and manually editing its files may not survive a reconnect. Check the settings currently in effect, then make changes through the corresponding management tool to avoid maintaining conflicting DNS configurations in two places.
After switching desktop sessions or network connections, or resuming from sleep, recheck proxy variables, listening ports, and routes. Auto-start assumes a prepared session; it cannot guarantee that elevated permissions are granted automatically. Export your configuration before updating. After the update, test the regular proxy before restoring TUN and custom rules. If something goes wrong, keep both package manager and client logs to distinguish installation failures from runtime failures.
05 / ANDROID
Android setup
Choosing between v2rayNG and v2flyNG
Open the Android downloads section and check v2rayNG first; it uses the Xray core. If an existing configuration specifically uses the V2Fly ecosystem, consider v2flyNG as an alternative. These are separate apps, not different themes for the same app, and their protocol support and field compatibility are not interchangeable. If you use REALITY or Vision parameters, confirm that the selected core supports that combination first.
The downloads page offers arm64 and universal builds. Recent mainstream devices can usually start with arm64, but check your system architecture to be sure. If you cannot determine it, check the notes for the universal build. If installation fails, read the system message and distinguish an architecture mismatch from low storage or an existing app conflict. Do not assume every installation error is a download problem.
For your first installation, grant the browser or file manager permission to install apps from that source. You can revoke that permission afterward if you no longer need it. If an app with the same name is already installed, back up its configuration before updating. If Android reports an incompatible source or signature, do not uninstall the old app right away; doing so may delete local groups, custom rules, and configurations you have not exported.
Import a subscription, update the configuration, and authorize the connection
In the client’s “Subscription Group Settings,” add a subscription, enter a note and URL, save, and update it. Depending on the build, the update option may be in the main menu or group menu; look for the feature name. If you import a single share link from the clipboard, first make sure the full link was copied. A subscription URL, a node share link, and a complete JSON configuration are different types of content and require different import options.
After updating, select an active configuration and tap Connect. Android will ask you to authorize the VPN connection. This permission creates a local traffic-routing tunnel; it does not mean the remote node is reachable. Once the connection icon appears, test a destination and check the logs. If another VPN is already running, the new connection may replace it, so check how the two are intended to work together.
A standard connection uses Android’s VPN interface to route traffic. You do not need to copy the desktop system proxy or TUN setup steps. If the app offers different modes, choose one based on the documentation for your build. Do not look for desktop menu items that do not exist, and do not skip node authentication and routing checks just because Android shows a VPN icon.
Background operation, app routing, and network changes
If the connection drops when the screen turns off, check battery optimization, background activity, and auto-start restrictions. Use the system’s app management settings to allow appropriate background activity, then lock the screen and test whether the connection recovers. Consider both battery use and connection requirements; you do not need to grant every background permission at once. Persistent notifications can help keep a connection alive, but their presence does not prove the remote node is working.
App routing has two opposite options: “only proxy selected apps” and “bypass selected apps.” Check which one is active before editing the list. After changing it, stop and reconnect, then restart the app you are testing to minimize the effect of existing connections. If the browser works but another app does not, check the app routing list, the app’s own proxy settings, and its network permissions before reinstalling the client.
Existing connections may need to be rebuilt after a network switch. Disconnect and reconnect, then check whether the logs show new requests. If it still fails, make sure the current network is actually connected. If the problem occurs only with large requests or certain apps, do not change MTU settings at random. First rule out differences in nodes, DNS, and routing, then use a reproducible test to determine whether packet size is involved.
When moving from v2rayNG to v2flyNG, import the subscription again rather than overwriting the app’s private data. Keep the original app configuration until you have confirmed that the new client can parse and run the required protocol. For background on core capabilities, see Xray vs. V2Fly core differences. Choose based on supported fields, not similar names.
06 / SUBSCRIPTIONS
Subscriptions and configuration migration
Distinguish subscription URLs, share links, and configuration files
A subscription URL retrieves a set of configurations. A node share link usually describes a single connection, while a full JSON configuration may include inbounds, outbounds, routing, and DNS. Identify the content type before choosing an import option. Importing a webpage URL as a node or pasting a full configuration into a subscription field can cause parsing errors. Do not assume content is complete just because it starts with a protocol name.
Create a separate subscription group for each source, with a note that describes its purpose and who maintains it. A group is not a remote account; changing its note does not change your access. Query parameters in the URL may be used for authentication, so preserve the full address when copying it and avoid messaging apps that may truncate it or add spaces. Save the original before editing the URL, and do not remove parameters just because they look unnecessary.
Choose an update method and review the result
“Without proxy” works when the current network can reach the subscription service directly. Updating through a proxy requires an existing working connection. If you have no active node yet, the latter can create a dependency loop. If an update fails, check whether it timed out, failed authentication, or returned content the client could not parse. Each points to a different cause; one error message is not a reason to replace every node.
After an update succeeds, check for changes in the node count, group assignment, and active node. The provider may remove or rename entries, so a previously selected node may no longer work. For important tests, select an entry from the current list and reconnect. The server manages subscription content; edits to fields in a subscription-managed node may be overwritten on the next update. Copy it as a standalone configuration before experimenting.
If the returned content cannot be recognized, check whether the URL actually returned a sign-in page, error page, or expiration notice. Being able to open a webpage in a browser does not mean the client received a parseable subscription. Likewise, a successful subscription download does not prove that the remote node port is reachable. Test subscription retrieval and proxy connections separately to avoid troubleshooting the wrong part of the setup.
Check manual settings in this order
When adding a node manually, first check the protocol, server address, port, and authentication fields. Then check the transport, security settings, and additional parameters. Transport path, hostname, and server name each serve a different purpose; do not swap them just because they look like domain names. For REALITY, also verify the corresponding public key, short ID, and other parameters. These values must come from the server configuration; generating your own will not make an existing server accept the connection.
| Configuration area | What to check | Common mistake |
|---|---|---|
| Remote endpoint | Address, port, and protocol | Using a website port as the node port |
| Authentication | User ID or password | Dropping characters or adding spaces when copying |
| Transport | Transport type, path, and hostname | Putting values in the wrong transport fields |
| Security | Server name and protocol-specific parameters | Disabling verification to hide mismatched fields |
During routine troubleshooting, do not edit the runtime configuration generated automatically by the client. It may be regenerated when you switch nodes or restart the core, wiping out manual edits. Prefer changing settings in the interface. If you need a fully custom configuration, identify which settings are controlled by the file and which remain controlled by the interface, and keep a working backup so you can roll back.
What to back up and how to restore across platforms
Before migrating, keep your subscription URLs, standalone nodes, custom routing rules, DNS settings, and any local listener details you need. Subscriptions can be downloaded again, but standalone configurations and local rules may not be recoverable. Exported files may contain credentials, so restrict access. When sharing a troubleshooting sample, keep only the structure and error location; remove anything that could connect to a real service.
To restore, import subscriptions and establish a regular connection first. Then restore routing, app rules, and TUN settings. Do not copy directories, network adapter names, or startup items across platforms. Even v2rayN has different permission models on different operating systems. Restoring everything at once makes it difficult to tell whether a subscription, old path, or adapter permission caused the failure. Restore in stages to make troubleshooting easier.
Set up automatic subscription updates only after manual updates are working reliably. Choose an interval based on how often the subscription changes; frequent requests are no substitute for troubleshooting. After an update, do a quick check: confirm the active node is still available, the core starts, and your usual apps can connect. If the provider has revoked the old URL, update the subscription source instead of repeatedly importing the same dead link.
07 / ROUTING & DNS
Routing, DNS, and connection modes
Traffic capture and routing are separate settings
System proxy and TUN determine which traffic reaches the client. Routing determines which outbound handles traffic after it arrives. Enabling TUN does not mean all traffic is forwarded remotely, and a global routing mode cannot force an app that ignores the system proxy to send requests through it. When troubleshooting, first confirm the app reaches the local proxy, then check whether the rules send the request to the expected outbound.
When getting started, use a client preset such as “Bypass mainland China” and verify the traffic path before adding rules. Presets rely on domain and IP classification data; they do not classify sites by interface language. Some services may use multiple domains or shared IP addresses. If a page loads but some resources do not, check the specific failed requests instead of looking only at the main domain.
Rule order, match criteria, and outbound tags
Routing rules are generally evaluated in order. Put specific rules before broad rules that could match first. Domain rules depend on the destination domain the client sees; IP rules depend on the destination address, and both may not be available at the same time. Matching can change if an app requests an IP directly, uses its own DNS, or has different sniffing settings. Do not assume a rule will match just because its description looks relevant.
This Xray-style routing snippet is an example, not a complete working configuration. It requires an existing direct outbound named direct and classification data the core can read. It sends private addresses and the specified category through the direct outbound. Traffic that does not match still depends on outbound order or subsequent rules in the full configuration; this snippet does not set a final proxy outbound.
{
"routing": {
"domainStrategy": "AsIs",
"rules": [
{
"type": "field",
"ip": ["geoip:private"],
"outboundTag": "direct"
},
{
"type": "field",
"domain": ["geosite:cn"],
"outboundTag": "direct"
}
]
}
}Desktop clients usually provide a routing editor. Prefer the interface to avoid conflicts with auto-generated files. An outbound tag must exist in the full configuration and match exactly; it is not just a display label you can make up. Fields and rule formats also vary between cores, so do not paste a JSON snippet from one core directly into another core’s configuration.
Make DNS follow the actual request path
DNS resolves domain names to addresses, but lookup requests may come from the OS, browser, or core. If Secure DNS is enabled in a browser, it may bypass the system resolver. When a domain fails to load, first identify which component is resolving it, then check whether the query can reach the selected server. Adding more DNS addresses will not automatically fix a query that is taking the wrong route.
If the proxy server itself uses a domain name, that name must be resolved before the remote connection can be established. If the DNS query depends on a proxy that is not yet connected, you can end up with a startup dependency loop. Start with the client’s recommended defaults and get a basic connection working before changing remote and direct DNS settings. Reconnect after each change, and remember that system and app caches may retain old results temporarily.
TUN and LAN traffic
Accessing a local router, network printer, or LAN admin page usually requires an appropriate direct route. If a local service stops working after TUN is enabled, check private address routing and the subnets already used by your system instead of forcing all traffic through the remote server. Remote-work networks may use dedicated subnets; base rules on the actual network configuration, not a generic example.
“Allow connections from the LAN” opens a local proxy endpoint; it is not another name for TUN. Other devices must use the LAN address of the computer running the client and its listening port. Firewall rules and network isolation also apply. Enable this only when needed on a trusted network, and limit access. For details, see Sharing a proxy over your LAN.
Once you have stable rules, record the preset, custom entries, and DNS settings. When switching cores, restore the basic preset first and then migrate custom rules to avoid startup failures from outdated fields. To understand how the configuration fits together, see How inbounds, outbounds, and routing fit together and map the interface settings to the runtime configuration.
08 / TROUBLESHOOTING
Common configuration questions
Start with the first failing step
Keep the test conditions consistent: use the same network, active node, target app, and test URL. Check each stage in order: installation and startup, subscription retrieval, core operation, local traffic routing, and remote connection. Do not use settings for a later stage to fix an earlier one. For example, changing browser DNS will not help if the core is not listening, and reinstalling a virtual network adapter will not fix an expired subscription URL.
Open the client logs and find the first actionable error after the current connection attempt, then review any follow-on errors. A port conflict, permission failure, unknown field, and handshake failure point to different layers. Note when it happened and what you had just done, and capture enough log lines to show the context. Do not share a full configuration or subscription details, and do not rely on the interface’s “connection failed” message alone.
Troubleshoot by symptom
The subscription updated successfully, but why can’t I connect?
A successful update only confirms that the subscription was retrieved and parsed. First select an active node, then check whether the core starts, and finally review the remote connection logs. The subscription service and node may use different addresses; access to the former does not mean the latter is reachable. If every node fails, check local traffic routing and shared configuration first. If only a few fail, compare their protocol settings and server status.
The core exits as soon as it starts. What should I change first?
Do not change the remote address yet. If a port is already in use, close duplicate instances or choose another listening port, then update the app’s proxy settings to match. If the core reports an unknown field, check that the core version supports the configuration format. If classification data is missing, check that the relevant data files can be read. For permission errors, identify whether the failure involves reading a file, executing a process, or creating a network adapter, then address that specific operation instead of repeatedly clicking Connect.
The browser works, but other apps cannot use the proxy. Why?
Check whether the app uses the system proxy or has its own proxy settings. If it needs independent settings, enter the actual listening port and the correct protocol. Consider TUN only if you need to route more traffic. On Android, also check the app routing list. If only one app still fails after TUN is enabled, inspect its requests and routing rules rather than assuming the system proxy is disabled.
All apps lose internet access after enabling TUN. How do I recover?
Turn TUN off first and restore the system proxy or regular connection path that worked before. Then check permissions, the virtual interface, default route, and DNS. If another tunnel is active, stop one and test the other by itself. Do not keep changing multiple advanced settings while offline. Once the basic connection is restored, enable options one at a time and watch the logs to determine whether the problem is adapter creation, a route conflict, or DNS resolution.
What should I do about a certificate error or TLS handshake failure?
Sync the system clock first, then check the server name, certificate domain, and transport security settings. The connection address and the name used for verification may be different fields; follow the server configuration. Do not use “Allow insecure” as a routine fix: it changes verification requirements but cannot correct a wrong target or expired certificate. For the full checklist, see Troubleshooting TLS and certificate errors.
I can’t connect after quitting the client. Do I need to reinstall the OS?
First check whether the system proxy still points to a local endpoint that is no longer running. Restore the correct proxy settings, restart the target app, then check for leftover tunnels, routes, and DNS settings. If the issue started after an update, make sure the old process has exited and the new one is running. Do not delete all network settings right away. Restore ordinary internet access with reversible changes, then reapply client settings step by step to preserve your existing setup.
Treat latency tests and real requests separately
A test result applies only to the destination and method used; it cannot prove that every website or protocol works. A failed test may mean the destination did not respond, the request took a different route, or DNS failed. Prefer a real request that reliably reproduces the issue, and check it against the connection logs. For intermittent problems, repeat the same test at different times on the same network rather than drawing conclusions about every configuration from one result.
When reporting a problem, include your OS and architecture, client name, connection mode, what fails, and the individual changes you have tried. A few error lines with sensitive details removed are more useful than a full node list. Once the basic connection works, return to the quick start guide for a final check. If you need a different package, visit the downloads page. Keep the last working configuration before continuing with advanced settings.