V2Ray FAQ
Setup & Connection Troubleshooting

Choose by platform: For Windows, macOS, and Linux desktops, start with v2rayN for centralized subscription, system proxy, and routing rule management. For Android, consider v2rayNG, which uses the Xray core. v2flyNG is an alternative in the V2Fly core family, suited to configurations that specifically depend on that family's behavior. These recommendations reflect platform support and configuration compatibility, not connection speed. If you already have a subscription, check its protocol, transport, and security settings before choosing a client. Switching clients is not a default fix for a server-side problem.

Know the roles: The client provides subscription management, node selection, and settings. The core parses the configuration, applies routing, and establishes connections. A node specifies the remote server's address, port, and authentication details. Successfully importing a node only confirms that the configuration was accepted; it does not mean the remote service is available. Troubleshooting means identifying whether the failure is at client startup, core configuration, or remote connection. Note the client version, the core actually in use, and when the error occurred. This is usually more useful than repeatedly importing the same subscription.

Traffic coverage: The system proxy mainly affects apps that follow the operating system's proxy settings. Some apps ignore them or use their own proxy options. TUN uses a virtual network adapter and routing to capture eligible traffic, making it useful when more apps need coverage, but it can introduce permission, DNS, and network-tool compatibility issues. For a first setup, use the system proxy to verify that the node works, then test TUN separately. These are not speed settings: TUN cannot fix incorrect node parameters or guarantee that every app uses the same connection path.

Keep parameters aligned: The protocol, transport, and security layer must match the server; changing a label in the client menu is not enough. VLESS, VMess, and Trojan are different proxy protocols. REALITY is a security mechanism, commonly used in specific VLESS configurations—not a drop-in alternative to those protocols. After importing a configuration, keep the supplied flow-control, transport, and security fields. If a field is unsupported, first check what the current core supports. Changing protocols to address a timeout usually adds new variables; check the original configuration and service status first.

Choose the right architecture: Most recent Android phones use arm64, so start with the matching package. The universal package typically includes multiple processor architectures and is larger; choose it if you cannot confirm your device's architecture. A device's release year is only a rough guide—check the architectures supported by the device and its operating system. If the package fails to parse, make sure the download completed, your system meets the version requirements, and the architecture matches. For updates, confirm that the package targets the same app and has a compatible signature. Back up subscriptions and custom settings before uninstalling and reinstalling.

Check the link and format: First distinguish a subscription URL from a single-node share link. Add a subscription URL to a subscription group and update it; import a node share link through the client's clipboard import option. Remove leading or trailing spaces, line breaks, and any explanatory text added by a chat app. Then check whether the URL has expired or requires renewed authorization. If the client reports a parsing error, the response may be a webpage, login prompt, or unsupported format. Don't guess at encoding changes. Use the error log to tell whether the failure occurred during the request or parsing stage. Subscription URLs are sensitive: don't share screenshots or paste the full URL publicly.

Check the startup sequence: Adding a subscription does not establish a working proxy connection by itself. Select a node and confirm that the core starts normally. Then enable automatic system proxy configuration in v2rayN and make sure the system proxy address matches the port the client is actually listening on. Use the port shown in the current settings; don't copy numbers from another guide. If only one app fails, check whether it has its own proxy settings. If all apps fail, check for port conflicts, core startup errors, and security software blocks. Temporarily close other proxy tools to prevent them from overwriting system settings during testing.

Check permissions: First confirm that regular proxy mode works, then troubleshoot TUN permissions. On Windows, grant administrator access as prompted by the client. On macOS and Linux, complete any helper service or elevated-privilege authorization required by your version. On Android, approve the system VPN connection request. Authorization steps differ by platform. If it still fails, check the specific error in the log and look for conflicts with other VPNs, virtual adapters, or security software. Don't repeatedly retry authorization or disable all security protections. Exit conflicting programs, restart the client, and test again with a minimal configuration.

