V2Ray Setup Guide:
Import a Subscription and Test Your Connection

Before you begin, install the client for your platform and get the subscription URL from your service provider. The client reads configurations and establishes connections; it does not create a working server account for you. A subscription URL is usually an HTTPS address and may contain personal access credentials. Copy it in full, without extra spaces, chat instructions, or line breaks. Keep the URL in the client and don't include it in public screenshots or support posts.

v2rayN: Add a subscription group, then update it

Open v2rayN and find Subscription Groups in the top menu. Open the group manager or settings, add a group, enter a recognizable name and paste the subscription URL into the address field, then save. The name is just a local label you can use to identify the service; the URL is what the client accesses when updating. Return to the main screen and check that the group appears in the list.

Open Subscription Groups again and choose Update current group or Update all subscriptions. For a first-time setup, if you don't have a working proxy yet, choose an update method that doesn't use a proxy. If your provider specifically requires an existing connection for updates, you'll need another working connection first. When the update finishes, server entries should appear in the main list. If you see only the group name, the URL is saved but the subscription hasn't been successfully fetched or parsed.

Select a configuration in the list and check that its address, port, and protocol are populated. You don't need to change transport, TLS, or other advanced settings yet; keep the values provided by the subscription. Selecting an entry only highlights it in the interface. In step three, you'll confirm which server is actually active.

v2rayNG: Save the group, then update from the main screen

Open v2rayNG and select Subscription Group Settings from the side menu. Tap the add option, enter a label and subscription URL, and save. Return to the main screen and choose Update subscription from the more menu. When the update finishes, imported configurations should appear in the server list. If group filtering is on, switch to the new group or all groups so an empty filtered list isn't mistaken for a failed import.

If you have a single share link beginning with vmess://, vless://, or a similar scheme, use the add option on the main screen and import it from the clipboard. Don't paste it into the subscription URL field. A share link describes one configuration, while a subscription URL retrieves a group of configurations; a share link usually won't change when the subscription is updated. See how to import share links and subscription URLs for details.

Once the server list is ready, don't change protocols right away. First, decide how traffic enters the client. The system proxy on desktop and VPN mode on Android determine how app traffic reaches the client. Routing rules then determine whether the core sends a connection through a proxy server, connects directly, or blocks it. These are separate settings. Choosing proxy in the routing rules doesn't mean all apps are using the client; seeing the system proxy enabled doesn't mean every connection goes through a remote server.

v2rayN: Start with the system proxy

Find System Proxy in the v2rayN status bar at the bottom or in the tray menu. Common options include Set system proxy, Clear system proxy, and Do not change system proxy. For an initial test, identify where to change this setting; after starting the core in step three, choose Set system proxy. This sends traffic from apps that follow the system proxy to the client's local listening address. You don't need to configure another proxy in your browser.

Do not change system proxy preserves the current system settings; it doesn't mean direct connection. An old proxy address already set on the system may still be active. Clear system proxy removes the system proxy configuration. When getting started, avoid adding other proxy tools or browser extensions, which can give the same app multiple traffic entry points. The client may appear to be on while the app is actually connecting to a different port. You can also skip TUN mode, which may require extra permissions, and verify the setup first with a browser that follows the system proxy.

Next, find Routing or Routing settings and choose a preset that suits your needs. Common routing presets send some connections directly and proxy the rest; a global proxy preset generally sends most connections that reach the core through the proxy. The exact scope depends on the rules. To check whether the server works, you can temporarily use a proxy preset that's easier to verify, then switch back to a routing preset suited to everyday use.

v2rayNG: Check VPN mode and per-app proxy separately

In v2rayNG settings, make sure VPN mode is enabled. It uses Android's VpnService to receive app traffic and pass it to the core. The VPN status indicator means this traffic entry is established. In Per-app proxy, check whether all apps are included or whether the client filters by an app list. For your first test, you can turn off per-app filtering and narrow the scope after confirming the connection works.

If you need per-app settings, read the description next to the switch carefully: the list may mean “only proxy these apps” or “bypass these apps.” The same checked apps can produce opposite results depending on the setting. Make sure the browser you're testing is within the actual scope, then check Routing settings. Per-app proxy filters by app; routing rules match connection destinations. They are not interchangeable.

At this point, you should be able to say which app enters the client through which route and which routing preset it uses. Leave the default DNS settings alone for now; don't change DNS, transport parameters, and routing rules at the same time. For domain strategies and core differences, see the protocols and cores reference. During initial setup, change one setting at a time to see what caused the result.

v2rayN: Set an active server and check that the core starts

