V2Ray FAQ
Subscriptions, proxy & connection troubleshooting

V2Ray is part of the Project V proxy ecosystem. V2Fly maintains a related core, while Xray is a separate development branch. The core handles connections, protocol processing, and routing; v2rayN provides a graphical interface for subscriptions, nodes, and settings. When troubleshooting, first distinguish a failed interface operation from a core startup failure: check the imported content and on-screen messages for the former, and the client logs for the latter. Whether a configuration works depends on the current core and the features supported by its version. Don’t rely on the client’s name alone, and don’t overwrite its configuration files with files intended for another core.

For Windows, macOS, and Linux desktops, start with v2rayN. For Android, v2rayNG with the Xray core is the usual choice; consider v2flyNG if you specifically need the V2Fly core. The three clients differ in menus, core capabilities, and configuration formats, and setting names may change between versions. Check your operating system and processor architecture, then confirm that your subscription’s protocol is supported. When switching clients, reimport the original subscription rather than copying the entire program folder. If you use custom routing, make a separate note of your rules and local ports.

A client manages configurations and connections; it doesn’t provide a server to connect to. A subscription URL retrieves a list of nodes, while an individual node link contains the address, port, protocol, and authentication parameters for one connection. Get configuration from a service you’re authorized to use or from your own server, then import it into the client. Subscription URLs often contain account identifiers, so anyone who can access one may be able to retrieve your configuration. Don’t post it in public comments, screenshots, or online conversion tools. If a subscription stops working, check the service’s notices and your account status before reinstalling the client.

The system proxy directs requests from apps that honor system settings to a local proxy. Routing rules determine whether traffic entering the core is proxied, sent directly, or blocked. TUN uses a virtual network interface to capture eligible network traffic. These features work at different stages: enabling the system proxy doesn’t send every app through the proxy, and enabling TUN doesn’t mean all traffic will use a remote node. For browser traffic, start with the system proxy. Consider TUN only when you need to capture traffic from apps that ignore proxy settings, and check permissions, DNS, and routing as well.

Most recent Android phones can start with the arm64 package, but choose based on the app architectures supported by your device. A 64-bit processor doesn’t necessarily mean the system can install 64-bit apps. The universal package includes multiple architectures and is usually larger, making it a good option when you’re unsure. If you see an “App not installed” message, check system requirements, available storage, and whether the installed app has the same signing key before investigating architecture. Don’t uninstall your current client just to test packages. Export essential settings first and keep your subscription details safe to avoid losing groups and rules.

First identify what you copied: a subscription URL, a single node link, or an account management page. Add a subscription URL in the address field for a subscription group, save it, then update the group. Import a single link using the appropriate option, such as clipboard import. Remove leading or trailing spaces, line breaks, and punctuation added by chat apps, and make sure the URL wasn’t truncated. If the list is still empty after updating, check the logs for an unsupported format, authentication failure, or a response containing webpage content. Don’t convert a private subscription with public tools. Confirm the compatible format with your configuration provider before trying again.

TUN creates a virtual network interface and adjusts routing, so it usually needs additional system permissions. On Windows, fully exit v2rayN, then follow the instructions for your version to launch it as an administrator and enable TUN. On macOS and Linux, follow the client’s prompts to install the service or grant permissions. If it still fails, check the logs for interface creation, driver loading, or permission errors, and look for conflicts with other virtual adapters or proxy tools. Don’t leave security software disabled to suppress an error or run privilege-escalation commands from unknown sources. Once resolved, test with only one traffic-capture mode enabled.

On macOS, check About This Mac: choose arm64 for Apple Silicon and x64 for Intel, and use a package that matches your architecture. On Linux, match both the architecture and package management system. Debian- and Ubuntu-based distributions typically use deb packages; distributions such as Fedora that use RPM typically use rpm packages. ARM64 devices also need the corresponding arm64 package. The same package format doesn’t guarantee that every distribution has the required runtime dependencies, so read your package manager’s prompts before installing. If dependencies are missing, install them using your distribution’s recommended method rather than forcing an installation that ignores them.

