V2Ray FAQ
and Troubleshooting

Choose a graphical client for your device first, then learn about its core. V2Ray usually refers to a core project in the Project V proxy ecosystem. V2Fly is its community continuation, while Xray is a related core project. v2rayN is a desktop client for Windows, macOS, and Linux that manages configurations, launches the core, and sets up proxies. v2rayNG is an Android client that uses the Xray core. The client interface and the core are separate layers: launching the interface does not mean the core is running. When troubleshooting, check separately that the configuration was imported, the core started, and app traffic is reaching the proxy.

Yes. Get a server configuration or subscription link you are authorized to use, then import it into the client. A client manages configurations and forwards traffic; it does not include a remote service you can connect to. A subscription usually groups multiple server configurations at one URL, which the client turns into entries when updated. A single share link usually describes one configuration. Do not use a provider's login page as a subscription or post subscription links in public forums. Subscriptions may contain access credentials, so redact links, user IDs, and authentication details from screenshots, logs, and support requests.

First identify how traffic reaches the client, then determine which outbound route it takes. A system proxy registers a proxy address with the operating system and works only for apps that follow that setting. Global routing usually sends traffic that has already reached the core through a proxy outbound; it does not take over every app on the device. TUN receives traffic within its capture scope through a virtual network interface, making it useful for apps that ignore system proxy settings, but it involves permissions, routing, and DNS. For a first setup, verify the connection with the system proxy, then test TUN if needed. Avoid changing the traffic entry method and routing rules at the same time.

Reproduce the issue with the website or app you actually use, then compare servers. A latency test measures response time for a particular probe and target; it does not measure sustained bandwidth or prove that every website will work. Page loads are also affected by DNS, packet loss, the remote exit, the destination service, and your local network. Keep the network, routing mode, and test target the same, and change only one server at a time. If small pages load normally but large files are slow, check bandwidth and packet loss. If only one site has problems, check the routing result for its domain and the destination service.

Check the device processor and the app architectures supported by its operating system. Most newer Android phones can use arm64, which usually has a smaller download size. If you are unsure which architecture your device supports, choose universal; it includes files for multiple architectures and is therefore larger. A 64-bit processor does not necessarily mean the operating system can install 64-bit apps, especially on older devices. If the package is incompatible, check the architecture, OS version, and available storage before trying another package. When updating an existing client, make sure the package name and signing key match. Back up any exportable configurations before uninstalling and reinstalling.

On Windows, start with the desktop version if your system meets the requirements on the download page. Its cross-platform interface offers a consistent desktop workflow. If you prefer the classic interface, choose the WPF version and make sure its required runtime is installed. Menus and setting names may differ, so do not assume a feature is missing just because an older guide shows a different screen. Before upgrading or switching versions, close the running client, back up your configuration, and test in a separate folder to avoid two instances competing for a local port. On macOS and Linux, choose the desktop package for your platform.

Make sure you copied the complete subscription URL, remove leading or trailing spaces and line breaks, and check whether the link has expired, been reset, or needs authorization again. Then confirm that the client supports the subscription format. A downloaded login page, error page, or configuration intended for another client usually will not produce any server entries. If the update URL can only be reached through an existing proxy, select a working configuration and try updating through the proxy. Keep the original group and import into a new test group to avoid overwriting working configurations. Check the error type in the logs, and redact the full subscription URL before sharing them.

Turn off TUN first and confirm that the regular system proxy works. Then address permissions separately. On Windows, install or start the required service as prompted by the client, using administrator privileges if necessary. On macOS and Linux, follow the instructions for your version to grant system authorization or configure a privileged service; do not reuse commands intended for another platform. Android clients use the system VPN permission prompt, which you must approve the first time you connect. Existing VPNs or other virtual networking tools may conflict, so quit them and test again. After resolving permissions, re-enable TUN and check the logs for interface and route creation, rather than relying only on the toggle.