Return to the server list, right-click your target entry, and choose Set as active server or a similar option. Some versions also let you double-click an entry. Check the active marker or status bar to make sure that configuration is in use. v2rayN usually loads the configuration and starts or restarts the core when you switch active servers. There may not be a prominent Connect button, so don't rely on finding one to determine whether the service is running.

Open the log panel on the main screen and check for immediate errors such as configuration parse failures, a port already in use, or a core startup failure. Then choose Set system proxy so apps that follow system settings send new connections to the client. If the system prompts you for local network permissions, follow the operating system's instructions and check the app's identity and requested permissions. Don't disable system-wide protections to work around a single startup issue.

If the logs report a port conflict, close duplicate client instances or stop other tools using the same listening port, then restart the core. Don't change the server port at random: the local listening port and the remote port in the subscription are different. The local port is where apps connect to the client on your device; the remote port must match the server configuration. If the error concerns protocol or transport fields, update the client and subscription first, then check which core the configuration requires.

v2rayNG: Select a configuration and approve the VPN request

On the v2rayNG main screen, tap the target server and make sure the selection indicator appears next to it. Then tap Start. The first time you connect, Android displays a VPN connection request. This means the app is about to create a VPN interface to handle network traffic. Confirm that the request is from the v2rayNG app you installed, then approve it. If you deny permission or dismiss the prompt, VPN mode can't start properly.

After starting, check the app's running status and the system VPN indicator. Another app using a VPN interface may conflict with v2rayNG and replace its connection, so stop the conflicting service first. If the Start button quickly returns to its stopped state, check the logs for startup errors instead of tapping repeatedly. If the connection works in the foreground but drops after the screen has been locked for a while, allow background activity in system battery settings. This can keep the service running, but won't fix incorrect server settings.

At this point, the client service should be running. That doesn't mean every destination is reachable. Proxy protocols often establish a real connection only when an app makes a request, so the running status alone doesn't prove the remote server is reachable. Next, make a new request from the target app and use a test and the logs to verify the full route.

Open the browser you confirmed in step two is included in the proxy scope, then visit a known-working HTTPS page that should use the current route. Open a new tab or restart the browser so the test creates a fresh connection; an existing page may be cached, and a long-lived connection may keep using its previous route. Reaching a site that normally connects directly only proves that the site is reachable. It doesn't prove proxy traffic is working.

Check app requests first, then test results

Run a real connection latency test or connection test in the client to see whether the selected configuration can complete a specific test request. The result applies only to that test destination and time; apps and destinations may behave differently. A standard ping doesn't test the full proxy chain, so a ping response doesn't prove the browser is using the client. See how latency tests work for the differences between test types.

To check your public IP, use an IP lookup page you trust and record the result with the proxy on and off. First make sure the lookup destination should use the proxy under your current routing rules; split routing may send it directly, in which case an unchanged IP is expected. Your public IP is only one clue. Consider it alongside app results, routing settings, and logs. Don't leave global proxy mode enabled just to get a different IP.

Troubleshoot in order: entry point, routing, remote server

If the client test succeeds but the browser can't connect, check the traffic entry first. Does the desktop browser follow the system proxy, or is an extension overriding it? Is the Android browser included in the per-app proxy scope? If needed, fully close and reopen the target app. If the logs support connection records, check for the destination when you make a request. If the default logs don't show every connection, don't assume that no traffic is flowing just because no record appears.

Once you've confirmed that the request reaches the core, check which outbound it matches. If it uses a direct connection instead of the expected proxy, check the routing preset and rule order rather than reinstalling the client. If the request reaches the proxy outbound but times out, check whether the subscription has expired, whether the server address and port have changed, whether the device time is correct, and whether all required protocol settings are present. For certificate or handshake errors, don't disable security checks to hide the cause.

If only some destinations fail, keep the current working configuration and note the failed destination, test time, and error type. Then use the FAQ to narrow down the cause. Before sharing logs, redact subscription URLs, access credentials, and personal server addresses. Don't change the server, routing, DNS, and core all at once. Change one setting while keeping everything else the same, then retest the same app and destination.

Everyday use after verification

Once the connection works, switch back from any temporary test routing mode to a preset suited to everyday use, then test again. On Android, you can enable per-app proxy gradually and check that your usual apps remain within the intended scope. Update the subscription periodically to sync server configurations; you don't need to import it again every day. Manual changes to subscription entries may be overwritten by an update, so keep a separate record of any important local changes.

When you're done, clear the system proxy before closing v2rayN, or make sure the client restores system settings on exit. Otherwise, apps may keep connecting to a local port that's no longer listening. In v2rayNG, stop the service from the main screen and check that the VPN indicator is gone. Next time, just check the subscription, select an active configuration, and start the client; you don't need to repeat all four steps.