v2rayN Setup for All Platforms

Before You Start: Installers and Connection Details

Know the Difference Between the Client, Core, and Nodes

v2rayN is a desktop GUI client for storing server details, updating subscriptions, generating runtime configurations, and managing proxy settings. The core handles the actual connection, while a node contains the address and credentials for a remote server. Installing the client does not give you nodes to connect to, and having a subscription does not mean every entry is compatible with your core. Before you begin, confirm whether your provider gave you a subscription URL, an individual share link, or a complete configuration file, and check which protocols and clients it supports.

For desktop use, v2rayN supports Windows, macOS, and Linux. On Android, use v2rayNG, which commonly works with the Xray core; consider v2flyNG if you specifically need a V2Fly configuration. Similar core names do not guarantee identical protocol fields. For REALITY, flow control, and transport settings in particular, use the options available in your current app. Do not assume a runtime configuration exported by one client is a universal subscription format for another.

Check Your System Architecture and Installation Requirements

Choose an installer for your operating system from the client downloads page, then check your processor architecture. The Windows download offered here is for x64. On a Mac, check the chip in About This Mac and choose the Apple silicon or Intel build. On Linux, match both the architecture and package format. For Android, arm64 is the usual choice; check the universal build if you are unsure of the device architecture or see an incompatibility warning. File extensions alone do not determine compatibility, so avoid repeatedly installing similarly named packages built for different architectures.

Make sure you have enough space for the app and its configuration, and that your account can install software. A standard system proxy usually does not require running the app as an administrator at all times; TUN, virtual adapters, and routing changes may require additional permissions. Organization-managed devices may restrict network extensions, VPNs, or proxy changes, so check your device policies if an action is blocked. Set the system date and time correctly, too: a significant mismatch can cause an otherwise valid encrypted connection to fail during the handshake.

Start with a Minimal, Testable Setup

For the initial setup, pause any other proxy or VPN that is managing network traffic, and leave only the client you are testing active. Note your existing system proxy and DNS settings so you can restore them later. Verify a browser connection through the system proxy before trying TUN. Avoid changing nodes, routing, DNS, and network adapter settings all at once. If you change several layers together, even a successful fix will not tell you what worked—and the same issue may return when you switch networks.

Subscription URLs often contain account identifiers or access tokens, so treat them as sensitive information. Do not share the full URL in public screenshots, online conversion tools, or support discussions; redact authentication fields from logs as well. Choose a regular webpage that should open directly as a baseline, along with a page that should be reachable through your current node. When reporting an issue, include the app name and whether the system proxy or TUN is enabled. That is more useful than simply saying the network is down.

This guide covers configuration steps and how the settings relate to one another. Menu names may change as the interface evolves. If you cannot find an exact match, look for the relevant function under labels such as “Subscriptions,” “System Proxy,” or “Routing,” rather than expecting screenshots from another platform to match. If your connection already works, skip to the relevant section. If you are still learning how to import and enable a configuration, complete the quick-start guide first, then return to add routing rules or TUN.

Windows: Install v2rayN and Configure the System Proxy

Choose the Desktop or Classic WPF Edition

Open the Windows downloads and choose either the v2rayN desktop edition or classic WPF edition. The desktop edition uses a cross-platform interface and suits users who want a similar experience across desktop operating systems; WPF is the classic Windows interface. Their menus may be organized differently, so mention which edition you use when troubleshooting. Do not run two copies of the client at once if they would compete for the same local listening port; the core started second may fail to bind.

Follow the installer prompts. On first launch, make sure the main window opens before importing nodes. If the app exits immediately, check the system message and application logs instead of changing network settings. If a required runtime is missing, install the one specified by the app. The classic WPF interface depends on desktop components, which cannot be replaced with runtimes intended for other purposes. Follow the installer’s requirements; there is no need to add unrelated components if the app already runs normally.

Import a Subscription and Select a Server

In subscription group settings, create a group, give it a recognizable name, and paste the full subscription URL into the address field. Save it, then update the current subscription. Saving a group records its source but may not fetch any nodes. When the update completes, switch to that group and check that server entries appear, then select one as the active server. If you copied the URL from a browser, make sure it is the subscription link from your provider—not a URL for an account dashboard or order page.

