V2Ray FAQs and Troubleshooting

A system proxy changes the operating system's proxy settings and only handles browsers and apps that read them. TUN mode uses a virtual network adapter to process more traffic, making it useful for software that ignores system proxy settings. For everyday browsing, start with the system proxy. If an app is not captured, enable TUN mode and confirm that the system has granted network permissions.

A global proxy sends most captured traffic through the proxy and is useful for quickly testing whether a node works. Split routing selects direct, proxied, or blocked access based on domains, IPs, protocols, and rule sets, making it better for long-term use. For a first setup, use global mode to verify the connection, then switch to rules that bypass local networks and mainland China traffic.

A subscription is an updateable configuration source that can contain multiple nodes. A node stores the server address, port, transport protocol, and authentication parameters. When the client updates a subscription, it refreshes the node list with the returned data. Editing one node does not change the remote subscription, and local changes may be overwritten by new subscription data during the next update.

The protocol must exactly match the server configuration; it cannot be switched arbitrarily on the client side. With an existing subscription, use the protocol and transport parameters provided by that subscription. For a self-built configuration, enter the protocol actually enabled on the server. If the connection fails, first verify the address, port, user ID, transport method, and TLS parameters.

v2rayN is for Windows, macOS, and Linux desktop environments, with subscription management, system proxy, routing rules, and TUN mode. v2rayNG is for Android and is commonly paired with the Xray core. v2flyNG also runs on Android and uses the V2Fly core, offering an alternative for different protocol compatibility needs and workflows.

Make sure you copied the complete subscription URL, not a webpage address, sharing instructions, or a note for a single node. Check that no spaces, line breaks, or non-ASCII punctuation were added before or after the link, then use the client's clipboard import or add-subscription feature. If it still fails, open the URL in a browser to confirm that the server returns data and that the subscription has not expired.

Confirm that the current network can reach the subscription URL and that the device clock is accurate. If the first update must go through an existing proxy, select a working node and connect before updating. Also check whether the provider changed the subscription URL, whether the account has expired, and whether the client's subscription-proxy option matches the current network.

Most mainstream Android devices released after 2015 can use arm64, which is usually a smaller file. Choose the universal version if you cannot confirm the processor architecture, the device is older, or installation reports an architecture incompatibility. Both packages provide the same client features; the main difference is the range of processor architectures they include.

TUN mode creates a virtual network adapter and changes system routes, operations that normally require administrator permissions. On Windows, start the client as an administrator. On macOS and Linux, grant the network extension or related permissions requested by the system. Restart the client afterward, then check the TUN switch, virtual adapter status, and system routes.

Close the warning, open Privacy & Security in System Settings, find the blocked app in the security section, and choose to open it anyway. Confirm the action the next time you launch it, then grant network-related permissions as prompted. The exact entry names vary by macOS version; only allow a client you intentionally downloaded and are ready to use.

Select a working node and start the connection in the client, then enable the system proxy. Open the operating system's network proxy settings and confirm that the HTTP, HTTPS, or SOCKS address points to the local listening address and port shown by the client. Test with a browser that reads system proxy settings; terminal programs require proxy environment variables separately.

Routing rules usually take effect when the core starts or reloads its configuration. After saving changes, disconnect and reconnect, or restart the client if necessary. Check the rule order as well: a broad rule placed first may match and override a more specific rule later. During testing, inspect the destination domain, inbound tag, and outbound tag in the connection log.

For a simple system-proxy setup, start with the system DNS resolver. After enabling complex split routing or TUN mode, let the client core handle DNS centrally so resolved addresses stay consistent with routing rules. Define which requests use local versus remote resolution, and avoid having multiple DNS tools handle the same request.

Set a reasonable update interval for each subscription while keeping a manual update option available. Make sure the network works before updating, then check that the current node still exists. If the subscription removed the node in use, select another node and reconnect. Users with multiple subscriptions should use groups and notes to identify sources and prevent identically named nodes from being mixed together.

Give each subscription a clear group name, then use the client's filters, notes, or prefixes to distinguish their sources. Do not identify configurations by the displayed node name alone: different subscriptions may use the same name for different parameters. If ordering changes after an update, filter by subscription group again and limit the selection to frequently used nodes.

Switch to other nodes in the same subscription to determine whether one node or all nodes are unavailable. Then check the local network, device time, firewall, and server-address resolution. If every node times out, update the subscription and verify that the client core starts normally. If only a particular node times out, check its port, transport parameters, and service status.

Connected only means that the client process and local proxy entry point are running; it does not guarantee that destination traffic can leave successfully. Test in global mode first, then check whether the system proxy is enabled, whether the app reads proxy settings, and whether the node works. If TUN is enabled, also check the virtual adapter, DNS, and routes. Reconnect after changing the configuration and test again.

In the browser, check for independent proxy settings, proxy extensions, or enterprise policies that may override the system proxy. Terminal programs usually do not read desktop proxy settings automatically, so configure the HTTP_PROXY, HTTPS_PROXY, or ALL_PROXY environment variables. Confirm that their protocol, local address, and port match the client's listening settings.

Confirm that the client has administrator or network-extension permissions and that the virtual adapter was created successfully. Then rule out interference from other virtual adapters, network-filtering tools, and stale routes. You can temporarily disable the system proxy and test with only TUN enabled. If the core log reports a DNS, routing, or device-creation error, fix that issue and reconnect.

First switch to another node in the same subscription to rule out node load or route fluctuations. Compare different times and local networks to determine whether the access route is responsible. Finally check the client's routing, DNS, transport parameters, and background resource usage. Change one setting at a time and repeat the same test so you can identify the actual cause.