Common Causes of Subscription Update Failures & Auto-Update Settings for v2rayN and v2rayNG

How subscription updates work: find where they fail

A subscription is a client feature for managing a node list, not a top-level field in the V2Ray or Xray core JSON. During an update, the client requests the subscription URL, receives a response, and converts its nodes into local configuration. Changing routing cannot fix an expired subscription token, and switching cores cannot turn a login page into a valid subscription.

“Update failed” and “node unavailable” are two different issues. An update failure occurs while fetching or parsing the list; a node failure happens after import, when establishing a proxy connection. If existing nodes still work but updates fail, check the subscription URL and update route first. If the update succeeds but websites won't load, check node settings, the local proxy, and routing separately.

• Fails before connecting: Check DNS resolution, your current network, the proxy listening port, and any timeout message.
• HTTP error received: Check the token, account status, server restrictions, and response status code.
• Download completes but no nodes appear: Check whether the response is a login page, error page, or unsupported format.
• Fails only in the background: Check whether the client is running, whether the device is asleep, and whether background tasks are restricted.

Expired links and status codes: verify the subscription URL first

Copy the “subscription URL” again from your provider's account page. Don't use the account homepage, a node details page, or the URL of a QR code image. Query parameters often contain an authorization token; a missing character, an accidental line break, or an old token that has been reset can all cause failures. Whether an expired plan invalidates a subscription depends on the server's policy, so don't draw conclusions from a status code alone.

These numbers are HTTP status codes, not client error IDs. 403 can also come from an access policy or security page; 404 may mean an old path has been withdrawn. Even 200 doesn't guarantee valid content—a login page can also return a success status.

1. Check the beginning and end of the URL in the original group. Remove spaces and line breaks introduced by copying, and don't manually edit or remove token parameters.
2. Check the account page for the expiration date and whether the subscription was reset. If needed, copy the URL again and replace the old one.
3. After receiving 429, stop retrying repeatedly. If the response includes Retry-After, wait as instructed.
4. When asking for help, share only the time, status code, client version, and redacted logs. Never post the full subscription URL.

Updating through a proxy: avoid blocking the subscription with a failed node

“Update subscription through proxy” controls the network route used to fetch subscription content; it doesn't switch every app to global proxy mode. In v2rayN, compare “Update subscription (without proxy)” with “Update subscription (through proxy)”: use the same group and URL, test each route in turn, and record the results.

If updates must go through a proxy and every node in the current group is already down, you have a dependency loop. Try updating directly, or use another verified working node to fetch a fresh list. Repeatedly restarting the same failed node usually won't break the loop.

Certificate, timeout, and format errors: work from the logs

Review logs for a single update at a time. Note the update time, then find the corresponding error line; don't mix in node latency tests or website access errors. These are common low-level error messages, though other details may appear depending on the system and version.

A subscription response may be plain text containing node share links, or it may be Base64-encoded. A browser downloading what looks like random text doesn't necessarily mean it's corrupted. If you see <html>, a login form, or an access verification prompt, resolve the authorization or access restriction with the provider. Browsers may have login cookies that the client doesn't, so opening the URL in a browser alone doesn't prove the client can use it as a subscription.

• The same protocol name—VMess, VLESS, Trojan, and others—doesn't guarantee that both clients support identical transport parameters.
• Prefer a subscription format your provider explicitly lists as compatible with v2rayN or v2rayNG. Don't paste in a different format without checking compatibility.
• If only some nodes fail to import, check the client version and support for the specific parameters before deleting the entire group.

Auto-update subscriptions in v2rayN: set an interval for each group

In the v2rayN desktop client, complete one manual update before setting a schedule. In many versions, go to “Subscription Group” → “Subscription Group Settings” in the main window, then set “Auto Update Interval” in the target group's edit window. Button locations and field units may vary by version, so follow the units shown in your current window.

1. Check the target group

   Open “Subscription Group” → “Subscription Group Settings,” edit the group you want to refresh, and check the subscription URL and enabled status. Keep the existing nodes for now so you don't lose working configurations while troubleshooting.

2. Verify a manual update

   Save, return to “Subscription Group,” and select “Update subscription (without proxy).” If the subscription source requires a proxy, select a working node and test “Update subscription (through proxy).” Confirm the log reports success and the node list changes as expected.

3. Set the refresh interval

   Return to the group edit window and set the auto-update interval. Start with every 6 hours: enter 360 if the field is in minutes, or 6 if it's in hours. Don't copy a number without checking the units in your version.

4. Save and monitor

   Save the settings, keep the program running, and check the logs after the scheduled time. If there's an update route option, use the route that worked in the previous step. Choosing proxy update manually once may not change the route used by background tasks.

Auto-update isn't a system-level background download service. It can't request subscriptions on schedule while the program is closed, the computer is off, or the system is asleep. Whether a missed update runs later depends on the version, so check the actual update time in the logs instead of relying on the tray icon.

Auto-update subscriptions in v2rayNG: check settings and background permissions

On Android, check the URL under “Subscription Group Settings” in the side menu, then tap “Update subscription” from the main screen's top-right menu. Scheduled refresh support and editable intervals vary by installed version. Don't mistake “Update on startup” for a recurring background task.

1. Verify a manual update

   Open “Subscription Group Settings” and save a valid URL. Return to the main screen, open the top-right menu, and tap “Update subscription.” Confirm at least one update succeeds before configuring background behavior.

2. Enable auto-update

   Open the side menu → “Settings,” find “Auto-update subscriptions,” and enable it. If your version has an update interval field, start with 6 hours; enter 360 if the field uses minutes. If there is no interval field, use the scheduling option provided by the app—don't assume a hidden toggle exists.

3. Allow background activity

   Long-press the app icon → “App info” → “Battery,” then allow background activity. Some devices label this option “Unrestricted.” Also check background data access under “Mobile data & Wi-Fi” or “Data usage”; the wording varies by system.

4. Check what happens while the screen is locked

   Note the time of a manual update, lock the screen, and wait one scheduled interval before checking the update log or timestamp. If your version doesn't show a timestamp, use the logs and changes to node details as clues. An unchanged node count doesn't necessarily mean the update failed.

v2rayNG uses the Xray core, but subscription fetching and background scheduling are implemented by the client. Don't edit the core's policy or invent a subscription field to fix scheduled tasks; those changes don't replace the app's settings.

Verify the update: a successful list refresh doesn't guarantee a working connection

A subscription update typically rebuilds the contents of its group. Node names, order, and count may all change, and nodes removed by the provider may disappear. Export manually maintained nodes or move them to a separate group beforehand so they don't get mixed in with subscription-managed entries.

• First: Update time. Confirm this request actually completed; don't rely on the previous successful update record.
• Second: Parsing results. Check that nodes appeared in the correct group. If there are none, verify the server response and format.
• Third: Actual connection. Test access using a new node to distinguish a successful subscription update from an available node service.
• Fourth: Background retest. Wait for the next scheduled run and check for authorization errors, rate limits, or route dependencies.

Keep four details in your troubleshooting notes: client version, time of the failure, direct or proxied route, and the complete error excerpt. Remove subscription tokens and account details before sharing. This makes it easier to distinguish local background restrictions from server issues and to retest after an upgrade or network change.