v2rayN Cross-Platform
Setup Guide

SETUP / Client & Network Basics

Getting started: know where your config comes from and how traffic is routed

Understand the client, core and connection settings

v2rayN is a desktop GUI client that stores server profiles, manages subscriptions, generates runtime configuration and controls features such as the system proxy. The core it launches handles the actual connections. Project V provides background on related proxy technology; V2Fly and Xray are common core families. On Android, options include v2rayNG with the Xray core and v2flyNG with the V2Fly core. Similar client names do not guarantee identical parameter support. When you receive connection details, first identify the protocol, transport and security settings, then confirm that your client and core support them.

Installing a client does not provide a working server. Before you begin, get a subscription URL, a single share link or complete server settings from a trusted source. Subscription URLs often contain account identifiers; anyone who can access one may be able to use the same connection details. Do not post them in screenshots, forums or shared notes. Check that your system date and time zone are correct and that your network can reach the services you need. A significantly incorrect clock can break certificate validation or time-dependent authentication, making a working server appear unavailable.

Check your architecture before choosing a download

Use v2rayN on desktop platforms and choose the download by operating system and processor architecture on the downloads page. On a Mac, check About This Mac for the chip. On Windows, check System type in System Information. On Linux, confirm both the processor architecture and your distribution's package format. Android devices usually use arm64; consider a universal package only if you are unsure of the device architecture or the installer reports incompatibility. Do not guess from a familiar word in the filename or use a package made for another operating system. If you already have a working client, note its current mode and important settings before upgrading so you can separate upgrade-related changes from network changes.

Start from a state you can restore

For your first setup, start with the system proxy. Do not enable TUN, a third-party network accelerator, another proxy client and custom DNS all at once. The system proxy directs apps that honor its settings to a local listening port; it does not route every network connection through the proxy. TUN uses a virtual interface to capture traffic that matches its rules, involving routing and permissions and making troubleshooting broader. If you only need a browser connection, start with the system proxy. Consider per-app proxy settings or TUN only if an app does not use the system proxy. Matching the mode to your needs helps distinguish normal limitations from faults.

Note the actual listening address, port and active server shown by the client; example ports are not necessarily the ones on your device. For local use, keep the loopback address so the service is not exposed to your entire LAN. Before testing, choose a regular HTTPS site and a separate service for comparison. An account restriction, regional policy or outage on one site does not prove that the client is broken. Change one setting at a time, then check the logs and access results before keeping or reverting the change.

Before installing, check that the destination is writable, no old process is using the listening port, and your work or school device is not under centrally managed network policies. Managed devices may restrict changes to proxies, certificates and virtual network permissions. Follow the device administrator's requirements instead of repeatedly trying to bypass them. If the device already has a working configuration, export the necessary details and store them securely. Exports may contain credentials and should not be shared as if they were ordinary, non-sensitive settings files.

PLATFORM / macOS

macOS: Install v2rayN and configure the system proxy

Choose the right build for your chip and keep the app in one place

Open About This Mac from the Apple menu. Choose the Apple Silicon download if it shows an Apple chip, or the Intel download if it shows an Intel processor. Get the matching package from the macOS downloads. Open the disk image, drag v2rayN to Applications and launch it from there. Do not run it long-term from the disk image or keep it in a temporary folder that may be cleared. Keeping the app in a fixed location helps preserve permissions and simplifies updates. After the first launch, you can eject the installer disk image; the copied app will remain in Applications.

If macOS says the app cannot be opened, first check the download source, chip selection and installation. Then see whether System Settings → Privacy & Security offers an option to allow this launch. Only use the system's one-time approval after confirming the source; do not disable system-wide protections just to open one app. Permissions may be restricted on managed devices. Repeatedly double-clicking will not change the outcome. Keep the full alert text and distinguish a security block from an app-damage warning or processor incompatibility, since each requires a different fix.

Import a subscription and test a server

Open the subscription group settings, create a group and enter the complete subscription URL. Save it, then update the subscription; seeing the group name does not mean the server list was downloaded successfully. When the update finishes, check the server list and select an entry. For a single share link with a protocol prefix, use the clipboard import option instead of the remote subscription field. Menu layouts can vary between builds; the goal is always to save the subscription source, update it and select a server. Do not rely on a screenshot to find a particular button.

