For v2rayN users seeing “Update failed,” “No available servers,” or an empty group after updating. Keep your existing configuration, then check the URL, request route, response, and parsing results in order. Finish by updating a single group to confirm the fix. Avoid changing the proxy, subscription, and core all at once, so you can tell what made the difference.
First, identify the problem: request failure or empty results
Updating a subscription is not a connectivity test for its nodes. The client first requests the subscription URL and retrieves text, then parses that text into server entries and adds them to a group. A reachable subscription URL does not mean its nodes work; working nodes do not mean the subscription endpoint is still valid. Identify which step failed before troubleshooting, so you don't mistake a download issue for a protocol problem.
- Connection timed out or name resolution failed: The request didn't retrieve content successfully. Check your network, DNS, and update route first.
- HTTP error status received: The server responded. Check authentication, URL validity, and server-side restrictions first.
- Request completed but no entries were added: Check the response, subscription format, and group filters. Don't switch cores right away.
Open the log or output panel on the main screen and note the time, exact error message, and target group around the failed update. Panel locations and menu labels can vary slightly between desktop versions. The steps below refer to common labels in the Chinese interface; look for the options corresponding to “Subscription Group Settings” and “Update via Proxy.”
Round 1: Keep your configuration and check the subscription URL
Don't delete the entire group first. Some failed updates leave existing entries intact, while other replace operations may clear the list. Your existing working nodes may be needed to update through a proxy. Backups and exported share links contain sensitive connection details, so store them only in a trusted local location.
-
Keep your existing configuration
On the main screen, select a working server and use the right-click menu to export a copy of its share link. To back up the entire configuration directory, exit the client first and copy the data directory used by the current installation; copying only the program files isn't enough.
-
Check the group
Go to “Subscription Group” → “Subscription Group Settings,” select the affected group, and confirm that its URL belongs to your current account and that updates are enabled. If you have several similar groups, check their labels and URLs first to avoid updating the wrong one.
-
Copy the URL again
Copy the v2rayN subscription URL again from your provider's subscription page and replace the old one. Check that it starts with
https://, contains no spaces, line breaks, or typographic quotation marks, and retains all query parameters. -
Retest one group
Save, then update only this group. Note the log and entry count. Don't rebuild every group or edit multiple nodes at once, or it will be hard to tell which action caused the change.
Round 2: Distinguish direct updates from proxy updates
Opening a subscription URL in your browser only proves that the browser's network route works. The browser may follow the system proxy, while the client's “Update Subscription (without proxy)” option uses a different route. Simply toggling the system proxy doesn't guarantee that subscription downloads will use it. Choose the update method in the subscription menu explicitly.
- Try a direct update first: In “Subscription Group,” choose the update option labeled “without proxy.” If it retrieves nodes successfully, keep using this method; there's no need to change routing just to download the subscription.
- If direct update fails, try a proxy: Select a known-working existing node and set it as the active server. Confirm that the core starts successfully, then choose the subscription update option labeled “via proxy.”
- If the proxy update also fails: Use the active node to open a known-working HTTPS page. If regular browsing fails too, fix the node connection first instead of repeatedly retrying the update.
- No working nodes left: Retrieve the subscription over another trusted network, or ask the provider for a temporary share link for a single node. An empty list can't establish the connection needed for a proxy update.
For proxy updates, check the local listener settings under “Settings” → “Parameter Settings,” and use the port the client is actually listening on. A port conflict, a core that hasn't started, or a client still pointing to an old listener address can all cause a local connection refusal. Don't copy port values from another machine, and never expose the listener on all network interfaces to fix updates on this computer.
Round 3: Check the status code and exact error message
A status code tells you more than the word “failed.” The three numbers below describe HTTP status codes, not success rates. 200 means the request returned successfully; you still need to check whether the response body is actually a subscription.
The operation has timed out.
Why it happens and what to do: The request didn't complete in time, possibly because direct access is blocked or the proxy isn't working. Keep the same subscription URL, test both direct access and a verified working proxy route, and compare the logs.
Connection refused
Why it happens and what to do: The target refused the connection. Check whether the error points to a local proxy port or the remote subscription server. For a local address, check that the core is running and the listener port is correct; for a remote address, check whether the service is available.
Response status code does not indicate success: 403 (Forbidden).
Why it happens and what to do: The server denied the request, possibly because of the token, account status, source restrictions, or a security challenge page. Get a fresh subscription URL and ask your provider about any restrictions. Don't assume the account has expired based on this log entry alone.
Error messages can vary with the system language and client version. Consider the status code and connection target together. For 404, check whether the path is no longer valid; for 429, stop retrying and follow the server's retry instructions; for 5xx, note the time and contact your provider. For certificate errors, check the system date and time and the certificate trust chain. Don't disable certificate verification as a permanent workaround.
Round 4: Check the response format and Base64 content
A common reason for “request succeeded but no nodes were parsed” is that the server returned a login page, account-expiration notice, or security challenge. These may also use status code 200. If you need to inspect the original response, use a trusted local tool to view the response text. What a page looks like in your browser doesn't prove what the client received; use the client's request result as the source of truth.
| Response pattern | Possible cause | What to do next |
|---|---|---|
Starts with <!DOCTYPE html> or <html | Login page, redirect page, or security challenge | Copy the client-specific subscription URL again and check the server's access restrictions |
| Empty response or account notice only | No nodes available from the endpoint, or the account doesn't meet the requirements | Check the plan's validity, remaining data allowance, and node allocation |
Multiple lines of vmess://, vless://, and similar links | A list of common share links | Test importing one complete link locally to distinguish a single-link issue from a bulk parsing problem |
| A long encoded string | Possibly the entire list encoded as Base64 | Decode it locally once and confirm the result contains node links, not a webpage or notice |
YAML text with fields such as proxies: | Another configuration format, not a general-purpose share-link list | Choose a subscription format on the provider's site specifically marked for v2rayN |
Base64 is an encoding method, not a node protocol or encryption. Common subscriptions encode a block of text containing multiple share links. A VMess share link may itself contain an encoded node configuration. So it's normal for decoding the outer layer to produce vmess:// links. Don't keep decoding everything and pasting the results back into the subscription settings.
- Rule out truncation: Line wrapping in chat apps, incomplete copying, or mishandling
&in a URL can change the request address. Copy the URL directly from its source page again. - Check the character set: Standard Base64 and its URL-safe variant use different characters, and the trailing padding may be omitted. If decoding fails, check the source first. Don't blindly remove
+or/, or add arbitrary characters. - Check format compatibility: Supported subscription formats vary by client version. Not every YAML file or full core JSON configuration can be imported as a general-purpose subscription.
Round 5: Distinguish parsing failures from display issues
If the log shows that nodes were retrieved and processed but the main window is still empty, check the selected group and search filters first. A search term, a different group, or filters in the subscription settings can temporarily hide existing entries. Repeated updates usually won't fix this.
- Clear the search field on the main screen, switch back to the group you just updated, and show all servers.
- Go to “Subscription Group” → “Subscription Group Settings” and check whether the group has filters configured. Note the current settings, temporarily disable them, and update that group once more.
- If only a few links fail to import, check their protocol, transport parameters, and required fields instead of assuming the entire subscription is invalid.
- If the format is correct but an older client can't recognize it, back up your data, update v2rayN, and test the same content again. Don't change the subscription source and client version at the same time.
Confirm recovery and prepare a support request
Confirm recovery in two ways: the subscription updates reliably, and at least one imported node establishes the expected connection. First check that the target group contains a reasonable number of entries, then test a node. If none of the nodes work, troubleshoot the server address, port, protocol, and transport settings instead of continuing to change the subscription URL.
- Record your environment: Client version, operating system, time of failure, target group, and whether you updated directly or through a proxy.
- Record the results: HTTP status code, exact error, response content type, entry counts before and after the update, and whether the old nodes still work.
- Hide credentials: Redact tokens, full subscription paths, node passwords, and user identifiers. Include only the domain and error context needed to diagnose the issue.
- Contact the right support team: Ask the subscription provider about authentication, empty responses, and endpoint restrictions. If valid content consistently fails to parse in your client, prepare a minimal, redacted set of reproduction details.
Try to change one thing at a time: the URL first, then the request route, then the response, and finally client compatibility. Even if the issue isn't fixed right away, this narrows “subscription failed” down to a specific step you can verify and helps avoid repeated actions.