All-Platform Guide

Choosing the right client for each platform

Use v2rayN on desktop systems. It supports Windows, macOS, and Linux, and provides a graphical interface for managing subscriptions, nodes, routing, and proxy status. On Android, v2rayNG is the usual choice; v2flyNG is also suitable when the subscription or environment is specifically built around the V2Fly core. The two Android clients differ in interface details and core focus, but the basic workflow is the same: import a subscription, update nodes, select a configuration, start the local VPN, and verify access.

Do not treat the client, core, and subscription as the same thing. The client handles the interface, configuration management, and system integration. Cores such as Xray or V2Fly establish connections and process traffic according to the configuration. A subscription link is generated by the service provider and typically contains the server address, port, user ID, transport, and TLS or REALITY parameters. Installing a client does not create usable nodes automatically, and a successful subscription import does not mean every node will connect.

Prepare subscription details, but do not keep importing repeatedly

Before you begin, prepare a valid subscription address that is currently accessible. Subscription links are sensitive configuration data and should not be pasted into public posts, screenshots, or shared documents. If the provider gives you a single VMess, VLESS, or other share link, use the client’s “Import from clipboard” function. If you receive a subscription URL, create a subscription group and update it once. These entry points handle different objects: a single link usually creates one node, while a subscription URL may produce a set of nodes maintained by the provider.

Before the first import, check for spaces at either end of the link, truncated parameters from messaging apps, and special characters rewritten by the browser. After importing, verify that the node names and count match expectations instead of clicking Update repeatedly. If an update fails, determine whether the address is unreachable, the system time is wrong, the certificate handshake failed, or the current network requires an existing proxy to reach the subscription service. Repeated updates only create more identical log entries; they do not change the root cause.

Record the existing proxy and DNS state

Before changing anything, record whether the system proxy is enabled, whether the LAN address was set manually, whether the browser has separate proxy rules, and whether system DNS uses manual values. The safest approach is to capture the system network settings or write the key values in a local note. If websites stop loading, LAN devices become unreachable, or a proxy remains after the client exits, you can restore the original state. This is especially important on company, school, or other networks that require a fixed proxy; never overwrite existing settings without keeping a record.

Also confirm that the system time and time zone are correct. TLS and REALITY connections depend on reasonable time checks, and significant clock drift can appear as certificate errors, aborted handshakes, or connections that close immediately after being established. Changing routing rules will not fix a time problem, so check the clock before changing protocol parameters.

Download sources and architecture selection

All client packages are available on the download page. On Windows, x64 is the common choice. On macOS, select Apple Silicon or Intel according to the chip shown in “About This Mac.” Most recent Android devices use arm64; choose a universal package if you cannot determine the architecture. On Linux, choose deb or rpm according to the distribution in addition to selecting x64 or arm64. A wrong architecture typically causes the installer to refuse to run, report an invalid format, or exit immediately after launch; it is unrelated to subscription availability.

Close old clients and clear any system proxy they still control before installing. Do not leave multiple clients competing for the same local port. If you truly need to compare them side by side, assign each client a different local listening port and make it clear which one controls the system proxy. Once preparation is complete, follow the relevant platform section step by step.

Choose the desktop or classic WPF edition

The download page offers the v2rayN desktop edition and the classic WPF edition. The desktop edition uses a newer cross-platform interface and suits users who want a similar workflow across desktop systems. The WPF edition is the long-established Windows interface, with stable menu locations and extensive tutorial coverage. Both support subscription management, node selection, routing, and system proxy control. Install only one for your first setup to avoid two instances modifying the same system proxy.

Get the appropriate package from the Windows download section, then exit any older version that is running. For an installed version, choose a directory writable by the current user. For a portable archive, extract it to a long-term location where it has write access; do not launch it from an archive preview window. The client needs to write configuration, logs, and core files. A non-writable directory can prevent settings from being saved or make every launch look like a first run.

First launch and subscription groups

After launching v2rayN, open subscription group management, add a group name, and paste the subscription URL. Use a descriptive name such as “Daily subscription” or “Test group”; do not use the full subscription URL as the name. Save it, update the subscription, and confirm that nodes actually appear in the main list. If the list remains empty, check the message and logs. A URL that returns a web page instead of subscription data, an expired link, or a redirect to a login page can all cause parsing to fail.

