For users seeing subscription timeouts, empty lists after an update, or nodes that won't parse in v2rayN, v2rayNG, or v2flyNG. First determine whether the subscription couldn't be downloaded, returned unexpected content, or imported nodes that won't start. Then check the URL, response format, request route, client, and core in order. Change one variable at a time and keep any nodes that still work.
First, find where the update fails
Updating a subscription involves more than testing a connection. The client requests content from the subscription URL, identifies its encoding and node format, then adds the parsed results to a group. Whether a node connects can only be determined after the core loads its configuration and connects to the server. So a successful update doesn't mean every node works, and a connection timeout doesn't necessarily mean the node itself is at fault.
- No response received: Check DNS resolution, connection timeouts, certificates, and the network used for the request.
- Content received, but no nodes imported: Check for login pages, error messages, subscription format, and filter settings.
- Only some nodes are missing: Check the affected protocols, individual node fields, and the client's parsing support.
- Nodes appear but won't start: Check the core logs; this is no longer just a subscription download issue.
Step 1: Check the subscription URL and group settings
A subscription URL is usually a complete address beginning with https://. By contrast, vmess:// and vless:// are commonly used for individual node share links. If you enter a single-node link in the subscription URL field, the client may not treat it as a network subscription. Your provider's account home page, payment page, and subscription URL are separate destinations.
-
Open the group settings
In the v2rayN main window, open “Subscription Group” → “Subscription Group Settings” and select the affected group. Menu labels may vary slightly by version. Open the window where you can edit the subscription URL, not the node editor.
-
Copy the URL again
Copy the address for your current client from the provider's subscription page. Check the protocol at the beginning and parameters at the end; remove leading or trailing spaces and line breaks. Don't manually remove
?,&, or encoded characters from the URL. -
Check that the group is enabled
Make sure the group is enabled. Temporarily clear its node filters, then switch to that group to view the list. This helps rule out nodes being hidden in the current group rather than all subscriptions being empty.
-
Update this group only
Save the settings, then choose the update action for this group under “Subscription Group.” Note the number of imported nodes and compare it with the nodes available on the provider's page.
On Android clients, first open the subscription group editor and check the URL, then select “Update Subscription” from the main menu. The v2rayNG and v2flyNG interfaces vary by version, so don't assume desktop menu paths apply to Android. Finding the “Subscription URL” field is more useful than repeatedly tapping Update.
- Generating a new subscription token may immediately invalidate the old URL. Replace the saved address in your client.
- If your account has expired or run out of data, the server may return an error message instead of a node list.
- Keyword filters may exclude every node. Restore the nodes first, then add filter rules back one at a time.
Step 2: Confirm the response contains node data
A successful network request only means that a response arrived. Opening the subscription URL in a browser doesn't guarantee the client receives the same content: the browser may be signed in, and the server may return a different format based on the User-Agent. In particular, distinguish subscription data from an account login page.
| What the response looks like | Possible cause | What to do next |
|---|---|---|
| A login prompt or webpage markup appears | You copied a web page URL, or the request was redirected to a verification page | Copy the dedicated URL from the subscription page and check your account status |
| A long block of encoded text | It may be a Base64-encoded list of nodes | Import it with a client that supports this subscription format; don't assume it's corrupted based on appearance alone |
| Each line starts with a node protocol | It may be a list of plain-text share links | Check whether the client supports the protocols and fields used |
| YAML configuration fields appear | A different configuration output format was selected | On the provider's page, switch to the subscription option for your client |
| The body only mentions expiration or permissions | The endpoint is reachable, but the account or token is invalid | Resolve the account issue or generate a new subscription URL |
Base64 is an encoding, not encryption. An entire subscription may be encoded once, and the payload in an individual VMess share link may also be encoded separately. VLESS share links usually express parameters in URL fields. Not all subscriptions use the same format, so don't treat them all as JSON or repeatedly decode and overwrite the original URL to “fix” the encoding.
Step 3: Check the network using status codes and error messages
Status codes are more specific than “update failed.” The numbers below are HTTP status codes, not speed test results. If the log doesn't show a status code, keep the original error instead of assuming the server is down.
Error: 401 Unauthorized
Cause: The endpoint didn't accept the current authentication details, often because the token has expired. Fix: Copy a valid subscription URL again and check your account status. Don't keep retrying the old URL.
Error: 403 Forbidden
Cause: The server rejected the request, possibly due to access policies, account restrictions, or the request's origin. Fix: Check your provider's guidance, subscription URL, and request method. This error alone doesn't prove that your password is wrong.
Error: 429 Too Many Requests
Cause: The request triggered rate limiting. Fix: Stop clicking Update repeatedly and wait as instructed by the server. If the response includes Retry-After, observe that wait time.
Error: No such host is known.
Cause: This DNS resolution error can occur during network requests on Windows. Fix: First check that you copied the full subscription domain, then compare using another trusted network. Don't change node settings yet.
Error: certificate has expired or is not yet valid
Cause: Certificate validity checks failed. The device clock may be wrong, or there may be a problem with the server's certificate. Fix: Sync the date and time in your system settings first. If the time is correct and the error persists, contact your provider. Don't disable certificate verification.
A timeout means only that the request didn't finish within the allotted time. On the same device and URL, compare your home network with a mobile hotspot. Change only the network each time; don't also change the subscription format or client. If both networks return the same account error, revisit the URL or account rather than switching DNS again.
Step 4: Compare updates with and without a proxy
v2rayN's subscription menu offers update options with and without a proxy. The system proxy setting, whether subscription requests go through a proxy, and TUN routing are separate settings. When TUN is enabled, even a request marked “without proxy” may be affected by system routing. The menu label alone doesn't tell you the actual route.
-
Try a direct update first
Under “Subscription Group,” choose the update option marked “Without Proxy.” If it works, note the result and avoid changing nodes or the core for now.
-
Check an existing node
If the direct update fails, select a known working node and confirm that you can access a regular web page. If the existing node doesn't work, updating through a proxy may time out as well.
-
Then try updating through a proxy
Run the subscription update marked “Through Proxy” and compare whether the error changes from a timeout to a specific HTTP status code. Test each method once; don't keep refreshing.
-
Check TUN routing
If TUN is enabled, temporarily turn it off and repeat the same test. Note the result, then restore the original setting. Avoid changing the system proxy, routing mode, and subscription URL at the same time.
Updating through a proxy requires a working proxy. If all existing nodes are down and only a proxy route can reach the subscription domain, you're stuck in a dependency loop. Ask your provider for an alternative subscription URL that works directly, or switch to a network that can reach the endpoint. Switching to “Global” routing won't create a working node.
- Direct update works, proxy update fails: Check the current node and proxy request route; keep using the direct update option.
- Direct update fails, proxy update works: The two request routes produced different results; that doesn't mean the subscription encoding changed.
- Both return the same access error: Check your account, token, or the endpoint's access policy first.
Step 5: Separate client parsing from core compatibility
The client usually parses a subscription first, then generates a configuration for the core to read. Updating the core won't necessarily fix share links the client can't recognize. Conversely, seeing nodes in the list doesn't guarantee the selected core accepts all their parameters. Record the client and core versions separately rather than just saying “everything is up to date.”
| Symptom | Check first | What to do |
|---|---|---|
| None of the links can be recognized | Output format and client parsing support | Choose the subscription option for your client, update the client, and test again |
| Only one protocol is skipped | The individual protocol, transport, and security parameters | Note the affected node type and ask your provider for a compatible format |
| Import succeeds, but the core won't start | Generated configuration and core support | Check the startup log and confirm which core is actually in use |
| Core starts, but connections time out | Remote service, network, and connection settings | Test a single node connection instead of repeatedly reimporting the subscription |
v2rayNG uses the Xray core, while v2flyNG uses the V2Fly core. v2rayN is a desktop client; check its settings and startup logs to see which core a node uses. “Supports VLESS” doesn't mean “supports every VLESS configuration.” For example, with a REALITY node, check the relevant Xray capabilities and version requirements. Changing only the protocol name won't make it work with a different core.
- Back up your current configuration first, then get the version for your system from our client downloads page. Don't overwrite your setup and immediately clear the group.
- If subscription parsing fails, update the client first. Check the core only when core loading fails; these are separate steps.
- When contacting your provider, specify “VMess or VLESS, transport, security mode, client version, and core version.” You don't need to include full credentials.
Verify the recovery and document the issue
Once updates work again, check the node count and group assignment, then test a node's actual connectivity. A successful latency test only shows that the test method received a response; it doesn't prove that every site or routing rule works. Verify access to a regular web page first, then restore filters and automatic updates one at a time.
- Check the list: Note the node count after recovery and make sure you're not viewing another group or old search results.
- Check the update route: Keep using the direct or proxy method that worked, so automatic updates don't continue using the failed route.
- Restore filters: Add one keyword filter at a time and make sure it doesn't hide the entire current list again.
- Avoid repeated requests: Set the automatic update interval according to your provider's recommendations. Don't use frequent refreshes as a substitute for troubleshooting.