V2Ray FAQ
Subscriptions, Proxies & Connection Troubleshooting

Project V provides the ecosystem context for related proxy tools, while V2Fly and Xray are core projects with a shared history. The core handles protocols, routing and connections; the client manages subscriptions, the interface and system integration. v2rayN is for desktop platforms, and its supported features depend on the selected core and version. v2rayNG uses the Xray core, while v2flyNG uses the V2Fly core. When troubleshooting, note both the client and core: the client name alone is not enough to determine whether a setting is supported.

A client lets you configure and run proxy connections; installing one does not create a working server. You’ll also need a subscription URL, share link or complete server settings that you’re authorized to use. For manual setup, check the address, port, protocol and authentication details. If TLS or REALITY is involved, verify the related security settings too. Subscription URLs often contain access credentials, so treat them as sensitive. Redact the full URL, user identifiers and authentication fields from screenshots, logs and support requests.

VMess, VLESS and Trojan are proxy protocols you can select in a client. REALITY is a transport security solution used with protocols such as VLESS, not a peer option that directly replaces the other three. Client settings must match the server; changing only the protocol in a dropdown won’t work. Choose based on the parameters your server actually provides, then check whether your core supports them. VLESS encryption fields alone do not determine the security of the entire connection; consider TLS, REALITY and the other relevant settings too.

A subscription URL fetches a set of server configurations from a source and can be refreshed when that source changes. A share link usually describes a single server and does not automatically update after import. A config file may include more, such as outbounds, DNS and routing, but full import depends on the file format supported by the client. Being able to open a URL in a browser doesn’t mean its response is a compatible subscription. Web pages, login screens and error pages cannot be imported as server lists.

A system proxy provides a proxy endpoint to apps that honor the system settings; it won’t necessarily capture every program. TUN receives traffic through a virtual network interface and usually involves routing, DNS and elevated permissions. Android VPN mode uses a system-provided virtual interface to capture traffic from selected apps. A VPN indicator only confirms that the interface is up. None of these modes guarantees that every request goes through the proxy: routing rules, bypass lists and per-app settings still determine where traffic goes.

First check which import method you’re using. Import a single share link from the clipboard or the share-link option; add a subscription URL to a subscription group, then update it. Make sure the copied text doesn’t include spaces, line breaks or notes, and that you haven’t mistaken a management page for a subscription. Then check whether the error is a connection failure, an authentication failure or a parsing error—these point to network, authorization or format issues, respectively. Changing the server protocol won’t fix a subscription parsing error; they occur at different stages.

Choose based on the app ABI supported by your device, not just the processor’s marketing name. Most newer mainstream devices can use arm64. If you’re unsure of the architecture, choose the universal package, which includes multiple architectures but usually takes up more storage. Some devices have 64-bit-capable chips but only allow 32-bit apps. If installation fails, check the Android version, available storage and whether the installed app’s signing key matches the package. Avoid uninstalling first if that could erase your settings.

The Desktop version has a cross-platform interface; the classic WPF version follows the traditional Windows interface. Check the download page for your operating system and architecture before choosing. Interface differences do not directly indicate protocol performance. Menus, backup contents and config directories may differ between versions, so export your settings and note custom routing, DNS and local listening ports before migrating. If startup fails, check the runtime requirements listed for that package. Don’t mix files from different installation directories.

First confirm that the client core is running and that its local listening address and port match the system proxy settings. Then check whether the app honors the system proxy. Some command-line tools, download managers and apps with their own network settings need separate configuration; browser extensions can also override system settings. Test with an app known to follow the system proxy, then check whether routing rules send the target domain direct. Consider TUN only if you need to capture more traffic, and avoid stacking proxy entry points that could create a loop.

Check the logs to see whether the failure occurred while creating the virtual interface, requesting permissions or adding routes. On Windows, grant the permissions requested by the client. On macOS and Linux, follow the instructions for that platform rather than copying driver steps from another system. Temporarily quit other tools that use virtual network interfaces or change the default route, then test again. Don’t leave the firewall disabled to work around a permissions issue. If you only need browser proxying, try system proxy mode first to confirm the server works.

