For Android users who have imported a subscription but aren't sure how to connect. First check that your server list is up to date, then use a real connectivity test to shortlist servers, start the Android VPN service, and verify actual traffic with your exit IP and the app you want to use. Following these steps helps distinguish an open port from a successful proxy handshake and traffic that actually uses the proxy—so you don't rely on a single green latency result.
1. Check Your Subscription and Selected Server
A successful subscription import only means v2rayNG has saved the subscription entry. You need to update the subscription and see configurations appear before the client has retrieved the server settings. Seeing servers in the list doesn't mean a connection is active. v2rayNG uses the Xray core, so each server's address, port, protocol, transport, and TLS settings must work together. Don't change individual settings to match examples you find online before your first connection.
The steps below refer to the commonly used Chinese-language interface. Menu wording may vary by version: the top-right option may appear as “Test all configurations (real connection)” or “Real connection test for all configurations.” Both mean the same thing. Choose a test labeled “real connection,” not one labeled only “TCP.”
-
Check the Subscription
Open the top-left menu → “Subscription group settings” and confirm the subscription is enabled and its URL has no leading or trailing spaces. Return to the main screen, open the top-right menu, and select “Update current group subscription” or “Update subscription.” Wait for the list to refresh.
-
Select a Configuration
Tap a working server and make sure the selection indicator moves to that row. Avoid entries explicitly marked as expired, out of traffic, or under maintenance. Those labels come from the service provider; they aren't results of an automatic client check.
-
Keep the Original Settings
For the first test, use the VMess or VLESS configuration provided by the subscription. Don't replace the server address with its resolved IP or change authentication settings such as SNI, transport paths, or public keys without a reason.
-
Note Your Test Conditions
Note whether you're using Wi-Fi or mobile data, and whether the app you're testing has its own proxy configured. Complete one round of checks on the same network before switching networks and testing again. This avoids mistaking a network change for a server difference.
2. Choose a Server: Check Availability, Then Stability
A location in a server name is only a filtering clue, not a measure of actual connection quality. Nearby servers can be congested, and servers with the same name may use different entry points. For your first connection, look for a server that can complete requests consistently, then compare latency. Unless your service requires a specific location, there's no need to target one right away.
Servers That Pass Repeated Real Connectivity Tests
RecommendedTest repeatedly on the same network and with the same test URL. Prioritize servers that keep succeeding and can open your target site after you connect. Use one as your initial active configuration, then verify its exit IP.
Best for: Getting connected for the first time and establishing a reliable baseline
Servers With Low TCP Latency Only
A low TCP latency result only shows that a particular server port is reachable. It doesn't verify proxy authentication, the TLS handshake, or a request to your destination. A low millisecond reading can still be followed by a handshake failure.
Best for: Quickly ruling out unreachable entry points; still requires a real connectivity test
Servers That Pass Occasionally
If a server succeeds once and times out the next time, keep it as a backup. Test again at another time or on another network. Don't make it your long-term choice based on a single best result.
Best for: Comparing with a stable server to identify network fluctuations
Start with two or three candidate servers and test each three times. These are practical guidelines, not a built-in scoring system. Keep the test URL the same for every round. If you have many servers, test them in batches to avoid sending too many probes at once and affecting your mobile network or results.
3. Run a Real Connectivity Test: Verify the Request Path, Not Bandwidth
Open the top-right menu on the main screen and choose “Test all configurations (real connection).” This test attempts to reach the configured test URL through each server being checked, verifying more of the proxy path than a TCP probe. Results depend on the test URL responding: if the test site itself is unreachable, several working servers may all appear to fail.
| Test Type | What It Tells You | What It Doesn't Prove |
|---|---|---|
| TCP latency | Whether a TCP connection can be established to a specific server port | Successful proxy authentication or that a webpage will load |
| Real connectivity test | Whether this configuration can complete a request to the test URL | That every app is routed through the proxy or that download speeds will remain high |
| Target webpage check | Whether a specific task works in your browser | That other apps use the same routing |
| Sustained transfer test | How the current route performs during sustained data transfer | That performance will be the same at other times or with other destinations |
The millisecond value in a real connectivity test measures the time taken by a single request. It's not Mbps and can't be converted directly into video quality. Don't prioritize the lowest number over consistent success. If every test times out, first check the test URL settings under “Settings” in the client and confirm the URL still returns the expected response. If your probe requires a specific status code, an ordinary webpage isn't an equivalent replacement.
These ports are shown to help explain the connection path, not as a reason to change your settings. A browser's HTTPS request, the client's connection to the proxy server, and DNS resolution are separate steps. Keep the server port from your subscription. A real connectivity timeout doesn't mean “changing the port to 443 will fix it.”
4. Start the VPN: Distinguish a Running Service From Routed Traffic
After choosing a server, tap the start button at the bottom right of the main screen. When Android first asks to set up a VPN connection, confirm that v2rayNG is the requesting app, then grant permission. The VPN icon only shows that the VPN service is running. It doesn't confirm successful authentication with the remote server or guarantee that every app is using the proxy.
- Check for another active VPN: Android generally allows only one standard VPN service per user at a time. Other VPN-based network tools may replace or conflict with v2rayNG. Stop them before testing.
- Check per-app proxy settings: Open the top-left menu → “Settings” → “Per-app proxy.” For your first test, you can temporarily turn this feature off. If you need to keep it on, make sure your test browser is included and check whether the option to bypass selected apps is enabled.
- Check the routing mode: Review “Routing” or “Routing settings.” A site matched by a direct-connection rule may still show your local exit IP. That doesn't mean the VPN service isn't running.
- Restart the service: After changing per-app proxy settings or routing, stop and restart the service so your next test uses the updated configuration. Don't rely on an old browser page or existing connection as a new test.
5. Verify the Proxy: Cross-Check Your Exit IP and Target App
Stop v2rayNG and use the same browser to note your current public exit IP. Then start v2rayNG and request the same lookup service again. You can enter https://api.ipify.org in the address bar to see the returned public IP. This is an external lookup service. If you can't reach it on your network, use another accessible IP lookup service; an unreachable lookup site alone doesn't mean the proxy has failed.
Verification: Use the Same Browser Before and After Connecting
Before connecting
- Keep using the same Wi-Fi or mobile data connection.
- Record the lookup time and full public IP address.
- Make sure the browser doesn't have a separate proxy configured.
- Note whether the target site currently loads.
After connecting
- Make sure the selected configuration is the same one you tested.
- Open a new page and request the same lookup service.
- Compare the exit IP and check the routing rules.
- Reopen the target app and make a new request.
A changed exit IP shows that this browser request used a different exit. Check the routing rules and the target app's results too before concluding that the traffic you need is being proxied.
If the IP hasn't changed, check in order whether the lookup domain is routed directly, whether per-app rules exclude the browser, and whether the request reused an existing connection. Don't rely on the IP's apparent location: different IPs can be in the same region, and geolocation databases may be out of date. To check IPv6 traffic, use a lookup method that displays IPv6. A page that returns only IPv4 can't prove that IPv6 also uses the proxy.
Next, open the app you actually need and refresh its content or make a new request. Cached pages, previously loaded images, and download history aren't proof of connectivity. If the browser works but a particular app doesn't, first check its per-app proxy settings, routing rules, and network requirements. Don't immediately replace the entire subscription group.
6. Troubleshoot First-Connection Failures by Symptom
Keep one working configuration for comparison. If a connection fails, open “Logs” from the top-left menu and check the latest entries after reproducing the issue; don't rely on the first error you see. When reporting a problem, note the client version, network type, time, and error keywords. Before sharing logs, redact subscription URLs, user identifiers, and server authentication details.
TCP Shows Latency, but the Real Connectivity Test Times Out. Why?
A reachable entry port doesn't mean proxy authentication succeeded. First update the current subscription and run the test again. Then check the logs for handshake, authentication, or certificate errors. If only one server fails, compare it with another in the same group. If they all fail, check the test URL and your network. Don't disable certificate verification as a substitute for finding the cause.
The App Says Connected, but Webpages Won't Load. What Should I Check?
Run a real connectivity test first, then go to “Settings” → “Per-app proxy” and make sure the browser isn't excluded. Check for direct-connection rules under “Routing,” restart the service, and open a new webpage. If the logs show a DNS resolution error, check DNS settings and Android Private DNS. Change one setting at a time and record the result.
Wi-Fi Works, but Mobile Data Doesn't. How Do I Troubleshoot It?
Keep the server and test URL the same, switch only the network, and repeat the real connectivity test. Under Android “Settings” → “Apps” → “v2rayNG,” check mobile data and background data permissions; wording varies by Android version. If permissions are correct and only one network fails, compare other servers to distinguish an unreachable entry point from a network restriction.
The Connection Drops When the Screen Locks. Do I Need a Different Server?
First check the battery settings under Android “Settings” → “Apps” → “v2rayNG” and allow background activity using the option provided by your system. Reconnect, lock the screen, and check whether the VPN icon or client service disappears. A system stopping the service and a remote server disconnecting are different problems and should be handled separately.
A successful first connection isn't about getting an impressive number for one server. It means the real connectivity test succeeds repeatedly, the Android VPN service stays running, the test browser's exit IP and routing match expectations, and the target app can make a new request. Once that's confirmed, enable per-app proxy rules, refine routing, or adjust DNS. Change one setting at a time so you can quickly return to a working setup if something goes wrong.