Importing an individual share link from the clipboard is different from updating a subscription. After importing, check the server address, port, protocol, and transport. In particular, do not mistake a note at the end of the link for the server address. For your first test, keep just one clearly usable candidate to avoid interference from automatic switching or batch tests. A latency result reflects only the specific test method; it does not replace a real request to your target page or prove that every protocol setting is correct.

Enable the System Proxy, Then Check Routing

Once the core starts normally, choose the option to automatically configure the system proxy from the system proxy menu. Apps that follow Windows proxy settings will then send requests to the client’s local entry point. The system proxy passes requests to the client; routing determines whether those requests go direct or through a proxy. These are separate settings. Choosing a preset that bypasses mainland China does not enable the system proxy, and enabling the system proxy does not guarantee that every app will use it. Terminals, developer tools, and some download managers may need their own proxy settings.

Reopen the test page to verify the connection, and restart apps that may be holding on to old connections. If the browser works but command-line tools still connect directly, check where those tools get their proxy settings instead of importing the subscription again. A browser extension may also override the system proxy. For an overview of the modes, see System Proxy and Routing Modes. Although the interfaces differ by platform, the traffic entry point and the route to its destination are separate layers.

TUN Permissions and Restoring Network Settings

Enable TUN only if you need to manage traffic from apps that ignore the system proxy or need broader network interception. First close other tools that manage virtual adapters, grant the permissions requested by the client, and check the core logs to confirm that the network interface was created. If security software blocks a network component, identify the exact component and why it was blocked rather than disabling all protection. Organization policies may still prevent access, even with administrator privileges.

Before quitting, turn off TUN, then clear the system proxy set by the client. If the computer shuts down unexpectedly and the browser cannot connect before the client starts, check Windows proxy settings for a manual proxy that still points to localhost. To restore connectivity, undo only the settings changed during this session; do not remove unknown adapters or reset the entire network. For startup issues, see Runtime and Startup Permission Troubleshooting and treat app launch failures separately from node connection failures.

macOS: Chip Selection, Installation Permissions, and Proxies

Choose the Installer for Your Mac

Check the chip in About This Mac, then open the macOS downloads. Choose the arm64 build for Apple silicon or the x64 build for Intel. Use a build that matches your Mac’s architecture instead of treating a successful launch through a compatibility layer as the best option. When the download finishes, open the disk image and follow the prompts to move v2rayN to Applications. Launch it from the Applications folder rather than running it from a temporary mounted location.

On first launch, macOS may show a security confirmation or ask for permission. First confirm that the file came from the expected download source, then use Privacy & Security in System Settings to allow it to open. Messages such as “app is damaged,” “cannot be verified,” or “permission denied” can have different causes: check that the download completed, the install location is writable, and system policies are not blocking the app. Do not assume every warning has the same cause, and do not disable macOS app security just to launch one app.

Run the Client Before Changing the System Proxy

Open v2rayN’s subscription group settings, enter a name and the full subscription URL, save, then update the current group. Once the node list appears, select the active server and confirm that the core starts. If the URL saves but the update fails, check for extra spaces, an expired link, or a network that cannot reach the subscription service. Updating a subscription and connecting to a node use different request paths: a successful update does not prove the node works, and a failed update does not necessarily mean an existing node is unusable.

Next, enable automatic system proxy configuration from the system proxy menu. On a Mac, proxy settings are associated with network services, so check the active service again after switching between Wi-Fi, Ethernet, or another network. “Do not change system proxy” means the client stops modifying system settings; it does not mean no proxy settings remain on your Mac. To restore a direct connection, clear the system proxy and verify the result in System Settings, rather than simply switching to “Do not change.”

Distinguish Browser Connections from App Connections

First, open the target page in a browser that follows the system proxy and check whether its requests appear in the client logs. If the browser works but a developer tool does not, check the tool’s own proxy settings and process environment. Some apps read proxy settings only when they start, so you may need to reopen them after changing the system settings. A browser may also use a separate proxy extension or custom DNS settings, causing apps on the same Mac to behave differently. Repeatedly switching nodes is unlikely to help.

Choose routing presets such as bypass mainland China or global mode based on your destination. “Automatically configure system proxy” does not mean all connections go through a remote server: the core can still route specified domains or addresses directly. Pay particular attention to loopback addresses and local network targets in development environments, so requests meant for the local machine are not sent to a remote server. Preserve suitable direct routes for printers, local network services, and internal domains.

TUN and Recovery After Sleep

