This applies when v2rayN, v2rayNG, or v2flyNG cannot update a subscription, shows zero nodes after an update, or receives a web page instead of configuration data. Follow this order: record the error, verify the link, inspect the response format, check access limits, isolate network issues, and review client settings. The fault can then be assigned to the subscription source, transport path, or local client.
Record the error first, then follow the six checks
Do not immediately delete the subscription, reinstall the client, or keep switching nodes after an update fails. Subscription URLs often contain account tokens. Their accessibility, the server response, and the way the client sends the request jointly determine the result. Preserve the original error, time, network, and client version so later comparisons have a reliable basis.
Effective troubleshooting requires repeatable conditions. Test the same subscription link on the current network and another trusted network; then keep the same network and compare requests from the client and browser. Change only one variable at a time to identify whether the problem comes from the server, DNS, proxy path, or client parser.
Record the situation
Copy the complete error and note the client name, version, time, node count change, and network in use. Do not overwrite the original configuration yet.
Verify the link
Check that the address is complete and not expired, look for 301 or 302 redirects, and confirm that the final response status is 200.
Inspect the body
Confirm that the response contains share links, Base64 text, or a supported structured configuration—not a login page, CAPTCHA page, or error page.
Check restrictions
See whether the subscription source limits the User-Agent, request count, account status, entry URL, or source network.
Isolate the network
Change DNS and access networks, disable an incorrect system proxy, and rule out DNS pollution, transparent redirects, and local proxy loops.
Review the client
Edit the subscription group again, make sure the link contains no spaces, update the client, and check the core type and local port usage.
Steps one and two: confirm the error and link validity
First distinguish “cannot download” from “downloaded but cannot parse.” Timeouts, DNS failures, and refused connections usually occur during download; zero nodes, format errors, and illegal characters usually occur during parsing. These cases require different solutions and should not all be labeled “subscription expired.”
When checking a subscription URL, focus on the protocol, domain, path, and query parameters. Common copying mistakes include a missing token at the end, line breaks inserted by a chat app, spaces around the address, or pasting display text together with the real link. A subscription token is an access credential and should not be submitted to public parsing sites, public logs, or screenshots.
A link opening in a browser does not guarantee that the client can update. Browsers may automatically send cookies, follow redirects, or display a message page; the client only receives the response body and passes it to its parser. Record the final status code, response type, and beginning of the body instead of checking only whether a download action appears.
Error: The operation has timed out
Cause and fix: The connection did not complete within the configured time. Possible causes include an unresponsive DNS server, an unreachable network, or server-side blocking. Set the timeout baseline to 10 seconds, retry on another network, and check that the system time is accurate.
Error: Response status code does not indicate success: 404 (Not Found)
Cause and fix: The subscription path does not exist. This commonly follows a changed entry URL, a reset token, or incomplete copying. Return to the subscription service and generate a new address instead of guessing the path manually.
Error: Response status code does not indicate success: 410 (Gone)
Cause and fix: The server has explicitly revoked the resource. Generate a new subscription link or confirm the account status. Repeatedly updating the local client will not restore this address.
| Observation | First conclusion | Next action |
|---|---|---|
| Status 200, body contains node data | Download succeeded; check format and client parsing | Inspect the first line, encoding, and share-link prefixes |
| Status 301 or 302 | The entry URL redirects | Confirm the final address uses the expected domain and retains the token |
| Status 401 or 403 | Credential, User-Agent, or access-policy restriction | Verify the token and check the source's client requirements |
| Status 404 or 410 | Path invalid or resource revoked | Obtain the subscription address again from the server |
| Status 200, body is HTML | A login, verification, or error page was returned | Check redirects, account status, and network redirection |
Step three: check the response and Base64 encoding
After a successful subscription download, the client identifies the format from the content. The body may contain multiple lines of vmess://, vless://, trojan://, or ss:// share links, or text encoded as Base64. Some services return structured configuration, but acceptance depends on the specific version and import entry point.
Base64 failure does not necessarily mean that node parameters are wrong. Spaces inserted during transmission, changed line breaks, or missing padding characters can cause a decoder to stop at a particular byte. Another common case is an HTML response beginning with <!doctype html>; the client tries to decode it as subscription data and reports an error that appears encoding-related.
Example of a normal plain-text subscription:
vless://[email protected]:443?type=tcp&security=tls#Example node
trojan://[email protected]:443?security=tls#Backup node
Response beginnings that require further investigation:
<!doctype html>
{"error":"token expired"}
Access denied- The body is still empty after removing whitespace: the server may be returning an empty subscription. Check whether the account has available nodes.
- Only an ordinary message remains after decoding: the subscription service returned a business error, not a client protocol-parsing problem.
- The share-link prefix is correct but importing one link fails: check the port, user ID, transport type, TLS parameters, and URL encoding.
- Only some nodes disappear: the server policy may have changed, or an older client may not recognize newly added fields.
Error: base64: illegal data at input byte
Cause and fix: The response contains illegal characters, was truncated, or is not Base64 text at all. Check the beginning of the body, then copy the complete link again from the subscription source. Avoid uploading token-bearing text to online tools.
Error: invalid character '<' looking for beginning of value
Cause and fix: The parser expected structured data but received a web page beginning with an HTML tag. Check the final redirect, login status, and server verification page.
Error: failed to parse subscription content
Cause and fix: The body was downloaded, but no supported subscription format was found. Confirm that it is not a web page, update the client to the current stable version, and try again.
Conclusion: inspect the first 100 characters
When the status is 200 but parsing fails, the beginning of the body is more useful than repeated updates. HTML, an error object, or an access message points directly to the subscription source; there is no need to change routes or node parameters first.
Step four: check User-Agent, authentication, and request limits
User-Agent, or UA, identifies the client making a request. Some subscription sources return different formats by UA or allow access only to registered client identifiers. If a browser works normally but v2rayN or v2rayNG receives 403 during an update, the UA policy is one variable to verify.
In v2rayN, open “Subscription groups” → “Subscription group settings,” select the relevant group, and check the subscription address and User-Agent fields. Change the value only when the subscription service specifies a requirement. An arbitrary browser identifier may cause the server to return a web page, leaving the parser with HTML.
Authentication errors can also result from an expired token, an account-status change, too many concurrent requests, or an update quota exceeded in a short period. Repeatedly clicking “Update all subscriptions” creates more 429 responses. When rate-limited, stop retrying and wait for the server's specified window instead of changing the local port.
Error: Response status code does not indicate success: 403 (Forbidden)
Cause and fix: The server identified an unauthorized request. Possible causes include the token, UA, source network, or account policy. Check the subscription service instructions and use its specified UA in the subscription group.
Error: Response status code does not indicate success: 429 (Too Many Requests)
Cause and fix: The request limit was exceeded in a short period. Stop automatic updates and repeated manual clicks, then wait 10 to 30 minutes before sending a single request.
Error: token expired
Cause and fix: The subscription token has expired or was reset by the server. Generate a new address and delete the old link saved in the client so background tasks do not keep requesting the invalid entry.
Step five: isolate DNS, system proxy, and local network issues
If the same subscription updates on a mobile network but times out on a home broadband connection, check DNS and the access path first. A domain resolving to the wrong address, stale records cached by network equipment, or a transparent redirect to a message page can connect the client to an unexpected server. Changing VMess, VLESS, or Trojan node parameters will not help because the failure occurs before the node list is downloaded.
If the system proxy points to 127.0.0.1:10809 while the corresponding core has not started, the subscription request may fail immediately. If updates must use the current proxy but the active node is already unavailable, the setup becomes circular: a node is needed to download the subscription, while the subscription is needed to obtain a node. Temporarily update through a direct connection, or use a backup configuration confirmed to work.
- Record the current DNS result for the subscription domain, then switch to another trusted DNS set. Avoid changing several network parameters at once.
- Confirm that the system date, time, and time zone are correct. A large offset can make TLS certificate validity checks fail.
- Check whether another process occupies the local port. Common v2rayN ports are SOCKS 10808 and HTTP 10809, but the actual values are defined under “Settings” → “Parameters” in the local listener configuration.
- Temporarily disable system-level proxy settings other than browser extensions, then test a direct subscription request to rule out a proxy loop.
- Test once on the current broadband connection and once on an Android mobile network. If only one network fails, check its DNS, gateway, and network restrictions first.
| Comparison test | Result | More likely fault |
|---|---|---|
| Same link fails on broadband but works on mobile | The subscription source is available | Broadband DNS, gateway cache, or source-network restriction |
| Same network, browser works but client gets 403 | The path is generally reachable | UA, cookies, redirects, or client request policy |
| All networks return 410 | The server explicitly revoked it | Expired subscription address |
| Recovery after disabling the system proxy | The direct path works | Local port, proxy loop, or inactive node |
Conclusion: compare networks before repeatedly changing DNS
The difference between two networks using the same link quickly separates a server problem from a local path problem. If both fail, inspect the subscription source; if only one fails, keep the client configuration and focus on that network.
Step six: review client settings, version, and core status
After the first five steps confirm that the link is valid, the body format is correct, and the network is reachable, address the client's local state. Reopen the subscription editor and check for spaces around the link, whether the group is enabled, and whether an automatic update task still uses an old address. Do not replace only the display name; the old token may still be stored in the original group.
For v2rayN, use “Subscription groups” → “Subscription group settings” → select a group → edit the address, then save and run “Update current subscription” once. Core settings are under “Settings” → “Parameters” → “Core type.” There is no need to switch cores for subscription errors 401, 403, or 404; those statuses come from the subscription server.
In v2rayNG, open “Subscription group settings” from the side menu, edit the current entry, confirm that it is enabled, and return to the main screen to update the subscription. v2flyNG uses the v2fly core and suits Android configurations that require its behavior. If the same subscription fails only on an older version, update the client first, then check whether the server has added new protocol fields.
Back up current items
Record working node names, subscription groups, and routing settings so that a usable backup configuration is not overwritten during troubleshooting.
Rebuild the group
Create a temporary subscription group, paste the complete newly obtained address, and enable only this item for testing.
Run one update
Update the current group only once, recording the status code, duration, and node count before and after the update.
Check ports
Confirm that 10808, 10809, or a custom listener port is available, and that the system proxy points to the port the client actually listens on.
Update the client
Retest with the current stable version of v2rayN, v2rayNG, or v2flyNG to rule out an older parser that cannot recognize new fields.
Error: address already in use
Cause and fix: Another process is using the local listener port. Close duplicate client instances, or choose an unused port under “Settings” → “Parameters” and update the system proxy accordingly.
Error: no valid profile found
Cause and fix: The update produced no usable configuration. Check whether the response body is empty and confirm that share links include the complete server, port, and identity parameters.
Determine where the problem belongs
If 401, 403, 404, 410, or 429 appears consistently across multiple networks and clients, the problem is usually with the subscription source or account policy. When contacting the subscription service operator, provide the time, status code, client name, and network type—but never send the complete token.
If a browser and another client both retrieve the same body while only one older client fails to parse it, focus on the client version, subscription-format compatibility, and fields in individual share links. If changing networks restores service immediately, there is no need to rebuild every node; focus on DNS, the system proxy, and the access network.
Only verify node connectivity afterward. A successful subscription update means that the node list was written to the client, not that every server is reachable. Select one node and check address resolution, port reachability, the TLS domain, transport method, and routing rules. Record these separately from the subscription download stage.
Final diagnosis: use status, body, and cross-network results
The status code shows whether the server accepted the request, the body shows what the parser actually received, and cross-network results show whether the fault is limited to the local path. Change settings only after all three forms of evidence agree, avoiding deletion of valid subscriptions or repeated client reinstalls.