v2rayN FAQ

For desktop use on Windows, macOS, or Linux, start with v2rayN. On Windows, the Desktop edition uses a cross-platform interface, while the WPF edition has a traditional Windows interface; check the download page for runtime requirements. For Android, v2rayNG with the Xray core is the usual choice. Choose v2flyNG if you specifically need the V2Fly core. Similar client names do not guarantee identical settings or protocol support. Before switching, confirm that the target client supports the server's required protocol, transport, and security settings. Then import the configuration; successful link recognition alone does not guarantee it will work.

The client reads your configuration, starts the proxy core, and routes matching network requests through the selected outbound. The installer does not provide a working server. Before connecting, get a subscription URL, share link, or complete manual configuration from a service provider you are authorized to use, or from your own server. After importing it, select a server and set it as active. A server address without a port, user ID, or transport settings is usually not enough to connect. Subscriptions may contain access credentials, so don't share the full URL or post screenshots of your entire configuration in public forums when asking for help.

Share links such as vmess:// and vless:// usually contain the details for a single server and can be imported from the clipboard. A subscription URL is typically an updateable web address that fetches a server list and later changes. In v2rayN, import share links from the clipboard option under “Servers.” To add a subscription URL, go to “Subscription Groups → Subscription Group Settings,” create a group, enter the URL, and update the subscription. Importing a subscription URL as a single-server link may produce a format error. Don't use a webpage's display title in place of the actual URL; when copying, make sure it contains no extra explanatory text, line breaks, or leading or trailing spaces.

System proxy settings direct requests from apps that honor those settings to the client's local proxy port. Routing rules determine whether requests that reach the core use a proxy, connect directly, or are blocked. TUN mode captures traffic from more apps through a virtual network interface. These operate at different layers: enabling the system proxy won't route every program through the proxy, and selecting global routing doesn't mean traffic is reaching the core. For an initial setup, use the system proxy to verify the server works, then enable TUN if your apps need it. Keep a known-working configuration before changing how traffic is captured; changing routing, DNS, and the virtual interface at the same time makes issues harder to diagnose.

Most recent Android phones can use the arm64 build, which targets 64-bit ARM devices and is usually smaller than the universal build. A phone's release date alone doesn't guarantee compatibility; check whether its processor and OS support the architecture. If you're unsure, choose the universal build or check the device's ABI in system information. If installation fails or the package can't be parsed, also check the minimum Android version, whether the download completed, and whether an app with the same name but a different signing key is already installed. Export any settings you need before uninstalling an existing app so you don't lose subscriptions or custom rules.

First check whether you're importing a single-server share link or a subscription URL that needs to fetch data online. Keep the share link's protocol prefix intact and import it using the client's clipboard option. Enter subscription URLs in a subscription group, then run an update. If the format isn't supported, ask the provider to confirm that the response is in a format supported by the client—not a webpage, login prompt, or configuration file for another app. Check that copied text doesn't include quotation marks, explanatory text, or spaces in the middle. Don't edit the user ID or encoded data in the link. If the list is still empty after updating, check the selected group and server filters.

In the v2rayN status bar, set “System Proxy” to “Automatically configure system proxy.” Make sure an active server is selected and the core log shows no startup errors. Then check that the proxy address and port in your system's network settings match the client's current local listener. Browser extensions, a browser's manual proxy settings, or another proxy client may override the system settings. For troubleshooting, use only one traffic-capture method at a time. Restart the browser and test again after making changes. Command-line tools and some apps may not use the system proxy, so their direct-connection results don't prove that the system proxy is broken; configure a proxy for them separately or use TUN.

Turn off TUN first and verify that regular system proxy access works, then troubleshoot the virtual interface. On Windows, exit the client, restart it as an administrator, and enable “Enable Tun.” On macOS and Linux, follow the client's prompts to grant the required permissions; don't permanently give every program unrestricted privileges. Check the earliest error in the log to distinguish insufficient permissions from interface creation or route setup failures. Temporarily quit other tools that use virtual network interfaces and try again. On Android, v2rayNG uses the system VPN permission flow. Approve the system prompt the first time you connect, and check whether another VPN is already active.

