V2Ray Beginner FAQ: Subscriptions, Proxy Modes, and Connection Problems

1. What are V2Ray, a client, and a subscription?

V2Ray usually refers to a proxy core and its related projects—not to a working server account. A client displays nodes, manages subscriptions, generates configuration, and starts or stops the core. The core handles connections according to that configuration. A subscription is a URL used to retrieve node settings. After installing a client, you still need a server configuration or subscription you’re authorized to use.

• Desktop: v2rayN is available for Windows, macOS, and Linux. Supported protocols also depend on the client version and the selected core and its version.
• Android: v2rayNG uses the Xray core, while v2flyNG uses the v2fly core. Similar-looking interfaces don’t mean they support exactly the same configurations.
• Subscription provider: Your server administrator or service provider supplies the subscription. Our download page helps you choose a client; it does not provide subscriptions or server accounts.

If you already have a configuration, first check whether the current client supports its protocol, transport, and security options. Don’t assume that any share link will import into any client just because both have “V2Ray” in the name.

2. How do you import a subscription, and why update it afterward?

A subscription URL is a way to retrieve configuration, not a node itself. Saving the URL creates a subscription group; updating it fetches and parses the node list. The steps below use the common Chinese-language v2rayN interface. Before importing for the first time, make sure you copied the complete subscription URL, not the URL of your account dashboard.

1. Add a group

   Open “Subscription Group” → “Subscription Group Settings” → “Add,” then enter a name you’ll recognize.

2. Save the URL

   Paste the complete link into the “Address (Url)” field and save. Don’t remove any parameters, slashes, or trailing characters.

3. Update the subscription

   Go back to “Subscription Group” and select “Update all subscriptions (without proxy).” If a direct connection can’t reach the subscription and you already have a working proxy, try the corresponding “Update via proxy” option.

4. Choose a node

   Select a node from the list, set it as the active server from the right-click menu, then enable the proxy option that suits your application.

In v2rayNG, the usual path is “⋮” → “Subscription group settings.” Tap “+” to save a name and URL, then return to “⋮” → “Update subscription.” For a single share link, use “+” → “Import from clipboard” instead. Don’t enter a single-node link as a subscription URL.

3. Subscription update failed or no nodes appeared—what should you check?

First distinguish between “nothing was retrieved” and “content was retrieved but couldn’t be parsed.” The first is usually related to the network or URL status. The second can mean the response was a login page, the format is incompatible, or the node uses an option unsupported by the current core. Keep the exact error message; it’s more useful than repeatedly deleting and reinstalling the client.

4. What’s the difference between a system proxy and TUN, and which should I use first?

A system proxy registers a proxy endpoint with the operating system. Only applications that read and honor that setting will use it. TUN routes traffic through a virtual network interface, so it can affect more traffic and is more likely to conflict with other virtual adapters, VPNs, or security software.

Android clients typically request system VPN permission on startup. This creates a local traffic-routing interface; it doesn’t mean the server connection has succeeded. In v2rayNG, “Settings” → “Per-app proxy” controls which apps use that interface. Check that you haven’t accidentally added apps to the exclusion list.

5. Are “Global” and “Bypass mainland China” proxy switches?

No. The system proxy and TUN determine whether traffic enters the client. The routing mode determines which outbound route handles traffic after it enters. “Global” usually sends traffic covered by the rules to the proxy outbound; it doesn’t make every app use the system proxy automatically.

• Everyday split routing: Start with the client’s built-in rules to bypass local network and mainland China addresses. Names and behavior depend on the rules currently in use.
• Quick troubleshooting: If a website only works after switching to Global, check its domain rules, DNS results, and rule order before reinstalling the client.
• Local network access: Printers, router admin pages, and company intranet addresses usually need direct-connection rules. After changing modes, check that these resources are still reachable.

In v2rayN, go to “Routing” → “Routing Settings” on the main screen to review the rules. Note the current mode before making changes, and change one setting at a time. Custom rules are usually order-dependent: a broad rule near the top can prevent more specific rules below it from taking effect.

6. It says connected, but webpages won’t load. What three things should I check?

“Started” usually confirms only that the local service is running. A latency test can show that the server port is reachable, but a webpage request also depends on the app’s proxy settings, the local listener, the remote handshake, and the connection to the destination site. Start with the layer closest to the app to narrow down the cause.

1. Confirm that the app is actually using the proxy. A browser extension’s own proxy settings may override the operating system settings.
2. Confirm that the active node and local listener are working. In v2rayN, check the local listening port under “Settings” → “Parameter Settings.” If you change it, update the app’s proxy settings too.
3. Open the client log and try loading the failed page again. Look for errors around that time. If every node fails, check the local setup first. If only one node fails, check that node and the server.