Select a working server and enable automatic system proxy configuration. Then check that the proxy address and port in system settings match the client's listening address and port. Open a test page in a browser that follows system proxy settings while checking the client logs or connection list for the corresponding request. For a more direct test, configure a command-line tool to use the local proxy port and compare the result with a request made without the proxy; the two tests use different traffic entry points. Browser extensions, built-in proxy settings, and cached data can affect the result. A changed exit IP is only supporting evidence; also check the request log and routing result.

Start with the default routing rules to establish a reliable baseline. Confirm that your usual websites, local network devices, and work apps are accessible. Rule-based routing selects direct or proxy connections by domain, address, and rule order, making it suitable for everyday mixed use. Global routing is more useful as a short-term test to see whether a problem is caused by routing rules. If global routing works but rule-based routing does not, check which rule matches the destination domain, the DNS result, and whether the rule resources are available instead of relying on global routing to hide the issue. Restore your original settings after testing, and make sure internal services are not mistakenly sent through a remote exit, which could disrupt printing, file sharing, or corporate network access.

Create a separate group for each subscription source and give each group an easy-to-recognize name. Do not import the same subscription into multiple locations. Before updating, note the entry you currently use and its key settings. After the update, confirm that the selected entry still works, since the provider may remove, rename, or change configurations. Keep manually added configurations in a separate group so subscription updates do not replace them. Periodically remove obsolete groups, but avoid repeatedly resetting all configurations. For automatic updates, make sure the update URL is reachable on your current network. If something goes wrong, check the update time and logs before deciding whether to import the subscription again.

Back up your current settings and note the active core and a configuration known to work. Then check whether the target core supports that configuration's protocol, transport, and security parameters. The presence of a core switch in the client does not mean every configuration works unchanged across cores. Pay particular attention to extension fields, DNS settings, and differences in TUN implementation. After switching, test with simple routing and one server. Restore custom rules only after confirming the connection works. If you see unknown fields or startup failures, switch back to the original core and compare the logs instead of repeatedly deleting parameters. Test client and core updates separately so you can identify what caused any change.

Check four layers: local device, subscription, server, and system. First, confirm the device clock is correct, the network works, and the local port is listening after the core starts. Then update the subscription to rule out an outdated address, expired credentials, or an incomplete import. Next, verify the server address, port, transport, and security settings, and compare them with another known-working configuration on the same network. Finally, check for conflicts with the firewall, other proxy tools, or virtual networks. One timeout does not prove the remote server is down; keep the target and conditions consistent when repeating a test. Note when the error first appeared and its type in the logs; this is more useful than repeatedly reinstalling the client.

Check the core logs first to confirm that the remote connection succeeded, rather than just a local proxy or VPN interface being active. Then check whether browser requests are reaching the client. If there are no requests, verify the system proxy, browser-specific settings, and local port. If requests appear but fail, check routing, DNS, and server availability. If only domain names fail, look for DNS resolution errors. If the local network and all websites fail at once, disable TUN and test again for a routing conflict. Keep just one proxy entry point and one client running while troubleshooting. Rule out other tools, and do not change DNS, ports, and routing mode simultaneously.

Keep the existing configurations; do not clear the list. A working server confirms that the proxy connection works, but it does not prove that the subscription URL is still valid. Check whether the subscription was reset, expired, or rate-limited, and look for device clock or certificate errors. If updating directly fails, select a working server and try updating through the proxy. If that fails, compare with a direct update to avoid making the update request dependent on the proxy. If the server returns a login page or has changed formats, get a compatible link again. Do not refresh repeatedly in a short period. Note the status code and a summary of the error, and remove authentication details before contacting the subscription provider.

If a port is in use, first check whether a second client instance is running. Then use your system's network tools to identify the process using the listening port. Once you confirm what it is, close the conflicting app or choose an unused port in the client settings. Also update the proxy settings in any browser or app configured manually. Do not terminate an unfamiliar system process. If direct access still fails after quitting the client, turn off any leftover manual proxy or automatic configuration URL in system proxy settings, then check whether TUN or another VPN is still running. Once network access is restored, start one client and test again. In future, clear the system proxy before exiting normally.