When setting up v2rayN for the first time, get the app and its core running first, then import a subscription, and finally configure the system proxy. This guide is for Windows and macOS desktop users. It walks through the installer, permissions, subscriptions, cores, and local ports to help distinguish between the app opening, a node being selected, and browser traffic actually going through the proxy.
Choose the right download: OS, architecture, and runtime
Start on the download page and choose a package for your operating system and processor architecture. Don’t rely on the v2rayN in the filename alone. The Windows desktop edition and the classic WPF edition have different interfaces; the WPF edition runs on Windows, not macOS. On macOS, choose the package for your hardware: arm64 for Apple Silicon or x64 for Intel.
v2rayN is a client for configuring and managing proxies; the core handles the actual connections. An app that opens successfully doesn’t mean its core is ready. If you see a missing runtime warning on first launch, note the framework name, architecture, and requirement shown, then install what the package documentation specifies. Don’t guess based on a similarly named runtime.
Check these items before installing
Windows
- Open “Settings” → “System” → “About” to check your system type.
- Make sure the x64 package matches your device architecture. x64 does not mean it works with every processor.
- If .NET is missing, follow the startup message and the instructions for your chosen package. The desktop runtime and SDK serve different purposes.
- If the package requires an external runtime, quit and restart the client after installing it.
macOS
- Open the Apple menu → “About This Mac” and check “Chip” or “Processor.”
- Choose arm64 for Apple Silicon or x64 for Intel. Use the package that matches your architecture.
- After opening the disk image, copy the app to Applications before launching it from there.
- Check the current download’s requirements to confirm your macOS version is supported.
Match the operating system and architecture first, then address any runtime warnings. Switching nodes repeatedly won’t fix an app that won’t start.
First launch: extraction and permission prompts
On Windows, fully extract the archive before running v2rayN. Don’t launch the main program from the archive viewer. Use a separate folder your account can write to, such as D:\Tools\v2rayN. That’s just an example; you don’t need a D: drive. Keep the main program, bundled files, and subfolders together.
If you copy only the executable to your desktop, the client may not find its core or other dependencies. Quit the app, then extract the complete archive again; this is usually easier than trying to replace files one by one. Avoid running copies from two different folders at the same time, or you may be looking at different settings, logs, and ports.
-
Extract the full archive
In Windows, choose “Extract All” for the downloaded archive, then launch the main program from the extracted folder. Don’t move or delete core subfolders you don’t recognize.
-
Use a permanent location
On macOS, copy the app to Applications, then eject the disk image and open the app from Applications. This avoids running it from a temporary mounted volume.
-
Read the prompt
If the system blocks the app, first check where the file came from and read the message. On macOS, the option to allow an app to open is usually under “System Settings” → “Privacy & Security.” Only do this for apps whose source you’ve verified; don’t disable system-wide security protections.
-
Check the logs
Open the client’s “Logs” section and look for missing files, permission errors, or port conflicts. Menu locations vary between desktop interfaces; start with the first specific error message.
Import a subscription: saving the URL doesn’t add nodes
A subscription URL retrieves node configurations; it isn’t a node name or a provider’s login page. First add a subscription group in the client, then update it. Saving the group without updating it can leave the node list empty. Even after a successful update, you still need to select a node as the active server.
Depending on the desktop interface, the menu may say “Subscription Groups” or “Subscription Group Settings.” The steps below use common menu labels. If yours differ, look for the group settings and update subscription options rather than changing unrelated settings based on someone else’s screenshot.
- Open “Subscription Groups” → “Subscription Group Settings,” select “Add,” then enter a recognizable name and the complete subscription URL.
- After saving, return to “Subscription Groups” and update the group using “Update Subscription (without proxy).” This can reduce dependencies when you haven’t set up a working proxy yet.
- If the subscription can’t be reached directly and you already have a verified working proxy node, try “Update Subscription (through proxy).” This option isn’t required for every subscription.
- When the update finishes, check the node list and select a node. Use “Set as active server” in the right-click menu, or the equivalent option in your interface.
- If parsing fails, check that you copied the complete URL, didn’t paste a webpage address by mistake, and that the subscription provider uses a format the client can read.
An imported node only confirms that the configuration was recognized; it doesn’t prove the server is reachable. Subscription URLs often contain access credentials, so don’t include the full URL in public screenshots. When asking for help, share the error text and protocol type, but hide subscription parameters, user identifiers, and sensitive server details.
Choose a core that supports the node’s settings
V2Ray and Xray are core projects; v2rayN is a desktop client. They aren’t different spellings of the same name. VMess and VLESS are node protocols, WebSocket is a transport, and TLS protects the connection. Choose a core that supports the node’s full configuration, not just the protocol abbreviation shown in the list.
For nodes using REALITY, xtls-rprx-vision, or similar settings, choose an Xray version that supports the combination and confirm the client generates a valid configuration. The option is commonly under “Settings” → “Parameter Settings” → “Core Type”; some interfaces list it separately as “Core Type Settings.” After changing it, re-enable the active node and check the logs to see whether it starts successfully.
- Keep the imported values: The provider determines the address, port, user ID, transport, path, SNI, public key, and other fields. Don’t guess at changes to “optimize” them.
- Check compatibility next: If you see an “unsupported field” error or the configuration fails to load, check the selected core and whether it supports the configuration before changing DNS.
- Investigate connection errors last: If the configuration loads but connections time out, check your network, server status, and node details. A timeout is not the same as a parsing failure.
System proxy: check the local address and listening port
For your first browser test, start with the system proxy. In v2rayN, choose “Set system proxy” → “Automatically configure system proxy,” then check the proxy address and port recorded by your operating system. This connects apps that follow system proxy settings to the client on your computer; don’t enter the remote server address in system settings.
The ports below are examples for troubleshooting, not instructions to overwrite your settings or a guarantee that every version uses them by default. Some interfaces use a mixed listener, while others provide separate HTTP and SOCKS listeners. A mixed listener handles both proxy protocols on one port; with separate listeners, check each port individually.
Check the client
- Settings location
- Local listener options under “Settings” → “Parameter Settings”
- Local address
127.0.0.1, the loopback address for this computer- Listening port
- Note the active HTTP, SOCKS, or mixed listener port
- Running status
- No bind failures or address-in-use errors in the logs
Entering a port in the interface isn’t enough; confirm that the core is actually listening on it.
Check the operating system
- Windows
- “Settings” → “Network & Internet” → “Proxy”
- macOS
- “System Settings” → “Network” → current connection → “Details” → “Proxies”
- Proxy address
- Should match the client’s local listening address
- Proxy port
- Must match the active listener port for the selected proxy protocol
Menu labels may vary by operating system version. Check the address, protocol, and port.
If the logs report that a port is already in use, quit duplicate client instances and other proxy processes, then try again. If you need to change the port, update the client’s listener, run automatic system proxy configuration again, and confirm the system proxy port was updated too. Changing only one side can leave the app open and a node selected while the browser still fails to connect.
Verify the setup: change one thing at a time
For testing, keep one active node, one known routing setup, and one traffic-handling mode. The system proxy affects only apps that follow that setting; some apps use their own proxy options or connect directly. A webpage opening in your browser doesn’t mean every app is using the proxy, and a successful node latency test doesn’t guarantee access to a specific site.
Routing rules determine which connections go direct and which use the proxy. For your first test, use a clearly documented preset in the client and note your choice. Switch temporarily to global proxy mode only if you need to tell whether a routing rule was missed or a node is unavailable, then restore your original routing settings.
- The app won’t open: Recheck the package, architecture, and runtime before troubleshooting subscriptions.
- The node list is empty: Check that the group was saved, the update completed, and the subscription format is supported.
- The node fails to start: Check core compatibility, configuration generation, and local port conflicts.
- The browser can’t connect to the proxy: Check the local listener and system proxy port first; don’t assume the server is at fault.
- Only some websites fail to load: Check routing rules, DNS resolution, and connectivity from the node to the target site.
Why can’t my browser open websites after I quit v2rayN?
The system may still have proxy settings pointing to a local port, even though the client has stopped listening. Reopen v2rayN, choose “Clear system proxy” under “System Proxy,” then quit normally. If the app won’t open, check for leftover settings in your system’s proxy options. On managed devices, check with your administrator before changing organization-wide settings.
Do I need to enable TUN and change DNS during initial setup?
No. First use the system proxy to confirm the node and browser connection work. Configure TUN only if you specifically need to capture traffic from apps that ignore system proxy settings. Check DNS only if you encounter a domain resolution error. Changing the traffic mode, routing, and DNS settings all at once makes it much harder to identify the cause.
After setup, note the installation folder, active node, selected core, listening port, and system proxy status. If something goes wrong later, start with the last setting you changed. Back up your configuration before upgrading. Don’t mix configuration files or cores from old and new folders, and don’t delete your existing configuration until you’ve confirmed the new one works.