Next, select “Set system proxy automatically” and confirm that the client core is running. This writes to the system's network proxy settings, directing apps that honor them to the local proxy. If behavior changes after switching Wi-Fi, connecting Ethernet or adding a network service, check the proxy settings for the active network service and confirm they point to the address and port the client is listening on. Do not enable every proxy protocol indiscriminately. Follow the client's automatic settings and the requirements of the apps you use to determine whether HTTP, HTTPS or SOCKS needs to be configured.

TUN, waking from sleep and network behavior on exit

Consider TUN only after the system proxy works. Before turning it on, read the permission prompts for your build, grant any required helper or network permissions, and check that no other virtual networking tool is also managing the default route. If ordinary network access fails after TUN starts, turn it off first and check whether system proxy mode still works. An enabled toggle does not prove that the virtual interface, routes and DNS are all set up successfully. Check the logs for permission errors, interface creation failures or failed route updates.

After a Mac wakes from sleep, switches hotspots or reconnects through a dock, existing connections may no longer work. Check that the network itself is available, then reconnect the client. If only one app is affected, fully quit and reopen it so it does not keep using a broken connection pool. Browsers may work while terminal commands fail; many command-line tools do not use the system proxy and need proxy options of their own. The reverse is also true: a working terminal connection does not rule out a separate browser proxy or interfering extension. Check each connection path separately.

Before quitting normally, clear the system proxy and turn off TUN. If webpages stop loading after the app exits unexpectedly, open the proxy settings for the active network service and check whether they still point to a local port that is no longer running. Remove only settings you have confirmed were added by this client; do not delete an unfamiliar organization-managed proxy. Sharing a connection with devices on the same network also requires more than sending them the local loopback address: you need to consider the listening interface and firewall. See how to allow LAN connections.

PLATFORM / Windows

Windows: Desktop, WPF and system proxy options

Choose an interface edition and keep its data separate

The Windows downloads offer v2rayN Desktop and the classic WPF edition. Desktop uses the newer cross-platform interface, while WPF retains the classic Windows UI. Both are GUI clients; interface differences do not mean they inherently use different server protocols. Choose a package based on your device architecture and the package notes. If a runtime component is missing, follow the specific startup message. Do not assume your system is missing a dependency just because someone else's screenshot shows it, and do not install a collection of runtime components from unknown sources just to test the app.

Install or extract the app to a writable location; do not run it from a read-only directory or an archive preview. If you need to compare both editions, keep their program and data locations separate. Export important settings first, and do not let both processes modify the same data. Check that an older instance is not still running in the taskbar or system tray. Multiple instances can compete for a port or make it seem that your changes have not taken effect when a different instance is managing the system proxy. Use the tray state and running processes to determine whether closing the window actually exits the app.

Subscription updates and system proxy settings are separate steps

Add a subscription group, update it, then select the active server from the server list. First check the update log to see whether the content was retrieved successfully; only then test the server connection. When copying a link from another device, watch for line breaks, spaces and trailing query parameters. Messaging apps sometimes show display text that differs from the actual link. If an imported entry has a name but fails to connect, check that its protocol, security and transport fields are complete rather than assuming the settings match based on the server name. Save the original details before making manual changes so you can restore them.

After you select “Set system proxy automatically,” apps that honor Windows user proxy settings will try to use the local proxy. Browser access does not mean that system services, background updaters or all command-line tools use the same route. Some programs have separate proxy settings or use a different network interface. Start testing with the default user permissions; request elevated permissions only for TUN or an operation that clearly requires them. Running as administrator all the time will not fix an invalid subscription or mismatched server settings, and can make it harder to tell a permissions problem from a configuration error.

Firewall, TUN and port conflicts

If the log reports that a port could not be bound, stop other proxy programs and check for an old v2rayN process before changing the local port. If you change it, update every app where you entered the proxy manually, then reapply the system proxy. Decide whether to allow a firewall prompt based on the program's source, network type and intended use. A single-device setup usually does not need inbound LAN access. Do not turn off the entire firewall to diagnose the issue. Identify the specific blocked program or connection and add a narrowly scoped rule instead.

TUN uses a virtual network interface, routes and permissions, so test system proxy mode before enabling it. Other virtual networking tools on the device can conflict over the default route, DNS or subnets. If TUN cuts off all network access, turn it off, restore normal connectivity and check the interface and routing logs. If disabling another tool resolves the problem, compare the traffic each tool captures rather than repeatedly reinstalling the client. Be especially careful over a remote desktop connection, since route changes can disconnect your management session.

