This guide covers “update failed,” “empty response,” and “0 nodes after parsing” in v2rayN and v2rayNG. Check download, parsing, and display separately, then inspect the URL, network path, response, and subscription filters instead of repeatedly reinstalling the client or changing core settings at random.
Identify the failing stage first
“Subscription failed” is not a single type of problem. An update must complete at least six stages: connecting, receiving a response, recognizing the content, parsing nodes, writing the group, and applying filters. The fix depends entirely on which stage failed.
If the log shows 403, a timeout, or a name-resolution failure, the problem usually occurred while fetching the response. If the update is marked complete but the number of new nodes is 0, check the subscription format, duplicate-node handling, and group filters.
| Visible symptom | Check first | Do not do this first |
|---|---|---|
| 401, 403, or 404 appears immediately | URL expiration, account status, and complete query parameters | Switch core type |
| Times out after 10 to 30 seconds | DNS, whether the update uses a proxy, and system time | Delete all existing nodes in bulk |
| Download succeeds but parsing returns 0 | Response body, encoding, and format compatibility | Repeatedly test node latency |
| Log shows a successful import but the list is empty | Current subscription group, filter expressions, and hidden status | Reinstall the client |
Expired, truncated, or incorrectly copied subscription URLs
A subscription URL is usually more than a simple path. It may end with authorization parameters, a device identifier, or an expiration value. Dropping one character, omitting query parameters after the question mark, or introducing a line break can make the server return an access-denied or not-found response.
When copying from a chat window, a QR-code result, or a page with collapsed text, it is easy to capture only the visible portion. If the URL contains spaces, or ends with a period, closing parenthesis, or Chinese punctuation, verify whether those characters belong to the original address.
Open group settings
In the v2rayN 7.x main window, open “Subscription groups” → “Subscription group settings,” then select the affected group instead of creating another group with the same name.
Copy the URL again
Use the full-copy action at the subscription provider. Confirm that it starts with a valid HTTP or HTTPS URL and contains no line breaks, Chinese spaces, or extra punctuation.
Replace the old URL
Delete the existing text in the input box before pasting, so no trailing characters from the old URL remain. Before saving, verify that every parameter after the question mark is present.
Update only this group
Update only the current group first and watch the log; do not update all subscriptions at once. A single-group update makes it easier to match the error with its response time.
HTTP 401 or 403 usually means the server received the request but the current URL is not authorized. A 404 more often means the path changed or the URL was copied incompletely. A 410 may indicate that the URL has been explicitly disabled. With these status codes, the local port and routing rules are usually not the first things to check.
The update request has no usable network path
The subscription URL may work normally, yet the client can still time out if its update uses an unreachable direct route. A page opening in a browser does not prove that the client uses the same proxy, DNS, or network interface for the subscription request.
v2rayN usually offers both proxy-based and direct subscription updates. If the current network cannot reach the subscription server directly, start a working node first and choose the proxy update option. If none of the existing nodes work, obtain a new configuration from a network that can access the URL.
Error: The operation has timed out
Cause and fix: The connection received no response within the timeout period. Check that the system clock is correct, start a verified working node, then choose “Update all subscriptions” and check whether the request uses the current proxy.
Error: No such host is known
Cause and fix: The subscription domain did not resolve to an address. Switch to a working DNS server, reconnect to the network, restart the client core, and try the update again.
Error: The remote server returned an error: (403) Forbidden
Cause and fix: The server rejected the request. Obtain a new valid subscription URL and confirm that the account status, URL expiration, and query parameters have not changed.
Error: An existing connection was forcibly closed by the remote host
Cause and fix: The remote host or a network device closed the connection during transfer. Switch the update method or network interface, and avoid reusing a stale connection after waking from sleep.
Also verify that the local listener is actually running. v2rayN commonly uses 10808 for a local SOCKS or mixed listener, while older configurations may place the HTTP listener on 10809. Use the local listener settings under “Settings” → “Parameter settings” and the startup log as the authority; do not rely on an old tutorial alone.
If another program occupies the port, the core may fail to start, so the subscription cannot use the current proxy. Check the bottom log for a message such as “address already in use,” then close the conflicting program or change the listener port, save, and restart the core.
Conclusion: Browser access does not mean the client can update
Use the request result in the client log as the evidence. A browser extension, the system proxy, and v2rayN’s internal update request may take three different paths. Only the status code and response length directly show whether the subscription request completed.
Base64 decode failures and incompatible response formats
A subscription body may contain text made up of VMess, VLESS, Trojan, or Shadowsocks URIs, or the entire text may first be encoded as Base64. Formats are not fully consistent across every service and client, so do not assume that a long string is necessarily decodable content.
If the server actually returns a login page, an error message, or a JSON notice, the client may still try to parse it as a subscription. This can produce a Base64 length error, invalid characters, or 0 nodes. Confirm the response content first instead of manually adding characters to the string.
Example of a normal troubleshooting record
HTTP status: 200
Response type: text/plain
Response length: 18.6 KB
Content: node URI list or complete Base64 text
Parsed: 24
Visible after filtering: 18Error: Invalid length for a Base-64 char array or string
Cause and fix: The body was truncated, contains non-encoded characters, or is not Base64 at all. Obtain the subscription again; do not manually reconstruct missing trailing content.
Error: Invalid URI: The format of the URI could not be determined
Cause and fix: One decoded line is not a complete node URI. Check whether explanatory text was mixed into the response, then update to the current client version and parse it again.
Error: Sequence contains no matching element
Cause and fix: The client found no recognizable nodes in the response. Confirm that the server output format is supported by v2rayN or v2rayNG, and check whether it returns only group information.
- HTTP 200 only means the request succeeded; it does not mean the body is a valid subscription.
- When the response is only a few dozen bytes, first suspect an error message, an empty group, or an expired URL.
- If the body starts with a webpage title or login prompt, do not continue treating it as Base64.
- A single VMess, VLESS, Trojan, or Shadowsocks link can be imported manually, but it cannot replace the subscription URL required for future automatic updates.
- If the same subscription parses in an older version but not in a newer one, keep the log and check whether the server uses nonstandard fields.
Filters hide all nodes in the group
An empty list after a successful update does not necessarily mean parsing failed. v2rayN subscription groups can include or exclude matching conditions. These conditions filter nodes after they are written, and overly strict expressions can hide every node.
For example, an include rule may target “Hong Kong” while node names use “HK”; an exclude rule may target “remaining” while every node name contains traffic-usage text; or an incomplete regular-expression character may cause the final visible count to become 0.
| Update record | Meaning | Next step |
|---|---|---|
| Fetched 30, parsed 30, displayed 0 | Download and parsing are normal; filtering is the main suspect | Temporarily clear include and exclude conditions |
| Fetched successfully, parsed 0 | The body format was not recognized | Check the response content and encoding |
| Parsed 20, added 0, updated 20 | Nodes already existed; only the existing records were updated | Check the currently displayed group |
| Group A has nodes, but the current list is empty | The interface is viewing another group | Switch the subscription group on the left |
Record the filter conditions
Open “Subscription groups” → “Subscription group settings,” and copy the current include and exclude rules first so they can be restored after troubleshooting.
Clear include conditions
Temporarily remove region, multiplier, and protocol keywords. Keep only the subscription name and URL, save, and update this group separately.
Clear exclude conditions
Remove rules used to hide expired, low-traffic, or test nodes, then confirm that the full list appears with filtering disabled.
Restore rules one at a time
Restore only one condition at a time and update after each change, recording the node count. If the count drops from 24 to 0, the last restored condition is the main suspect.
In v2rayNG, also confirm the current group and subscription filter state. Menu layouts may differ between versions, but the principle is the same: show the complete subscription result first, then restore keyword filters one by one. v2flyNG uses the v2fly core, so when its list is empty, first distinguish fetching, parsing, and display stages as well.
Conclusion: Separate parsed count from displayed count
When the log shows a parsed count above 0 but the main list shows 0, check the selected group and filter conditions first. Only when the parsed count itself is 0 should you investigate the response format and encoding further.
Restore the subscription in a fixed order
A reliable recovery process minimizes variables. Changing DNS, ports, the core, the subscription URL, and filter rules all at once may make the problem disappear temporarily without revealing the real cause.
Keep one existing node that can start and use it to verify proxy-based updates. Then replace only the subscription URL. Restore filters only after confirming the parsed count. Throughout the process, monitor the log and node count for the same group.
Confirm that the core is running
Check the bottom log to confirm that the local listener has started. Open “Settings” → “Parameter settings” and verify the core type and listener port, with no port-conflict errors.
Keep a working node
Do not delete all old nodes. Choose one that has passed a real connection test and first verify that the current proxy path can establish a connection.
Update one group
Use the newly obtained full URL and update only the affected group. Record the HTTP status, response length, parsed count, and update time.
Compare the two paths
If direct updates time out but proxy updates succeed, keep using the proxy method. If both methods return 403, fix the URL permissions instead of continuing to change the port.
Restore the filter rules
Confirm that nodes are visible with filtering disabled, then restore include and exclude conditions one at a time. After each update, compare the parsed count with the displayed count.
Test an actual connection
Run a real connection test on one node. After latency results appear, enable the system proxy and visit a commonly used site. Do not judge node availability solely by a successful subscription update.
| Final result | Confirmed conclusion |
|---|---|
| Recovery immediately after replacing the URL | The original URL expired, was truncated, or lost authorization |
| Only proxy-based updates succeed | The direct route, DNS, or network interface is restricted |
| Recovery after clearing filters | The include or exclude conditions were too strict |
| HTTP 200 but parsing still returns 0 | The response format is incompatible or the body is not subscription content |
What to collect if the problem persists
If updates still fail after the steps above, gather information that identifies the failing stage. Do not share the full subscription URL because it may contain access parameters. You can share the protocol, whether the domain resolves, the HTTP status, and the body length without exposing complete credentials.
The client version also matters. Record the exact version of v2rayN, v2rayNG, or v2flyNG, along with the Xray or v2fly core version. The client usually performs subscription parsing, but version differences can affect field recognition, redirect handling, and group behavior.
- Client name and full version, such as the exact minor version of v2rayN 7.x.
- Operating system version and current network type.
- Whether the update command uses a proxy.
- Time of the error, HTTP status code, and complete error text.
- Response length, parsed count, updated count, and final displayed count.
- The core type and local listener port under “Settings” → “Parameter settings.”
- Include conditions, exclude conditions, and the currently selected group in the subscription group.
Symptom: The same URL stops working on multiple devices
Cause and fix: First suspect an expired URL, an account-status change, or an abnormal server response. Obtain a valid URL again instead of changing ports separately on every device.
Symptom: Desktop succeeds but Android is empty
Cause and fix: Compare the client versions, subscription-group filters, and response-parsing logs on both devices. Confirm that Android uses the complete URL, clear its filters, and update again.
Symptom: The update succeeds but every node is unusable
Cause and fix: Fetching a subscription and connecting to a node are separate stages. Run a real node connection test, then check server-address resolution, system time, transport parameters, and routing settings.
After subscription updates recover, if webpages still bypass the proxy, continue with the system proxy and routing settings. In v2rayN, verify the system proxy status and active server; on Android, confirm that v2rayNG or v2flyNG has started its connection and check the live log for outbound errors.