V2Ray FAQ

First, distinguish a subscription URL from an individual share link. Add a subscription URL to a subscription group; import a single share link through the appropriate option, such as importing from the clipboard. Remove leading or trailing spaces, line breaks, and any notes added by a messaging app, but keep the full query string. Then update the group and check the logs to see whether the request failed, the content could not be parsed, or filtering removed all results. Repeated imports won’t help if the response is a login page, an information page, or an unsupported format—ask the subscription provider to confirm the format. Don’t post a full subscription URL in a public forum; its parameters may contain access credentials.

Check whether the subscription URL has expired, the account is still active, and your system date, time, and time zone are correct. Then check the specific log error: DNS resolution, connection timeout, TLS certificate verification, and content parsing are different issues. If your client version supports updating subscriptions through a proxy, test that option against an existing working connection; don’t rely on it if you have no working connection. For certificate errors, check the system trust store or contact the provider—don’t hide the problem by disabling certificate verification. Once the network is working again, run a manual update to confirm, then set a sensible automatic update interval instead of making repeated requests.

Make sure the core is running, then check that the system proxy address and port point to the client’s current listening endpoint. For local use, this is usually a loopback address, not the remote server address. Next, check whether browser extensions, in-app proxy settings, or environment variables override the system settings. Some apps don’t follow the system proxy at all and need to be configured individually. Check the client connection logs while browsing: if there’s no entry, investigate how traffic reaches the client; if there is an entry but the direct outbound is used, check routing. Avoid running multiple programs that change system proxy settings, and clear the system proxy when closing the client if needed.

First confirm that your configuration works in regular proxy mode, then troubleshoot TUN permissions. Desktop systems may require administrator privileges, a virtual network interface component, or approval for a system network extension; follow the prompt for your client version. On Android, allow the VPN connection in the system dialog. Check whether another VPN is already capturing traffic and whether security software is blocking the component. If it still fails after authorization, inspect the first startup error instead of repeatedly toggling the switch. Be careful when changing routes on a remote device. If you lose connectivity, turn off TUN and restore the original network before checking automatic routing and DNS settings one at a time.

First confirm that your local network can reach services that are allowed to connect directly, then check the server address, port, protocol, and security settings. A DNS resolution failure in the logs is different from a connection timeout, so check DNS and network reachability separately. Without changing your configuration, try another network or compare with a known working configuration to narrow down the cause. Some connectivity tests rely on a specific test address, so a failed test alone doesn’t prove the server is unavailable. If only one configuration keeps failing, ask the provider to check the remote server. If all configurations fail, start with your local firewall, network, and core startup logs.

“Connected” usually means the client or VPN interface has started; it doesn’t mean requests are reaching their destinations. Check whether a connection appears in the logs when you open a website, then inspect the outbound and error type. No log entry? Check system proxy or TUN traffic capture. A logged DNS resolution failure points to DNS; a handshake error calls for checking the protocol, security settings, and system time. If only some sites fail, check routing rules, the destination service, and the app’s own proxy settings. To narrow down the issue, turn off TUN and test the same destination with the system proxy, leaving everything else unchanged. Once the basic connection works, restore your original traffic capture method.

Check that you selected the right subscription group and that the search box, server filters, or display filters aren’t hiding the results. A successful update may only mean the URL request completed; the response might not contain any recognizable servers. Look in the logs for parsing failures, unsupported formats, or messages that no valid entries were found, then ask the provider to confirm the subscription format and account status. Don’t delete all groups just to try importing again. Keep your existing configuration and test one group first. If you’ve changed a filter expression, clear the filters temporarily and update again. Once the issue is resolved, restore filters one at a time to identify which one excluded the servers.

First determine whether the system is stopping the app, the connection drops when the network changes, or the client is under sustained heavy load. If the app is stopped in the background, use your device’s system settings to allow background activity and adjust battery optimization if needed. If battery use has increased, check which apps are continuously using the network, whether detailed logging is enabled, and whether routing sends unnecessary traffic through the proxy. Use per-app proxy settings to limit traffic capture if needed. Don’t automatically disable every battery restriction; change settings one at a time and monitor the results. When you’re done, disconnect in the client and check the system VPN status. If the problem persists, record redacted logs and the steps to reproduce it for further troubleshooting.