A subscription group is a management entry, not a connection status. A successful update only means that the client retrieved and parsed the configuration. Next, select a node as the active item and run a real connection test. Focus on whether a connection is established and whether the logs show a clear error, rather than looking only at download speed. Speed tests are also affected by the destination server, network congestion, and local bandwidth, so they cannot prove that the system proxy has captured browser traffic.

Importing a single link and checking its parameters

If you have a single share link, copy it and use “Import batch URLs from clipboard.” After importing, open the node editor and check that the server address, port, user ID, transport, security layer, and server name are complete. VLESS configurations using TLS or REALITY may also include flow, fingerprint, public key, short ID, and serverName. Do not delete unfamiliar parameters for the sake of “compatibility”; these values often must match the server exactly.

If you are unsure whether to use VMess or VLESS, do not judge speed by the protocol name alone. The protocol defines identity and data format, while TLS, REALITY, WebSocket, and gRPC form the security and transport combination. Whether the connection works depends on the entire parameter set. Read VMess and VLESS parameter differences for more detail, then compare each field in the client.

Test the system proxy first

For most browsers and desktop applications that follow the Windows system proxy, start with the system proxy because it is easier to troubleshoot. In v2rayN’s system proxy menu, choose “Automatically configure system proxy,” then select a routing mode as needed. This points the system proxy to the client’s local listening port, but it does not mean every application will follow it. Some games, command-line tools, virtual machines, and applications with their own networking stack may bypass the system proxy.

After enabling it, visit a regular website that normally loads reliably to confirm that basic connectivity is intact, then visit a site that verifies the proxy path. Check the client logs for the corresponding connection. If the browser is still using an old connection, fully close and reopen it or test in a new private window. See v2rayN first-connection verification for a thorough cross-check.

TUN permissions and boundaries

Consider TUN when an application ignores the system proxy or when you need to capture more traffic uniformly. TUN creates a virtual network interface and receives traffic through routing rules, so it usually requires administrator privileges and driver support. Clear the system proxy first or define the role of each method clearly to avoid an unclear path when both are enabled. If startup reports insufficient permissions, exit the client and run it as administrator. If the virtual interface cannot be created, check for conflicts with old TUN drivers, other VPN software, and security policies.

TUN is not a “faster connection” switch; it changes the capture scope. LAN access, virtual machine networking, development environments, and corporate intranets may be affected by routing. After enabling it, test the local gateway, LAN devices, and commonly used internal domains, and confirm that private addresses are covered by direct rules. If the intranet becomes unreachable, disable TUN first to see whether access returns, then check geoip:private or direct rules for private subnets instead of immediately changing nodes.

Common Windows conflicts

Port conflicts are common on Windows. If the logs report that local listening failed, check whether another v2rayN instance, an old client, or a debugging tool is using the same port. Do not simply choose a random higher port; after changing it, update the system proxy, browser extensions, and applications that depend on that port. Security software blocking the core process can also produce a normal-looking interface with no connection logs, so compare system events with client logs.

Another common mistake is treating a latency result as proof that the connection is complete. A latency test may verify only TCP establishment, while a real connection test sends an actual request using the node protocol. Even after a real connection succeeds, the browser may still connect directly if the system proxy is off. The complete sequence is: select a node, run a real connection test, enable one capture method, make a new browser request, find the matching domain or target connection in the logs, and only then test other applications.

Confirm Apple Silicon or Intel first

Open “About This Mac” and check the chip information. If it shows an Apple M-series chip, choose the arm64 package; if it shows an Intel processor, choose the x64 package. Neither architecture offers higher functionality; it simply needs to match the device. Installing an Intel build on Apple Silicon may require an additional translation environment and can cause performance or compatibility issues, so prefer the native arm64 version.

Get the matching dmg from the macOS download section, open the disk image, and drag the app to the “Applications” folder before launching it from there. Do not run it long-term from the read-only disk image, because updates, helper components, and configuration writes may be restricted. If the first launch is blocked, review the interception record in “Privacy & Security” and confirm the launch instead of disabling the entire system security mechanism.

Importing subscriptions and choosing a node

Open subscription group management, add the subscription name and address, save it, and update it. On macOS, subscription failures do not necessarily originate in the client: system DNS resolution, a web authentication requirement, an incorrect clock, or an invalid certificate on the subscription service can all cause the request to fail. Complete any network login in a browser first, then check whether the logs show resolution failure, a timeout, or unrecognized content.

