At a glance

This guide is for Windows and macOS users trying v2rayN for the first time. It covers processor architecture, runtimes, launch permissions, core selection, subscription imports, system proxy settings, and connectivity tests, then walks through common fixes for launch failures, missing tray icons, empty node lists, and browser access problems.

Check your system and processor architecture before downloading

The v2rayN 7.x desktop interface runs on Windows and macOS, but each platform uses a different package format, and the processor architecture must match. Most Windows PCs use x64, while some Qualcomm-based devices use arm64; older 32-bit systems should not use the current 64-bit release. On macOS, choose between Intel x64 and Apple Silicon arm64.

In Windows, open Settings → System → About and check System type. Choose x64 for “64-bit operating system, x64-based processor” and arm64 for an ARM-based processor. On macOS, open System Information: Apple M-series chips require arm64, while Intel processors require x64. With the wrong architecture, the app may show no window at all or the system may report that it cannot run.

Files and permissions for the first installation

Windows
  • Choose an x64 or arm64 package for your system
  • Extract the entire archive to a fixed folder
  • Make sure your account can write to the folder
  • If required, install the matching .NET 8 Desktop Runtime
macOS
  • Choose an arm64 or x64 package for your chip
  • Move the app to the Applications folder
  • For the first launch, use Open from Finder
  • If the runtime is missing, install the matching .NET 8 Runtime

The package format, processor architecture, and runtime must all match before you can troubleshoot the client configuration.

A Windows archive should not be run directly from an archive manager’s preview window. v2rayN reads configuration, logs, and core files from its own folder or the user data directory; running only the executable inside the archive can leave the core missing, prevent settings from being saved, or make subscriptions disappear after a restart. Use a fixed folder such as D:\Apps\v2rayN, and avoid protected system directories that require extra write permissions.

When opening the downloaded app for the first time on macOS, the system may ask you to confirm its source. In Finder, select the app and choose Open, then follow the prompt; if it is still blocked, go to System Settings → Privacy & Security to review the recent block. Do not keep double-clicking different copies, or it becomes difficult to tell whether the active version is in Downloads or Applications.

Complete these six checks in order after the first launch

You do not need to tune every advanced setting immediately. First make sure the client, core, subscription, and local listening port form a complete chain, then choose routing and system proxy modes. Following the order below helps separate a client startup issue from a node that is unavailable.

  1. Extract or move the app

    On Windows, extract all files to a fixed folder; on macOS, move the app to Applications and avoid keeping multiple runnable copies with the same name.

  2. Launch the main app

    Once the main window appears, check the title bar and the tray or menu bar icon. Closing the window usually leaves the app running in the background.

  3. Check the core

    Open Settings → Parameters → Core type. For standard VLESS, VMess, and Trojan nodes, Xray is the preferred choice.

  4. Add a subscription

    Go to Subscription groups → Subscription group settings → Add, enter a label and the complete subscription URL, then save.

  5. Update nodes

    Run “Update all subscriptions” and wait for nodes to appear in the main list; select one and set it as the active server.

  6. Test the connection

    Run a real connection latency test first, then enable the system proxy. Do not judge proxy availability from ICMP ping alone.

After the main window appears, check the status information at the bottom or open the log window. A healthy state should at least show the active node, the local listening port, and a running core process. On the first run, the system firewall may ask whether to allow network access; grant only the permissions needed for the current trusted network type. If access is denied, the client interface may still look normal, but other apps will fail to connect to the local proxy port.

Closing the main window does not necessarily quit the app. By default, v2rayN can minimize to the Windows notification area or the macOS menu bar. To exit completely, choose “Quit” from the tray or menu bar menu, then confirm in Task Manager or Activity Monitor that the related processes have ended. Do this before updating files, moving the folder, or changing runtimes.

How to configure the Core type, listening port, and system proxy

The Core type determines which core parses the node configuration. Xray offers broader support for VLESS, REALITY, XTLS Vision, and common VMess configurations, making it a solid default for everyday use with v2rayN. The V2Fly core is useful for checking compatibility with existing VMess and WebSocket configurations. The core must match the node fields; changing its name cannot fix parameters missing on the server.