To restore connectivity, clear the system proxy in the client before exiting. If the client has crashed, check Windows proxy settings for a leftover manual proxy. Automatic configuration scripts and manual proxy settings are separate; do not clear an organization-managed script as well. After sleep or a network change, try restarting the connection before reinstalling the app. Before upgrading, save your subscription sources and custom routing rules. After the upgrade, retest the original system proxy setup before enabling additional features. This makes it easier to identify whether a problem came from the upgrade or a new setting.

PLATFORM / Linux

Linux: Packages, desktop proxy and permissions

Check both processor architecture and distribution package format

Before installing on Linux, check two things: whether the processor is x86_64 or aarch64, and whether the distribution uses deb or rpm packages. The first determines whether the program can run; the second determines whether the system package manager can install it. One does not replace the other. Choose v2rayN by architecture and package format from the Linux downloads. If the graphical installer cannot handle the package, read the specific error and distinguish an architecture mismatch from missing dependencies or an unsupported system environment. Do not assume every installation failure means the file is corrupt.

Use these read-only terminal commands to check your environment. uname -m usually reports x86_64 for x64 and aarch64 for arm64. Your distribution name and version can help identify its package system, but a package in the right format is not necessarily compatible. Install dependencies from your distribution's own repositories and package manager; avoid combining low-level libraries from multiple unknown sources. If the app exits immediately after launch, check the desktop launch record or terminal output. First determine whether the issue is with the graphical environment or the core failing to start.

uname -m
cat /etc/os-release

After importing a subscription, check your desktop environment's proxy settings

Start v2rayN, create a subscription group, save the URL, update the server list and select an active server. Linux clipboard access is managed by the desktop session; remote sessions, display protocols and permission changes can all prevent it from working. If clipboard import does nothing, first confirm the link is in the current user's clipboard, then use the client's manual entry option if needed. Do not mistake a clipboard access problem for an unsupported protocol, or run the entire client with elevated privileges as a workaround; doing so can separate its data from your desktop session.

Desktop environments implement system proxy settings differently. After the client applies its settings, check the proxy page in your current desktop environment rather than assuming all distributions behave alike. Browsers may use the desktop proxy; terminal programs often rely on their own options or proxy environment variables. Already-running processes may not reload changed environment settings. To separate a working core connection from a desktop proxy that is not being used, temporarily specify a proxy for an individual command. The troubleshooting section explains the diagnostic command below.

Loopback listening and TUN permissions

For local use, bind to a loopback address whenever possible. Binding to every network interface does more than make local connections easier: it may expose the port to other devices on the same network, so consider firewall rules and access controls. The remote address selected in the server list and the local inbound listening address are different settings; do not swap them. If a port is in use, check for an old client or another proxy process. After changing the port, reapply the desktop proxy and update any terminal commands or apps with a hard-coded address. Otherwise the new core may listen correctly while your apps still connect to the old port.

TUN usually needs permission to create a virtual interface and change routes; the exact authorization method depends on your distribution and client build. Follow the client's specific instructions and do not grant broad permissions to the entire program directory. Manage subscriptions and settings as a normal user first, then grant only the network capability that is clearly required. Running as a different user may use a different data directory, making the server list appear to disappear. Check the running user and data location before changing anything. Do not overwrite the original directory or assume a blank screen means your data has been deleted.

If network access fails, check for container networking, other tunnels or custom routes that overlap with TUN. If turning off TUN restores access, investigate routes and DNS before changing remote server settings. Restore the desktop proxy before exiting; after an unexpected shutdown, check whether a startup script has left proxy environment variables in place. Keep a copy of a working configuration. After updates, test four things: app startup, subscription updates, system proxy and TUN. This helps distinguish changes to the desktop environment from client issues.

PLATFORM / Android

Android: v2rayNG, v2flyNG and VPN permissions

Choose a core, then the right package architecture

The Android downloads recommend v2rayNG, which uses the Xray core. v2flyNG uses the V2Fly core and is an alternative when you need the corresponding compatibility. Choose based on your server protocol and transport settings, not similar-looking names. Most recent mainstream devices use arm64; a universal package supports more architectures but is usually larger. If the installer reports a parsing error or incompatibility, check the Android version requirements, whether the package finished downloading and the device architecture. Do not attribute every error to a lack of phone performance.

