V2Ray Subscription Not Working? Check the Link, Format, Proxy, and Client Step by Step

A subscription update is not a single action. The client first reads the link, resolves the domain, establishes an HTTPS connection, retrieves the response body, identifies its encoding and node protocols, and only then writes entries such as VMess and VLESS to the current subscription group. A failure at any stage may appear in the interface as “Update failed” or “0 nodes.” The goal is therefore not to keep clicking Update, but to identify the layer where the failure occurs.

Identify the failing layer first

Before starting, record the update time, client version, subscription group, and the exact error message. Do not delete the original group first: old nodes, group settings, and update logs are useful evidence. If the client lets you copy logs, keep the section from five seconds before clicking Update through ten seconds after the error appears.

If neither the browser nor the client can open the same subscription address, start with the link, DNS resolution, and access permissions. If the browser retrieves text but the client reports a Base64, JSON, or protocol-format error, the problem is probably in content parsing. If the update succeeds and adds nodes but latency tests fail for every node, the subscription was read successfully; investigate node addresses, ports, transport, and routing instead.

• Connection layer: Common symptoms include timeouts, refused connections, failed TLS handshakes, or unresolved domains.
• Response layer: Common symptoms include HTTP 401, 403, 404, or 429 responses, or a login page instead of the subscription content.
• Parsing layer: Common symptoms include an invalid Base64 length, malformed JSON, or an unrecognized protocol prefix.
• Write layer: Common symptoms include a completed update with 0 nodes, or every node being removed by filter rules.
• Connection test layer: Nodes are visible, but TCP latency tests time out and real connections cannot be established.

Check the subscription link, response status, and expiry

A subscription link may contain an access token, user ID, device parameters, or expiry information. Dropping one character during copying, leaving a trailing space, or having a chat app truncate query parameters can make the server return an error page. Copy the complete address again from the original management page. Do not assemble it manually or put multiple addresses in one field.

1. Check the beginning and end

   Confirm that the address starts with https:// and has no spaces, line breaks, or non-ASCII punctuation before the first character or after the last. Copy every query parameter, especially the token after the question mark.

2. Open it separately

   Open the link in a browser on the current device and note whether it returns text, triggers a file download, redirects to a login page, or shows a 401, 403, 404, or 429 status.

3. Check the expiry

   Open the subscription provider’s management page and verify the account status, expiration time, traffic quota, and whether the subscription was regenerated. Once an address is reset, its old token is usually no longer valid.

4. Rule out rate limiting

   Wait 60 seconds before making another request. If the first request returns 429, repeated clicks will only prolong the limit; wait until the server allows the next request.

A link opening in the browser does not mean its response is parseable. A normal subscription body is often a long encoded string, one protocol link per line, or structured content supported by the client. If the page contains navigation, a CAPTCHA, a login form, or an error message, it is only a web-page response. The client may receive HTTP 200 yet show a parse error because the body type is wrong.

Confirm the network path used for subscription updates

“The current node can access the internet” and “the subscription update request uses the current node” are two different things. A client may send browser traffic through the system proxy while sending subscription updates directly. Conversely, enabling proxy updates before the core has started can point the request to a local port with no listener.

Two-path testing in v2rayN

1. Confirm the core

   Select a working old node and start the core first, then check the status at the bottom of the main window. Common local SOCKS and HTTP ports are 10808 and 10809; use the actual listening settings under “Settings” → “Parameters” as the source of truth.

2. Test direct access

   Open “Subscription Groups” and run “Update All Subscriptions (without proxy).” Record the duration, HTTP status, and change in node count.

3. Test through the proxy

   Open “Subscription Groups” again and run “Update All Subscriptions,” sending the request according to the current proxy settings. Compare the result with the direct test.

4. Check the port

   Go to “Settings” → “Parameters” and confirm that the local address and listening port used for subscription updates match the actual listener. Restart the core after changing them, then run one more update.

Network checks in v2rayNG and v2flyNG

On Android, confirm that the connection switch on the main screen is enabled before updating the subscription. v2rayNG uses the Xray core, while v2flyNG uses the v2fly core; subscription requests still depend on the app’s current network, proxy state, and system restrictions on background networking. A common local SOCKS port is 10808, but use the port shown in the app settings when troubleshooting.

• Open “Subscription Group Settings” from the side menu and confirm that the target group is enabled and its address has not been overwritten by old content.
• Return to the main screen and choose “Update Subscription” from the top-right menu. Note whether the result is a timeout, parse error, or successful update.
• Run one test on the current network and another on a different working network. Change only the network condition; do not modify the subscription address and core settings at the same time.
• If the connection switch turns off immediately after startup, fix the core startup error before testing the “update through proxy” path.

Check the subscription body’s encoding and protocol format

After the connection succeeds, the client must determine the format of the response body. It may contain Base64-encoded node links on separate lines or links beginning directly with a protocol name. After decoding, every record must still meet that protocol’s field requirements. VMess commonly contains encoded JSON, while VLESS usually places the user ID, server, port, and transport parameters in the URI.

Example of a recognizable entry:
vmess://encoded node configuration
vless://user ID@server address:port?type=ws&security=tls
trojan://authentication details@server address:port?security=tls

Key checks:
1. Does each record occupy one complete line?
2. Is the protocol prefix made of half-width characters?
3. Is the port an integer from 1 to 65535?
4. Are query parameters separated with &?
5. Does the response contain a web page, error message, or blank content?

