This guide covers only the steps required for first use: add a subscription, choose a mode, start the connection, and confirm the result. Follow the page in order; see the protocol manual for protocol fundamentals, core differences, and parameter selection.
v2rayN · Desktopv2rayNG · AndroidAbout 10 minutes
setup.flowREADY
01
subscriptionSave the URL and update nodes
02
proxyModeChoose rules or global routing
03
connectionSelect a node and start the connection
04
verificationConfirm the result with a real request
Follow the order and do not skip verification
STEP INDEX
Jump to a Setup Step
BEFORE START
Before You Start: Client, Subscription URL, and System Time
Before configuring anything, make sure the client is installed correctly and opens to its main screen. Use v2rayN on desktop and v2rayNG on Android. If it is not installed yet, open the download center and choose the package for your platform. On first launch, the system may ask for network access; allow the client to connect before moving to subscription import. There is no need to change the core path, listening port, or routing rules during installation. Keeping the defaults makes later troubleshooting easier.
Next, prepare a complete subscription URL. It is usually a link beginning with https:// that lets the client retrieve a node list and its parameters. When copying it, select everything from the first character through the last, without extra spaces, line breaks, or end punctuation. A subscription URL differs from a single vmess:// or vless:// sharing link: the former can update multiple nodes at once, while the latter usually imports one configuration. See the glossary for more terminology.
Finally, check the device date, time, and time zone. Many secure connections depend on an accurate system clock; a large time difference can make an otherwise correct node fail during the handshake. Enable automatic time setting, then fully quit and reopen the client. After these three checks, import the subscription. This helps rule out installation issues, a missing URL, and incorrect system time when an error appears.
01
SUBSCRIPTION
Import a Subscription: Save the URL, Then Update
Subscription Settings in v2rayN for Desktop
After opening v2rayN, look for “Subscription Groups” or a similar subscription-management entry in the top menu. Open the subscription settings and add a subscription group. Use a recognizable source name, then paste the complete subscription link into the URL field. Save it after checking that there are no spaces at either end. This only adds the subscription source; nodes may not appear immediately. Return to the subscription menu and choose “Update all subscriptions” or update the current group.
Wait for the client to finish its request. Normally, one or more configurations will appear in the server list, with columns such as alias, address, port, protocol, and transport. Nodes appearing in the list does not mean they are connected; it only means the subscription was parsed. Do not adjust advanced settings or manually rewrite the address or port yet. Subscription fields usually need to remain consistent, and changing one field can cause a connection failure.
Subscription Settings in v2rayNG for Android
Open the v2rayNG main screen, expand the side menu, and enter “Subscription Group Settings.” Tap the add button, enter a recognizable name in the remarks field, paste the subscription link into the URL field, and save. Return to the main screen, open the menu again, and choose Update subscription. When the update finishes, node cards or names should appear in the main list. If the list is still empty, pull to refresh or run the update again before attempting to connect.
Some subscriptions return multiple protocols and transport configurations. For first use, there is no need to study every field. Confirm that node names are visible, entries can be selected, and the update completed without a clear error. Protocol selection and the relationship between REALITY, VMess, VLESS, and different cores are covered in the protocol manual. This page keeps to the shortest path for a first connection.
Once the node list appears, the first step is complete. Do not click Connect immediately; first decide which requests the client should handle. That choice is controlled by the proxy mode and directly affects the verification results.
02
PROXY MODE
Choose a Proxy Mode: Rules or Global
The proxy mode determines which connections the client takes over. The common choices are rule-based routing and global proxying. Rule-based routing follows built-in or subscription-provided rules: some addresses use the proxy node while others connect directly. Global proxying sends most requests that follow the system proxy through the current node. Either mode works for an initial test, but remember which one is selected so you can interpret the verification results correctly.
Set Routing First, Then Confirm the System Proxy on Desktop
In v2rayN, the routing mode and system proxy status are related but separate settings. Routing mode controls how the client splits traffic internally; the system proxy determines whether browsers and other system-aware apps hand requests to v2rayN. For a first connection, choose the client’s basic rules mode, then use the system proxy menu to enable automatic system proxy configuration. The client menu in the taskbar area usually shows the current system proxy status. If you select a node without enabling the system proxy, the core may be running while the browser still uses a direct connection.
If you only want to determine whether routing rules cause the difference, temporarily switch to global mode for one comparison test, then switch back to rule-based routing. Do not change routing rules, listening ports, DNS, and node parameters at the same time. Change one condition at a time so the result points to a specific cause. For domain rules, IP rules, and direct-connection priority, see the routing section of the protocol manual.
Confirm the Mode in the Android Connection Settings
The v2rayNG mode options are usually in Settings or Routing settings. Choose the basic rules mode, return to the main screen, and keep the node you want to use selected. When Android starts the connection, a system network authorization prompt appears; confirm it so the client can create a local connection channel. Authorization only allows this client to handle network requests; it does not guarantee that the remote node works. Continue by checking the connection status and completing the fourth step.
If you are unsure which option to choose, start with rule-based routing. It suits everyday use and makes it easier to check whether local resources still connect directly as expected. If a target address fails, use global mode briefly for comparison: if global works but rules do not, inspect the routing match; if both fail, continue checking the node, subscription parameters, and network connection.
Once the mode is set, leave it unchanged and return to the node list. Select one node and start the connection. Avoid switching among several entries during connection, which can mix the logs and test results.
03
CONNECTION
Connect to a Node: Select an Entry and Watch the Status and Logs
Choose a Node Using Clear Identifying Details
Choose an entry with a clear name from the current subscription group. For a first setup, do not guess speed from the name or treat an ordinary ping as proof that the proxy works. Ping only shows whether a specific network probe can reach its destination; it does not cover the full protocol handshake, transport layer, or real proxy request. If the client offers a real connection test or a test through the proxy, you can use it before connecting, but browser results remain the final measure.
In v2rayN, double-click the target node or use the context menu to set it as the active server. Confirm that the row is marked as selected, then check the bottom of the window or the log area. Start the system proxy and make sure the core is running. Normally, the log shows startup completion and the local listening port becoming available. If there are no repeated configuration parsing failures, connection timeouts, or protocol parameter errors, proceed to browser verification.
In v2rayNG, tap a node card to make it the active configuration, then tap the Connect button on the main screen. Confirm the system authorization prompt if it appears on the first connection. The Connect button or top status will change, and a network connection indicator will appear in the system status area. This only means the local channel has started; a failed remote node may still look connected briefly, so do not stop here.
Read Errors in Chronological Order
When a connection fails, find the first clear error in the log rather than focusing only on the last repeated line. An initial configuration parsing error usually calls for updating the subscription again instead of editing node fields. An address resolution error points to DNS problems on the current network. For a timeout, try another node in the same subscription for comparison. If several nodes time out, check the system time, subscription expiry, and local network stability.
If the log reports that the local port is already in use, another program or an older client process is using the same port. Exit duplicate client instances and restart the current client. Do not change several ports without knowing their purpose; the browser and system proxy may still point to the original port, adding more troubleshooting steps. Common log terms and their recommended handling order are listed in the Troubleshooting section of the help center.
Connection status is only an intermediate result. You still need to confirm that browser requests enter the client, the remote connection succeeds, and rule-based routing behaves as expected. The fourth step verifies these three points separately.
04
VERIFICATION
Verify That It Works: Check the Address, Pages, and Routing
First Check: Does the Browser Use the Current Connection?
Keep the client connected without switching nodes or modes. Open a new browser window, visit a familiar IP lookup page, and note the displayed exit address and approximate region. Disconnect the client, refresh the same page, and compare the results. A difference consistent with the node configuration shows that browser requests are passing through the client and current node. Use a new window where possible to avoid false results caused by cached pages.
If the results are identical before and after connecting, first check that the v2rayN system proxy is enabled, then confirm that the browser is not using a separate proxy configuration. On Android, check that the main-screen connection is still active and that the test browser is not on a bypass list. Reconnect, close the original test page, and run the comparison in a new page.
Second Check: Make a Real Web Request
An address lookup only proves that one request used a different exit path. Open two or three ordinary websites and check whether they load completely. Pages with text, images, and several resource requests reveal problems more readily: text loading while images remain stuck may indicate DNS, routing, or transport instability; if every page fails immediately, check the system proxy, local port, and node connection first; if only one page fails, do not conclude that the entire node is unavailable.
Do not use ordinary ping as the only test. Real web access includes DNS resolution, the protocol handshake, remote outbound routing, and content transfer, making it closer to the client’s actual operation. If the client offers a real connection latency test, use it as a relative comparison between nodes, but judge the result by whether pages open continuously, resources load, and the connection remains stable.
Third Check: Does the Mode Behave as Expected?
If you chose rule-based routing in step two, visit a local resource or familiar service that should normally connect directly, and check whether its speed and exit behavior match expectations. Under rule-based routing, different destinations may use different outbound paths; that is normal. Different network paths on two websites do not by themselves indicate a failed setup. In global mode, most browser requests that follow the system proxy should use the current node.
For further confirmation, switch between rule-based routing and global mode only once while keeping the node unchanged, then repeat the same page test. If the result changes with the mode, the connection itself is probably working and the difference comes from routing rules. If both modes fail, return to step three and check the node status and logs. This one-variable comparison avoids changing the node, mode, DNS, and system proxy back and forth at the same time.
RESULT NOTES
Common Results and What to Do Next
connected
Connection and Verification Both Pass
Keep the current node and mode. When updating the subscription later, update it first, then choose a node from the refreshed list. Client upgrades usually do not require adding the subscription again, but confirm that the existing group and routing settings were retained.
same_address
The Exit Address Does Not Change
On desktop, check the system proxy status and browser proxy settings first; on Android, confirm that the connection has not been paused by the system. Do not change protocol parameters yet, because this symptom more likely means requests are not reaching the client.
timeout
The Node Keeps Timing Out
Check the system time first, then update the subscription and try other nodes in the same group. If several nodes behave the same way, continue through the help center’s recommended order: local settings, subscription status, then node parameters.
route_mismatch
Only Some Addresses Fail
Keep the node unchanged and run one comparison in global mode. If global mode works, focus on routing matches and DNS settings; consult the protocol manual for protocol fields and core compatibility.
Need to Check Parameters or Error Causes?
Visit the help center for common connection issues, or read the protocol manual for guidance on choosing protocols, cores, and transports.