Try TUN only when you need to handle traffic from apps that do not read the system proxy. Follow the client’s prompts to authorize elevated access or helper components, and approve any network capabilities requested by macOS. Once TUN is on, test a regular webpage, then local network access and the target app. Testing just one page can miss routing or DNS problems on the local network. Do not run multiple tools that manage the default route at the same time; closing a window may not stop background network features.

After your Mac wakes from sleep or switches networks, existing connections may no longer work. First check that the basic network connection is available, then reconnect to the current node. If the problem persists, turn off TUN, restore your system proxy baseline, and enable the settings again in the original order. Clear the proxy before quitting; after an unexpected exit, check the proxy settings for the active network service for anything left behind. For more detail, see macOS System Proxy Modes Explained; for startup problems, see Permissions and Quarantine Troubleshooting.

Linux: Packages, Desktop Proxies, and Permissions

Check Your Distribution and Processor Architecture

Open the Linux downloads, first confirm whether your distribution uses deb or rpm packages, then check whether your system is x64 or arm64. Do not change a file extension to turn one package format into another, or confuse processor architecture with distribution name. Check the system’s About page if available. If you use a terminal, the command below only reads system information; it will not install software or change network settings. Match the reported architecture to the download page before continuing.

uname -m
cat /etc/os-release

Open the downloaded package with your distribution’s software installer, check any dependency messages, and complete the installation. If the installer reports missing components, resolve them through your distribution’s standard package repositories; do not mix in packages from another distribution. If the app installs but its window does not appear, launch the installed program from a terminal to read the error output. Focus on graphics sessions, desktop components, and file permissions. This is still a launch issue, not a node connection issue, so changing the subscription will not help.

Run as a Regular User and Check the Listening Port

For everyday use, open the GUI as a regular user. Running it with elevated permissions once can leave its configuration directory unwritable for your normal account. On first launch, check that subscription and app settings save correctly. Quit and reopen the app to make sure they persist. If changes keep disappearing, check the configuration directory permissions, disk status, and whether you are running the app from a temporary location. For backups and migration, preserve appropriate file ownership rather than masking the problem by making every directory writable.

Create a subscription group, enter its URL, save and update it, then select a node and check the core logs. An “address already in use” message usually means another core or proxy tool is using the same local port. Identify the process, then stop the duplicate instance or change the client’s listening port. If you change the port, update any apps using that proxy too. Changing it only in the client can leave the browser, terminal, or desktop proxy pointing to the wrong entry point, so the core runs but receives no requests.

Desktop Environments Do Not Share One Universal System Proxy

Linux desktop proxy behavior depends on the desktop environment and how each app is implemented. If the client offers a system proxy option, also check the desktop’s network proxy settings to confirm the change was applied. Some graphical apps read desktop settings, while command-line tools may use environment variables or their own configuration files; running processes may not update automatically. Start by routing traffic from one app known to support proxies through the local entry point. Once the node connection is confirmed, add other apps one at a time to keep troubleshooting focused.

Before configuring a terminal proxy, check which proxy protocols the tool supports and what type of local listener the client has enabled. HTTP and SOCKS listeners are not interchangeable just because both run on localhost. Temporary environment variables usually affect only the current terminal and its child processes; they do not change the whole desktop. Remove the corresponding environment settings when you are done. Otherwise, new commands may keep trying to use a local port that no longer exists after the client exits, making the problem look like a system network failure.

TUN, Routing, and Network Management Services

TUN needs access to a virtual network device and permission to change related routes. Follow the client’s instructions to grant the required permissions, but do not run the entire desktop app with elevated privileges indefinitely just to make TUN work. Once enabled, check that the network interface was actually created, whether another VPN is managing the default route, and whether local network targets are still reachable. Desktop network management services may reapply settings after a network change, so a successful initial launch does not guarantee the same behavior after switching networks.

DNS may be managed separately by the desktop environment, network management service, or local resolver. Identify which layer is responsible before changing client DNS; avoid overwriting system-managed resolver files. If name resolution fails, turn off TUN first and check whether system resolution works again. Once basic networking is restored, inspect the virtual interface and rules one step at a time. Clear only the proxy settings changed during this session before quitting, and never change the default route on a remotely managed machine without a recovery path.

Android: Import Subscriptions and Grant VPN Access

Choose v2rayNG or v2flyNG