Once nodes appear, select one configuration and run a real connection test. If only some nodes in the same subscription fail, compare their server names, ports, transport, and TLS or REALITY parameters instead of deleting the entire subscription. If every node fails during the handshake, first check the system time, whether the network blocks the target port, and whether the subscription has been updated with a new user ID.

Which applications work with the system proxy?

The macOS system proxy is written to the proxy settings of the current network service. Browsers and applications that follow system network settings usually use it, but terminal commands, some development tools, and programs with their own connection handling may not. After enabling it, open the system network details to confirm that the proxy state changed and that you modified the active network service. If the device has Wi-Fi, Ethernet, or multiple network locations, changing the wrong service makes the client appear enabled while traffic remains unchanged.

Command-line tools typically need their own environment variables or configuration. To temporarily use the client’s listening port in the current terminal session, set the variables according to the port shown by the client. The examples below show the syntax; use the ports configured on your machine:

export http_proxy="http://127.0.0.1:local HTTP port"
export https_proxy="http://127.0.0.1:local HTTP port"
export all_proxy="socks5://127.0.0.1:local SOCKS port"

These environment variables affect only the current shell and its child processes. Do not write them permanently to a startup file before confirming the ports. When testing is complete, run unset http_proxy https_proxy all_proxy to restore the environment. If the tool supports its own proxy settings, configure them there explicitly so the source of the setting remains clear.

TUN and network-extension authorization

Evaluate TUN when you need to capture applications that do not read the system proxy. The first activation may request administrator verification or network-extension authorization. After authorization, return to the client to confirm that the virtual interface was created and check the logs for routing results. Clicking Allow in a system dialog does not prove that TUN is running reliably; interface creation, DNS capture, and route installation can fail independently.

On macOS, other VPN tools, network filters, enterprise security software, and virtualization networks may compete over route priority. During troubleshooting, close other programs that modify the default route or DNS and keep only v2rayN and the basic network active. If the issue disappears, restore the programs one at a time. Do not change nodes, routing modes, and multiple network extensions at once, or the log timeline will become difficult to interpret.

Sleep, wake, and DNS cache

After the device wakes from sleep, the network interface and default route may be reassigned. If the client still appears active but new requests keep timing out, stop traffic capture, wait for the network to recover, and start it again. Do the same after frequent Wi-Fi changes. If domain connections fail while a test using a known IP succeeds, the problem is more likely in the DNS path. Check the client DNS settings, system resolution results, and whether routing rules send DNS requests to an unreachable exit.

Do not treat flushing the DNS cache as a routine fix. It is needed only when records are clearly stale or still return old values after changing the resolution strategy. Most proxy problems come from the capture method, route matching, or node parameters; repeatedly refreshing the cache will not repair a failed handshake. Clear the system proxy before exiting. If TUN is enabled, stop it normally first so the client can remove the interface and routes.

Choose arm64 or a universal package

Most recent Android phones use arm64. Choose an arm64 package when the device architecture is known; use a universal package if you cannot confirm it or the installer reports incompatibility. Universal packages cover more devices but usually include resources for several architectures. Architecture determines whether the app can run on the processor; it does not change node protocols or subscription content. The download list places v2rayNG before v2flyNG; visit the Android download section to choose.

If an app with the same name is already installed, confirm its signing source and whether its existing configuration must be retained. If the system refuses an upgrade, do not uninstall it before backing up the subscription. Record the subscription address, routing mode, per-app routing, and DNS settings first, then decide whether to upgrade or reinstall. Subscription addresses are sensitive information, so keep backups only in controlled locations.

Importing subscriptions and single-node links

In v2rayNG, add and update an address through subscription groups, or import a single share link from the clipboard. If you use a QR code, confirm that it comes from a trusted source, then check the server address, port, user ID, transport, and security parameters. Scanning reduces manual entry; it does not validate the configuration.

After updating the subscription, tap a node name to make it the active configuration, then start the connection. Android will ask to create a VPN connection, which is the standard authorization for local traffic capture. If another VPN connection is active, Android generally allows only one at a time, so stop the old connection first. After denying the authorization dialog, the client cannot capture traffic through background services alone; restart it and allow the request.

Per-app routing and bypass choices

Per-app routing determines which applications enter the local VPN interface. For the first connection, avoid complex exclusions and let one browser complete verification. Once basic connectivity works, configure either “Proxy selected apps only” or “Bypass selected apps.” The modes have opposite meanings, so review the list after switching to avoid placing the target app on the wrong side.

