v2rayN FAQ

V2Ray usually refers to technologies and software in the Project V proxy ecosystem. The core handles protocols, connections, and routing, while a graphical client provides an interface for importing subscriptions, selecting servers, and changing settings. V2Fly and Xray are related core families, but their supported features and configuration details are not identical. If a protocol is unsupported, check which core the client actually uses and its version—not just the client name shown in the window.

For desktop use on Windows, macOS, or Linux, start with v2rayN. On Android, consider v2rayNG, which uses the Xray core; choose v2flyNG when you need compatibility with a V2Fly core configuration. Pick a client for your operating system, then check the protocol and transport required by the server. Similar names do not mean configurations are interchangeable. Client and core support changes between versions, so a field an older version cannot recognize does not necessarily mean the subscription URL is invalid.

A subscription URL usually points to a collection of configurations that the client fetches when you update the subscription. A single-server share link typically describes just one connection configuration. They may require different import options, and an ordinary webpage URL cannot be used as a subscription URL. A token in a subscription URL may grant access to your account, so protect it like a password. If you ask someone for help, hide the full URL and credentials; share only the error and relevant settings.

System proxy settings direct requests from apps that honor them to a local proxy port. TUN uses a virtual network interface to capture eligible traffic and usually requires additional permissions. Routing rules then decide whether traffic entering the core goes direct, through the proxy, or gets blocked. These are separate controls. If a browser works but another app does not, first check whether that app honors the system proxy. Consider TUN only if needed—don't switch straight to global routing.

A client manages local settings and connections; installing it does not provide a working remote service. A proxy connection still needs a valid server address, port, and authentication details, usually supplied by a subscription or a single configuration. Successful installation only means the app can run; it says nothing about whether a remote connection will work. Before using the client, get a configuration you're authorized to use, import it, select an active server, and choose how traffic enters the client. Toggling the system proxy repeatedly cannot supply missing configuration details.

If you know your device supports arm64, choose that package; it's usually smaller. Most newer phones meet this requirement, but a 64-bit-capable chip does not guarantee that the system provides the matching runtime. Check your device's system information or the installation result. If you're unsure of the architecture, try the universal package, which supports multiple architectures. If installation fails, also check the Android version, available storage, and whether the signatures match an existing app with the same name. Not every installation error is caused by the architecture.

Make sure you copied the complete subscription URL, with no line breaks, extra spaces, or punctuation added by a messaging app. Enter it in the subscription group's URL field. Save the group, then update it; some versions don't fetch content as soon as you save. The list may also be empty if the server returns a login page, an error page, or no content. Next, check that the subscription is valid and its output format is supported by your client. If parsing fails, note the error and ask the configuration provider about the format. Don't edit URL parameters at random.

First make sure the core has started and a valid server is selected. Then set the system proxy to automatically configure the system proxy. Check that the proxy address and port in your operating system match the client's local listening settings; there is no single port that applies to every installation. Browser extensions, other proxy tools, or organization device policies may override the settings, so rule them out separately. If only one app is affected, check whether it uses the system proxy; it may need proxy settings configured within the app itself.

Turn off TUN first and check whether the regular system proxy works. Then grant the permissions requested by the client. Windows may require administrator access and the relevant networking components; macOS may require network permissions; Linux needs the appropriate virtual network interface and permissions. Implementations vary by version, so use the current error message as your guide. Don't disable all security protections. Check whether another VPN or virtual adapter is using the interface, then look for the first related error in the core startup log.

First, make sure the installer matches your processor: choose the appropriate version for Apple Silicon or Intel. If macOS says it can't verify the developer, confirm the download source is trustworthy, then open Privacy & Security in System Settings and use the option macOS provides to allow the app to open. The wording may vary by macOS version. If the source is unknown or the file appears damaged, don't run bulk commands found online to remove security restrictions. Once the app opens, check system proxy and network permissions separately; allowing the app to open does not grant TUN permissions.

