V2Ray FAQ

Choose a client for your operating system, then check that its core supports the features your configuration requires. Use v2rayN on Windows, macOS and Linux. On Windows, choose between the cross-platform Desktop interface and the classic WPF interface. On Android, v2rayNG with the Xray core is usually the first choice; consider v2flyNG when you need compatibility with the V2Fly core. All three are graphical clients, not server software. Configuration support depends on the actual client and core versions, so don't rely on the app name alone. Make sure the package architecture matches your device.

A client reads configuration and handles traffic; installing it does not create a usable remote server. A subscription URL retrieves and updates multiple server configurations, while a share link usually contains a single configuration. They are different types of input. Use a service configuration you are authorized to access, or generate one from your own server. This site provides client downloads and configuration guides, not proxy subscriptions. Subscription URLs may contain access credentials, so don't share them in public screenshots, chats or online conversion tools. Before importing, check the service period, data allowance and supported protocols.

Protocols, transport methods and security layers are separate configuration options and should be combined according to the server's requirements. VMess, VLESS and Trojan are common proxy protocols; REALITY is a security layer, not a standalone option that replaces every protocol. A VLESS configuration may use REALITY or another security layer. After importing, check the address, port, user ID, transport and security settings. If required server names, public keys or short IDs are missing, the profile may save successfully but still fail to connect. Don't disable certificate verification just to test a connection.

System proxy and TUN determine how traffic reaches the client; routing rules decide which outbound handles it. System proxy works for browsers and apps that honor the operating system's proxy settings, but some apps ignore them. TUN uses a virtual network interface to capture eligible traffic and typically requires additional permissions, routing and DNS configuration. Routing rules send specific domains, addresses or ports through a direct, proxy or block outbound. If you're new to this, test the connection with system proxy first. Consider TUN only if your apps need it, and avoid changing everything at once so you can identify the cause of any problem.

If you've confirmed that your device uses a 64-bit ARM architecture, choose arm64. If you're unsure of the architecture or run into compatibility issues, try the universal package. Most mainstream phones released after 2015 use 64-bit ARM processors, but processor capability doesn't always match the architecture the operating system actually runs. Don't rely on the phone's release year alone; check its specifications or system information. If installation fails, also check for an incomplete download, insufficient storage, an unsupported OS version or a signature mismatch with an existing app. Don't uninstall the existing app first, or you may lose its configuration.

First identify the type of input, then check that it is complete. Share links that start with a protocol name are usually imported from the clipboard; add subscription URLs to a subscription group and then update it. When copying, exclude any explanatory text, quotation marks, line breaks or ellipses added by a chat app. If no profiles appear after import, check for a parsing error or unsupported fields, and confirm that the client and core support the configuration. A website login URL may not be the subscription endpoint, so copy the URL again from the service's management page. Never post a full link containing credentials in a public help forum.

Check the update log first to tell a network request failure from a parsing error, then follow the relevant checks. For request failures, verify that the subscription URL hasn't expired, the device clock is correct, and the update isn't relying on a proxy that no longer works. In v2rayN, you can try updating without a proxy, but only if your current network can reach the endpoint directly. For parsing errors, check whether the response is actually a login page, error page or unsupported subscription format, and contact the service provider to confirm. Keep the existing group before retrying so you don't lose working configurations. Not every subscription problem is caused by Base64 encoding.

Make sure a standard proxy works before troubleshooting TUN permissions or virtual interfaces. On Windows, check the client prompt to see whether administrator privileges are required. On macOS and Linux desktop versions, follow the instructions for your installation method and check for prompts to authorize a helper service or create a network interface; don't copy steps from another platform. Android usually requests permission to establish a VPN connection; if you denied it, grant permission again. Also quit other VPN or TUN tools that are capturing traffic to prevent interface and routing conflicts. If the connection still fails after authorization, save the logs and check routing and DNS instead of repeatedly escalating permissions.

