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.
-
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.
-
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.
-
Check the core
Open Settings → Parameters → Core type. For standard VLESS, VMess, and Trojan nodes, Xray is the preferred choice.
-
Add a subscription
Go to Subscription groups → Subscription group settings → Add, enter a label and the complete subscription URL, then save.
-
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.
-
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.
- The app window is visible, but there are no nodes: check that the subscription was saved and that “Update all subscriptions” has been run.
- The node list exists, but no active server appears at the bottom: right-click the target node and set it as the active server.
- The core exits immediately after starting: open the logs and check port conflicts, node fields, and the Core type first.
- The browser still uses the direct connection: confirm that the system proxy is enabled and check whether the browser has its own proxy settings.
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
RecommendedSupports 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.
- First confirm that the main executable and all other extracted files are at the same directory level.
- Then confirm that the runtime and app architectures match.
- Next check whether local ports such as 10808 are occupied by another process.
- Finally check that the system proxy points to the port currently listening.
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.
- In Finder, confirm that the running copy is in Applications.
- Open Activity Monitor and search for v2rayN and the current core process.
- After confirming that it has quit, reopen the app and select an active node.
- 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.
- After every client update, recheck Settings → Parameters → Core type.
- When a subscription update fails, check the logs first instead of deleting the original group.
- Keep one verified working node to distinguish a new-node failure from a local problem.
- After changing the local port, update the browser, command-line tools, and other manual proxy settings as well.
- Quit normally and back up the current configuration before upgrading or moving the app folder.
- After troubleshooting, restore the log level to warning to avoid generating excessive debug records over time.
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.