V2Ray FAQ
Subscription & Connection Troubleshooting

Start by distinguishing the core from the interface. V2Ray is part of the Project V ecosystem. V2Fly and Xray are related core families that handle protocols, routing, and network connections. v2rayN is a desktop GUI client, while v2rayNG is an Android GUI client; both import configurations and manage connections. v2flyNG is another Android option that uses the V2Fly core. Installing a client does not provide server configurations. You still need to import a subscription or share link you are authorized to use, then connect as instructed by your service provider.

Check what the content is for rather than judging by how the link looks. An installer installs the client; a server share link describes one server configuration; a subscription URL retrieves and updates a set of server configurations. Pasting a subscription URL into a single-server import field may result in an unrecognized format. Using a website login URL as a subscription URL may return only a web page. Get a subscription link that works with your client from your service provider, then add it in the subscription group settings. Subscription URLs may contain access credentials—don’t post them publicly or submit them to unfamiliar conversion services.

Start by identifying where traffic is handled. The system proxy setting directs apps that honor it to the client’s local listening port. Routing rules determine whether requests that reach the core are sent direct, proxied, or blocked. TUN uses a virtual network interface to capture matching traffic. Enabling the system proxy doesn’t mean every app will use it; enabling TUN doesn’t mean every destination will be proxied, since core routing rules still apply. To troubleshoot, turn off TUN first and confirm that the regular system proxy works. Then test TUN separately to avoid changing multiple layers at once.

First, make sure you have a valid configuration. A client manages connections; installing it does not automatically give you access to a working server. A latency test is only the result of a particular test method on the network at that moment—it doesn’t guarantee that browsing, downloads, or video will work. A TCP test mainly checks whether a port is reachable, while a real connection test also involves a protocol handshake and a test destination. If the latency looks fine but websites won’t load, check the service validity period, device clock, DNS, and routing. Don’t switch cores repeatedly based on one latency reading; compare results using the same configuration.

Check your device’s processor and system architecture first. Most newer Android phones can use the arm64 package, which is generally smaller than the universal package that includes multiple architectures. If you’re unsure of the architecture, have an older device, or run into an architecture mismatch, try universal. A 64-bit-capable processor doesn’t necessarily mean the device runs a 64-bit system, so check the device’s system information and installation results. If installation still fails, check the Android version requirements, available storage, and whether an app with the same name but a different signing key is already installed. Export your configuration before changing signing keys; don’t uninstall your only working client without a backup.

Choose your operating system first, then your processor architecture. The Windows desktop build uses a cross-platform interface, while the WPF build retains the classic Windows desktop interface. Menus and some feature locations may differ, so don’t rely on screenshots from one build when configuring the other. On macOS, check the chip under About This Mac: choose arm64 for Apple Silicon or x64 for Intel. On Linux, choose deb or rpm for your distribution, then confirm whether your device is x64 or arm64. Package format doesn’t determine architecture. If the app won’t start, check the download type and the current version’s system requirements before reinstalling.

Open the subscription group settings and make sure the URL is saved in the right group, then update that group’s subscription. Saving the URL alone may not populate the server list. Check for spaces, line breaks, or punctuation added by a messaging app, and make sure the list isn’t filtered to another group. If the response is a login page, an expiration notice, or a web error, importing it again won’t create nodes—resolve the subscription access issue first. For a single share link, use the import-from-clipboard option. If it’s still not recognized, ask the provider about the link format and client compatibility.

Turn off TUN first and check whether the regular system proxy connects, so a server issue isn’t mistaken for a permissions problem. On Windows, run the client as administrator or use its service mode as required by your version. On Linux, check the required permissions and whether the TUN device is available. On macOS, grant permissions when prompted by the system. Don’t disable your entire system security setup just to troubleshoot. If the virtual adapter still can’t be created, close other network interception tools and check the specific error in the logs. Permission handling varies by OS, installation method, and core. After fixing the issue, restart the client and confirm that routing works normally.