Choose an app from the Android downloads. For a typical Xray configuration, start with v2rayNG; consider v2flyNG if your configuration is specifically designed for V2Fly. Both apps manage nodes, but their options and protocol support are not necessarily the same. If your provider requires REALITY or a particular flow control setting, check that the fields are available in your chosen app before importing. That can save you from discovering at connection time that the core does not support them.

The available installers include arm64 and universal builds. Most recent mainstream devices can use arm64, but check the processor architecture if you are unsure. If Android reports an incompatibility, verify the architecture and system requirements instead of repeatedly overwriting the installation with packages from different sources. When installing through a browser, Android may ask you to allow installs from that source; grant permission only for the source you are using. After installation, open the app from your app list and make sure you can reach the main screen and save settings.

Paste the URL, Then Update the Subscription

Copy the full subscription URL. In the app’s subscription settings or group manager, add a source, enter a name, and save it. Then run the subscription update. Some interfaces put the update action in the main list menu, so seeing the URL in subscription settings does not mean it has been fetched. After updating, return to the node list and select an entry. For an individual share link, use the relevant clipboard import feature instead of pasting it into a field that accepts subscription URLs only.

When copying a subscription on your phone, watch for line breaks, extra spaces, or explanatory text added by a chat app. Check the protocol at the start and make sure the full content is intact before importing. Scanning a QR code only reads the encoded data; it cannot confirm that the configuration is still valid. If a node appears but will not start, check the transport, encryption parameters, and core support, then review the logs. For a closer look at format differences, see Subscriptions, Native JSON, and Share Links. Do not treat every text format as if it used the same import method.

How Android VPN Routing Works

When you tap Connect, Android usually displays a VPN connection request. After you approve it, the app can receive traffic through a local virtual network interface. This is Android’s network-routing mechanism for apps of this kind; it does not automatically fill in missing node details. A VPN status icon only confirms that the local traffic tunnel is active. Check the logs and make a request to your target to confirm the remote connection. If you deny system permission, changing nodes repeatedly will not fix the authorization issue.

Android generally allows only one regular VPN app at a time to manage traffic for a user. If another VPN, filtering tool, or network app using the VPN interface is active, stop it before testing. Per-app proxy settings control which apps are included in the tunnel. Depending on the selected mode, the list may mean “proxy only selected apps” or “bypass selected apps.” Read the current mode before changing the selection: checking an app does not always mean its traffic will use the proxy.

Background Limits, Network Changes, and Recovery

If the connection works in the foreground but often drops when the screen is locked, check the system’s battery optimization, background activity, and auto-start restrictions for the client. Allow the background activity the app needs, without changing settings for unrelated apps. Also check whether the system stopped the process or whether the connection dropped after switching from Wi-Fi to mobile data. These have different causes: the first points to background restrictions; the second is a reason to reconnect with the current configuration and check the logs.

For your first test, avoid enabling system options such as always-on VPN or blocking connections without a VPN. These can block other traffic when the client has not connected successfully, hiding the state of your basic network connection. If you need these options, first verify that connecting, disconnecting, and restarting all work as expected. When troubleshooting is done, disconnect in the app and confirm that Android has cleared the VPN status. Before switching clients, disable the previous one’s traffic interception so its leftover state is not mistaken for a problem with the new app.

Subscriptions: Formats, Updates, and Configuration Migration

Identify the Configuration Type and Use the Right Import Method

A subscription URL is a reusable endpoint from which the client fetches node details when it updates. A share link usually describes a single node, while native JSON may contain a complete set of inbounds, outbounds, routing, and DNS settings. These formats cannot be used interchangeably just by changing a file extension. If import fails, first check the input type, then confirm that the client supports it. Saving webpage content as text or encoding already encoded content again will not make it a valid configuration.

Base64 subscriptions are commonly used to encode a collection of share links. After decoding, the contents still need to use a link format the client can read. Some subscription services return different content depending on the request, so what you see in a browser may not match what the client receives. Check the update log for the response and any parsing errors; do not conclude that the subscription works just because the URL opens in a browser. A login page, error message, or empty response can all leave the client with no importable nodes.

Keep Group Updates Separate from Node Selection

Give each subscription group a recognizable name to distinguish its source and purpose. Updating the current group refreshes only that source; updating all subscriptions may replace entries in several groups at once. If you have edited subscription nodes manually, back them up before updating, since the client may regenerate entries from the source and overwrite your changes. For custom nodes you need to maintain long term, save them separately rather than relying on a subscription entry you must edit again after every update.

