V2Ray FAQ

V2Ray is part of the Project V proxy ecosystem. V2Fly continues development of the V2Ray core, while Xray is a separate core fork. The core handles protocol connections, routing, DNS, and related tasks. GUI clients save server profiles, manage subscriptions, generate configurations, and launch the core. When troubleshooting, distinguish these two layers: an open client window does not mean the core has started, and a running core does not mean system traffic is being routed through the proxy. Check the startup result in the client log first, then verify the proxy entry point.

For Windows, macOS, and Linux desktops, choose v2rayN, then select the appropriate download for your processor architecture and package format. On Android, v2rayNG with the Xray core is usually the first option to consider; choose v2flyNG if you need the V2Fly core. Don't judge configuration compatibility by the client name alone. Check the server's protocol, transport, and security settings. If a specific field isn't supported, confirm which core and version actually launched before switching clients.

A client is a configuration and connection tool; installing it does not provide a server address or access credentials. Add servers using a subscription URL or share link you obtained legitimately, or enter the connection details manually. A subscription usually contains multiple servers, while a single share link typically describes one server, and each has a different import option. Check which type of information you have before importing, then confirm that server names, addresses, and ports appear in the list. Don't paste an account management page URL as a subscription URL.

VMess, VLESS, and Trojan are proxy protocols; REALITY is a security mechanism, not a standalone server protocol on the same level. A connection may also include transport settings such as TCP, WebSocket, or gRPC. When configuring a connection manually, check the protocol, address, port, user ID, transport, and security settings separately. Matching protocol names alone doesn't make two configurations equivalent. Ask the configuration provider about missing fields; don't guess the server name, public key, or short ID.

Check your device's supported app architecture rather than relying on its release year. Devices that support 64-bit ARM apps should generally use arm64. If you're unsure, choose the universal package, which supports multiple architectures but is usually larger. If installation fails or the package can't be parsed, check that the download completed, review the system requirements, and look for an existing installation signed differently. Export your configuration before uninstalling an older version to avoid losing servers and group settings with the app data.

First identify where the process fails: saving the URL, retrieving its contents, or parsing the servers. If saving fails, check for spaces, line breaks, or a truncated copy. If retrieval fails, look for network or HTTP errors in the log. If content is retrieved but no servers appear, check whether the response is a login page, an error page, or a format the client doesn't support. In v2rayN, save the URL in the subscription group settings, then run an update. Subscription URLs may contain access tokens, so hide the full URL in screenshots and support logs.

The system proxy provides a proxy address to apps that follow system settings; it doesn't automatically route every network request. First confirm the client core is running, then check that the system proxy host and port match the local HTTP or mixed inbound. Next, check whether the app uses a custom proxy, explicitly bypasses proxies, or needs to restart before it picks up the settings. Command-line tools and some apps may need separate configuration. For traffic that doesn't follow the system proxy, consider whether TUN mode is appropriate. Don't infer the traffic path from the toggle alone.

TUN typically uses a virtual network interface and system routes. Required permissions vary by platform, client version, and implementation. On desktop, read the client's permission prompt and grant the administrator or helper-service access it requests. On Android, approve the system VPN connection request. Also check whether another VPN or network interception tool is using the same resources. After granting access, restart the relevant mode and check the logs. Don't repeatedly install unknown drivers or assume every permissions error means the server is unavailable.

Create a separate group for each subscription source, give each group a recognizable name, and save the corresponding URL there. Keep manually added servers separate so a subscription refresh can't overwrite them. Before updating, confirm whether the action applies to one group or all groups. Afterward, check changes to the server count and selected server; a smaller list may reflect changes at the source rather than a client problem. Groups and filters are client management features, not universal core configuration fields.

Rule-based routing selects an outbound based on criteria such as domain, IP, or port. Global proxy mode generally sends traffic that reaches the client through a proxy outbound, though the exact scope depends on the client. It doesn't mean traffic from every app has been intercepted, and it doesn't automatically enable TUN. To troubleshoot routing, temporarily send the target request through the proxy for comparison, then restore rule mode and inspect the matching rule. Check separately how traffic enters the client and how the client selects an outbound.

Make a reproducible request, then look in the client log for the domain, destination address, and outbound tag. Routing rules are usually evaluated in order, so an earlier broad rule may catch the request first. The rule's outboundTag must match a tag in outbounds. Also check whether the request still includes its domain name when it reaches the core; requests containing only an IP may not match domain rules. Change one rule at a time and reload the configuration. Avoid changing DNS and routing together, or it may be hard to tell what caused the result.

In the desktop client, enable LAN connections and make sure the proxy inbound listens on an address other than loopback only. Note the computer's LAN IP and the actual listening port. On the other device, enter that IP and the corresponding HTTP or SOCKS port in its proxy settings. Then check that the computer's firewall allows access from trusted devices on the LAN. The devices must be able to communicate; guest networks and wireless client isolation can block connections. Expose the proxy only on a trusted network, restrict source addresses where possible, and never forward the proxy port to the public internet.

Keep your existing servers so you don't lose a working configuration. Check whether the subscription expired, its URL was reset, and your device's clock is correct. Use the logs to distinguish connection timeouts, certificate errors, and HTTP status errors. If the client offers both direct and proxied updates, try each when you have a working server. Relying on a failed server to update the subscription can create a loop. If the response has changed, confirm which subscription formats the provider supports; don't keep importing an error page into the server list.

Not necessarily. Results depend on the test target, DNS, your current network, protocol settings, and server status. First check whether the test measures a port connection or an actual proxy request; these aren't equivalent. Then verify the address, port, system clock, and required transport and security settings, and review the failure log. Compare with a known-working server or network, but avoid frequent bulk tests. If all servers fail at once, first check that the local core has started and that your network is working.

Check the local entry point, routing, remote connection, and DNS in that order. First see whether the browser request appears in the client log. If it doesn't, check the system proxy, app-specific proxy settings, or the scope of TUN interception. If it appears but the connection fails, verify the outbound tag, server settings, and remote error. If only domain lookups fail, check the path to the DNS server. Don't simply disable all security software. Also determine whether the issue affects every site or just one domain or app.

Look for the first clear error during startup, not just the final exit message. For JSON parsing errors, check commas, quotation marks, and brackets. For a port conflict, check whether an old process or another program is using the same inbound port. For an unknown protocol or field, verify that the configuration is supported by the core. If the log reports a missing routing resource, check whether the client-managed resource is present. Changes to a temporary configuration generated by the client may be overwritten on the next launch, so fix the setting in the client UI or the custom configuration source instead.