Banking, LAN control, casting, and device-discovery apps may depend on local networking and should be routed directly when appropriate. Direct routing does not mean the app is unaffected by DNS; DNS requests may still be handled by the client. If one app fails while the browser works, first remove its per-app restriction and test again, then check whether it uses QUIC, Private DNS, or a fixed address instead of changing the global node.

Background restrictions and reconnection

Android manufacturers often restrict background services through battery optimization, sleep policies, and auto-start controls. Typical symptoms include a connection stopping after the screen is locked, failure to recover after a network switch, or the system reclaiming the client process. Check the system battery statistics to see whether the client is restricted, then choose an appropriate background policy. Not every device needs all restrictions removed; observe first and change only the settings affecting connectivity so sustained traffic is not mistaken for a system limitation.

Frequent reconnects also increase battery use. If the logs repeatedly show network changes, timeouts, and immediate retries, determine whether the cause is unstable mobile coverage, an unreachable node, or the system pausing background networking. Test at the same location with the screen awake for a while, then compare after locking it. See v2rayNG background battery-drain troubleshooting for the detailed sequence.

Private DNS and client DNS

System Private DNS, a browser’s built-in secure DNS, and the client DNS may all be active at once. During initial troubleshooting, identify which component is resolving domains. If Private DNS is set to a strict hostname but that service is unreachable on the current network, resolution may fail before the proxy starts. Temporarily restore automatic mode to test, then decide whether the client should handle DNS.

Client DNS does more than “switch servers.” It also determines which exit handles domain requests, whether routing rules match the domain or the resolved IP, and whether local results conflict with the proxy exit. If only domain access fails while the node server address is an IP, focus on DNS. If the server address itself cannot establish TCP or a protocol handshake, changing the DNS server will usually not help.

Switching between Wi-Fi and mobile data

A network switch changes the local address, default route, and NAT state, so existing connections may not be reusable. Wait for the network to stabilize, then see whether the client reconnects automatically. If the interface says connected but no new logs appear, stop and restart the local VPN. Do not tap Start repeatedly while the old service still holds the interface, as this can create conflicting instances.

After troubleshooting, if the problem occurs only on one Wi-Fi network while mobile data works, check whether that network requires a web login, blocks the target port, or returns abnormal DNS results. If both networks fail, return to node parameters, subscription validity, and system time. This comparison separates device settings from current-network problems.

deb, rpm, and processor architecture

Debian, Ubuntu, and common derivatives usually use deb. Fedora, Rocky Linux, openSUSE, and similar environments commonly use rpm, but follow the distribution’s package-management system. Standard desktop computers are usually x64; arm64 is common on some development boards and ARM desktop devices. Run uname -m to check the architecture: x86_64 usually corresponds to x64 and aarch64 to arm64.

uname -m
cat /etc/os-release

Get the matching v2rayN package from the Linux download section. When installing a local deb, use the system package manager from the package directory to handle dependencies; rpm distributions should likewise use their own package manager instead of merely extracting files. The filename pattern in the commands below must match the actual download name, and the directory should not contain multiple old packages:

sudo apt install ./v2rayN*.deb
sudo dnf install ./v2rayN*.rpm

If the system reports an architecture mismatch, return to the download page and choose the correct package instead of forcing the installation. If dependencies are missing, refresh the distribution’s software sources and confirm that the desktop environment version is supported. Ignoring dependencies forcibly usually postpones the failure until launch.

First launch and configuration directories

Launch v2rayN from the desktop application menu and confirm that the interface, tray icon, and configuration saving work normally. If launching from a terminal shows errors while the desktop menu does nothing, run the application entry from the terminal to observe missing libraries, display-service errors, or permission messages. Do not run the entire graphical client as root long-term; otherwise root may own the configuration directory and prevent normal users from writing to it.

The subscription workflow is the same as on other desktop platforms: add a group, paste the subscription URL, save, update, select a node, and run a real connection test. Linux desktops often separate system-level and user-session proxy settings, so after the client reports success, check the current user’s proxy values in the desktop network settings. Lightweight desktops and standalone window managers may lack a unified system proxy interface, requiring separate settings for browsers and individual applications.

Desktop proxy and environment variables

GNOME, KDE, and other desktop environments provide system proxy settings, but whether an application follows them depends on its networking implementation. Browsers usually follow the desktop proxy, while terminal tools often read environment variables or their own configuration. For a temporary test, set proxy variables in the current shell and remove them immediately afterward:

