1. Client is running, but there’s no internet access
First determine whether no websites load or only some. If nothing loads, check the proxy entry point and server connection first. If only certain sites fail, check routing rules and DNS. A browser’s connection error doesn’t prove the server is at fault: the request may never reach the client, or it may be routed to the wrong outbound. Follow the steps below and note the result of each one.
Check the selected server and client status
Make sure a server is selected in the v2rayN server list. Importing a subscription without selecting an entry—or having an entry replaced during a subscription update—can leave you with nothing to test. Open the client logs and check for configuration errors, core startup failures, port conflicts, or connection errors. If an error appears during startup, address the first specific error in the log before changing DNS.
Temporarily switch to another server known to work and test again. If only one server fails, check its address, port, and transport settings. If they all fail, check the local proxy entry point and network. Use server details from your subscription provider or server configuration; don’t guess the user ID, PublicKey, or ShortId. Before editing an entry, copy it so you can compare or restore the original.
Check the system proxy and which apps are affected
Check the current status in v2rayN’s system proxy menu. If your browser relies on the system proxy, running the client doesn’t mean the operating system is routing browser traffic through it. Set the system proxy to the mode you need, then close and reopen a browser window to test. Also check whether the browser has its own proxy settings or extensions that override the system proxy. Whether other apps follow the system proxy depends on how each app is implemented.
To test the proxy path, briefly switch to global mode and try the same destination. If it works in global mode but not with your usual routing mode, the entry point and server are probably working; check the routing rules instead of reinstalling the client. Restore your original mode when you’re done so a diagnostic change doesn’t become part of your everyday setup. TUN can capture more traffic, but it shouldn’t be used to mask an unconfirmed system proxy issue.
Use logs to see where the request stops
Open the client’s log view, visit just one test page, and check whether a corresponding connection appears. If there’s no log entry, check the system proxy, app-specific proxy settings, or TUN entry point. If the request appears but name resolution fails, go to the DNS section on this page. If the log shows a remote connection timeout, see the server timeout section. If it identifies a direct or blocked outbound rule, check the routing configuration.
Use the same browser, destination, and server throughout the test so requests from multiple tabs don’t get mixed together. “Client started” in the log only means the program is running; it doesn’t mean the destination is reachable through the proxy. If needed, test one site that normally connects directly and another that should use the current proxy rules, then compare the routing results.
Rule out local network issues and stale proxy settings
Temporarily turn off the client’s system proxy and check whether the device can reach a page that should be available directly on the current network. If direct access also fails, troubleshoot Wi-Fi, Ethernet, the gateway, or the operating system’s network settings first. A proxy client can’t fix a broken base connection. Then check whether another proxy app is using the same listening port or whether an old proxy address remains in the system settings. A port conflict in the logs is usually more important to resolve than repeatedly switching servers.
When you’re done, restore the intended system proxy and routing modes, then repeat the action that originally failed. If the issue affects only one app, check its proxy options and network permissions rather than treating it as a device-wide failure. For quick answers to questions like “connected, but websites won’t load,” see the Help Center. To rebuild the basic setup step by step, return to the guide.
2. Server timeouts or repeated disconnections
A server timeout means a connection didn’t complete within the allotted time; it doesn’t point to one specific cause. Server address resolution, the destination port, transport protocol, transport security, and your current network may all play a part. First check whether only one server times out, then verify its configuration. If every server in the same subscription times out, check the shared network entry point, subscription contents, and client status.
Compare the scope; don’t treat a latency test as the final verdict
On the same network, test the current server and another known-working one. Note whether the failure affects one server, one group, or all servers. A client latency test probes a specific connection path; it can’t replace testing an actual website or app. If the latency test passes but websites fail, check routing, DNS, and app proxy settings. If the test fails but some services still work, don’t delete the server based on one reading alone.
Compare results on another working network, such as switching from Wi-Fi to mobile data. If the same configuration fails on only one network, check that network’s DNS and gateway, and whether it allows the connection method in use. If it fails on multiple networks while other servers work, focus on the server’s status and whether its fields match the server-side configuration. Keep the test time and log error type; these details are more useful to your configuration provider than “the server doesn’t work.”
Check the server configuration field by field
In “Edit Server,” check the address, port, user ID (id), transport (network), and transport security (TLS) one by one. Each field must match the server-side configuration; the same protocol name doesn’t mean two configurations are interchangeable. For VLESS with REALITY, also check SNI, Fingerprint, PublicKey, ShortId, and the required flow setting. Some fields may be left blank, but follow the actual server configuration.
Change only one field at a time, based on evidence, and note its original value. If the server address is a domain name, first check whether the current network can resolve it. If it’s an IP address, DNS usually isn’t the first thing to investigate for that connection. For transports such as WebSocket, also check the path and host settings. Compare the imported subscription entry with the manually edited one to spot transport parameters that may have been missed.
Check where the timeout occurs in the log
If the log says the server domain couldn’t be resolved, check local DNS or the domain used by the subscription. If a remote connection times out, check the address, port, base network, and server status. If the connection is established but a security handshake then fails, focus on SNI, certificate-related settings, or REALITY parameters. The failure stage determines the fix; don’t switch cores just because the log says “timeout.”
On Windows, the built-in name lookup command can help determine whether a domain resolves. The domain below is only a syntax example; replace it with a server domain you’re authorized to check. A returned address means resolution succeeded, not that the remote port is reachable or the protocol handshake will work.
nslookup v2raypeizhi.comReconnects and connection stability
If a connection works at first but drops later, note whether the device went to sleep, switched from Ethernet to Wi-Fi, or resumed from standby when it happened. Switching mobile networks or putting a computer to sleep can invalidate existing connections. Retry the request first and see whether a new connection can be established. Continue troubleshooting the server only if new connections also keep failing. Don’t confuse a stale connection held by an app with its ability to establish a new one.
Check for multiple client instances running at once, and whether security software is blocking the core process or listening port. If one server is persistently unstable, keep its original configuration and compare it with other entries in the same group; don’t overwrite settings across all servers. For differences between Xray and V2Fly, see the core selection notes. Switch cores only after checking protocol compatibility.
3. Subscription update fails or the server list is empty
Subscription updates have two stages: fetching the content, then parsing it and adding entries to a group. First determine whether the request failed to retrieve content or the client couldn’t recognize the content it received. An empty list may also mean the current filters are hiding servers. Don’t keep changing the URL, group, and filters on the original subscription; save the current settings and check them one at a time.
Check the subscription URL and current network
Open the subscription group settings in v2rayN. Make sure the URL wasn’t truncated and doesn’t contain extra spaces or line breaks, and confirm the group is enabled. A subscription URL usually contains access credentials, so treat it as private. Don’t post the full URL in public screenshots or support requests. When contacting your provider, share the error category, time, and client—not the complete link.
When an update fails, first confirm the device can reach a regular website. Then check the update method configured for the subscription group and whether the request needs an existing proxy. On a first import, there may be no working server yet; if subscription retrieval is set to require that proxy, you can end up in a loop where you need a server to update the subscription but need the subscription to get a server. If existing servers work but the subscription request fails, test both direct and proxied update methods and use the one that can reach the subscription URL.
Distinguish a network error from a content error
If the log reports a DNS resolution failure or connection timeout, check the domain, network connectivity, and request path. If access is denied or the response isn’t in a subscription format, ask the provider to check authorization and content type. Downloading a webpage doesn’t mean it’s an importable server list. If the URL opens a login page, information page, or error page in a browser, clicking update again won’t create usable servers.
If the log reports a parsing failure, don’t paste the returned content into the server editor. Subscriptions usually contain multiple configurations, and an individual server entry can’t represent the group, filters, or update rules. Create a temporary subscription group with only the confirmed URL to test it. If that group updates successfully, check the original group’s update method or filters. Delete the temporary group after identifying the cause so duplicate servers don’t remain.
Servers imported, but aren’t visible
Check the selected subscription group, list search box, and keyword filters. After switching groups, the list may show only that group’s servers; a filter may also hide every entry. Clear the search and filters and show all servers, then check whether the logs or update results confirm that entries were imported. Don’t assume an empty list means the subscription source is broken, especially after changing keyword filters.
If the import succeeds but the number of servers is unexpected, check whether the provider changed the content, then review deduplication, filters, and group assignment. Server names can look similar across subscriptions without the configurations being identical. For managing multiple sources, see Managing Multiple Subscription Groups in v2rayN. During troubleshooting, use as few filters as possible, then add them back one at a time once the servers are visible.
Make the update process reproducible
Record the exact result of one manual update instead of clicking repeatedly. If you trigger another update before the first finishes, the log entries may overlap and make the failure hard to identify. Check the group name, server list, and most recent specific error before and after the update. If you have multiple subscriptions, update them one at a time to find out whether one source or all sources are failing. If they all fail, check the device network and request method first.
If existing servers still work, keep them for testing; don’t delete the whole group to fix a subscription update. If the existing servers also stop working, check for a network change or system proxy status change, then return to the no-internet section and verify the entry point. Subscription updates and server connections are separate paths: a failed update doesn’t necessarily make saved servers unusable, and a working server doesn’t guarantee the subscription URL is reachable.
4. Connected, but pages or downloads are slow
First distinguish slow initial loading, slow sustained transfers, and slowness in only one app. Slow initial loading often involves DNS, connection setup, or the security handshake; sustained transfers also depend on server load, the route, and your local network. Don’t judge throughput by client latency rankings alone. And don’t change servers, DNS, and TUN at the same time, then credit the improvement to just one of them.
Set up a fair comparison
On the same device and network, and at roughly the same time, use the current server and another known-working server to visit the same type of page. Stop any large downloads first, then note whether the initial page load is slow or page resources keep loading slowly. If only one server is slow, focus on that server and its remote status. If all servers are slow, test the base network without the proxy too. Changing client settings usually won’t fix congestion on the underlying network.
Browsers cache resources, so reopening the same page may produce misleading results. Compare several common pages and look for a consistent pattern rather than trying to get an exact speed from one test. Check the client logs for repeated retries, handshake failures, or connection resets; these are more useful signs of an unstable connection than a single latency figure. Keep the original routing mode during testing so traffic takes the same outbound path.
Check whether routing is sending traffic the wrong way
If services that should connect directly are also slow, check the order, match conditions, and outbound settings in v2rayN’s routing rules. Rules are usually evaluated in order, so a broad rule near the top may capture a request before a more specific rule can match. Open the log and check which rule matched a clearly slow destination before making changes. Don’t move entire groups of rules around at random.
A brief test in global proxy mode can help compare split routing, but it doesn’t prove a routing rule is wrong: global mode may also reroute traffic that should connect directly. If some sites are slow and others aren’t, note each domain, resolution result, and outbound path. After changing a rule, retest both a destination that was slow and one that worked, so you don’t fix one case by breaking another.
Check for DNS delays and connection retries
If a page stays blank for a long time and then appears all at once, check the browser’s network information and client logs for delays at resolution or initial connection. DNS issues don’t always cause a complete failure: an unreachable address, a slow upstream response, or a mismatch between resolution and routing can all increase load times. Go to the DNS section for related checks. For how split DNS resolution works with routing, see the DNS split-routing configuration notes.
If the log shows repeated attempts to reconnect to the same remote server, follow the server timeout section and check transport settings and network stability. Don’t automatically blame DNS for delays caused by retries. If you use TUN, compare performance with TUN off and only the system proxy enabled. If the issue occurs only with TUN, check its traffic capture scope and possible conflicts with other local network tools rather than replacing every subscription.
Check app, device, and network boundaries
If only one app is slow, check whether it has its own proxy settings, is reusing an old connection, or has separate DNS or network acceleration settings. If a browser works but a download manager doesn’t, they may be using different entry points. Trace the traffic path before judging server performance. If things are briefly slow after a computer wakes from sleep, reconnect and test again on a stable network.
If several devices on the same network are slow, check router load, Wi-Fi signal, and the network provider’s status. If the same device works as soon as you switch networks, focus on the original network. If needed, make a simple comparison table covering network, client, server, destination app, routing mode, and whether TUN is enabled. It will show which variable changed and make it easier to restore the original settings.
5. DNS resolution errors, interference, or routing mismatches
DNS translates domain names into addresses that can be used for connections; routing determines which outbound path a request takes. They’re separate settings. A browser reporting that it can’t find a server, a domain that works only intermittently, or a connection that works by known address but not by domain are all reasons to check the resolution path. First identify what resolves the name, when resolution happens, and which outbound receives the result. Then consider changing upstream DNS or enabling FakeDNS.
Is it the server domain or the destination website domain?
Before connecting to a server, the client may need to resolve the server address. After the proxy connection is established, accessing a destination website may trigger another lookup. It matters which layer the failed domain belongs to: a failed server-domain lookup can prevent the server connection from starting, while a failed destination-domain lookup may affect only some websites. Note the domain type shown in the log instead of treating both as one generic DNS problem.
Use the system’s built-in lookup command to check whether the device can obtain a domain record. The example uses this site’s domain only to illustrate the command; results vary by network and over time, so don’t copy them as a fixed configuration. A successful command doesn’t mean the client uses the same resolver. The browser, operating system, client, and TUN environment may each use a different resolution path. When comparing results, note where you ran the lookup.
nslookup v2raypeizhi.comCheck DNS settings by domain and outbound path
Review the DNS and routing settings in v2rayN. Confirm whether the destination domain will connect directly or through the proxy, then check which resolution method that path uses. Direct traffic may receive an address reachable only from another network; proxy traffic may resolve locally to an unsuitable address too early. Either can make a connection fail even when the routing rules look correct. Back up the current DNS configuration before changing it, and change just one upstream or domain rule at a time.
With custom DNS settings, check rule order and the default upstream. If no specific domain rule matches, the request falls back to the default path. DoH, traditional DNS, and system resolution can be combined as needed, but each new upstream also needs a reachable network path. If the upstream is a domain name, consider how that domain itself will be resolved. For configuration examples and troubleshooting steps, see V2Ray DNS Split Routing: A Detailed Guide.
When to check FakeDNS
FakeDNS assigns a virtual address to a domain, then uses traffic sniffing to associate subsequent connections with that domain. It’s often used when you need to capture device traffic while keeping domain names available for routing rules. It isn’t a general-purpose fix to turn on whenever DNS fails. If sniffing doesn’t cover the actual traffic, or an app relies directly on the real address returned by DNS, enabling it may cause new compatibility issues.
First record the failing destination with your original settings. Then change only the FakeDNS-related setting and retest in the same app. If toggling this setting consistently changes the result, continue by checking sniffing, virtual address mapping, and routing rules. For how it works and its limitations, see How FakeDNS Works. Don’t mistake an assigned virtual address for the remote server’s real address or use it to change the server entry’s address field.
Clear caches and investigate intermittent DNS differences
After changing DNS, the browser, operating system, or app may continue using a cached result. Close and reopen the test app, then try again on the same network. If needed, use the operating system’s DNS cache clearing feature. Clearing the cache removes old answers; it won’t fix the wrong upstream or outbound route. If the issue returns, compare the actual request path instead of repeatedly clearing the cache.
If only one domain is affected, note the domain, time, network, matched routing rule, and any logs from the resolution stage. If all domains fail, check the local network and whether the DNS upstream is reachable. Don’t enable new DoH, FakeDNS, and TUN settings all at once. Record what changed, what happened, and whether you reverted it at each step to identify which layer fixed the issue.
6. System proxy is on, but apps aren’t using it
The system proxy is a set of proxy settings that the operating system makes available to apps; it doesn’t force all network traffic through a proxy. v2rayN can configure the system proxy or use TUN to capture more traffic, but they cover different traffic. First check whether the app reads the system proxy, then verify that its proxy address matches the client’s listening endpoint. Only then decide whether you need TUN.
Check that the settings were applied to the system
Check the current “System Proxy” selection in v2rayN and make sure it isn’t disabled. Restart the app you’re testing so it doesn’t keep using old proxy settings or a long-lived connection. You can cross-check the current proxy in Windows’ system proxy settings. If they show an old address or port, check whether another tool is also changing the system proxy, then reset it in v2rayN.
Some apps have their own proxy settings that may take precedence or explicitly bypass the proxy. Check the app for options such as “Use system proxy,” “Auto-detect,” or “Manual proxy” rather than assuming it follows the operating system. A browser working while a command-line tool doesn’t is a common difference in proxy handling. Troubleshoot the tool according to its own proxy mechanism instead of relying only on the system proxy toggle.
Understand the difference between system proxy, routing, and TUN
The system proxy determines which apps that follow system settings send traffic to the client. Routing determines the outbound path for requests that have already reached the client. If the log shows no requests from the target app, changing routing rules usually won’t help. First find out whether the request gets in, then where it goes. If the log does show the request and it matches the wrong outbound, check routing instead of repeatedly toggling the system proxy.
TUN is useful for traffic from apps that don’t follow the standard system proxy, but starting it may require system permissions and a virtual network interface, and can cause conflicts with other network software. First get a reproducible test working with only the system proxy enabled, then turn on TUN and compare. If the connection drops as soon as TUN starts, turn it off and check the client logs, permissions, and other virtual network adapters. Don’t run multiple tools that capture the same routes.
Understand proxy entry points by platform
For desktop use, v2rayN is the main client, but operating systems and apps vary in how they handle the system proxy. Test the same app with the setting on and off, then check whether its requests appear in the client logs. The table below suggests where to start; it doesn’t mean every app in a given environment uses the same proxy method. Check the app settings and actual logs to confirm.
| Environment | Check first | Verify next |
|---|---|---|
| Windows · v2rayN | System proxy status and app-specific proxy settings | Check whether the app’s requests appear in the client logs |
| macOS · v2rayN | Proxy settings for the current network service | Switch networks and check the settings again |
| Linux · v2rayN | Desktop environment and each app’s proxy options | Check whether the app reads the relevant setting |
| Android · v2rayNG / v2flyNG | Connection status and VPN permission | Check whether requests from a foreground test app resume |
Remove stale settings and retest
After an unexpected client exit, the operating system may still have proxy settings pointing to a local proxy port. Apps then send traffic to an endpoint that is no longer listening, so websites may stop loading even after the client closes. Restart v2rayN and turn off the system proxy properly, or check and clear the stale proxy settings in the operating system. Then confirm direct access works again. Don’t delete the configuration directory while an unknown proxy address may still be active.
If the issue returns after switching networks, resuming from sleep, or starting another network tool, note which action changed the system proxy. Then test direct access, the system proxy, and the target app separately: does direct access work, does the client receive the request, and is the outbound path correct? These three results pinpoint the next step much more precisely than “the proxy is on, but it doesn’t work.”
7. Client won’t start, crashes, or fails to start the core
A client that won’t open and one whose interface opens but core won’t start are different problems. First identify when the failure happens: no window after launch, the window closes immediately, a crash after importing configuration, or a core error when you connect. Keep the logs and current configuration, then investigate the installation environment and configuration errors. Don’t start by deleting all user data and reinstalling.
Check the installer and runtime environment
Make sure you installed a client that matches your operating system and processor architecture. For desktop use, start with v2rayN. Windows users can distinguish the desktop and classic WPF versions in the Windows section of the Download Center; macOS and Linux users should select the appropriate platform. Put the app somewhere with normal read and write permissions. Don’t run it from a restricted or read-only location, or open the file before the download finishes.
If the startup problem began after an update, note what changed, the installation method, and the error message. Check whether an older process is still running; multiple instances can conflict over listening ports. End any unresponsive old instance in the system task manager, then try launching the client once. Before reinstalling, save your subscription groups and custom settings so a startup issue doesn’t turn into lost configuration.
Interface opens, but the core reports an error
Open the v2rayN logs and look for the first specific configuration parsing, port listening, or core startup error. If a port is in use, find out whether another client instance or local app has claimed the endpoint. If configuration parsing failed, review the server fields, routing, or DNS settings you edited most recently. Don’t copy only “startup failed” from the end of the log; it’s usually a consequence of the earlier, specific error.
Temporarily select an unedited server and disable recently added custom rules, then test again. If the client starts, restore the original settings one at a time to find the cause. When using different cores, confirm that the selected protocol and parameters are supported; Xray and V2Fly don’t support exactly the same features. For details, see Xray vs. V2Fly: Core Differences.
Rule out permissions, security software, and configuration corruption
If the log shows a file read or write failure, check permissions for the app and configuration directories, as well as available disk space. If security software reports a block, check which file or action it flagged and when, then determine whether it matches the startup failure. Don’t disable system protection long-term just to troubleshoot. Before moving the installation, back up your subscriptions and custom settings, then reinstall using the correct package for your platform.
If the program exits only when loading the existing configuration, back it up in full and test whether the interface opens with a clean configuration. If it does, the issue is more likely in the original configuration or a referenced file. If it still won’t open, focus on the installation environment and system logs. Don’t publicly upload a complete configuration file containing subscription URLs; share only error details with sensitive fields removed.
Use a repeatable recovery sequence
First make sure the interface opens reliably, then confirm the core starts. Next, import one server configuration you can verify, and finally restore subscriptions, routing, and custom DNS settings. Start the client and check the logs after each step to find what brings the issue back. Restoring all old settings at once may reproduce the failure, but won’t tell you what caused it; the order of recovery is part of the diagnosis.
After resolving the issue, check that the system proxy still points to the running client and that it turns off correctly when the client exits. Crashes and stale proxy settings often occur together, but need separate fixes: check the program and configuration for crashes, and the operating system’s proxy status for leftover settings. For common installation questions, see the Help Center. To start from scratch, follow the main guide.
8. Android connections, background operation, and per-app routing
On Android, start with v2rayNG. If you need a client built around the V2Fly core, choose v2flyNG. For either one, use the device architecture to choose an installer in the Android section of the Download Center. Desktop troubleshooting for “Set system proxy” doesn’t apply directly to phones: Android clients mainly use system VPN permission to route device traffic, and are also affected by background restrictions and per-app routing settings.
Tapped Connect? Check VPN permission first
Select a server in the client and start the connection. Watch for the system’s VPN connection request. You may need to approve it again after first use, reinstalling, or a permission change. If the client says it’s connecting but the system never shows a stable VPN connection, make sure the permission flow completed and that another VPN service isn’t already using the connection. Don’t rapidly switch between two similar services; stop one before testing the other.
If the system shows a connection but no apps can access the internet, open the client logs and check the server address, port, and transport settings. Compare with another known-working server. When switching from Wi-Fi to mobile data, an existing connection may drop; reconnect and check whether access returns. If the same configuration fails only on one network, record that network’s conditions instead of deleting every server on the phone.
Only some apps can’t connect
Check the client’s per-app proxy or bypass settings and make sure the affected app isn’t excluded. Then determine whether it fails only in the background or also while open. A failure in the foreground points first to routing or the app’s network settings; a background-only failure also warrants checking system background restrictions. Some apps keep connections opened before the proxy changed, so fully close and reopen the app before comparing again.
If a browser works but another app doesn’t, don’t assume the server is down. Keep the same server and network, test both apps, and check whether their requests appear in the client logs. If there’s no request, check per-app routing, VPN capture, and system permissions. If the request appears but uses a different outbound, check routing. Apps may also resolve domain names differently; compare their behavior with the DNS section on this page if needed.
Disconnects when the screen locks or the app goes into the background
Android may restrict background activity or network connections to save power. First check whether the client stays connected in the foreground, then lock the screen for a while and test again. If the issue occurs only in the background, review battery management, background activity, and notification permissions for the client. Menu names vary by device, so use the settings shown on your device rather than copying another manufacturer’s steps.
Even with background activity allowed, a switch between Wi-Fi and mobile data may require a new connection. When a disconnection occurs, note whether the network changed, battery saver was on, and whether the client still showed as running. Change one system setting at a time and retest instead of disabling several unrelated restrictions. Once it’s stable, make sure battery usage still works for your needs.
Subscription and configuration differences between the two clients
For Android subscription failures, first distinguish a fetch failure from a parsing failure or a filtered list. When copying the subscription URL, don’t include spaces or line breaks, and never show the full URL in a public screenshot. If a v2rayNG configuration depends on features supported by a particular core, don’t assume it will behave identically after import into v2flyNG. Check compatibility against the actual protocol parameters and client logs.
When troubleshooting is complete, check the selected server, VPN status, per-app routing, background permissions, and current network, and note the final settings one by one. If desktop and phone results differ with the same subscription, compare their networks and core capabilities before changing the subscription source. To compare the platforms and use cases for all three clients, see Client Comparison. For the basic import steps, start with the guide.