After an update, check that the currently selected node is still there. Its name, server address, or configuration may have changed. Do not assume that a successful group update means you are done. Set automatic update intervals according to the provider’s limits, and avoid rapid repeated retries when updates fail. If the subscription service is temporarily unreachable but a saved node still works, keep using the saved configuration while you investigate the subscription request path; there is no need to delete every entry and rebuild the setup.

Use App-Level Backups for Migration

When moving between installations of the same client, use its backup and restore features if available, or back up the configuration directory as documented. Close the app before copying files to avoid copying a database while it is being written. Save the destination device’s existing configuration separately before restoring. Backups may contain full subscription URLs, authentication details, and local usage records, so store them somewhere secure. After restoring to the new device, recheck the local listening port, system proxy, and TUN settings; do not assume machine-specific options will work unchanged.

For cross-platform migration, pay particular attention to file paths, permission models, and network services. Windows paths do not work as-is on a Mac, and Linux authorization settings cannot be copied directly to Android. When moving between clients, use a share format supported by both and verify key parameters individually. A complete runtime configuration may contain core-specific fields; JSON format alone does not guarantee compatibility. Even if import produces no error, test the connection and routing behavior.

Check REALITY and Transport Settings

For a VLESS node, check the server address, port, user ID, transport, connection security, and flow control separately. The REALITY server name, public key, and short ID must match the server’s requirements; do not copy them arbitrarily from another node. The server name may also differ from the actual connection address. If a required value is missing, ask your provider rather than turning off verification and hoping it works. For background, see REALITY and XTLS Vision Explained.

After migration, run two rounds of checks: first establish a minimal connection on the new device, then restore your routing rules, automatic updates, and background settings. Clean up the old configuration only after the new setup is stable. If the new device has not connected successfully yet, keeping the old configuration helps distinguish configuration issues from platform-specific ones. For details on format conversion, see Subscription Formats Explained.

System Proxies, TUN, Routing, and DNS

First, Find Out How Requests Reach the Client

A system proxy is a way for apps to work with a proxy: the operating system stores the proxy entry point, and apps that read this setting send requests to it. TUN creates a virtual entry point at the network layer and uses routing to pass matching traffic to the client. These settings determine how traffic gets to the client; they do not decide the final route for every request. If an app ignores the system proxy, changing node routing rules usually will not help because its requests never reach the core.

To check whether the entry point is working, make a specific request and look in the logs for a matching destination, time, and app behavior. If there is no log entry, check the proxy entry point and app settings. If a request appears but fails, check the node, routing, and DNS next. Do not leave verbose logging enabled longer than needed. Restore your usual log level and clear any records containing sensitive information when you finish. Connection reuse may mean that reloading a page does not create a new connection; reopen the app if needed before testing again.

Routing Rules Select an Exit in Order

A bypass-mainland-China preset usually directs matching domains and addresses to a direct connection, then applies other preset rules to the rest. Rule order matters: a broad rule near the top can prevent more specific rules below it from matching. Consider local network addresses, specific development domains, and remote destinations separately instead of adding a single rule that covers everything. On a corporate network in particular, internal domains may require an internal DNS resolver and should not automatically be sent to a remote server.

This Xray routing example shows how database rules relate to outbound tags. Merge it into an existing configuration; it cannot run as a complete client configuration on its own. The example assumes that outbounds named direct and proxy and a compatible rule database already exist. A GUI client may regenerate its runtime configuration, so for day-to-day changes, use its routing interface rather than editing a temporary generated file directly.

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

DNS Is More Than Entering a Resolver Address

Domain lookups can happen in the app, operating system, client, or on a remote server; the lookup location may also vary by proxy method. If a browser uses encrypted DNS, changing system DNS may not affect it. To troubleshoot, first find out which layer resolves the target for that app, then check whether the client’s rules can see the domain. If the request reaches the client only as an IP address, domain-based rules may not match as expected. Do not change DNS at several layers at once just because a webpage will not load.

The client’s DNS settings and its direct and proxy exits can also depend on one another. For example, if resolving the node server’s address requires a request through that same node, the connection has a startup dependency loop. First make sure the server’s address can be resolved before the connection is established; then configure DNS routing for target domains. With TUN, also confirm that DNS requests are intercepted as intended. If the system and client return different results for the same domain, app behavior may be inconsistent.

