For users whose subscriptions fail to update or show no nodes in v2rayN, v2rayNG, or v2flyNG. First identify whether the failure occurs during the request, response, parsing, or filtering stage. Then check the subscription URL, network route, response format, and group filters. Change one setting at a time and keep your working configuration intact.
1. Tell a Failed Request from an Empty Parse
“Subscription update failed” can point to several different problems. The client first sends an HTTP request to the subscription URL, identifies the response format, parses the nodes into a group, and displays them in the interface. A timeout may mean no response was received. A parse error means the response may not be a valid subscription. An empty list could also be caused by the selected group or search filters.
Start by opening the client log or update status and noting the first error and when it occurred. Don’t mistake core logs from a node connection for subscription download logs: the client may fetch subscriptions using its own network component, while the selected core handles node connections. Errors in one path don’t explain the other.
- It times out after waiting: Check subscription-domain DNS, network connectivity, and whether the update is routed through a proxy.
- It fails to parse immediately: Check whether the response is a login page, error page, or unsupported configuration format.
- It says the update succeeded, but the list is empty: Switch to the target group, clear the search field, and then check the filters.
- Nodes appear but won’t connect: The subscription import likely worked. Check the server address, port, protocol parameters, and TLS settings separately.
2. Verify the Subscription URL and Account
A subscription URL is not the provider’s homepage or account dashboard. Copy it again from the provider’s “Copy subscription link” option or the relevant client-specific entry, then paste it into the subscription group’s URL field. These links often contain access credentials. Don’t post the full URL publicly or submit it to online decoders or subscription converters.
-
Keep Your Existing Configuration
Back up the client configuration or keep the original subscription group. Don’t delete your only working nodes before confirming the new URL works, and avoid repeatedly clearing the list and importing again.
-
Get a Fresh Link
Check the subscription expiry and authorization status in your provider account, then copy a client-compatible URL again. If you reset the subscription, the old URL may no longer work.
-
Check the Characters
Check the beginning, end, and query parameters of the URL locally. Remove spaces, line breaks, or quotation marks added during copying. Don’t remove parameters after the question mark or replace ASCII punctuation with full-width characters.
-
Update One Group
In v2rayN, open “Subscription Groups” and select “Subscription Group Settings” to check the URL. In v2rayNG, open “Subscription Group Settings” from the side menu. Save your changes and update only the group you’re troubleshooting to avoid mixing in errors from other subscriptions.
Menu labels may differ slightly between versions; use the subscription group editor in your current interface. Check v2flyNG’s menus and options separately rather than assuming its update behavior is identical. If the link came from a chat message, check for a Chinese full stop at the end. If you copied it from page source, make sure parameter separators haven’t been copied as &.
3. Check Whether Updates Depend on a Broken Proxy
Routing an update through a proxy isn’t inherently wrong; the problem is whether that proxy still works. If the client needs a dead node to download a new subscription, you get a dependency loop: the old node can’t connect, so the subscription request times out too. Conversely, if the subscription domain isn’t directly reachable on your network, forcing a direct connection won’t help either.
Error: The operation has timed out
Cause and fix: The request didn’t finish in time, but that alone doesn’t tell you whether the account has expired. Test updates both without a proxy and through a known-working proxy, then check whether the subscription domain is reachable.
Error: No such host is known
Cause and fix: The hostname required for the request could not be resolved. Check whether the hostname in the log belongs to the subscription server or the proxy, then verify its spelling and your current network’s DNS. Don’t change node protocol settings.
Error: Connection refused
Cause and fix: The target port refused the connection. Check whether the error points to the remote subscription service or a local proxy listening port. If it’s a local port, make sure the client core is running and the port matches your proxy settings.
In v2rayN versions with the relevant menu, go to “Subscription Groups” and compare an update option labeled “without proxy” with one labeled “through proxy.” If v2rayNG has a “Update subscriptions through proxy” option under “Settings,” note its current state, switch it once, and update the current group. If your version doesn’t have that option, don’t assume another client’s menu path applies.
- If updates work without a proxy but fail through one, check the selected node and local proxy listener first.
- If updates work through a usable proxy but fail directly, keep the working update route and check DNS resolution or access restrictions on your local network.
- If both methods fail, check the HTTP status and response. Don’t keep switching routing modes at random.
- If TUN is enabled, note that “without proxy” usually describes the application-layer request; it doesn’t guarantee packets bypass the virtual network adapter. If needed, record the current state, temporarily disable TUN, and compare results.
4. Use the Status Code and Response to Find the Cause
Being able to open the subscription domain’s homepage doesn’t mean its subscription endpoint works. An HTTP 200 only means the request received a successful response; it doesn’t guarantee the content can be parsed. If the log shows a status code, use the table below to narrow down the issue. If the client doesn’t show the response body, ask the provider for details about the endpoint error. If you need to inspect the response locally, do so only on a trusted device and don’t sync or forward content that contains credentials.
| What You See | What It Usually Means | What to Do Next |
|---|---|---|
| HTTP 401 | The endpoint requires valid authentication, but the credentials weren’t accepted | Copy the subscription link again from your signed-in account and verify your authorization status |
| HTTP 403 | The server rejected the request, possibly due to an access policy | Check the server’s error details; don’t assume the account has expired |
| HTTP 404 or 410 | The endpoint doesn’t exist or the resource has been removed | Check whether the old subscription endpoint has moved, then get the current URL |
| HTTP 429 | Updates are too frequent or have triggered rate limiting | Stop retrying and wait for the Retry-After value in the response or the provider’s guidance |
| HTTP 5xx | The server or an intermediate gateway encountered an error | Keep your local nodes, try again later, and check the server status |
| HTTP 200 with an HTML response body | The response may be a login, verification, or error page | Use the dedicated subscription URL and check that the endpoint doesn’t require browser interaction |
| HTTP 204 or an empty response body | There’s no response content to parse | Check your subscription entitlement, server-side node allocation, and endpoint response |
Bottom line: Make sure the subscription response is there before troubleshooting parsing
If the response is a login page, access denied, or empty, fix the endpoint or authorization first. Check encoding and filters only after confirming the response contains node data supported by the client.
A URL that works in a browser but fails in the client may rely on the browser’s login cookies, automatic web verification, or a different network route. Copying the page URL from the browser address bar usually won’t work. If the log shows a certificate error, check the system clock, request hostname, and server certificate. Don’t disable certificate validation to hide a subscription endpoint problem.
5. Check Base64, Share Links, and Configuration Formats
A subscription is a way to distribute content, not a single standardized file format. Common responses include one node share link per line or a Base64-encoded list of links. Format support varies by client version, and a provider’s “universal subscription” may not work with every client.
- Base64-encoded subscription: Some subscriptions encode the entire list of share links as Base64. Decoding it reveals prefixes such as
vmess://orvless://. The missing prefixes in the original text don’t mean the content is corrupted. - Individual share links: Traditional VMess share links usually carry Base64-encoded JSON after the prefix; VLESS share links typically use URI parameters. Don’t “decode twice” for every protocol.
- Base64 variants: Standard Base64 and URL-safe Base64 use different character sets, and their trailing padding may differ. Whether a parser accepts each form depends on its implementation; don’t try to fix it by swapping characters at random.
- Full configuration files: A core JSON configuration isn’t the same as a list of subscription links. An import option that accepts full configurations doesn’t mean “Update subscription” can read the same content.
- Other formats: If the response starts with YAML fields, HTML tags, or an error message but the current import option expects share links, switch to a compatible subscription endpoint provided by your service provider.
If you need to check the encoding, use a local tool and inspect only the structure. Don’t upload decoded content to a third-party service. If decoding reveals an HTML login page, the problem is still the response. If a link is missing a server address, port, or required parameters, ask the subscription provider to fix it; manually filling in fields is not a substitute for a valid configuration.
6. Update Succeeds but the List Is Empty: Check Filters and Display
Filtering usually happens after the content has been fetched. The subscription may return nodes and the client may parse them correctly, while group include rules, exclude rules, or the interface search hide every result. Clear the main search field and select the group you just updated. Don’t judge the result while viewing a different, empty group.
-
Check the Group
Check the subscription group name and saved URL. Make sure the update status refers to the group you’re viewing, not another group with the same name or an old group.
-
Temporarily Clear Filters
Note the current filter settings in the group editor, then temporarily clear them. Not all versions have the same filter fields. If yours doesn’t, check the search field instead.
-
Update One Group Again
Update only the current group and check the log. If the nodes reappear, investigate the filter rules rather than resetting the subscription URL again.
-
Restore Rules One at a Time
Restore one condition at a time and check the list after each change. First confirm whether the field keeps matching items or excludes them, then check whether it accepts plain text or regular expressions.
Only when a field explicitly supports regular expressions does ^$ usually match an empty string and .* usually match any number of characters. In an include field, the former may filter out every non-empty name; in an exclude field, the latter may remove every item. Don’t paste regular expressions into a field that accepts only plain keywords, and don’t assume every version uses the same separator for multiple keywords.
Bottom line: Clear the conditions, then restore the rules
If nodes appear after clearing the filters and search, keep the subscription URL and update route unchanged and fix only the filter conditions. If the list is still empty, go back to the response and format checks.
7. Record the Steps to Reproduce and Avoid Repeated Changes
If you still can’t find the cause, a concise troubleshooting record is more useful than a screenshot of your full configuration. Parsing compatibility can change between client releases, so include the full version number rather than just saying “latest.” If you plan to upgrade, keep your existing configuration and choose the client for your platform on the downloads page. Don’t make uninstalling and reinstalling your first step.
- Environment: Client name and full version, operating system, and whether TUN is enabled.
- Steps to reproduce: Whether you updated one group or all subscriptions, used a direct connection or proxy, and whether the issue happens every time.
- Request result: Exact error text, HTTP status code, and whether the response was empty, a webpage, or subscription text.
- Display result: Whether the list is still empty after clearing search and filters, and whether other existing groups work.
- What you’ve tried: Whether you got a new URL, reset authorization, switched networks, or changed the update route. Before sharing your notes, remove credentials and node access parameters from the URL.
Work through these checks in order: valid URL, reachable request, correct response, supported format, and appropriate filters. Once you’ve confirmed a stage, stop changing it. Changing DNS, routing, the core, and the subscription endpoint all at once makes it impossible to know what fixed the issue.