Standard Base64 commonly uses letters, numbers, plus signs, slashes, and trailing equals signs; URL-safe variants may use hyphens and underscores. Clients usually support common variants, but truncation, inserted notice text, or incorrect line-break conversion can still corrupt the length. Do not add characters at random to “repair” it: successful decoding does not prove that the node fields are complete.

Chinese characters, spaces, and special symbols in node names usually need proper encoding. If only one record fails, inspect the subscription body line by line and see whether the failure always occurs near the same entry. If removing one malformed record lets the rest import, the network and overall encoding are probably fine; focus on that node’s fields or escaping.

• VMess: Check that the decoded JSON is properly closed and that the address, port, user ID, and transport type are present.
• VLESS: Check for @ between the user ID and server, and confirm that the parameters after the port use a half-width question mark and separators.
• TLS parameters: The server name, fingerprint, and security type must match the server configuration; parseable fields do not guarantee a successful handshake.
• WebSocket parameters: Slashes and special characters in the path must remain encoded and must not be rewritten a second time during subscription generation.
• Empty response: If the HTTP status is normal but the body length is 0, the client has no entries to write; check the subscription generator.

Client version, core, and group settings

When the same subscription fails in an older version but works in a newer one, the cause is often a change in protocol fields, share-link format, or core capabilities. v2rayN 7.x has different interface and configuration entry points from early 6.x releases; compared with some 1.8.x releases, v2rayNG 1.10.x includes a newer Xray core and import handling. Record the full version number instead of writing only “latest.”

1. Record the version

   Write down the complete client and core versions. For example, “7.x” alone is not enough to compare parsing behavior; keep every version segment shown on the About page.

2. Upgrade the client

   Download the current stable version from this site’s download page, exit the old process, and update it for the relevant platform. Keep a copy of the original configuration so the troubleshooting sample is not lost.

3. Create a new group

   Do not modify the old group immediately. Go to “Subscription Groups” → “Subscription Group Settings,” create a test group, paste the same address, and run one update.

4. Disable filters

   Temporarily clear include, exclude, regex, and deduplication rules. If the node count changes from 0 to a specific number, the problem is group filtering, not subscription parsing.

5. Compare counts

   Record the node count shown by the server, the number imported by the client, and the number filtered out. For example, if the source shows 24 entries but the client writes 0, check the format or filters first; if 23 are written, inspect the single malformed record.

Group filtering is a common reason for “update succeeded but the list is empty.” Include rules keep only matching names, while exclude rules remove matching names. A broad dot or wildcard range in a regular expression can filter out every entry. For testing, clear all filters first, then restore them one by one and record each change in node count.

Update succeeds, but nodes still do not work

A successful subscription update only proves that the client retrieved and parsed the configuration; it does not prove that every node is online. The next layer includes server DNS resolution, destination ports, transport, TLS parameters, system time, and routing. Do not keep changing the subscription link at this stage—the link has already done its job.

• Run a TCP latency test first. If all 20 nodes time out at roughly the same time, check the local network, DNS, or a shared server domain first.
• If only one node fails, compare its address, port, transport type, and security parameters with a working node.
• A system clock offset can affect TLS certificate validity checks. Enable automatic synchronization for the date, time, and time zone.
• Check whether the routing mode is mistakenly sending the node server address back through the proxy outbound, creating a connection loop.
• Confirm that the system proxy port matches the client’s listening port; v2rayN commonly uses HTTP port 10809, but the actual configuration takes priority.

Read latency results by type. TCP latency checks only whether a connection to the destination port can be established; it does not fully validate a VMess, VLESS, TLS, or WebSocket session. A real connection test also passes through authentication, transport encapsulation, and routing, so “80 ms TCP latency but no access” usually indicates a problem with protocol parameters after the port.

Minimal connection verification

1. Choose one node with complete fields and a clear name, and temporarily disable complex routing rules.
2. Start the core and confirm that the local SOCKS or HTTP port is listening.
3. Route only one test application through the proxy to keep unrelated traffic out of the logs.
4. Watch for the earliest error in the logs rather than focusing on repeated retries later.
5. Test again after restoring the routing rules. If it fails then, the issue is in the split-routing conditions or outbound tag.

A reusable ten-minute troubleshooting sequence

Layered diagnosis suits complex issues, but everyday troubleshooting needs a fixed order. The workflow below puts high-probability, low-cost checks first, avoiding an immediate client reinstall or complete configuration rebuild. Record the result after every step, especially the response status, duration, node count, and exact error.

1. Save the current state

   Record the client and core versions, and save the old group, update time, node count, and first error log entry.

2. Copy the link again

   Copy the complete subscription address from the original management page and check leading or trailing spaces, line breaks, tokens, and expiry.

3. Inspect the response

   Confirm that the response is the subscription body, not a login page, CAPTCHA, blank page, or a 401, 403, 404, or 429 response.

4. Switch the path

   Test direct updates and proxy updates separately, and confirm that local ports such as 10808 and 10809 match the actual settings.

5. Create a new group

   Import the same address into a blank test group with include, exclude, regex, and deduplication rules disabled.

6. Verify the nodes

   After the update succeeds, test TCP and real connections, then continue in order through DNS, port, TLS, transport, and routing.

If the process stops at step two, the link or account status is usually the issue; stopping at step three usually indicates a server response or access restriction; step four usually points to the network path or local port; step five usually indicates a format, version, or filter problem. Only after the first five steps pass should you investigate node protocols and server configuration in depth.

Frequently asked questions