How to Set Up v2rayN After Installation: First-Run Settings for Windows and macOS

1. Check Your System Architecture and Launch Method

v2rayN is a desktop client for managing nodes, subscriptions, and proxy settings. The selected core handles the actual connection. An open window does not mean the core has started, and a listening core does not mean every app will use the proxy. Verify these three things separately during initial setup.

First, choose Windows or macOS on the downloads page, then select a package that matches your processor architecture. On Windows, check System type under Settings → System → About. On macOS, find your chip or processor under Apple menu → About This Mac. Apple silicon uses ARM64; Intel Macs generally use x64. Do not mix up the two packages.

On Windows, do not launch the app from the archive preview, and do not copy out only the executable. If startup reports a missing .NET runtime, install the version and architecture specified in the prompt. A package that requires the Windows Desktop Runtime will not work with only the standard .NET Runtime installed. Requirements vary by release, so do not follow older guides that prescribe one fixed major version.

2. First Launch: Import a Subscription and Select a Node

The steps below use menu names common to desktop versions. Menu locations may change between releases. First, note the client version under Help → About, then look for the settings in the same version. A subscription URL is used to fetch nodes; it is not a local proxy address and should not be entered in the system's HTTP proxy field.

1. Launch the client

   Start the client from its permanent folder and leave TUN disabled for now. Make sure the main window and log panel open, and avoid launching a second v2rayN instance at the same time.

2. Add a subscription

   Open Subscription Groups → Subscription Group Settings, add a group, enter a name and subscription URL, then save. If the interface has an Add or + button, use it to create a new entry.

3. Update nodes

   From the Subscription Groups menu, select Update All Subscriptions (without proxy). If your current network cannot reach the subscription source, use an available node and the update-through-proxy option instead.

4. Set the active node

   Select an imported node, right-click it, and choose Set as Active Server. Check the log to see whether the corresponding core starts loading. A node appearing in the list does not mean it is active.

5. Check the startup log

   Check for configuration parsing errors, missing core files, and listener failures before testing the remote connection. If an error appears, note the exact log line rather than repeatedly changing settings at random.

3. Local Ports: Check the Listener Before Setting the System Proxy

Under Settings → Parameter Settings, check the local listener options and note the address, port, and protocol. Some versions use a mixed port, while others list SOCKS and HTTP endpoints separately. The ports 10808 and 10809 below are examples for troubleshooting only. Use the values shown in your current interface and logs; do not assume both ports are open on your machine.

For initial setup, serve only the local machine and keep the loopback address. Enabling LAN access changes the exposure scope; it is not a general fix for websites that will not load locally. If you change a port, update manual settings in apps, the system proxy, and terminal environment variables as well.

Check for occupied ports from the command line

The commands below are for Windows PowerShell and macOS Terminal, respectively, and only check listener status. No output means the port is not listening at the moment. If there is output, identify the process; an open port alone does not prove the node connection works.

# Windows PowerShell
Get-NetTCPConnection -State Listen -LocalPort 10808 |
  Select-Object LocalAddress, LocalPort, OwningProcess

# macOS Terminal
lsof -nP -iTCP:10808 -sTCP:LISTEN

4. Choosing Between System Proxy, PAC, and TUN

The system proxy sends requests from apps that follow system settings to the local endpoint. Client routing determines which outbound route the core uses for those requests. These are separate settings. In “Automatically configure system proxy,” “automatically” usually means the client writes the proxy settings; it does not mean PAC is enabled or that every program is captured.

On Windows, check the result under Settings → Network & Internet → Proxy. On macOS, go to System Settings → Network → your current network service → Details → Proxies. Wired and wireless connections may appear as separate services. If configuring settings manually, check the HTTP and HTTPS fields and use the actual HTTP or mixed listener port.

5. Verify the Connection: Check the Endpoint, Node, and DNS Separately

Speed tests and connectivity checks can offer clues, but they do not replace a real request. First confirm that the active node is selected and the core started successfully. Then test the route with a request that explicitly specifies the proxy, and check the browser last. This helps distinguish node problems from browser extensions or leftover system proxy settings.

• Local endpoint: The log should confirm that the listener started successfully, with no address already in use or bind errors.
• Node settings: Check the server address, port, protocol, and transport parameters. Do not change imported TLS, SNI, or WebSocket path values to match another node.
• Real request: Test with a command that specifies the HTTP proxy, then compare the result in your browser.
• DNS and routing: If only some domains fail, check whether the error occurs during name resolution, direct outbound routing, or proxy routing. Do not change all DNS settings at once.

# Windows: Replace the example endpoint with the actual HTTP or mixed port
curl.exe --proxy http://127.0.0.1:10808 --connect-timeout 10 -I https://example.com/

# macOS
curl --proxy http://127.0.0.1:10808 --connect-timeout 10 -I https://example.com/

Here, 10 is the connection timeout in seconds, not a speed measurement. An HTTP response means the request received a response from the remote host. If client routing sends the destination directly, that alone does not prove the proxy outbound works; also check the outbound route in the logs. For TLS errors, check the system clock, certificate hostname, and SNI instead of disabling certificate verification.

6. Start at Login and Restore Proxy Settings on Exit

After confirming that browsing works, look under Settings → Parameter Settings for a launch-at-startup option; its name and location vary by version. On Windows, check existing startup entries under Settings → Apps → Startup. On macOS, check System Settings → General → Login Items or Login Items & Extensions. Use only one startup method to avoid duplicate instances competing for the same port.

1. Move the app to a permanent location before configuring startup to avoid breaking shortcuts if you move the folder later.
2. After restarting, check the system tray or menu bar for the client, then check the core log and local port. A hidden window does not mean the app failed to start.
3. Before quitting, select Clear System Proxy under System Proxy, then exit normally from the client menu.
4. Test browser access after the client exits. If the client is closed but the system proxy still points to an old 127.0.0.1 port, clear that entry in your system proxy settings.

7. Common First-Install Problems

Initial setup is complete when the client starts normally, the active node loads, the local endpoint is listening, app requests reach the core as expected, and system networking is restored after exit. To fine-tune traffic routing, see the routing and DNS sections in the configuration reference. For everyday steps, see the user guide.