When you open an installer from a browser or file manager, Android may ask you to allow app installs from that source. Grant permission only to the source you are actually using, and revoke it afterward if that fits your security preferences. When updating an existing client, Android may refuse to install over it because of a signature, installation source or package identity mismatch. Save subscriptions and custom settings first, then decide whether you need to migrate them. Uninstalling immediately can delete app data and should not be your first step. An “update failed” message does not necessarily mean your saved server settings have stopped working.

Import a configuration, update and start the service

In v2rayNG, add the URL under subscription group settings, save it, update the subscription and then select an entry from the server list. For a single share link, use the clipboard or QR-code import option. A QR code is simply a way to carry configuration data; it does not inherently contain more parameters than a text link. Confirm that you selected the newly imported server rather than an older entry. Menu labels may differ in v2flyNG, but remote subscription updates and single-profile imports are still separate actions. A regular webpage URL is not a subscription URL.

When you start a connection, Android asks for permission to establish a VPN connection. This lets the client capture traffic through Android's virtual network interface; it does not mean the server connection has succeeded or that every app will use the remote proxy. A VPN indicator in the status bar only confirms that the capture mechanism is active. Check the client logs and test actual access as well. Do not apply the desktop “set system proxy” model here: Android clients generally use the system VPN service as their traffic entry point, and routing rules can still send some requests directly.

Per-app routing and background operation

Per-app proxy settings may offer opposite modes, such as “proxy selected apps only” and “bypass selected apps”; follow the wording in the interface. After changing the selection, stop and restart the service, then test the target app so it does not keep an existing connection on the old route. For troubleshooting, first turn off per-app filtering to keep the capture scope clear. Once the basic connection works, add exceptions one at a time. If a webpage loads but an app does not, the app may use its own DNS, long-lived connections, account status or service policies. One failure is not a reason to change the client's protocol settings for everything.

If the connection works with the screen on but drops after the device locks, check battery optimization, background activity and the manufacturer's auto-start settings. Relax restrictions only for a client that needs it; there is no need to disable all battery-saving features. System restrictions on the client's persistent notification can also affect background operation. When switching from Wi-Fi to mobile data, wait for the network transition to finish, then restart the connection and test again. If only one network type fails, compare network permissions and server reachability instead of immediately deleting the subscription. Signal strength, data limits and hotspot conditions can also affect mobile connections.

At first, avoid enabling system options such as Always-on VPN or blocking connections without a VPN. Confirm that the client reconnects after a reboot, screen lock and network change; otherwise, a forced block can also cut off regular network access. If the device loses all connectivity, stop the VPN connection and restore normal network access before checking the client logs. Switching to v2flyNG is not a universal fix; consider it only when you have identified a protocol or core compatibility difference. After migrating, recheck routing, DNS and per-app rules. Copying server entries alone does not transfer the full setup.

CONFIGURATION / Subscriptions & Server Profiles

Subscription management: formats, updates and multi-device sync

Tell apart remote subscriptions, share links and full configurations

A remote subscription URL lets the client retrieve configuration data, usually over HTTPS. A single share link starts with a protocol prefix such as vmess:// or vless:// and represents one connection profile. A full JSON configuration may also include inbounds, outbounds, DNS and routing; these three formats are not interchangeable. A long encoded string is not enough to tell whether something is a subscription or a single link. Check the provider's instructions and the client's supported import methods. Repeatedly re-encoding the original data can corrupt it.

Some subscriptions use Base64 to package multiple share links; others return structured content that the client can read directly. Base64 is an encoding format, not encryption that protects access. Whether a client can process a subscription depends on its returned format and core compatibility, not merely on whether the URL opens in a browser. For a closer look at the import options, see subscription imports, Base64 and URI formats. If the service returns a login page, error page or verification screen, the client usually cannot parse it as a server list.

Separate update failures into request and parsing issues

Saving a subscription group only adds the URL to local settings. After you update it, check first whether the client received a response, then whether it could parse that response. Connection timeouts and certificate errors occur at the request stage; unsupported-format or empty-content messages call for checking the response and subscription type. Do not delete existing working entries as a first step. Keep the group and logs, confirm that the URL has not expired or lost query parameters, and check the system clock. Before sharing logs publicly, redact the full subscription URL and account identifiers.