Automatic updates generally require the client to be running and the configured update interval to have elapsed. Don't assume updates will run while the computer is asleep or the app is closed. Try a manual update first and check the result and subscription group, then verify that updates are enabled and the interval is set correctly. If the update succeeds but the entries don't change, the server may not have published any changes. Automatic updates only fetch configuration again; they don't fix expired accounts, invalid URLs, or system proxy settings. Distinguish a fetch failure from a connection failure.

Bypass mainland China typically uses domain and IP rules to send destinations that match mainland China directly, then handles other traffic according to the remaining rules. The exact behavior depends on rule order and data files. Global proxy typically sends traffic that has entered the client through the proxy, but it won't automatically capture apps that ignore the system proxy. Choose a routing mode that fits your needs. If one site has a problem, switch modes temporarily for comparison, then restore the original setting. Don't use frequent mode changes to mask a routing rule issue.

First confirm that v2rayNG has established the system VPN connection. Then check the per-app proxy list and whether it is currently set to include or exclude listed apps. Excluded apps won't enter the client as expected. Also check for another VPN, work profile network policies, or manufacturer restrictions on background activity. If the app is being captured, check whether routing rules send the domain it accesses directly. Change one setting at a time and reopen the app to tell whether the issue is traffic capture, routing, or the remote connection.

It can. Entries in a subscription group are usually regenerated or synced from remote content. Changes you make to an entry's address, port, or transport settings may be reverted on the next update, depending on the client version and sync method. To keep an experimental configuration, save it as a separate manual entry and give it a clear alias so it's easy to distinguish from subscription entries. Record the original values before editing and keep only necessary changes after testing. Don't turn off all subscription updates just to preserve one edit; other configurations could become outdated too.

In the same browser, visit a known working HTTPS page and compare the client connection log to see which routing rule matched the domain and which outbound route was used. If helpful, check the exit IP with a trusted lookup site, but a changed IP alone doesn't prove that every app is being captured. Cached pages, browser-specific proxy settings, and direct-connection rules can all affect the result. Confirm that the target app's traffic enters the client, the correct route is selected, and the request completes. Don't rely only on a connection button or tray icon.

Start with the update error. A name resolution failure usually points to DNS; a connection timeout usually points to the network path to the subscription server; 401 or 403 may indicate permissions, a token, or access restrictions; and a parsing error may mean the response format is unsupported. These are clues, not definitive diagnoses. If the subscription is only accessible through a proxy, establish a working connection first, then try the client's option to update through the proxy. Avoid relying on configuration you haven't fetched yet. If the URL has expired, ask the provider for a valid one.

Not necessarily. The test method and target may differ from an actual app request, and a timeout can occur at local DNS, the network exit, or the test site. Check the server address and port, then use the same configuration to visit a known working page. Look in the logs for connection timeouts, authentication failures, or handshake errors. If only one entry fails, compare it with other entries in the same subscription. If all entries fail, check your local network, system time, and whether the core started. Don't delete every configuration based only on test results.

Connected may only mean the local service or VPN interface has started; it doesn't prove that requests can reach remote sites. Temporarily turn off the proxy to confirm your regular connection works. Then turn it back on and check the active server, traffic entry point, and logs. If the regular connection works but all proxied requests fail, check the local listener, remote connection, authentication, and DNS in that order. If the log shows no requests to the target site, first check whether the app is being captured. If a request appears with a specific error, troubleshoot that step without changing the port, DNS, and routing all at once.

Check the device's date, time, and time zone, and enable reliable automatic time synchronization. Then verify the domain, SNI, and transport settings required by the server. An expired certificate, a domain mismatch, interference from the network, or an unsupported client configuration can all cause a handshake failure. Don't routinely skip certificate verification; doing so weakens authentication. If the settings came from a subscription, fetch a valid configuration again. If the error persists, send the server administrator the error and its timestamp, with sensitive information removed.

First check whether the system still points to a local proxy port that has stopped running. If you can reopen the client, clear the system proxy, then exit normally. If you can't open it, disable any leftover manual proxy in your operating system's network settings. If TUN was enabled, make sure its connection has stopped and check whether another VPN is capturing traffic. Don't immediately reset every network setting on the device. Record the current state and restore settings one at a time. Stop traffic capture before exiting to help prevent the same issue next time.