First distinguish a download failure from a content-parsing failure. Then check the subscription URL, HTTP response, encoding, proxy path, and client version in order. This guide covers empty lists, missing nodes, and format errors in v2rayN, v2rayNG, and v2flyNG.
Identify the failing layer first
A subscription update is not a single action but a processing chain. The client reads the saved URL, sends an HTTPS request directly or through a local proxy, receives the response body, identifies Base64, a list of share links, or structured configuration, and only then writes VMess and VLESS entries to the subscription group. If any step fails, the interface may show only “Update failed” or zero nodes.
Do not delete the entire configuration at the outset. Check the update time, response status, and log keywords first to determine whether the request returned no content or the content could not be parsed. The former usually involves DNS, proxies, certificates, access permissions, or HTTP status codes; the latter more often means the response was a web page, the encoding was corrupted, or the current version does not support the protocol fields.
| Observed symptom | Check first | Typical interpretation |
|---|---|---|
| Connection failed immediately | DNS, proxy path, and port | The request did not obtain the subscription body |
| 403 or 404 appears after a few seconds | Link expiration and access permissions | The server rejected the request or the resource has expired |
| Update succeeds but node count is 0 | Response content and encoding | The body is empty, a web page, or contains no recognizable entries |
| Only some nodes are imported | Client version and field support | The current client cannot recognize certain protocol parameters |
Conclusion: distinguish request errors from parsing errors first
When logs show HTTP status codes, timeouts, or DNS errors, fix the network request first. When they show Base64, JSON, URI, or field errors, inspect the response format. Reversing this order creates unnecessary work.
Follow these six checks in order
The sequence below starts with low-risk checks and does not overwrite existing nodes. It uses the v2rayN 7.14.3 menu layout as a reference; wording and placement may vary slightly between releases, but the subscription groups, logs, and parameter settings remain the key entry points. On Android, perform the same checks from the subscription settings and log pages in v2rayNG or v2flyNG.
Back up the current configuration
Keep existing subscription groups and working nodes; do not clear the list first. Record the failed group name, its last successful update time, and the exact current error so you can compare results after each fix.
Verify the complete URL
In v2rayN, open “Subscription groups” → “Subscription group settings” and confirm that the scheme, domain, path, and query parameters exactly match the provider’s URL. Be especially careful not to omit the token after the question mark.
Try a direct update first
Select “Subscription groups” → “Update all subscriptions (without proxy)”. If the direct update succeeds, the subscription format is recognizable and the issue is likely the local proxy port, current node, or routing rules.
Then try updating through the proxy
Switch back to the normal update method. If updates work only through the proxy, check whether the system network can reach the subscription domain directly. If they work only directly, check the proxy exit and subscription-domain routing.
Read the original log messages
Open the log panel at the bottom of the main window and look around the update timestamp for keywords such as 403, 404, timeout, Base64, JSON, and URI. Do not rely only on the brief message at the top.
Update the client and test again
Keep the group configuration, upgrade to the current version listed on the download page, and restart the client. Update only the affected group, then compare the node count and logs.
If one group fails while others work, you usually do not need to change global network settings. Check that URL’s expiration, permissions, and response format first. If all groups fail, check the network, system time, local proxy port, and whether the firewall is blocking the client.
Check the subscription link and HTTP response
A subscription URL often contains a path or query parameter used to identify the account. Dropping one character, saving a trailing space, or copying only up to a line break can produce a different server response. Some URLs also have expiration dates or device limits. Even when the domain remains reachable, an old link may return 401, 403, 404, or an explanatory page.
A link opening in a browser does not guarantee that the client can update it. The browser may have a saved login session or use a different system proxy, while the client usually requests the URL directly and parses the body according to the subscription format. Conversely, seeing a long string in the browser proves only that the server returned text, not that the content is valid.
Error: Response status code does not indicate success: 403 (Forbidden)
Cause and fix: The server detected an invalid token, changed permissions, or a request origin that does not meet its rules. Obtain the current subscription URL again and replace the old URL in full; do not edit only part of it.
Error: Response status code does not indicate success: 404 (Not Found)
Cause and fix: The subscription path was revoked, moved, or copied incompletely. Return to the subscription provider’s page, copy the address again, and verify the ending path and query parameters.
Error: The operation has timed out
Cause and fix: The request did not receive a complete response within the allowed time. Test both direct updates and proxy updates, then check DNS, the current exit route, and connectivity to the server.
Error: The remote name could not be resolved
Cause and fix: The subscription domain did not return a valid DNS result. Check the spelling, switch to a working DNS resolver, reconnect to the network, and update the individual group again.
For further confirmation, inspect the response status, the beginning of the body, and its byte count in a trusted environment. A normal subscription usually returns status 200 and a body containing decodable text, multiple lines beginning with protocol prefixes, or structured content explicitly supported by the client. If the body starts with HTML, a login prompt, a CAPTCHA notice, or gateway error text, the problem is the server response—not the VMess or VLESS node parameters.
- Status 200 but the body is only a few dozen bytes: check whether it is a plain-text message such as “Link expired”.
- Status 200 and the body starts with web markup: the client will try to parse the page as a subscription, often producing JSON or Base64 errors.
- Status 301 or 302: confirm that the redirected URL still carries authorization parameters and that the client version handles the redirect correctly.
- Status 429: too many requests were made in a short period. Stop refreshing repeatedly and test again after the server’s rate limit clears.
Recognize Base64, share links, and format mismatches
Traditional subscriptions often encode a complete list of share links as Base64. After downloading the body, the client decodes it and identifies entries such as vmess:// and vless:// line by line. Some subscriptions return an unencoded list of share links directly, so “not Base64” is not necessarily an error. The key question is whether the client recognizes the actual format returned.
A single VMess node link and a full subscription may each contain their own encoding layer. Older VMess links commonly place encoded JSON after the protocol prefix; VLESS usually uses URI query parameters to describe transport, encryption, and the server name. Incomplete escaping, truncated encoded strings, or new fields unsupported by the current client can remove only a few nodes or stop the entire subscription from parsing.
dmxlc3M6Ly9leGFtcGxl
vless://[email protected]:443?type=ws&security=tls
<html>Access denied</html>The three prefixes above can indicate Base64 text, plain-text share links, or an error page. For a real check, inspect only the format signature; never submit a complete subscription body containing an access token to a public decoding site. The subscription URL itself usually grants access to the node list and should be treated like an account credential.
| Body characteristic | Possible format | What to do |
|---|---|---|
| A continuous mix of letters, numbers, and a few equals signs | Entire body encoded as Base64 | Check for truncation, embedded spaces, or incompatible characters |
| Each line starts with a protocol prefix | Plain-text share-link list | Confirm that the client version supports the protocol and query fields |
| Starts with a curly brace or square bracket | JSON or structured list | Confirm that the structure is a subscription format supported by the client |
| Contains html, title, or Access denied | Web page or gateway error | Fix the link permissions, network entry point, or server response |
| Empty body | Empty response | Regenerate the subscription and confirm that usable entries exist in the account |
Error: The input is not a valid Base-64 string
Cause and fix: The body was treated as Base64 but contains a web message, spaces, invalid characters, or truncated content. First verify the actual HTTP response body, then obtain the complete subscription again.
Error: Unexpected character encountered while parsing value: <
Cause and fix: The parser expected JSON but found a web-page tag at the first position. Check for a login page, access restriction, gateway error, or redirect result instead of modifying node fields.
Error: Invalid URI: The format of the URI could not be determined
Cause and fix: One decoded line is not a complete share link, commonly because of a line-break error, a missing protocol prefix, or incorrectly escaped parameters. Regenerate the subscription and import it with an up-to-date client.
Conclusion: inspect the body type before node parameters
If the response is actually a web page, empty text, or an access message, changing the UUID, port, or transport parameters will not repair the subscription. Make sure the client receives a valid list first.
Check the proxy, DNS, and local port
A subscription request can go directly or through the current proxy exit. For a proxy update, the client needs an existing node that can start and reach the network. If that node is already dead, the subscription request is blocked as well, creating a loop: the update is needed to connect, but the update depends on the current connection. The no-proxy update option is the quickest way to isolate this problem.
Use the port actually configured in the client. 10808 is a common local port example for v2rayN, but it may change after parameter edits, configuration migration, or running multiple instances. Do not assume the client still listens on 127.0.0.1:10808 just because that address remains in the system proxy settings.
- In “Settings” → “Parameter settings”, verify the local listening port and make sure another process is not using it.
- Temporarily exit duplicate v2rayN instances, then start one main program for testing.
- Disable proxy-based updates that depend on the failed node and run “Update all subscriptions (without proxy)” once.
- If direct access fails but proxy access works, check the subscription domain’s DNS result and direct route.
- If proxy access fails but direct access works, check the current node, proxy outbound, and whether the subscription domain is routed incorrectly.
- Correct the system date, time, and time zone. A clearly incorrect clock can affect HTTPS certificate validity checks.
Routing rules can also send the subscription domain through an unavailable outbound. For example, a domain rule may select an outbound tag that was deleted; ordinary web pages still work, while requests to that domain keep failing. After a temporary direct update succeeds, return to routing settings and check the domain rule, rule order, and outbound tag instead of relying on repeated switching.
The troubleshooting logic is the same on Android. v2rayNG uses the Xray core, while v2flyNG uses the v2fly core. The client downloads the subscription; the corresponding core handles the node connection afterward. If the subscription already returns a 403 or error page during download, changing the core type will not change the server response.
How to identify the client version and core type
An outdated client often does not make every subscription fail. More typical signs are missing nodes in newer formats, ignored query parameters, or an invalid configuration after import. If the provider changes field names, transport combinations, or output structure, an older parser may not be compatible. After upgrading, keep the original group and update the same URL again; use node counts and log changes as evidence.
| Symptom | Most likely layer | Recommended action |
|---|---|---|
| Every URL fails to download | Network or client request layer | Check direct access, proxy, DNS, system time, and firewall |
| The same subscription imports in a newer version | Compatibility of the older parser | Upgrade the client and update the group again |
| Import works but the core fails to start | Node fields or core support | Review core logs and verify the core type |
| Only individual VLESS entries fail | Transport, security parameters, or field combinations | Compare the failed entry’s query parameters with a working entry |
| Node count is normal but there is no connectivity | Connection phase, not subscription phase | Check the server address, port, routing, and current exit |
In v2rayN, “Settings” → “Parameter settings” → “Core type” determines which core runs a given protocol configuration. This affects node startup and configuration generation, but it is not a universal switch for subscription parsing errors. When logs clearly show a response status, download timeout, or Base64 failure, fix the upstream issue first.
On Android, distinguish the core paths used by v2rayNG and v2flyNG. Both can read common share links, but support for newly added fields may arrive at different times. When migrating a subscription, check its protocols and transport parameters first, then choose a compatible client. Do not judge compatibility solely by whether the app can save the URL.
Error: Failed to parse subscription content
Cause and fix: The client received the body but found no valid subscription entries. Check the body type and upgrade the client. If the latest version still fails, ask the subscription provider to regenerate a compatible format.
Error: Unsupported protocol
Cause and fix: The subscription contains a protocol identifier unsupported by the current client or core. Confirm that the entries are supported types such as VMess or VLESS, then update to a client version compatible with that format.
How to verify the fix
One successful update is not enough to prove the issue is fully resolved. Check the group’s update time, node count, node fields, and an actual connection. If 24 nodes become only 3, the provider may have changed the list, or the parser may have skipped the other 21. In that case, per-entry warnings in the log are more useful than the success message.
- Confirm that the target subscription group’s update time changed, rather than another group with the same name.
- Record the node count before and after the update, such as recovering from 0 to 24 or dropping unexpectedly from 24 to 3.
- Spot-check one VMess entry and one VLESS entry for the address, port, transport type, and server name fields.
- Start one node and confirm that the core log shows no configuration-generation or unsupported-field errors.
- Exit and restart the client, update the individual group once more, and confirm that the result is reproducible.
If switching networks restores service immediately while the original network continues to fail, focus on DNS, access policy, and outbound routing. If generating a new URL fixes it, the old token or path has expired. If only a client upgrade fixes it, keep the newer version and check whether other groups also contain entries skipped by the old parser.
What if the update succeeds but the list is still empty?
First confirm that you updated the subscription group currently displayed. Then check whether the response body is empty or a web page, and whether group filters are hiding new entries. If the logs contain no parsed protocol links, obtain the subscription again.
Why does v2rayN still report an error when the link opens in a browser?
The browser and client may use different proxy paths, DNS settings, and login sessions. Compare the client’s HTTP status and final response with the browser result instead of checking only whether the page opens.
Can I keep clicking Update until it works?
Repeated requests are not recommended. If the server returns 429 or enforces rate limits, refreshing repeatedly can extend the wait. Record one complete error, fix the network or link, and test again.
Can switching cores fix a Base64 error?
Usually not. A Base64 error occurs while parsing the subscription body, before nodes are handed to the core. Check that the response is complete, contains no web-page text, and is being parsed by a current client version.
Final check: finish with a reproducible result
The link, parsing, and runtime chain can be considered restored only when the same group returns the same node count twice in a row, updates successfully after a restart, and at least one node generates a valid configuration.