export http_proxy="http://127.0.0.1:local HTTP port"
export https_proxy="$http_proxy"
export all_proxy="socks5://127.0.0.1:local SOCKS port"

# End of test
unset http_proxy https_proxy all_proxy

Read the port from v2rayN’s settings. If the client listens only on the local loopback address, other devices on the LAN cannot use that port directly; this is the safer default boundary. Only expose a LAN address when proxy sharing is intentional, and then review the firewall and access controls to avoid exposing an unauthorized proxy entry to other devices on the network.

TUN, capabilities, and routing conflicts

Linux TUN requires the kernel device, network-management permissions, and the ability to write routes. First confirm that /dev/net/tun exists, then use the client logs to determine whether the device is unavailable, permissions are insufficient, or route installation failed. Do not grant the entire application permanent root access. Prefer the authorization flow or system capability configuration provided by the client, and remember that executable changes after an upgrade may invalidate older permissions.

ls -l /dev/net/tun
ip route
ip rule

Containers, virtual machines, corporate VPNs, and multi-interface systems may already have policy routing. Before enabling TUN, save the output of ip route and ip rule, then compare the new entries afterward. If the intranet becomes unreachable, check whether private subnets were sent into TUN, whether default-route priority changed, and whether DNS requests entered a different namespace. After disabling TUN, confirm that its interfaces and rules were removed.

DNS and systemd-resolved

The Linux resolution chain may include the application, glibc, NetworkManager, systemd-resolved, and upstream DNS. After changing the client DNS, do not rely only on the visible contents of /etc/resolv.conf, which may link to a local resolver. Use resolvectl status to inspect DNS and domain settings for each interface, then compare them with client logs to determine whether queries actually enter the proxy.

resolvectl status
getent hosts example.com
ss -lntup

ss can confirm whether the local proxy port is listening and whether a conflict exists. If networking becomes abnormal after the client exits, first clear the desktop proxy and shell environment variables, then check the TUN interface and policy routes. Rebooting may restore the state, but it destroys valuable evidence; save logs and route output before rebooting to make the root cause easier to identify.

The capture method determines which traffic enters the client

A system proxy publishes an HTTP or SOCKS proxy endpoint to applications. Only applications that read and follow system settings will use it. Its advantages are a clear boundary and easy enable/restore workflow, making it suitable for browsers and most desktop applications. TUN receives traffic through a virtual interface and routes, covering more applications that lack proxy settings but also more easily affecting LANs, virtual environments, and existing network tools.

You do not have to enable both methods. Start with the system proxy: if it captures the target application, there is no need to add TUN just for broader coverage. Enable TUN only after confirming that an application bypasses the system proxy and needs unified capture. Android’s local VPN capture is similar to TUN in practice, but per-app routing is handled jointly by the system interface and the client.

Routing rules are matched in order

Routing decides which exit handles traffic that has entered the core. Common conditions include domain categories, IP categories, ports, network types, and processes. Rules are usually evaluated in order, with the first match taking effect, so specific rules should come before general ones. If a broad proxy rule comes first, later direct rules for the LAN may never run.

The following routing fragment illustrates the structure. It sends common private addresses and selected categories directly, while later rules and the default exit determine everything else. In actual use, the exit tags must match the outbound configuration generated by the client:

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

domainStrategy determines whether and when routing resolves a domain. With AsIs, the original domain is matched first; other strategies may resolve it to an IP when needed. No single strategy fits every environment. If routing depends on domain categories, ensure that the request still contains domain information when it reaches the core. If an application connects directly to an IP, domain rules cannot match.

GeoIP and GeoSite data

GeoIP contains IP classification data, while GeoSite contains domain classification data. Routing rules reference category tags; they are not “automatic smart routing.” Missing databases, nonexistent tags, or incompatible core versions can prevent startup or produce rule-loading errors in the logs. After updating the data, check the logs to confirm that the new files were read and keep the old files for rollback. See GeoIP and GeoSite database update guide for the full maintenance process.

Do not replace the database, rule set, and core in one change. If an issue appears after an update, restore the old data while keeping the rules unchanged. Once normal operation returns, verify separately that the new data contains the required tags. A misspelled rule tag will not be fixed by changing nodes.

DNS must follow the routing path