Xray core

Recommended

Supports common combinations such as VLESS, REALITY, XTLS Vision, VMess, and Trojan, making it the default Core type for v2rayN 7.x.

Best for: everyday use, VLESS nodes, REALITY nodes

V2Fly core

Suitable for traditional VMess, TCP, WebSocket, and TLS configurations, and useful for comparing core compatibility with specific configurations.

Best for: existing VMess nodes, compatibility checks

The local listening port is the entry point that browsers and other apps use to connect to v2rayN. A common default port is 10808, but use the local listening settings under Settings → Parameters and the runtime logs as the source of truth. You can change the port, but it must not duplicate another proxy app or local service. If the log says “address already in use” or reports a port conflict, quit other proxy apps or change the port to 10818, then restart the core.

The system proxy only passes traffic from apps that honor the system proxy settings to the local port; it does not automatically cover every process. Some command-line tools, games, and apps with their own networking stack ignore the system proxy. For the first check, test with a regular browser, then configure apps that require a separate SOCKS or HTTP address.

Baseline configuration

Core type
Xray
Local address
127.0.0.1
Default port
10808
Log level
warning

Keep the loopback address at first to avoid exposing the local proxy port to other devices on the same LAN.

First connectivity test

Active node
Select one manually
System proxy
Automatic configuration
Routing mode
Bypass LAN
Test method
Real connection latency

Reduce variables first; once access is confirmed, move on to rule-based routing, subscription groups, or automatic selection.

Validate node fields after importing a subscription

Saving a subscription URL does not guarantee that nodes will appear immediately. Run “Update all subscriptions” so the client fetches the remote content and writes it to the current group. If the update returns zero nodes, first check that the URL is complete and contains no spaces accidentally included during copying, then review the HTTP status and parsing messages in the logs. Do not create several identical groups, which produces duplicate nodes and makes update results harder to identify.

The advantage of importing a subscription is that the provider supplies the protocol fields consistently. With VLESS + REALITY, for example, the server address, port, user ID, Server Name, public key, Short ID, fingerprint, and Flow must correspond; if any one is expired or missing, the client may start successfully but fail the protocol handshake. VMess + WebSocket + TLS likewise requires Host, path, TLS, and server-side transport settings to match.

VLESS + REALITY

Transport
TCP
Security
REALITY
Flow
xtls-rprx-vision
Fingerprint
chrome

The public key, Short ID, and Server Name come from the node configuration and should not be edited casually after importing the subscription.

VMess + WS + TLS

Transport
WebSocket
Security
TLS
Path
Use the subscription value
Encryption
auto

Host, path, and port must match the server; the leading slash in a path is part of the configuration.

Once nodes appear, select one and run a real connection latency test. It uses the local core and attempts an actual connection, so it is closer to the proxy handshake result than a simple ping. A single result reflects only the network at that moment; test three times about 10 seconds apart. For example, 168 ms, 175 ms, and 171 ms indicates little variation, while 140 ms, 890 ms, and a timeout suggests line instability, packet loss, or an unreliable handshake.

Low latency does not guarantee high download speeds. Latency mainly reflects the time needed to establish a connection; throughput is also affected by server bandwidth, congestion along the route, transport method, and the destination site. During first-time setup, just confirm that a connection can be established, pages load, and DNS resolution works. Optimize speed separately after the basic link is stable.

Test result Most likely status Next step
120–250 ms with three similar results Stable connection; the remote server may be far away Enable the system proxy and test a webpage
One result below 200 ms and another above 800 ms Route instability or network congestion Compare with another node in the same group
All tests time out The node is unavailable, fields are incorrect, or the connection is blocked Update the subscription and review the core logs
The test passes but webpages fail An issue with the system proxy, routing, or DNS Check proxy mode and browser settings

Common Windows startup and tray issues