Updates usually apply to the corresponding subscription group, but replacement, retention and deduplication behavior varies by client and settings. Keep manual configs in a separate group; don’t edit subscription-generated entries and assume your changes will survive the next update. Back up important settings before updating, then check the active group, filters and default server afterward. If an entry is missing, the group or filter may have changed. Clear the filters and check again before wiping your configs and importing everything from scratch.

Use rule mode for everyday traffic to send different destinations direct, through the proxy or to a blocked outbound. Global proxy can be a short-term comparison test to see whether routing rules are causing a problem, but it may not affect app traffic that never reaches the client. If global proxy works but rule mode doesn’t, check rule order, domain matching and the final outbound before changing servers. Restore your usual mode after testing, and confirm that local network services and devices still work as expected.

First check whether the list means “proxy only selected apps” or “bypass selected apps”—the two settings work in opposite ways. Reconnect as required by the client so the updated app selection takes effect. Apps may make requests through separate components, work-profile copies or system services, so selecting only the main app may not cover every related process. Start with one target app, confirm how its traffic is routed, then expand the list. Avoid changing the app selection, DNS and server settings at the same time, so you can identify what made a difference.

Mux tries to carry multiple logical connections over fewer underlying connections, but the benefits depend on the protocol, transport, server and use case. It is not a guaranteed speed boost. Some combinations are unsupported or discouraged; follow your core’s guidance, especially for combinations involving VLESS flow control. When troubleshooting slowdowns, turn Mux off to establish a baseline, then enable it and compare the same tasks. Battery life on mobile also depends on signal strength, sustained transfers and background wakeups, not just the Mux setting.

For servers managed by the same provider, import the subscription URL on each device and update them separately. Move a single manual config with a share link or QR code, then check that its protocol and transport fields were retained. Client backups may not work across platforms, and desktop routing, DNS and listening ports don’t map automatically to Android per-app settings. Test one server first, then recreate local policies one at a time. Transfer subscriptions and backups securely; don’t upload files containing credentials to public locations.

First confirm that the device has a working internet connection, then check the server address, port, authentication details and device clock. Distinguish a TCP connectivity test from a real proxy request: an open port doesn’t prove that the protocol handshake or access to a destination will work, and a timed-out probe doesn’t necessarily mean every app is affected. Check the logs for DNS resolution errors, connection refusals or handshake failures, then verify the related settings. Compare with a known-working config while leaving other settings unchanged; don’t switch networks and several security options at once.

“Connected” may only mean that the core or virtual network interface started; it doesn’t guarantee a working remote connection. Check whether a real web request appears in the logs. If there’s no entry, check the app’s proxy settings, VPN permission and per-app scope. If there is an entry but it fails, check the selected outbound, DNS and handshake details. Test different destinations to distinguish a single-site issue from a broader failure. If only the browser is affected, check extensions, custom Secure DNS and cache. Don’t start by clearing all client data.

Fetching a subscription and connecting to a server are separate paths. Working configs don’t guarantee that the subscription source is reachable. Check whether the subscription expired or its authorization changed, and look in the logs for HTTP status errors, certificate errors or parsing failures. If the client lets you choose direct or proxied access for updates, compare the options based on your network—but avoid relying on a server that may already be unavailable. Don’t delete the existing group first. Keep working configs and backups, and update only after confirming that the source returns compatible content.

Check where the failure occurs in the logs. A failed lookup, empty result or unreachable resolver points to the DNS path; if an address is resolved but the connection is refused or the handshake fails, investigate the remote connection. Check where local and remote DNS requests are sent, and whether the client handles system DNS resolution. Browser Secure DNS may send requests independently, so include it in your checks. Don’t rely on direct IP access alone to diagnose the issue: HTTPS may still require the correct domain and certificate.

Check whether the system still points to the client’s local proxy port. If the client has exited but its proxy settings remain, apps will keep trying to connect to an endpoint that no longer exists. Use the client’s option to clear system proxy settings, or restore the previous settings in your system network preferences. If you used TUN, also check that the virtual interface, default route and DNS were restored; reconnect to the network through your operating system if needed. Note any work proxy or custom DNS settings beforehand so you don’t remove settings you still need.