In v2rayN, go to “Subscription Groups → Subscription Group Settings” and create separate groups by provider or purpose. Use labels that make each source easy to identify, and avoid repeatedly replacing different URLs in the same group. After changing a URL, update that group and verify its contents before updating all subscriptions if needed. Check the selected group before filtering servers so hidden entries from another group aren't mistaken for lost data. Subscription-generated entries may be replaced during an update; save manual changes you want to keep in a separate configuration. When backing up, note custom routing and DNS settings too, then check that the restored configuration still references them.

Tcping mainly checks whether a TCP connection can be established to the server's port. It doesn't confirm proxy authentication, a successful transport handshake, or access to the destination website. A real connection latency test sends a request through the proxy, so it better reflects everyday use, but results also depend on the test endpoint, DNS, and routing rules. Download tests measure sustained throughput and typically use more data; don't compare routes based on a single result. Start with real connection tests to find a working configuration, then verify it with the apps you actually use. If a test fails, check its corresponding log rather than treating an unreachable test endpoint, a closed port, and incorrect server settings as the same “high latency” issue.

In v2rayNG, open “Settings” and find “Per-app proxy.” Enable it, then follow the on-screen instructions to choose whether selected apps should use the proxy or bypass it. The two modes interpret the app list in opposite ways, so review the selected apps after changing modes. Stop and restart the connection for the changes to take effect. Per-app proxy settings control which apps are included in VPN capture; they don't replace routing rules applied by the core. If an app that needs the proxy is excluded, switching to global routing won't add it back. If background downloads or system components have problems, check whether another app or system service is making the request.

Consider changing DNS or enabling FakeDNS only if domain resolution is failing, traffic isn't routing as expected, or a TUN setup needs specific domain mapping. Keep your current working settings, note whether all domains or only some fail, and confirm that the proxy connection itself works. FakeDNS returns virtual addresses for mapping; it isn't a regular public DNS service, and not every app supports it. Before changing settings, make sure your core and TUN implementation support the configuration. Enabling a single option without matching traffic capture and routing settings may not work. If problems persist, restore the original configuration and restart the affected apps. Stale DNS cache entries can also affect results.

Open “Subscription Groups → Subscription Group Settings” and check that the URL is complete and hasn't expired, and whether the provider requires you to generate a new one. Then review the update log for the specific error. If the request times out, check whether your current network can reach the subscription service. If the response can't be parsed, check whether you received a login page, error page, or unsupported format. If a direct request fails, try “Update subscription through proxy” only if you already have a working server; don't rely on a configuration that hasn't imported successfully. If the update succeeds but the list is empty, clear group filters and check server filters. Also verify the system date and time, which can affect certificate validation.

Keep the original settings and don't change the port at random. First confirm that your current network can access ordinary websites. Then check that the active server's address, port, protocol, transport, and security settings match the provider's details, especially the TLS server name and transport path. Check the logs to distinguish DNS resolution failures, TCP connection timeouts, and handshake failures; each needs a different fix. If other servers in the same subscription work, switch to one temporarily to see whether the problem is with a single entry or the client environment. Change a port or setting only if the provider confirms it has changed. A failed local test doesn't by itself prove the remote server is offline.

“Connected” or a running core only means the local process has started; it doesn't guarantee that requests to remote servers are succeeding. Confirm the active server, then check the core log, whether traffic is reaching the client, whether routing selects the expected outbound, and whether DNS resolution works. With the system proxy, check that the app uses proxy settings. With TUN, turn off other VPN or proxy tools first to avoid interface and route conflicts. You can temporarily select an explicit proxy route for comparison, then restore your original rules. If only certain websites fail, check routing and DNS for those domains rather than resetting everything or changing several settings at once.

If the connection drops when the screen locks, check whether the system restricts battery use, background activity, or background data for v2rayNG or v2flyNG. Allow necessary background activity in your device settings, then confirm that system VPN permission is still active. Some devices also have app auto-start settings; menu names vary by system. If the network acts up after you exit the client, check whether “Always-on VPN” or “Block connections without VPN” is enabled. These options may keep restricting network access after the client stops. Before exiting a desktop client, turn off TUN and clear the system proxy. To restore connectivity, remove any lingering traffic-capture settings before reconnecting; don't delete the entire configuration folder as a first step.