DNS determines which address a domain returns, while routing determines how a request reaches that address. If local DNS returns an unreachable or exit-incompatible result, the connection can fail before the protocol handshake. If DNS requests themselves must use the proxy, the startup path must already have working resolution; otherwise you can create a loop where resolving the proxy server requires the proxy.

When troubleshooting DNS, use the logs to confirm that the request reaches the client, then compare system-tool results with the client’s results. Focus on the resolution chain only when domains fail but direct addresses work. If TCP is established and failure occurs during TLS or REALITY, check serverName, public key, short ID, fingerprint, and system time. Treating a handshake error as a DNS issue sends troubleshooting in the wrong direction.

Four-step verification

First, confirm the subscription update. The node list should contain the expected entries, and the active node should have complete key parameters. Second, run a real connection test and check whether the client establishes an actual request using the protocol. Third, enable one capture method and have the target application make a completely new request. Fourth, find the matching domain, destination address, route exit, or error in the logs. Only when all four steps succeed can you say that the node connects and application traffic is entering the client.

If the real connection test succeeds but the browser does not change, check the system proxy, the browser’s separate proxy, old connection caching, and the active network service. If the browser request appears in the logs but fails, identify whether the failure occurs during DNS, TCP, TLS, REALITY, or remote closure. If the target request is absent from the logs, the capture layer is not working yet; do not change protocol parameters first.

Read logs by failure stage

“Resolution failed” usually means the domain did not produce a usable address. “Connection timed out” means the network connection was not completed within the limit, but the cause may be an unreachable destination, a blocked port, or incorrect routing. “Connection refused” means the destination responded explicitly but did not accept the port. TLS or REALITY handshake errors should prompt checks of the server name, time, public key, short ID, and fingerprint.

Read logs as a timeline rather than looking only at the final line. The last line may merely summarize an earlier error. Before reproducing the issue, clear the log or note the current time, perform the target action once, and save the continuous section from request start through failure. When asking for help publicly, redact subscription URLs, user IDs, server addresses, and other sensitive parameters, but retain the error type, sequence, and client actions.

Narrow the scope with controlled comparisons

A useful comparison changes only one variable. Test the same node on two networks to determine whether the current network is involved. On the same network, try another node from the same subscription to compare node-specific behavior. Keep the node unchanged and test the system proxy and TUN separately to compare capture methods. Keep everything else unchanged and restore the default DNS to determine whether custom resolution introduced the problem.

An unhelpful comparison changes too much at once: updating the subscription, switching nodes, enabling TUN, replacing DNS, and updating the rule database. Even if the issue disappears, you will not know which change helped, and the next failure will require starting over. Keep a text record of the stable configuration, including the client, capture method, routing mode, and necessary custom settings.

Subscription updates and configuration backup

A subscription update may add, remove, or modify nodes. If important settings were adjusted manually, confirm whether the client will overwrite them during the update. Keep subscription nodes and locally created nodes in separate groups to avoid deleting local content by mistake. After updating, compare node counts and name changes, then verify one node instead of testing every node repeatedly.

Backups should include subscription group information, necessary routing settings, and custom DNS, but sensitive data should not be stored in a public sync service. After restoring a backup, recheck system permissions, TUN authorization, and local ports because those states may not be fully included in the client configuration. When moving between platforms, do not assume every setting maps exactly; re-import the subscription first, then restore only the essential policies manually.

Update the client, core, and rule data separately

The client interface, proxy core, and GeoIP and GeoSite data are separate layers. Updating the client may change the interface or configuration format. Updating the core may affect protocol support. Updating rule data affects category tags. In a stable environment, update them separately and perform a basic connection, capture, and routing check after each update. This makes it possible to roll back the affected layer accurately.

Do not decide that your installation must be upgraded based on a specific version number found online. This site does not fix version information; use the packages currently shown on the download page. Exit the running client before updating and keep the working configuration. If old settings cannot be loaded afterward, check migration notices and logs instead of immediately overwriting the original configuration directory.

Why can’t I access anything after a successful subscription update?

A successful subscription update only means that the client retrieved and parsed the configuration. You still need to select a node, confirm that it passes a real connection test, enable one capture method, and verify that application requests appear in the logs. First check that the intended node is actually active, then run a real connection test. If it fails, use the log stage to check the network, time, and connection parameters. If it succeeds but the application produces no request logs, check the system proxy, TUN, or Android per-app routing.