Check the request path: Confirm that the subscription URL is still valid, then distinguish a connection timeout from access being denied or content failing to parse. If a direct connection cannot fetch the subscription but you already have a working node, try enabling proxy use for subscription updates. Run one manual update and check the log. This option depends on an existing working proxy; enabling it during initial setup with no usable node can create a dependency loop. If the request succeeds but parsing fails, check the subscription format and returned content instead of switching proxies. Set automatic update intervals to match the source's update frequency and avoid repeated requests in a short period.

Organize subscriptions: Create a group for each source and use clear labels to distinguish their purpose. Don't repeatedly import multiple URLs into the same group. Before updating, note the selected node and its group; afterward, check whether nodes were removed, renamed, or replaced. Automatic updates often rebuild the node details supplied by the source, so avoid making important manual changes directly to subscription nodes. Save settings you need to keep separately. Before deleting a group, check whether it contains manually added items. Test filters with a few conditions first to avoid hiding usable nodes.

Choose a routing mode: For everyday use, start with rule-based routing that fits your needs: send specified destinations through the proxy and let others connect directly according to the rules. Global proxy is useful for a short comparison test to see whether a problem comes from routing rules, but it is still limited by the client's traffic coverage and does not capture all device traffic. If global mode works but rule-based mode does not, check rule order, domain matching, and DNS routing before switching nodes. Local networks, printers, and internal services often need explicit direct-connection rules. Save the original settings, change one thing at a time, and record the result.

Map domains: FakeDNS maps domain names to fake IP addresses. In supported TUN and routing setups, this can preserve domain information and help domain-based rules match. It is not a general network-speed setting, and you shouldn't enable it before understanding the DNS path. Some apps rely on real DNS results and may stop working correctly. Save your DNS and routing settings before testing. If only certain apps fail after enabling FakeDNS, turn it off, restore the original DNS configuration, reconnect the client, and clear the app or system DNS cache. Then check whether the issue is resolved.

Troubleshoot in layers: First confirm that the device itself has internet access. Then check whether the core is running, whether its listening port is occupied, and whether the system proxy points to the correct address. Verify the selected node and subscription update time, check the device clock, and use the logs to identify whether the timeout occurred during DNS resolution, connection setup, or the handshake. Compare with another known-working configuration or network, changing only one variable at a time. A failed latency test does not necessarily mean apps cannot connect; they may test different destinations. If multiple devices fail on the same node, ask the configuration provider to check the remote service.

What the status means: Connected or running usually means only that the local service has started—not that every destination is reachable. Check whether the browser uses the system proxy or its own proxy settings, then compare rule-based and global proxy modes using the same destination. Look in the logs for DNS failures, routing to the wrong outbound, or authentication errors. If regular proxy mode works but TUN does not, focus on virtual adapter, DNS, and routing conflicts. If only the browser fails, check its extensions and proxy settings. Don't reinstall the client, switch nodes, and change DNS all at once, or you won't know which step affected the result.

Check handshake settings: First set the system date, time, and time zone correctly. Then verify the server name, SNI, transport path, and other security settings required by the configuration source. The connection address may differ from the name used for certificate validation; follow the server configuration rather than changing them to match. Standard TLS connections must validate the certificate name. For REALITY, also check its specific parameters and whether the core supports them. Don't make certificate verification bypass a permanent fix. Keep the exact error message, but hide addresses and credentials, to help distinguish certificate, parameter, and server-side configuration issues.

Compare results: First check whether the issue affects just one app or domain. Then review the logs for DNS resolution results and the actual outbound route. If a destination works in global proxy mode but fails in rule-based mode, check rule order, domain rule data, and DNS selection first. If it fails in both modes, continue checking the node and destination service. Don't rely only on direct IP access: some services require a domain name and the correct TLS name. After changing DNS, reconnect and clear the cache if needed. Record settings before and after each change, and avoid switching multiple resolvers at once so you can reproduce the results.