Create a separate subscription group for each source and give each group a recognizable name. Then update the intended group. Check that the currently selected node is still available afterward; subscriptions may change node names, regions, or list order, so your previous selection may no longer be suitable. Select one node manually and test connectivity before restoring automatic selection or other rules. Don’t rely on a node’s position in the list to remember a frequently used route, and don’t put self-hosted nodes in a subscription group that updates may overwrite. Manage custom entries in a separate manual group.

First check whether you’re changing the system proxy mode or the core’s routing rules. Bypass mainland China rules typically use domains, IP addresses, or other criteria to send some traffic directly. Global proxy rules send more requests that enter the core through the proxy, but still don’t capture traffic from every app. After changing a setting, retry a destination that previously failed and check its outbound route in the access logs. If only one domain is routed incorrectly, check the match order for that domain and its dependencies instead of switching permanently to global proxy. Back up custom rules before editing them so you don’t overwrite existing direct-connection requirements.

A latency test measures round-trip or handshake performance under specific conditions; it doesn’t directly measure sustained throughput. Actual download speeds also depend on the destination server, node egress, congestion, service limits, and your local Wi-Fi. Use the same download target and time window to compare direct and proxied connections, then test a small number of candidate nodes from the same subscription. Pause background sync and check for data caps or usage multipliers. Don’t run large-scale speed tests across every node at once: they consume bandwidth and may trigger server-side limits, making results harder to compare.

Record your subscription groups, manual nodes, custom routing, DNS, local listening ports, and traffic-capture mode. Then use the client’s supported export or backup feature to save your configuration. Backups may contain authentication details and private subscription URLs, so store them securely and redact those details before sharing logs. After upgrading, test one node and one commonly used rule before restoring more complex settings. When moving between platforms or clients, reimport the original subscription and recreate only the rules you need. Configuration folders and core formats may differ, so copying an entire folder can cause conflicts with old settings.

First confirm the subscription URL is complete, your account is active, and the service hasn’t reported an outage. Then check the update log for the specific error. For authentication failures or access denials, ask your configuration provider whether the URL has been reset. For timeouts or DNS lookup failures, check your local network and DNS. If the client offers options to update through or without a proxy, choose based on your current network. Make sure the node used for a proxied update is working so a dead node doesn’t block the update. Don’t retry rapidly. Note the error and time before investigating, and never share the full subscription URL when asking for help.

First confirm that your local network can reach ordinary websites, then check whether the client core started successfully. Test just one node with a known-complete configuration and verify its address, port, transport, and security parameters against the provider’s requirements. If every node in the same group times out, retest on another network you’re authorized to use. If only one node fails, check the status of that route first. If logs point to a TLS handshake or certificate issue, check the system clock and server name rather than assuming the port is unreachable. A timeout only means that a particular test failed; use actual request logs to help diagnose the cause.

A connected status or running core only confirms that part of the startup process completed; it doesn’t mean requests to websites are succeeding. First check whether browser requests appear in the client’s access logs. If there’s no entry, check the system proxy, local listening port, and the app’s own proxy settings. If there is an entry but the request fails, check the selected node, routing outbound, and DNS. Temporarily disable other proxy tools and repeat the test, comparing DNS lookup errors with connection errors. Change one setting at a time and note its original value. If only one site fails, check the site’s status, browser extensions, and related domains.

In your system network settings, first confirm that the proxy address and port match the client’s current listening address and port. Then check the client logs to see whether requests from the app arrive. Some apps ignore system proxy settings, while browser settings or extensions can override them. Test with a browser that follows the system proxy, and fully quit and reopen the app if needed. If you use another proxy or VPN tool, disable its traffic-capture feature to prevent settings from being repeatedly changed. If you need to capture traffic from an app that doesn’t support system proxy settings, consider TUN and check routing and DNS. Don’t expose the listening address publicly to fix a local connection issue.