Whether subscription updates use a proxy depends on the client's update options and implementation. Try an update-through-proxy option only after confirming that the subscription endpoint cannot be reached directly on your current network and that an existing proxy works. If no server is available yet, this option can create a dependency loop: you need an update to get a server but need a server to update. Restore a direct route to the subscription endpoint or ask the configuration provider how to access it from your network. Do not keep switching to unknown servers and retrying.

Subscription groups and the lifecycle of manual edits

Grouping subscriptions by source or purpose makes it easier to see which URL manages each server. Updates may rebuild entries, refresh names or overwrite fields, so do not assume a manual edit will persist. To test parameters, first copy the profile as a separate configuration, label it as independent of the original subscription and note why you changed it. After an update, check the selected server again: entries with the same name may have different addresses or transport settings. Whether an existing connection is rebuilt depends on the client's behavior.

Reusing a subscription across devices mainly syncs server profiles. It does not guarantee that routing, DNS, per-app filters, system proxy settings or TUN permissions will transfer too. A process rule on a Mac is not a direct equivalent of an Android app rule. QR codes work well for sharing a few individual profiles; a full export is more suitable for moving local settings, but check whether the destination client supports the same format. See multi-device sync options. Decide whether you need to sync server sources or the client's full behavior before choosing a method.

Set the update frequency to match your needs; refreshing more often is not a substitute for troubleshooting. If multiple devices show an empty list, first check the subscription's status and response format, then check client compatibility on each device. If only one device fails, compare its local network, proxy update option and system clock. A name that remains in an old client does not mean the server still works after the provider removes or replaces it. Before cleanup, check which group an entry belongs to so you do not delete manual profiles too. Keep enough information to restore the setup rather than relying on a server display name that may be reused.

CONFIGURATION / Inbounds, Outbounds & Resolution

Routing and DNS: follow the request path

Start with inbounds and outbounds, not assumptions based on a button

A request typically enters through a local inbound, then routing rules decide which outbound handles it. inbounds describes how traffic is accepted locally, outbounds describes where connections go, and routing chooses between them. The system proxy and TUN control how traffic enters the client; routing controls what happens after it does. “Global” mode generally sends captured requests to a proxy outbound; it does not force every app to use the client. Rule mode matches conditions to send traffic through a proxy, directly or to a block. Ultimately, interface labels must correspond to the actual configuration.

This minimal V2Ray configuration illustrates the relationship between local inbounds and tags. It contains only direct and block outbounds, does not provide a remote proxy connection and is not meant to replace the runtime file generated by a client. The two ports are examples only; the configuration cannot start if they are already in use. Loopback listening restricts access to the local machine. direct and block are custom tags; their actual behavior comes from the freedom and blackhole protocols, respectively. Understanding this helps avoid mistaking tag names for built-in core features.

{
  "inbounds": [
    {
      "tag": "socks-in",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": { "udp": true }
    },
    {
      "tag": "http-in",
      "listen": "127.0.0.1",
      "port": 10809,
      "protocol": "http",
      "settings": {}
    }
  ],
  "outbounds": [
    { "tag": "direct", "protocol": "freedom", "settings": {} },
    { "tag": "block", "protocol": "blackhole", "settings": {} }
  ],
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["domain:example.com"],
        "outboundTag": "direct"
      }
    ]
  }
}

Rules are evaluated in order, and resource files affect the result

Common routing configurations evaluate rules in order; the first match determines what happens. Put specific exceptions before broader conditions. outboundTag must match an existing outbound tag exactly; a typo will not be corrected automatically. Check the core configuration and how the client generates it to understand the default outbound when no rule matches. When reading a breakdown of config.json, review the full outbound list alongside the rules. A single line on its own does not reveal the final route.

geosite represents domain collections, while geoip represents IP address collections. Neither is a magic keyword that automatically applies to every destination. Before using these rules, confirm that the current core supports the syntax and that the required resource files exist and can be loaded. Domain collections and IP geolocation are not substitutes for a service-specific policy; multi-address services, content delivery and changes to rule data can all affect matching. When setting up split routing, define the target scope first, consult the geosite and geoip routing guide, then use logs to verify the result.

Separate system DNS, core DNS and remote resolution

DNS resolution can happen in an app, the operating system, the client core or at the other end of a remote connection. Changing system DNS does not necessarily change how every proxied request is resolved. Apps with their own encrypted DNS may bypass system settings. domainStrategy controls when domain resolution is used for routing decisions; it is not a master switch for “resolve everything remotely.” A common value, IPIfNonMatch, tries to resolve a domain for IP matching when no domain rule matches. Check the configuration semantics of the core you use to understand how it interacts with other settings.