Check that the system proxy's local address and port match the client's listening settings, then confirm that the core has started. In v2rayN, enabling the system proxy writes the settings to the OS; clearing it removes those settings, while leaving it unchanged generally preserves the current state. Browser extensions, separate proxy settings or company policies may override the system configuration. Temporarily disable conflicting options and restart the browser to test. SOCKS and HTTP ports aren't interchangeable; some versions provide a mixed port. Android commonly routes traffic through the app's VPN permission, so desktop system proxy checks don't apply.

Choose a mode based on what its rules actually match, not just its name. Bypass mainland China mode typically sends selected mainland China domains and IP addresses directly, while other traffic follows the default outbound. Blacklist mode usually proxies only destinations specified in the rules. Global mode is often used to route most traffic through the selected proxy for comparison testing. Default rules and exceptions vary by client configuration, and global mode doesn't necessarily disable protections for local addresses. For everyday use, keep LAN and private addresses direct. After editing custom rules, check their priority so broad rules don't match first unintentionally.

A latency test only shows reachability under its specific test conditions; it doesn't replace testing with real apps. Select a server and start the core, then confirm that system proxy or VPN routing is enabled. Open a known-accessible HTTPS page in a browser and check the client logs for the corresponding request and expected outbound. If you need to verify UDP or a particular app, test it separately rather than assuming a web page proves all traffic works. When comparing direct and proxied results, use the same destination at roughly the same time and close other proxy tools. When sharing troubleshooting details, report the error type without exposing server credentials.

Back up user configuration you can restore before upgrading or migrating. Include subscription groups, manually added servers, custom routing, DNS settings and local listening ports. Use the client's export or backup feature, and store the file somewhere secure. Backups may contain subscription credentials and server authentication details, so don't share them like ordinary screenshots. After upgrading, check that the configuration loads correctly and the core starts before restoring custom settings one at a time. When switching clients, some client-specific fields may not transfer; review them again. Don't remove the old device's configuration until the new setup is confirmed to work.

Start with a minimal comparison to find out whether one profile fails or all of them do. If only one profile times out, check the server address, port, service period and authentication fields, then ask the service provider about its status. If every profile times out, confirm that your local network can reach ordinary websites, then check the client's core startup logs, system clock and security software blocks. Compare with another known-working configuration you're authorized to use. A successful TCP latency test doesn't guarantee a successful protocol handshake, and some servers restrict certain test methods. Don't repeatedly change every protocol setting after a single timeout.

Connected usually means the core or VPN interface has started; it doesn't guarantee that the remote service, routing rules and DNS are working. Check whether the logs show a request when you open a webpage. If there's no request, check whether the app is routed through the client, including system proxy settings, browser-specific settings or VPN coverage. If requests appear but fail, use the error to investigate the handshake, DNS resolution or outbound route, and compare with another known-working configuration. If only some sites fail, check whether a rule is incorrectly sending them direct and whether the destination service itself is having problems. Change one thing at a time and record the results instead of changing ports, DNS and routing together.

First find out whether the failure is in the OS, the client or remote DNS resolution; then decide whether to change DNS. Check that you've completed any network sign-in and that the DNS address configured in the client is reachable. With encrypted DNS, also check the server name, access path and outbound used for the request. In TUN mode, mismatched DNS interception and routing can cause request loops or send traffic the wrong way. Don't enable FakeDNS just because of its name. Temporarily restore the client's default DNS settings for comparison, then reapply custom settings one at a time. Don't judge DNS by opening a website's IP directly; HTTPS and virtual hosting may require the domain name.

First determine whether the slowdown affects one destination, one profile or the whole network, then compare under the same conditions. Pause background downloads and test the same destination on different networks and with different working profiles. Record when the issue occurs and the client error type. If Android disconnects only after the screen locks, check battery optimization, background permissions and whether another app has replaced the VPN. On desktop, check wake-from-sleep behavior, network changes and conflicts with other proxy tools. Throughput depends on your local connection, remote server load and destination site; a single latency figure isn't enough to diagnose it. If disconnections are frequent, collect logs before changing advanced settings such as MTU.