V2Ray FAQ

V2Ray is part of the Project V proxy ecosystem. V2Fly continues the community maintenance of V2Ray, while Xray is a core fork that grew out of the ecosystem. The core handles protocols, routing, and traffic forwarding; v2rayN, v2rayNG, and v2flyNG provide configuration management and a graphical interface. v2rayNG uses Xray, and v2flyNG uses V2Fly. The core used by v2rayN depends on its version and configuration. To check whether a protocol is supported, verify the client version, the core actually in use, and the server settings—not just whether a similar name appears in the interface.

Installing a client only means the local app is ready to run; it does not provide a remote service to connect to. You’ll usually need to import a valid subscription or share link, or enter the server address, port, authentication, and transport settings manually. This site provides client downloads and configuration guides, but does not provide nodes or subscriptions. Check existing configurations for expiration, service status, and protocol compatibility. Don’t overwrite your current setup with a subscription from an unknown source. Create a separate group first, verify the source and purpose, then select a node and test the connection.

A system proxy provides a local proxy address to apps that honor the system proxy settings; it does not cover every app. Routing rules select an outbound after traffic reaches the core—they can’t route traffic that never entered the client. TUN uses a virtual network interface to capture eligible traffic and also involves system routes, DNS, and permissions. To troubleshoot, check in order whether traffic enters the client, whether a routing rule matches, and whether the outbound works. For an initial setup, test browser access with the system proxy first, then test TUN separately to avoid changing multiple traffic entry points at once.

For desktop use on Windows, macOS, or Linux, start with v2rayN. On Android, consider v2rayNG, which uses the Xray core; choose v2flyNG if you need the V2Fly core. Base your choice on the operating system, device architecture, and protocol requirements of your existing configuration—not on how similar the names look. On Windows, the v2rayN desktop edition uses a cross-platform interface, while the WPF edition has a classic interface, so menus may differ. Back up your configuration before switching clients, confirm the new client supports your transport and security settings, and don’t copy another app’s internal database directly.

arm64 is for devices running a 64-bit ARM system. It’s a good first choice for most Android phones released after 2015, but check which ABIs your device’s OS supports. The universal package includes native components for multiple architectures, making it a fallback if you can’t confirm your architecture; it’s usually larger. A 64-bit processor does not necessarily mean the installed OS is 64-bit. If the installer reports incompatibility, check the OS version and ABI. A signature conflict means the installed app and new package have different signing keys; choosing universal won’t fix it.

First, distinguish a subscription URL from a single-node share link. Add a subscription URL to a subscription group and update it; import a single-node link through an option such as Import from clipboard. When copying, check for leading or trailing spaces, line breaks, or missing characters, and make sure a messaging app hasn’t truncated the URL. If the list is empty, check the subscription update log and make sure the current group filter isn’t hiding new nodes. A URL that opens a login page, error page, or empty response can’t be parsed as a valid subscription. If the server uses a format your client doesn’t support, ask the provider which format to use; don’t try to fix it by repeatedly changing authentication fields in the URL.

On macOS, check your chip in About This Mac: choose arm64 for Apple silicon and x64 for Intel. On Linux, check both the processor architecture and package format. Debian- and Ubuntu-based distributions typically use deb packages; Fedora and similar distributions typically use rpm. ARM devices need the corresponding arm64 package. If the app won’t launch after installation, first review any system warnings about dependencies, permissions, or compatibility instead of switching nodes. If the app opens but the core won’t start, check the logs, runtime libraries, and file permissions. Don’t mistake an installation issue for a network problem.

First, confirm that your client version supports TUN, then grant the permissions it requires to create a virtual interface and change routes. Windows usually requires administrator access or a service provided with the client. Authorization on macOS and Linux varies by version, so don’t apply instructions from another platform. On Android, approve the system VPN prompt and check whether another VPN app is already using the connection. Grant only the permissions required; don’t disable security protections entirely. Before troubleshooting TUN, turn it off and verify that the regular proxy works. If the basic outbound connection fails, elevated permissions won’t fix the remote connection.