7. Should I change DNS? Do I need to enable FakeDNS?

DNS translates domain names into addresses, but lookups may happen in the app, the local operating system, or the proxy core. Changing system DNS won’t necessarily change the resolver used by the proxy core; changing the core’s DNS won’t necessarily affect apps that bypass the proxy. First identify which path is failing, then decide where to make changes.

• DNS timeouts in the log: Check whether the configured DNS server can be reached through the specified outbound route. Watch for a dependency loop where the proxy needs DNS to resolve a domain, but DNS itself depends on the proxy being connected.
• Only some domains fail: Check domain rules, sniffing settings, and the app’s own secure DNS feature to avoid settings overriding one another.
• Before enabling FakeDNS: Confirm that your core and access method support the full mapping flow. FakeDNS returns synthetic addresses for mapping, so it must be paired with the subsequent domain restoration step. It’s not a universal speed boost.

Beginners can start with the client’s working preset, record the original values, and then adjust one setting at a time. If changing the resolver doesn’t help, check the log to see whether the error actually changed instead of piling on more options. For detailed steps, see the DNS settings section in the full guide.

8. Can VMess and VLESS be used interchangeably? What should I watch for when entering settings manually?

You can’t switch between them by changing only the protocol name. VMess and VLESS use different protocol mechanisms and fields, and the server must be configured for the protocol you choose. VMess has its own authentication and encryption mechanisms. VLESS doesn’t encrypt payloads on its own; it’s typically used with security options such as TLS or REALITY. The name “VLESS” alone doesn’t mean the connection is encrypted.

• Shared fields: The server address, port, and user ID must match the server configuration. Your provider sets the server port; don’t replace it just because an example shows 443.
• Transport fields: The WebSocket path and Host are not the same as the TLS server name. Check each one separately; don’t enter the server IP in all of them.
• Security fields: The REALITY public key, short ID, server name, and Flow (if required) must come from the server configuration. A UUID is not a substitute for these fields.
• Time settings: VMess authentication checks the time, so enable automatic system time synchronization first. TLS also checks certificate validity dates, but works differently.

Use the complete share link or subscription from your provider to avoid mistakes when entering settings manually. After importing, watch for messages about unsupported protocols or fields. When moving between v2flyNG and an Xray-based client in particular, don’t assume every newer feature works in both.

9. A node works but feels slow. Is a latency test enough?

No. Latency measures the time for a round trip or a specific test request. Throughput also depends on node load, server egress, network congestion, your local connection, and the destination site. Low latency doesn’t guarantee fast downloads, and a single timeout doesn’t mean a node is permanently down.

1. Rule out local contention first: Pause system updates and large downloads. On desktop, compare wired and wireless connections if possible; on Android, compare Wi-Fi and mobile data.
2. Keep test conditions consistent: On the same device and website, test two nodes at the same time of day, three times each. Record all the results rather than just the fastest one, so website fluctuations aren’t mistaken for differences between nodes.
3. Look at each metric separately: If connections take a long time to establish but transfers are stable, focus on DNS and the handshake. If performance starts out fine but slows down consistently in the evening, check for congestion or server load at that time.
4. Check the app itself: If the client’s test succeeds but one app is slow, check whether it uses a different proxy entry point, per-app routing rule, or connection to the destination site.

Don’t change DNS, MTU, sniffing, and routing all at once in an attempt to “optimize.” Without a controlled comparison, it’s hard to tell which change helped. Organize your test results and logs using the node speed test and maintenance guide, then share them with your provider.

10. How often should I update a subscription, and what should I avoid sharing when asking for help?

Updating a subscription refreshes node settings; it doesn’t increase bandwidth or update the client. Refresh it when your provider changes a server address, port, or authentication details. If something goes wrong, try one manual update—you don’t need to repeat it every minute. Set automatic updates according to your client’s capabilities and your provider’s rate limits.

• Updating the client: Before updating, note the client and core versions, active node, proxy mode, and custom rules. Keep a recoverable copy of your configuration. After the update, test a known-good route before restoring other custom settings.
• Protect your subscription: A complete subscription URL often contains an access token. Single-node links, QR codes, and exported configuration files may also contain credentials. Don’t post them in public comments or screenshots.
• Useful details to include: Share your operating system, client and core versions, when the failure happened, the exact error message, and whether it affects all nodes or one, and all apps or just one.
• Redact logs: Hide subscription tokens, UUIDs, passwords, and any server addresses you don’t want to make public, while keeping the error stage and status code visible. If an address has already been exposed, reset the relevant credentials in your provider’s dashboard.

The most useful record for a beginner isn’t a screenshot saying “connected.” It’s a repeatable set of steps: which app you used, which access method and routing mode you selected, and where it failed. Clear details like these usually show whether to investigate local settings, node parameters, or the server.