When troubleshooting DNS, first check whether the domain resolves, then whether a connection is established to the resulting address. If a certificate name does not match, do not hide the problem by disabling certificate validation. Check the target domain, the security layer's server name and whether the network is returning a captive portal. With TUN, also check whether DNS requests are captured, whether the resolver itself is reachable and whether the setup creates a recursive dependency. Change one resolution path at a time and compare the logs before and after. Changing DNS, routing rules and servers together makes it impossible to tell what fixed the connection.

TROUBLESHOOTING / Find the failing layer

Common configuration issues: test each layer and restore connectivity

Check your network and local listener first

When a destination is unreachable, turn off TUN, clear the system proxy and stop other traffic-capture tools first, then verify that regular network access works. Hotel and public Wi-Fi may require a captive portal sign-in. Changing servers will not help if the underlying network is offline. Once regular access is restored, start the client and check that its core is running. If “connection refused” points to a local loopback address, first check that a listener exists and the port is correct, not the remote server password. The same error can point to different causes depending on the destination address.

If the client reports that it is running but no apps can connect, check the local listening port, then use an explicit proxy request to isolate system settings. The command below works in desktop environments with curl; it assumes a local SOCKS port of 10808, so replace that with the port shown by your client. socks5h sends the domain name to the proxy for resolution. The example site is a regular HTTPS test destination. A successful test proves only that this particular path works, not that every app or protocol is being captured.

curl --proxy socks5h://127.0.0.1:10808 \
  --connect-timeout 10 \
  --max-time 20 \
  --head https://example.com/

If the explicit proxy works but the browser does not, check whether the system proxy is applied to the active network, whether the browser has its own proxy and whether an extension overrides the settings. If the explicit proxy also fails, check the core logs for a local inbound, remote connection or handshake error. Do not apply a successful terminal test directly to Android; use the mobile client logs and app access tests instead. Keep the same server and destination during testing, control one variable at a time and change the comparison only after that. This helps avoid false conclusions from network fluctuations.

Choose the next step based on the error

For a connection timeout, check the destination address, port, network reachability and server status first. For authentication failures, verify credentials and protocol fields. For a TLS handshake failure, check the system clock, the security layer's server name, transport settings and server requirements. An empty field is not necessarily an error, and you should not fill it with a value copied from a different configuration. Transport parameters work together; changing just one can make failures harder to diagnose. Logs help narrow the problem, but one line rarely identifies a single cause. Use them alongside a change history and comparison tests.

A successful subscription update means the path used to retrieve configuration is at least partly working; it does not validate the proxy connection settings. If only some servers fail, compare their protocol and transport settings first. If all fail at once, check shared factors such as system time, core startup and network conditions. If only one site is affected, consider DNS, routing matches, the service itself and account restrictions separately. Do not change the routing mode for all traffic to fix one service, and do not treat a client connectivity check as a complete substitute for testing the service you need.

Troubleshoot TUN separately from restoring network access

If system proxy works but TUN does not, remote connection details are usually not the first thing to investigate. Check permissions, the virtual interface, routes, DNS and overlapping tunnels. If turning off TUN immediately restores access, keep that comparison in mind. When managing a remote device, avoid changing the default route without a local recovery plan. If a network switch causes problems, stop and restart the traffic-capture service before clearing all settings. Reinstallation may preserve or alter some data, so it is not a reliable way to determine whether the configuration is correct.

If the network drops after a normal exit, check for leftover system proxy settings. If problems occur after TUN stops, check whether another networking tool is still running and restore ordinary system connectivity first. Before reporting the issue, record the operating system and architecture, client name, traffic-capture mode, when the failure occurred, whether it is reproducible and the most recent change. Include only relevant log excerpts and redact subscription URLs, user identifiers and server credentials. A comparison such as “explicit proxy works, system proxy fails” is more useful than simply saying “it doesn't work.”

To follow the setup steps again, return to the user guide and go through import, mode selection and testing in order. To install on another platform, check the operating system and chip on the client downloads page. Handle subscription updates, client upgrades and network policy changes separately, and keep notes so you can roll them back. This reduces interactions between settings and helps identify the failing layer instead of relying on repeated reinstalls or changing multiple switches at once.