A subscription may also contain nodes that are temporarily unavailable or operate under different conditions. Do not test only the first item, and do not attribute every failed node to the client. Compare a small number of nodes with different parameter types from the same subscription to determine whether the problem affects one node or the subscription as a whole.

Should the system proxy and TUN be enabled together?

Usually not. Choose one method based on the target application. Start with the system proxy for browsers and most desktop applications that follow it. Evaluate TUN for applications that ignore the system proxy or require broader capture. Both can work together, but they make path analysis more difficult, especially with DNS, LANs, and virtual network adapters.

When troubleshooting a setup with both enabled, disable TUN first and test the browser with only the system proxy. After confirming the system proxy, clear it and test TUN alone. This shows whether each entry point works independently. Do not switch back and forth without closing old connections, because the application may reuse an existing session.

Why does networking break after I exit the client?

The most common cause is a system proxy still pointing to a local port that the client has stopped listening on. Reopen the client, choose “Clear system proxy,” and exit normally. On Windows and macOS, also check the proxy value in the system network settings. On Linux, check shell environment variables in addition to the desktop proxy. On Android, check whether the system VPN still shows the old connection.

If TUN was enabled, also confirm that its virtual interface and routes were removed. A normal TUN shutdown usually restores them, but force-quitting, a system crash, or permission problems can leave state behind. On Linux, check ip route and ip rule; on desktop systems, first disable leftover virtual interfaces or restart the network service. Once networking is restored, analyze the logs instead of deleting all client configuration.

Only one application cannot connect. Should I change nodes?

Not yet. If the browser works but one application does not, the node and basic capture are probably working. Check whether the application follows the system proxy, is excluded by Android per-app routing, uses its own proxy, has fixed DNS, uses QUIC, or requires special network permissions. If a desktop application ignores the system proxy, specify the local HTTP or SOCKS port in its settings or test it separately with TUN.

If the logs show that the application request is being sent directly or blocked for a particular domain, check the routing rules. If there is no request in the logs at all, the issue is still in the capture layer. Change nodes only after confirming that the request enters the client and fails during the remote connection stage.

Which fields should I check when a REALITY connection fails?

First confirm the server address, port, user ID, and flow, then check serverName, public key, short ID, and fingerprint. Field names may vary slightly between client interfaces, but the values must match the server-provided configuration. Significant clock drift, parameters truncated by a messaging app, or omitted characters during copying can all cause a handshake failure.

Do not guess missing values or disable the security layer just because the configuration uses VLESS. REALITY is a combination of connection-security parameters, not a node name by itself. If the configuration came from a subscription, update it and compare the provider’s instructions. If it came from a single link, re-importing the original link is usually more reliable than repairing it manually.

What should I do if the client cannot start after updating GeoIP or GeoSite?

Check the logs for database read failures, missing category tags, or incompatible file formats. Restore the data files from before the update, keep the routing rules unchanged, and restart. If the client works again, the issue is in the new data or its compatibility. If it still fails, check for spelling errors or invalid JSON structure introduced while editing the rules.

Do not change the core at the same time to hide a data problem. Verify the core, rules, and database separately. After restoring a stable setup, confirm that the current core supports the referenced tags. The complete update and rollback procedure is covered in the rule database maintenance article.

Which DNS address should I use?

There is no fixed answer for every network. First determine whether DNS requests go directly or through the proxy exit, then choose a resolver that is reliably reachable along that path. Without a specific requirement, keep the client’s default strategy while verifying the connection. Change it separately only when you have a domain-resolution problem, a routing requirement, or a defined privacy boundary.

After changing it, cross-check the result with a system resolver tool, a browser request, and client logs. If a direct address also fails, DNS is usually not the cause. If the domain resolves but the connection fails during TLS or REALITY, check the connection parameters. Do not cycle through multiple DNS addresses without recording the returned results.

How do I restore the minimum working configuration?

Stop TUN first, clear the system proxy and per-app routing, and restore the default DNS and basic routes. Keep one subscription group from a known source, update it, and run a real connection test with one node. After it succeeds, enable only the system proxy, make a new browser request, and check the logs. If the target desktop application ignores the system proxy, disable it separately and test TUN.

On Android, first remove complex per-app routing, keep the system VPN authorization, and test with a browser. On Linux, also clear proxy environment variables from the shell. Once the minimum setup is stable, restore routing, DNS, per-app routing, and background policies in that order, testing after each change. This is faster than repeatedly reinstalling the client and preserves evidence about when the issue occurred.