This guide covers subscription update issues with v2rayN, v2rayNG, and v2flyNG. First determine whether the client failed to retrieve the subscription or retrieved content but found no recognized nodes. Then check link access, response format, update route, and certificates. Keep your working configurations, change one thing at a time, and use the update log to identify where the failure occurs.
Identify where the update fails
A subscription update fetches a server list; it is not a connectivity test for individual nodes. The client requests the subscription URL, receives a response, parses its contents, and adds the results to the selected group. Only then does the Xray or V2Fly core use a node configuration to establish a connection. So a successful subscription update does not mean every node will connect, and a working node does not mean the subscription URL is still valid.
Check in this order: link and access, content format, update network path, then TLS certificates. This order prioritizes issues that are easy to verify and inexpensive to fix; failure rates vary across network environments. Open the client log first and note the time and full error for this update, so you don't mistake an earlier connection error for a subscription issue.
- Connection timed out or DNS lookup failed: The client probably hasn't received a valid response yet. Check the network and DNS first.
- Response is 401, 403, or 404: The server returned a response. Check access permissions, request policies, and the URL first.
- Update completes but adds zero nodes: Check the response body, format compatibility, and filters on the selected group.
- Nodes appear but don't work: Check node settings, core support, and routing. Don't keep resetting the subscription.
Expired links and access changes: verify the subscription URL first
Subscription URLs often contain account tokens. Resetting a subscription, a plan expiring, a change to your account status, or an API change by the provider can invalidate an old URL. Being able to sign in to the provider's website only confirms that your browser session works; the client may not send the same login credentials with its subscription request. Copy the subscription URL provided for your client, not the URL of an account page.
-
Keep your current list
Note the current group name and node count. If you need a backup, save it in a secure local location. Don't delete the existing group or include token-bearing links in public screenshots.
-
Get a fresh URL
Open the provider's subscription management page, verify your account status, and copy a new URL in the format for your client. Keep all query parameters, and remove any spaces, line breaks, or quotation marks accidentally copied with it.
-
Check the group settings
In v2rayN, the usual path is “Subscription Group” → “Subscription Group Settings.” Open the target group and check its URL. On Android, open “Subscription Group Settings” from the main menu and edit the relevant entry. Menu labels may vary slightly by version.
-
Update only the target group
Save the changes, update just that group, and check the log right away. Don't update every source at once; a success message for one group can hide an error in another.
Generating a new URL usually invalidates the old token, so you'll need to update it on your other devices too. Don't assume a 403 means your plan has expired: source restrictions, protection pages, and rate limits can return the same status. Assess the status code alongside the information on your provider's account page.
No nodes found: check the response and its format
A successful HTTP request only means that content was retrieved—not that it was a node list. A login page, maintenance notice, security check page, or even a JSON error message can all come back with a 200 status. If parsing returns no nodes, check the content before considering a client upgrade. Pasting the same error page again won't change the result.
| What it is | How to identify it | What to do |
|---|---|---|
| Subscription request URL | Usually starts with HTTPS and fetches a list | Enter it in the subscription group URL field, then update |
| Single share link | Often starts with vmess:// or vless:// | Import from the clipboard; don't use it as a remote subscription URL |
| Base64-encoded list | Usually decodes to multiple share links | Confirm the client supports the subscription encoding and protocols |
| Other configuration text | May be YAML or a complete JSON configuration | Ask the source for a subscription format compatible with your client |
| Web page or error message | Contains HTML tags, a sign-in prompt, or access information | Fix the URL, permissions, or access policy—not the nodes |
Base64 is an encoding, not encryption or a protocol name. A long string doesn't prove the content is complete or valid; don't add characters based on guesswork. If you need to inspect it, use a secure local environment. First check that nothing was truncated, then verify that the decoded content actually contains share links.
Also distinguish between a client that can parse a share-link format and a core that can run the resulting configuration. On Android, v2rayNG uses the Xray core, while v2flyNG uses the V2Fly core. For features such as REALITY, check support in the core and version you're actually using. Switching clients won't fix an invalid token or automatically convert an arbitrary configuration file into a compatible subscription.
- Clear the search filter on the main screen and make sure you haven't switched to a different subscription group.
- Compare the group counts before and after the update to make sure filters aren't hiding nodes.
- If only some nodes are skipped, note their protocols and parsing errors; don't assume every node is invalid.
Subscription updates bypass the proxy: test direct and proxied routes separately
Subscription requests don't necessarily use the same network route as your browser. Some clients have a separate setting for subscription updates, and selecting “without proxy” uses a direct connection even when the system proxy is enabled. Conversely, a proxied update will fail if it relies on a current node that is already down, creating a loop where you need an update to get a working node.
-
Test a direct update
In v2rayN, open the “Subscription Group” menu and select the “Update without proxy” option for the subscription. Note whether it times out, fails DNS resolution, or returns an HTTP status—not just that it “failed.”
-
Make sure the proxy works
Select an existing node that you've verified works, make sure the core is running, and confirm that a regular HTTPS request completes. A latency test alone doesn't prove that full web requests will work.
-
Try updating through the proxy
In the same menu, choose the corresponding “Update through proxy” option. On Android, connect using an existing working configuration, then update the subscription from the main menu and check the log for the result. Don't infer the request route from the connection icon alone.
-
Compare the two results
If the proxy works but direct access fails, focus on the direct network connection and DNS. If direct access works but the proxy fails, check proxy egress and the access policy for the subscription domain. If both fail, check the URL and certificates next.
To check a desktop client's local proxy port, use the actual listening address shown under “Settings” → “Parameter Settings.” For example, check 127.0.0.1:10808 only if the interface is configured to use that address; 10808 is not a universal default across versions and protocols. HTTPS subscriptions typically connect to remote port 443, which is separate from the local proxy listening port.
Certificate and network errors: choose a fix based on the exact message
TLS verification happens before subscription content is parsed. A certificate error may prevent the client from retrieving the subscription body at all. Check the system date, time zone, and automatic time sync first, then verify the subscription domain and certificate chain. Don't treat a node's “skip certificate verification” setting as a fix for subscription downloads; they may apply to entirely different request layers.
Error: x509: certificate has expired or is not yet valid
Cause and fix: The certificate's validity period doesn't match the current time. The device clock may be wrong, or the server certificate may have expired. Sync the system clock first; if the error persists, ask the provider to renew the certificate.
Error: x509: certificate signed by unknown authority
Cause and fix: Your device may not trust the issuing chain, or a network device may be replacing the certificate. Update the system trust store and test on a trusted network. Ask the server operator to provide the complete certificate chain; don't install root certificates from untrusted sources.
Error: Could not resolve host
Cause and fix: The current DNS path can't resolve the subscription domain. Check the spelling, make sure you're online, and compare the result on another trusted network.
Error: Connection refused
Cause and fix: The target port refused the connection. The target could be the subscription server or a local proxy. Identify the host and port in the log, then check the service status or proxy listening settings.
Error messages can vary by operating system and request component, so the examples above may not match your log word for word. A connection reset or timeout alone doesn't prove there's a certificate problem; identify the stage where the error occurs.
- Android: Check “Settings” → “System” → “Date & time” for automatic time settings. The exact path depends on your device.
- Windows: Go to “Settings” → “Time & language” → “Date & time” and sync the clock.
- Public Wi-Fi: Complete the network sign-in first. A captive portal may intercept the subscription request and return a web page instead.
- Persistent certificate error: Don't replace the domain with an IP address. This can cause a certificate name mismatch and may break server routing.
Verify the update and document the result
After fixing the issue, verify the update result and test an actual node connection. First check that the expected entries appear in the target group, then test one of them. If the update succeeds but the connection fails, keep the successful update record and check node settings, core support, system proxy, and routing rules instead.
-
Check the update result
Make sure the current log has no remaining parsing errors, search filters aren't hiding entries, and the nodes are in the right group. The node count should match the content actually provided by the source.
-
Test one node
Select a new entry, start the connection, and visit a normal HTTPS page. Record latency tests separately from real browsing; don't draw conclusions from a single test number.
-
Prepare a redacted report
Record the client version, operating system, update time, direct or proxied route, HTTP status, and exact error message. Before sharing, remove tokens, node passwords, and the full subscription body.
If you still need help, describe the comparison—for example, “The same URL times out on a direct update but returns 403 through an existing node.” This makes network and access issues easier to distinguish than saying “the subscription is broken.” Don't keep clicking update; if you get a 429 status or an explicit rate-limit message, wait as instructed by the server before trying again.