V2Ray FAQ
Setup, subscriptions, and connection troubleshooting

V2Ray usually refers to the proxy core and related projects in the Project V ecosystem. V2Fly continues this core family, while Xray is a separate development branch. v2rayN is a graphical client for importing configurations, choosing servers, setting routing rules, and launching a core. Being able to import a link does not mean the active core supports every parameter it contains. When checking compatibility, note the client version and the core actually in use, then verify the protocol, transport, and security settings.

For Windows, macOS, and Linux, start with v2rayN and choose the installer that matches your operating system and processor. On Android, v2rayNG is usually the first choice; consider v2flyNG when you need a V2Fly core configuration. Choose based on your configuration requirements, not on similar client names. In particular, a configuration that relies on Xray-specific features should not be assumed to work with V2Fly. Before switching clients, export any settings you need and confirm which client and format your subscription provider supports.

A client manages configurations and connections; installing it does not create working servers. Import a share link, configuration file, or subscription URL that you manage or are authorized to use. A share link usually represents a single configuration, while a subscription URL retrieves a set of configurations that can be updated. Identify which type you have and use the matching import option. Entering a subscription URL as a server address usually will not create a valid configuration. Subscription links may contain access credentials, so do not share them in public screenshots or forums.

No. VLESS is a proxy protocol; REALITY is a transport security mechanism provided by Xray. They can be used together—they are not alternatives. A configuration may also include parameters such as the transport type, server name, public key, fingerprint, and shortId, which must match the server requirements. Changing the protocol dropdown to VLESS alone does not convert a configuration, and a regular TLS setup should not be casually changed to REALITY. Use the complete share link and server documentation to choose the right settings; consult the protocol documentation when core differences matter.

Most recent Android phones can use the arm64 package, which is usually smaller. The universal package supports multiple architectures and is a good choice if you are unsure which architecture your device uses. However, a 64-bit processor does not guarantee that the system runs a 64-bit environment; some older devices may still need the universal build. If arm64 is reported as incompatible, check the system architecture and try universal. Package installation errors can also result from the Android version, an incomplete download, or a signature conflict—not just the device architecture.

Make sure you entered the subscription endpoint, not an account page, help page, or individual share link. Check for extra spaces or missing query parameters. In v2rayN, save the subscription group and then run the subscription update; in v2rayNG, trigger an update as well. Check the update message and logs to tell a request failure from a parsing failure. For request failures, check connectivity and whether the URL has expired; for parsing failures, check the response format. If entries exist but the list looks empty, check whether the selected group filter is hiding them.

Copy the complete link again, preferably from a plain-text source. Messaging apps may split links across lines, replace parts with ellipses, or append punctuation. Check that the link type is supported by your client version, especially if the configuration uses newer transport parameters. Enter subscription URLs in subscription management, not through the share-link import option. If parameters are missing, ask the configuration provider for the complete original link rather than guessing at the public key or user ID. If entering settings manually, verify the protocol, port, transport, and security options one by one, then test the connection.

Creating a virtual network interface and changing routes on desktop usually require elevated permissions. Follow the instructions for your operating system and client to grant access; on Windows, you can try running the app as an administrator after confirming its source. Quit other tunneling tools that may be managing network traffic to avoid route or interface conflicts. On Android, approve the system VPN connection request and check whether another VPN is running. Disabling security protections should not be a routine fix. If the problem persists, check the logs for the specific interface, driver, or routing error and address that issue directly.

The system proxy is mainly for apps that follow the operating system’s proxy settings. TUN captures matching traffic at the network layer and is useful for apps that ignore the system proxy. Routing rules decide which outbound connection the core uses. These handle different parts of the process. When setting things up, first test browser access with the system proxy, then enable TUN only if needed; changing several variables at once makes troubleshooting harder. With TUN enabled, check DNS and routing rules too. Captured traffic does not necessarily all go through the proxy, and menus and behavior can vary across operating systems.

Start by identifying what the test measures. A TCP connection test only shows whether a connection to the port can be established. A real request test also involves protocol handshakes and access to the target, while download tests depend on bandwidth and the test server. A successful test does not guarantee that every website will work, and one timeout does not prove that a configuration is broken. Repeat the test with the same server, route, and target, then compare the results with the core logs. Browser extensions, secure DNS, or caching may also send browser traffic along a different path from the client test.

In a client that supports automatic updates, enable updates for the relevant subscription group and choose an appropriate interval. Then check that an update completes successfully. Scheduled tasks may not run on time if the app is closed or a phone restricts background activity. Subscription entries are usually regenerated from remote content, so manual changes to them may be overwritten at the next update. To keep custom settings, copy them to a separate manual group and keep the sources distinct. If your subscription credentials change, update the URL; repeatedly refreshing the old one will not restore expired authorization.

Copying an entire folder between systems is not recommended. Clients may use different databases, file paths, interface names, and routing settings, and the same subscription may return content tailored to a particular client. Add a compatible subscription on each device, or use the client’s import/export feature to move the settings you need. Recheck system proxy, TUN, DNS, and app routing on the target device. Backups may contain server credentials and subscription tokens, so store them securely. After syncing, test the imported settings separately before replacing a working configuration.

A core starting successfully does not mean it can reach remote destinations. Make sure a server is selected, then check whether the browser uses the system proxy, whether the client is set to the corresponding proxy mode, and whether the local listening port is in use by another app. Temporarily disable browser proxy extensions, retry the same destination, and check the core logs for connection or DNS errors. If only some websites are affected, review routing rules and the browser’s secure DNS settings. Change one thing at a time and keep the original settings so you can trace the cause.

First make sure the device itself can access the internet, then check the server address, port, and subscription expiry. Enable automatic system time and confirm that the active core supports the configuration. Verify the transport, security type, server name, and other parameters against the server requirements. Check the logs to distinguish DNS resolution failures, connection timeouts, and handshake failures; each has a different cause. If only one configuration fails, ask the provider to check the server. If several fail at once, investigate the local network, proxy chain, and firewall rules first. Do not bypass errors by casually disabling certificate verification.

The system proxy does not cover every app. Some use their own network stack or store separate proxy settings. First test with a browser that follows the system proxy, then check whether the affected app offers HTTP or SOCKS proxy settings and enter the type and port the client is actually listening on. Browser extensions, enterprise policies, or other proxy tools may override system settings. Consider TUN only if you need network-level traffic capture, and check for bypass rules. Widening the listening address to your local network is not a fix; it does not change whether an app uses the proxy settings.

Working configurations only show that the current server connection is okay; the subscription endpoint may still have an access, authorization, or response-format problem. Check the update message: verify subscription credentials for authorization errors, endpoint reachability for timeouts, and client format support for parsing errors. If the client offers both direct and proxied updates, try each while keeping your working servers, and make sure the proxy is actually running. Do not clear all configurations first. Note when the failure occurred and keep a redacted error message for further troubleshooting.