V2Ray FAQ

For desktop use on Windows, macOS, or Linux, start with v2rayN and choose an installer for your operating system and processor. On Android, v2rayNG with the Xray core is the usual choice; consider v2flyNG when you need compatibility with the V2Fly core. The client manages configuration, while the core handles connections—they serve different roles. Before switching clients, check which protocols, transport methods, and core your provider supports. Similar names do not guarantee that configurations are interchangeable.

Yes. A client manages connections and settings; installing it does not give you access to a working server. You’ll need a subscription URL you’re authorized to use, or a complete configuration with the server address, port, credentials, and transport settings. A V2Ray subscription from a proxy provider is a way to distribute configurations, not a client installer. The provider controls subscription availability, data limits, and expiration. When troubleshooting, distinguish client issues from service outages—reinstalling won’t fix missing configuration.

With a system proxy, apps that follow the system’s proxy settings use a local proxy port; this may not cover every app. TUN routes eligible traffic through a virtual network interface, usually requires extra permissions, and may conflict with other networking tools. Global routing determines which outbound route the core uses for traffic it receives; it does not mean every app is being routed through the client. First use the system proxy to confirm that your subscription and server work, then enable TUN if your apps require it. Change routing and traffic capture separately so you can identify the cause of any issue.

No. Subscription URLs often contain credentials. Anyone who gets one may be able to view your server configuration or use your service quota. When asking for help, hide the full URL, QR code, account identifiers, and sensitive details in screenshots. Share only the client name, operating system, error type, and steps you’ve tried. Import the URL directly in the client rather than submitting it to an unknown online converter. If you’ve already shared it, reset the URL in your provider’s account portal and update the subscription on your devices. Deleting the post alone won’t invalidate the old credentials.

Check your phone’s system information or specifications for its processor architecture. Most mainstream phones released after 2015 can usually try arm64 first, but the architecture supported by your Android system is what matters—not the purchase date. A universal package includes multiple architectures, making it a good option if you’re unsure or need compatibility across devices; it’s usually larger. If parsing or installation fails, check the Android version requirements, whether the download completed, and signature compatibility with any existing app. Not every installation error is caused by the architecture.

Make sure you copied the complete subscription URL—not an account portal page, sign-in link, or sharing instructions. In v2rayN, add a remark and URL in the subscription group settings, then update the subscription. In v2rayNG, save the URL in the subscription group settings and update from the menu; labels may vary by version. Check for leading or trailing spaces, line breaks, and truncated parameters. If the format isn’t supported, ask your provider for a subscription format compatible with your client instead of repeatedly importing the same web page URL.

Turn off TUN first and confirm that a regular proxy connection works. Then address permissions and network interfaces. On Windows, follow the client’s instructions to run with administrator privileges or install the required service. On macOS and Linux, follow the client’s own steps for permissions and components rather than applying instructions for another operating system. On Android, approve the system VPN permission on first use and check whether another VPN app is already using the connection. If TUN still fails, check the core logs for specific errors such as permission denied, interface creation failure, or a routing conflict.

Make sure v2rayN has started the core and selected a working server. Set the system proxy to automatically configure the system proxy, not to leave it unchanged. Check that the system proxy’s local address and port match the client, and make sure another proxy tool isn’t repeatedly overwriting the settings. If your browser has its own proxy extension, disable it temporarily or set it to follow system settings. If only one app is affected, it may not use the system proxy; configure it according to the app’s instructions, or consider TUN after verifying a regular connection.

In v2rayN, create a separate subscription group for each provider, use a recognizable remark, and save each URL and its update options separately. After updating, select the relevant group and confirm that its servers come from the expected subscription; don’t rely on similar names. Start with broad filter settings to avoid hiding every server. Before deleting a group or clearing old configurations, back up any manual entries you want to keep. Subscription updates can overwrite generated entries, so avoid maintaining custom settings on those entries long-term.

TCPing usually only shows that the destination address and port respond at the transport layer. It doesn’t verify authentication, the encryption handshake, the transport path, or access to the target website. A real connection test sends a request through the proxy chain to a test URL, making it more representative of everyday use, though the result still depends on whether that URL is reachable. Run a real connection test on the same group, then try the websites you need. If every server fails only with one test URL, check the URL and routing settings before deleting your configurations based on a single test.

For everyday use, start with bypass China: traffic that matches direct-connection rules goes directly to its destination, while other traffic follows proxy rules. Global mode can help check whether an issue is related to routing, but it only affects traffic that reaches the core; it doesn’t automatically route every app through the proxy. After switching modes, start a new connection and, if needed, restart the app you’re testing so existing connections don’t skew the results. When adding custom rules, check rule order and DNS resolution. Back up the default configuration and use the logs to confirm which outbound route was selected.

Select a server and complete a real connection test before enabling the system proxy or TUN you plan to use. In the same browser, visit a regular website and a trusted IP-check page, then compare the outbound IP before and after. Check the client logs for a connection entry matching that visit. In global and rule-based routing modes, different websites may use different routes, so test a destination that should use the proxy. Finally, test other apps individually. A successful browser test confirms only the browser’s route—not that every app is covered.

Keep the existing group and configuration. Check that the subscription URL is complete, your account hasn’t expired or run out of data, and the system clock and current network are working. Review the update logs to distinguish DNS resolution failures, connection timeouts, access denied errors, and format parsing failures. If the client can update through a proxy, you’ll need a working connection first; if the current one is down, try updating directly. If the update succeeds but the list is empty, clear filters and confirm that you selected the right group. If there’s still no content, ask your provider about the format and status of the subscription response.

Check from your device outward. First, make sure the client core is running and no other app is using its local port. Then confirm that the system proxy or TUN is capturing traffic. Update the subscription, check the system clock, and try another server in the same group. If only one server fails, check its configuration and service status. If they all fail, check your network, DNS, and security software alerts. A timeout and an authentication failure in the logs mean different things. When asking for help, include the error type and the steps that led to it, but hide server credentials and subscription URLs.

First check whether “connected” only means the local service has started, then run a real connection test. If the test succeeds but your browser fails, check its proxy extensions, the system proxy port, and DNS settings. If only some websites are affected, temporarily switch routing modes and check the logs to see whether those domains use a direct or proxy route. Don’t change the server, DNS, and routing at the same time, or the issue will be hard to reproduce. For certificate or handshake errors, check the system clock and the subscription’s transport settings. Don’t disable certificate verification to mask a configuration problem.

Before quitting, turn off TUN and clear the system proxy in v2rayN. If the client crashed, check the system network settings to see whether they still point to a local proxy port that is no longer running. If LAN devices such as printers or router admin pages are unreachable with TUN enabled, check direct-connection rules for private network ranges and look for routing conflicts with other VPNs or security software. Allowing LAN connections lets other devices access your local proxy; it’s not a general fix for LAN access. Note the original settings before making changes, then re-enable only the features you need after connectivity is restored.