v2rayN FAQ

Use v2rayN on Windows, macOS, or Linux desktops. On Android, v2rayNG with the Xray core is usually the first choice. Consider v2flyNG if an existing configuration specifically depends on V2Fly behavior. The client provides the interface, subscription management, and proxy controls; supported protocols also depend on the bundled core and its version. Before choosing, check your platform, processor architecture, and server requirements. An app’s name alone does not guarantee compatibility. All three clients require a working server configuration; installing one does not establish a connection by itself.

VMess and VLESS are proxy protocols; REALITY is related to the security layer. They are not interchangeable options of the same kind. A working connection also depends on the transport, port, and security parameters matching the server configuration. For example, a VLESS configuration using REALITY requires the correct public key, serverName, shortId, and other fields; set flow as specified by the server as well. If an imported configuration contains unsupported fields, check the client and core capabilities rather than switching the protocol to VMess at random.

A subscription link is usually an address a client uses to fetch a list of configurations, and refreshing it requests the content again. A share link typically describes a single server configuration; common prefixes include vmess://, vless://, trojan://, and ss://. Native JSON can contain a complete set of core settings, including inbounds, outbounds, routing, and DNS, so don’t assume it can be imported as a regular subscription. Choose the subscription group, clipboard import, or custom configuration option based on the content type. Subscription URLs may contain access credentials, so hide the full URL and related parameters in screenshots or support requests.

System proxy writes proxy settings to the operating system and mainly affects apps that use those settings. Apps that connect directly or have their own proxy settings may bypass it. TUN mode uses a virtual network interface to route traffic that matches its routing rules, and involves permissions, DNS, and network routes. It does not guarantee that all traffic goes through the proxy; routing rules still determine what happens. When setting things up, first verify the server with system proxy, then enable TUN if your apps require it. Changing several settings at once makes problems harder to track down.

For most phones released since 2015, arm64 is usually the first package to consider, but use the ABI supported by the device’s operating system as the deciding factor. A 64-bit processor does not necessarily mean the OS supports the corresponding app. The universal package includes files for multiple architectures, which can help when you’re unsure of the device architecture, but it is usually larger. If installation reports that the package is incompatible, check the OS version and architecture before choosing another package. A signature conflict won’t be fixed by repeatedly switching architectures. Keep your configuration before installing over an existing app, so subscriptions and custom rules aren’t lost if you need to uninstall.

Make sure you copied the complete subscription URL—not a subscription management page, instructions, or a single share link—and remove any leading or trailing spaces or line breaks. After adding the URL to a subscription group, run the subscription update. If the list is empty, check the logs for the request result and parsing errors. A login page in the response often means the URL or authorization is wrong; an unrecognized format may mean the provider’s recommended client type needs checking. Don’t share the full subscription URL while troubleshooting. Record only the error type, response status, and content details with sensitive information redacted.

First check that a server is selected and the core is running. Then verify that the operating system’s proxy address and port point to the client’s actual listening endpoint. Don’t assume an example port is fixed; updates or custom configurations can change it. Check whether the browser is set to use the system proxy and whether a proxy extension overrides that setting. Some apps have separate network settings and need a proxy configured individually. Close other proxy tools and test the same destination again. If only certain sites connect directly, check whether routing rules send them to direct.

Desktop operating systems usually require elevated permissions to create a virtual interface and change routes. Follow the current client version’s prompt to grant permission, then check that the required service or virtual interface component was created successfully. On Android, approve the request in the system VPN authorization dialog. Don’t run another tool at the same time if it uses the same traffic-capture capability. If TUN still fails after authorization, check the logs for the specific failed step and look for security software blocks or leftover interfaces. Disabling system protection long-term is not a solution. After turning off TUN, confirm that regular network access is restored before troubleshooting further.

Tcping mainly checks whether a TCP connection can be established to a destination address and port. It does not fully test the proxy protocol handshake, authentication, or access to the destination website. A real connection latency test visits a specified test address through the proxy, so it more closely reflects the actual connection path, but results still depend on the test destination, DNS, and current network conditions. If the port is reachable but the real connection test fails, check the protocol parameters and logs. Don’t choose a server based on a single test. Repeat tests against the same destination, then use a browser to confirm that the app you care about is actually going through the proxy.

For everyday use, choose a routing setup such as bypassing mainland China based on your needs; the result depends on the rules and their order. To troubleshoot a destination, temporarily route it through the proxy or switch to the client’s global proxy routing mode for comparison, keeping the server and test destination unchanged. If that fixes the issue, check rule priority, rule data, and domain resolution behavior. The system proxy toggle controls how apps send requests to the client; it is not the same as global routing in the core. Restore your preferred routing settings after testing.

A subscription update may replace server entries generated by that subscription group, so avoid making long-term changes directly to entries that update automatically. If you need to adjust settings, copy the entry to a separate manual group if the client allows it, and keep the original subscription for comparison. Back up subscription groups, routing rules, and any essential custom configuration before updating, and store the backup securely. If the active server stops working after an update, check which server is selected and which group it belongs to. Don’t assume an entry with the same name still uses the original address and parameters.

First confirm that the core is running, then identify whether the app uses the system proxy, a manually configured proxy, or TUN. In that app, visit a destination that should clearly use the proxy, and check the client’s connection records or access logs for inbound and outbound markers. A page loading successfully does not prove it went through the proxy: the destination may be directly reachable or match a direct rule. You can temporarily increase the log level for testing, then restore your usual setting. Before sharing logs, redact server addresses, subscription parameters, and information that could identify your activity.

First confirm that your regular internet connection works and that the server address and port are complete. Then distinguish between a DNS resolution failure, a TCP connection timeout, and a protocol handshake failure. For DNS failures, check DNS; for connection timeouts, check the server listener and network path; for handshake failures, verify the protocol, security layer, and authentication fields. A significantly incorrect system clock can also affect authentication or certificate validation. Test one server as a baseline and change only one setting at a time. If the same configuration works on another network, compare local network conditions before reinstalling the client.

A running client or successful local listener only means the traffic entry point has started; it doesn’t mean every remote request will succeed. Check a real connection test and the access logs to see whether requests reach the client. If there are no records, check the app’s proxy settings. If requests are logged but outbound connections fail, check the server and protocol parameters. If the logs show repeated domain resolution errors, check DNS and its routing; avoid making DNS requests depend on a proxy connection that hasn’t been established. If only some destinations fail, compare routing matches and destination connectivity. Disabling certificate verification is not a general fix.

First determine whether the error is a request timeout, an authorization denial, or a content parsing failure. For an authorization denial, check whether the subscription has expired or its URL has been reset. For a parsing failure, check whether the response has changed to a webpage or an incompatible format. If the client supports updating both directly and through a proxy, compare the two while you still have a working connection; this avoids relying on a server that may already be unavailable. Also check the system clock, DNS, and local security software logs. If existing entries still work, keep them for now instead of clearing every group and losing your baseline configuration.

A port conflict usually means another process or a duplicate core instance is listening on the same address. Close duplicate clients, identify the process using the port in your operating system, then stop it or change the local listening port in the client settings. Update any manually configured app proxy settings to match. If internet access fails after an unexpected exit, check whether the system proxy still points to a local listener that has stopped, then check whether the TUN interface and routes have been restored. Use the client’s normal stop and exit process where possible. If the network still isn’t working, save the error details and check your operating system’s network settings one by one.