First, identify which network route the update request uses. If the current server is down and subscription updates go through it, the connection failure will block the update; try Update subscription (without proxy). If the subscription service can’t be reached over your direct connection, select a working server first and update through the proxy instead. If both methods fail, check the subscription’s validity period, device clock, server response, and logs rather than repeatedly recreating the group. Before setting an automatic update interval, confirm that a manual update succeeds. A shorter interval won’t fix an invalid URL and may trigger server-side rate limits.

First, check whether the app follows the system proxy settings. For apps with manual proxy settings, enter the protocol, address, and port the client is currently listening on. On the same device, the address is usually 127.0.0.1; use the local mixed listening port shown in the settings rather than assuming every version uses 10808. Terminal tools may use HTTP_PROXY, HTTPS_PROXY, or their own settings, so check those separately and restart the terminal before testing. Consider TUN only for apps that can’t be configured to use a proxy. Don’t enable LAN access just to connect apps on the same device—it broadens the listening scope.

First, confirm the request is reaching the current client, then check which routing ruleset is active. Rules are usually matched in order, so a broad rule near the top may take precedence. Domain, IP, and process rules also apply to different targets. With IPIfNonMatch, the destination IP is resolved and IP rules are checked only if no domain rule matches; it doesn’t mean every domain must be resolved first. Restart the service if needed, then close the app’s existing connections and test again. If the app uses its own proxy or bypasses the system proxy, changing only the core routing rules won’t change its actual route.

Use the client’s export or backup feature to save your subscription groups, local listening ports, routing choices, DNS settings, and custom configuration. Backups may contain sensitive information, so store them somewhere you control. Before updating, exit the client and keep the original configuration and a way to roll back; then check whether the new version can read your settings. Before switching to the Xray or sing-box core, confirm that your node protocol and custom parameters are compatible—fields may work differently across cores. Change one thing at a time. Once the connection works, re-enable features such as automatic updates and TUN.

Turn off the client proxy and confirm that your regular connection works. Then check whether the subscription has expired and whether the device clock is set to update automatically. Test the same node on your current network and another working network to see whether the issue is network-specific. Test one node at a time so batch results don’t obscure the error. Next, check the logs to distinguish DNS lookup failures, connection timeouts, refused connections, and handshake failures. A reachable port doesn’t mean the protocol settings are correct; verify the address, port, transport, and TLS settings. Don’t disable certificate verification to mask clock or certificate issues, and don’t assume one timeout means the client is broken.

Make sure a working server is selected, then set v2rayN to configure the system proxy automatically. Check that the local listening port matches the port in the system proxy settings, and temporarily disable browser proxy extensions that might override them. If the browser works but the terminal doesn’t, check the terminal’s environment variables separately. If neither works, see whether the client is receiving requests. No requests in the logs usually point to the app entry point or proxy settings; if requests appear but fail, check the node, DNS, and routing. If direct access still fails after you exit the client, reopen it, clear the system proxy, and check whether a manual proxy setting remains in the OS.

Handle each issue based on the error in the logs. If a port is already in use, check whether the client is running twice or another proxy app is active. On Windows, use netstat -ano to find the process ID using the port. Confirm what the process does before closing it—don’t terminate an unfamiliar system process. You can also change the local mixed listening port in the settings and update any manual proxy settings to match. For DNS lookup failures, first confirm that the server hostname resolves, then check whether core DNS settings and routing are creating a loop. Change only one setting at a time and keep logs from before and after each change.

Check whether the system restricts v2rayNG’s background activity or battery use. Allow the background activity it needs in your device settings, and check that connection notifications are enabled. An Android VPN connection may be taken over by another VPN app, so confirm which app currently manages the connection. After switching between Wi-Fi and mobile data, disconnect and reconnect, then check the logs for a new connection attempt. If it fails only on one network, check that network’s DNS and connectivity. Don’t clear app data as a first step; export your configuration first. If disconnections persist, note when they occur, the network type, and a redacted error message for further troubleshooting.