Test Databases and UDP Separately

GeoSite classifies domains, while GeoIP classifies address ranges; they are different rule datasets, not interchangeable. If a rule is correctly written but its classification does not work, check that the database exists, loaded successfully, and uses a format supported by the current core. After updating the database, check whether the core reloaded it; a successful download alone is not enough. For rule matching order, see the GeoIP and GeoSite Update Guide.

A webpage working in your browser does not prove that UDP-based apps will work. UDP forwarding depends on the app’s entry point, client settings, protocol support, node service, and network conditions. For voice, real-time communication, or apps using other transports, inspect that traffic separately instead of treating a webpage test as proof. Add complexity gradually: verify the system proxy, then routing, then TUN, and finally DNS and app-specific requirements. Keep the previous working configuration at each step so you can roll back.

Common Configuration Issues: Troubleshoot by Failure Stage

The App Won’t Open or the Core Won’t Start

First, check whether the main window appears. If it does not, focus on the installer architecture, system dependencies, app permissions, and security warnings; subscription content is unlikely to be the issue yet. If the window opens but the core exits, check the core logs for configuration parsing errors, a local port conflict, file access failures, or unsupported fields. Note exactly when the error occurs. That prevents you from repeatedly switching nodes to fix an app launch issue or reinstalling the whole client to fix a configuration error.

If startup failed after you changed a setting, undo the most recent change first. If you have a backup, restore a configuration known to start. Do not immediately delete the entire configuration directory; it may contain useful logs and working settings. For a port conflict, look for another running copy of the client. For a permissions error, check the specific file location. For cross-platform startup troubleshooting, see v2rayN Crashes and Permission Issues. Restore the app to a working baseline before testing the network.

Subscription Updates Fail or Connections Fail

If a subscription update fails, first check whether the subscription service is reachable, then whether its response can be read by the client. A timeout, expired authentication, and unsupported format are different issues. Confirm that the URL is complete and still authorized, then check whether your current network is showing a sign-in page or blocking access. If saved nodes work but the subscription cannot be reached, check whether the client offers a suitable update request method. Do not send a sensitive subscription URL to an online conversion service; that can turn a configuration problem into a credential leak.

If a node imports but will not connect, check the remote address, port, protocol, transport, and security settings one at a time. For a timeout, check reachability and service status. For authentication or handshake errors, focus on the configuration, system time, and server requirements. An error message alone does not prove the cause; consider when it appears. Before switching through a list of nodes, test one configuration with known details. If all configurations fail at the same stage, check the shared environment before changing each node.

Connected, but Webpages or Apps Don’t Work

If the client says it is running, that only confirms that the local process is active. First check whether requests appear in the logs, then verify which exit route matched, and finally inspect DNS results and the remote response. If the browser works but other apps do not, compare their entry points and proxy settings. If every app fails, revisit the core and node. If only some domains fail, check the routing category, DNS response, and destination service instead of immediately enabling broader traffic interception.

Partial page loads, interrupted downloads, or buffering video do not necessarily mean the node is slow. A page may request resources from several domains, and a routing error affecting just one group can cause partial failure. Check the failed request’s destination and exit route to see whether it took the expected path. A latency test measures only one kind of connection; it does not predict throughput, sustained transfers, or performance across every protocol. When comparing nodes, use the same destination, network, and proxy method so the results are comparable.

No Internet After Quitting and How to Report an Issue

If the network stops working after you quit the client, first check whether the system proxy still points to the local entry point, then check whether TUN or a system VPN is still intercepting traffic. Undo the client’s changes and test a page that should open directly. On Linux, check for leftover terminal environment variables as well as desktop proxy settings; on a Mac, check the active network service; on Android, check whether the system is set to block connections without a VPN. Do not jump straight to a full network reset. Start with settings clearly related to what you just changed.

If you need more help, provide your operating system and architecture, client name, configuration type, connection method, and steps to reproduce the problem. Include an error excerpt with sensitive fields redacted. Say whether all destinations fail or only some, whether a direct connection works, and whether the issue started after installation or a network change. Test one hypothesis at a time and record the result. For common concepts, see FAQs. To repeat the full connection setup, return to the user guide and establish a baseline by importing, selecting, enabling, and verifying the configuration in that order.