V2Ray FAQ
Configuration & Connection Troubleshooting

Start by narrowing down your options by device: use v2rayN on Windows, macOS, and Linux desktops. On Android, v2rayNG with the Xray core is the usual starting point; consider v2flyNG if you need the V2Fly core. Features can vary by version and core, so a client's name alone doesn't tell you which protocols it supports. If you already have a configuration, check the provider's required protocol, transport, and security settings, then confirm the client supports that combination. Switching clients should not be the first step for every connection problem.

The client provides the user interface, configuration management, and proxy controls. The core handles connections, routing, and protocols according to the configuration. A node is a set of remote connection parameters; a subscription URL retrieves or updates those parameters. Installing a client does not give you a working node, and a client that opens successfully does not mean the core or remote connection is working. When troubleshooting, identify whether the problem is with the interface, core startup, subscription retrieval, or node connection. Subscription URLs may contain access credentials, so keep them private and never share them in screenshots or public forums.

No. VMess, VLESS, and Trojan are different proxy protocols. REALITY is a security layer, not a standalone node protocol alongside them. A connection works only when the client and server agree on the protocol, transport, security layer, and relevant settings. Simply changing a protocol name or toggling an option usually won't produce a working configuration. Import the complete link from your configuration provider whenever possible. Before editing a configuration manually, make a backup and check applicable fields such as the port, user ID, server name, and public key.

A system proxy registers a proxy address with the operating system and mainly affects apps that honor that setting. TUN uses a virtual network interface to capture traffic matching its routing rules, giving it broader coverage but making it more dependent on permissions, routing, and DNS. If you're new to this, leave TUN off and use the system proxy to test a configuration first; then address apps that ignore system proxy settings. TUN does not improve connection quality or guarantee that all traffic will be captured. When switching modes, change one setting at a time and avoid running multiple VPNs, virtual adapters, or proxy tools that may compete to control network traffic.

If your device supports 64-bit ARM apps, choose arm64. If you're unsure of its architecture, choose the universal package, which includes components for multiple architectures. Universal packages are usually larger, but that won't make your connection faster. Don't rely on the device's purchase date: some processors support 64-bit apps while the operating system still runs in a 32-bit environment. If you see an incompatibility warning, check the system requirements, device architecture, and package source. If you see a signature conflict, back up your configuration and check whether the installed app came from the same distribution channel.

First, distinguish a subscription URL from a link for a single node. Add subscription URLs to a subscription group; import individual links through the appropriate option, such as importing from the clipboard. Check for leading or trailing spaces, line breaks, or truncation, and make sure you copied the actual URL rather than a page title or login page. You may need to update the group before its nodes appear. If the content downloads but won't parse, the format may be unsupported or the response may be an error page; ask the provider which client and output format to use. Never paste a full subscription URL into an unfamiliar conversion website to troubleshoot it.

Note the error message, then check the system, processor architecture, and package type against the app's requirements. Extract archives completely to a writable folder instead of launching the app from within an archive; install packages by following the prompts. Windows desktop and WPF editions use different UI technologies, so check the relevant release notes for runtime requirements rather than assuming every startup error means the same runtime is missing. If the app used to work, close any lingering processes and back up your configuration. Then try a fresh configuration in a separate folder to determine whether the issue is with the app or the old configuration.

On desktop, check the logs to identify the exact failure, then grant administrator or network-extension permissions as required by your system and client. Don't leave system security protections disabled. On Android, confirm system VPN permission is granted; another app using the VPN service usually can't run at the same time. If TUN worked before, check whether another VPN, virtual adapter tool, or security app has changed the network environment. Close other traffic-capturing apps and restart the client. If it still fails, switch back to the system proxy to test the node and avoid mistaking a permissions issue for a server problem.

Subscription retrieval and node connections use separate request paths, so working old nodes don't mean the subscription URL is reachable. Keep your existing configuration, check that the URL hasn't expired and its credentials haven't been revoked, then review the update log for timeouts, access denials, or parsing errors. If the client offers both proxied and direct updates, try each with a working node available; the options may have different names in different versions. If the response is a login page or access-denied message, ask the provider to check your access. Don't repeatedly delete the group or run updates back to back.

For everyday use, start with routing rules so different destinations can be sent direct, through the proxy, or blocked as needed. Global mode is useful for temporary comparisons, but its meaning depends on the client's configuration; it doesn't mean all app traffic is going through the client. Traffic coverage still depends on the system proxy, app-level proxy settings, or TUN. After switching modes, make a new request and, if needed, close existing app connections, which may keep using their original route. If only rule mode fails, check the matching rules and DNS results before changing nodes.

No. A TCP connectivity test usually only confirms that a connection can be made to a specific address and port. Request-based tests also depend on the test destination, TLS, DNS, and server policies. A failed test alone doesn't prove a node is unusable, and a successful response doesn't mean every site and app will work. Test a few destinations you actually use and check the logs to see where failures occur. Bulk tests can generate extra traffic or trigger service limits, so reduce concurrency and compare results under the same conditions instead of chasing a single number.

Use the client's export or backup feature, and note the current core, proxy mode, listening port, and custom rules. If you need to copy the configuration folder, exit the client normally first to avoid copying files that haven't finished saving. Backups may contain node credentials and subscription URLs, so store them securely and remove sensitive fields before sharing logs or configurations. Change one type of setting at a time, then test the same destination and record the result. When restoring, make sure the client version supports the configuration format. Don't overwrite the GUI client's management database with an arbitrary core JSON file.

Turn off the proxy first and confirm your basic internet connection works. Then check the system time, node address and port, and whether the current network requires web-based sign-in. Review the logs: for DNS resolution failures, start with DNS; for connection timeouts, check the destination address, port, and network path; for handshake failures, verify the protocol, security layer, and identity fields. Testing the same node on another authorized network, or a known-working configuration on your current network, can help narrow down the cause. Don't change DNS, routing, and protocol settings all at once; repeated changes can mix the original issue with new ones.

Connected may only mean the core has started or the system VPN tunnel is established; it doesn't mean remote requests are succeeding. Visit a known test destination in your browser and check whether the client logs the corresponding connection. If there's no log entry, check whether the app is using the proxy. If there is an entry but DNS resolution fails, check DNS. For certificate or handshake errors, verify the system time and security settings. Temporarily try another routing mode to see whether a rule is misrouting traffic. If the internet still doesn't work with the proxy off, restore the basic network connection, close other traffic-capturing apps, and check for leftover proxy settings.

Not every app reads the operating system's proxy settings. Some use their own proxy options, some only read the settings at startup, and some types of traffic don't work with a standard HTTP proxy. First, confirm the client has actually set the system proxy and check the listening address and port. Then fully quit and reopen the app. If it supports manual proxy settings, enter the protocol and port provided by the client; don't mix up HTTP and SOCKS. If you need broader traffic coverage, consider TUN and check the app exclusion list and routing rules. The system proxy toggle alone doesn't show which route an app's traffic is taking.

First, determine whether the issue affects one domain, a type of app, or all connections. Note the DNS results and matched outbound in the logs. Apps, the operating system, and the core may all take part in DNS resolution. If your browser's encrypted DNS is enabled, requests may bypass the core's expected DNS path. Check each setting in turn: whether the DNS server is reachable, how DNS requests are routed, whether routing rules match domains or IPs, and whether there's a stale cache. After making a change, establish a new connection before testing again. FakeDNS, IPv6, and domain resolution policies can interact, so don't enable every advanced option to fix a single domain.