First, complete one successful manual update. Then look for an auto-update option in the client’s subscription group or subscription settings; the label, time units, and trigger conditions vary by version. Set a reasonable interval based on how often the provider updates the subscription, and avoid repeated requests at very short intervals. Desktop clients usually stop running scheduled tasks when closed, while Android background restrictions may delay updates. If updates require a proxy, keep a working node available and check how update requests connect. Auto-update refreshes configuration only; it won’t extend a subscription or reactivate a discontinued service.

Usually not. A subscription fetches and refreshes node configurations in bulk; switching nodes selects an active configuration from the existing list. After switching, check that the client applied the new configuration and that the logs show no reload errors. Existing browser connections may continue using the old connection, so close and reopen the page when testing, or restart the app if needed. If the list is controlled by auto-selection or load balancing, the node selected in the interface may not be the final outbound; check the current mode. Update the subscription only if node settings have changed, the configuration has expired, or the list needs refreshing.

First, confirm the core started successfully. Then enable the system proxy and check that its address and port match the client’s local inbound settings. Open a new browser tab and check the client’s access log; a matching request in the log confirms that request reached the core. If logging is off, enable an appropriate level for the test, then restore the previous setting. Browser extensions, custom proxy settings, or app-specific connection policies may override system settings. A successful latency test only confirms that the test path works, not that the browser is connected. The exit IP can offer a clue, but direct-routing rules may send different requests through different routes.

Use the current client’s backup or export feature if available, and note your subscription groups, active node, routing mode, local ports, and DNS settings. Exports may contain subscription credentials and node authentication details, so store them securely and don’t upload them to public forums. Before upgrading, check the target version’s system requirements and migration notes. After migration, test a basic connection first, then restore custom routing and TUN settings one at a time. Subscription updates may overwrite node changes, so save custom edits separately. When switching clients, importing a standard share link or supported configuration format is safer.

First, make sure the device can reach the internet, then check the server address, port, and subscription status. A connection test timeout may be caused by DNS resolution, connection setup, a TLS handshake, or an unreachable test target; one result doesn’t prove a node is permanently unavailable. Check the logs from the same time to distinguish DNS failures, refused connections, and handshake errors. On the same network, compare with a known working configuration, then test the original configuration on another network you’re authorized to use. If all configurations fail, check the local network and core first. If only one fails, check its transport and security settings, along with the service status.

“Connected” may only mean that the local VPN interface is up or the core process has started; it doesn’t confirm that remote requests are working. First, check whether browser requests appear in the access log. If not, check the system proxy, browser settings, or which traffic TUN captures. If they do, check the matching outbound and error logs. If domain names fail but other connections work, focus on DNS settings and system time. If only certain sites fail, check their routing rules and service status. Start with a simple configuration, disable duplicate proxy entry points, and change one setting at a time before retesting. This makes it easier to identify the cause than changing DNS, routes, and nodes all at once.

First, check that the client core is listening on its local inbound port, then compare the host and port with the system proxy settings. The system proxy toggle alone doesn’t confirm that traffic is routed correctly. Some apps ignore system proxy settings; configure a supported HTTP or SOCKS proxy in the app, or consider TUN separately. If the log says address already in use, close duplicate client instances or change the local listening port to an unused one, then update any apps that refer to that port. Don’t terminate system processes unless you know what they do. If a proxy extension or another network tool keeps overwriting the settings, disable the conflicting feature before applying the system proxy again.

A subscription update failure occurs while fetching or parsing subscription content. Check the link’s expiration, authentication, network path, and any certificate errors. Verify the system time, then test updating directly and through an already working proxy. Don’t expose the full subscription URL in public logs. A core startup failure occurs while loading the local configuration. Find the first specific error in the logs, such as invalid JSON, an unknown field, a missing file, or a port conflict. An update failure may leave existing nodes usable; a startup failure prevents connections that depend on that core. Identify which stage failed and fix the relevant setting—don’t start by deleting all configuration.