On Windows, startup failures most often come from three places: the archive was not fully extracted, the .NET runtime does not match, or the app folder is not writable. If double-clicking produces no interface, first check Task Manager to see whether the process appears briefly; then inspect log files in the app folder and the system event records. If the error clearly points to .NET 8, install the Desktop Runtime matching the v2rayN architecture—not just the SDK or a runtime for another architecture.

If you cannot find the app after closing the main window, the process may still be running. Windows may have folded the icon into the hidden notification-area list. Click the up arrow on the right side of the taskbar to find the v2rayN icon, and allow it to appear in the tray icon settings under Settings → Personalization → Taskbar. Launching the main app again may only wake the existing process rather than create a second window.

What if double-clicking the main app shows no window?

First confirm that the archive was fully extracted, then verify the x64 or arm64 architecture. Check whether the process exits immediately in Task Manager, and use the logs to identify missing .NET runtimes, folder permissions, or missing core files.

What if the browser still cannot connect after quitting v2rayN?

If the app ends unexpectedly, the system proxy may still point to the 127.0.0.1 port that is no longer listening. Restart v2rayN and choose “Clear system proxy”, or check the manual proxy status in Windows Settings → Network & Internet → Proxy.

What if the logs say port 10808 is already in use?

Quit other local proxy apps first, then restart v2rayN. If another service genuinely uses that port, change it to 10818 under Settings → Parameters and update every app that connects to the port manually.

If v2rayN starts but settings return to their defaults after every restart, check the folder’s write permissions and the actual location of the configuration files. Do not keep the app in a temporary extraction folder, and do not let cleanup tools delete its data directory. Quit the client normally before moving it and keep a configuration backup; after moving it, check the subscription and Core type again.

Handling macOS permissions, background icons, and leftover proxy settings

On macOS, the key points for the first launch are the app location and system permissions. Launch the app from Applications and keep its path unchanged after the initial confirmation whenever possible. If you open different copies from Downloads each time, macOS may treat them as separate apps, repeatedly request permissions, and make the configuration file location confusing.

After closing the main window, check the v2rayN icon in the menu bar at the top of the screen. When menu bar space is limited, some icons may be hidden; quit apps that take up space, then use Activity Monitor to confirm whether v2rayN is still running. Before restarting the client, choose Quit from the menu to prevent the old core from continuing to occupy the local port.

  1. In Finder, confirm that the running copy is in Applications.
  2. Open Activity Monitor and search for v2rayN and the current core process.
  3. After confirming that it has quit, reopen the app and select an active node.
  4. Enable the system proxy and test the browser; clear the system proxy before quitting.

If network requests continue to fail after the client quits, reopen v2rayN and choose Clear system proxy, then open the detailed settings for the current network service under System Settings → Network and check whether the proxy still points to 127.0.0.1 and the old port. A typical sign of leftover system proxy settings is that regular webpages all fail while direct connections to LAN devices still work.

When the app opens and the subscription updates but starting a node is the only failure, the issue has usually moved beyond the system permission layer. Return to the logs and check the Core type, node fields, and port conflicts. Do not change the fingerprint, Server Name, Flow, and transport path repeatedly; update the subscription again first and compare another node to determine whether the problem affects one node or the local environment.

Essential maintenance checklist after installation

After the first successful connection, keep changes limited and easy to explain. Routing rules, Mux, concurrency tests, and custom DNS add troubleshooting variables and are not suitable while the basic connection is unstable. Use the setup for a while first, confirm that subscription updates, node switching, the system proxy, and the exit flow all work, then adjust settings for your needs.

A subscription URL is a configuration entry point. Keep it in a controlled location and never paste it into public logs, screenshots, or shared documents. When reporting an issue, you can include the protocol type, port, transport method, and error text, but redact the subscription URL, user ID, public-key-related information, and server credentials.

A reproducible baseline is: v2rayN shows its main window and background icon, the Xray core keeps running, the subscription update produces a reasonable number of nodes, the active node returns a real connection latency result, the browser can access the network with the system proxy enabled, and direct access works again after clearing the system proxy and quitting. Once all six conditions hold, first-time setup is complete.