This guide is for users who have already added a subscription but encounter timeouts, empty results, occupied ports, or automatic updates that do not run in v2rayN or v2rayNG. Check the subscription URL first, then determine whether it requires a proxy, inspect local ports and system time, and finally set a suitable automatic update interval.
First identify where the update fails
Updating a subscription is not the same as connecting to a node. When a client updates a subscription, it reads the saved URL, sends a request to the subscription server, receives text or structured data, and parses it into VMess, VLESS, and other node records. The node list changes only after all these steps are complete. Therefore, “old nodes still connect” does not mean the subscription URL remains valid, and “subscription update succeeded” does not mean every node in the subscription can connect.
When an update fails, first record the exact message from the dialog or log instead of clicking Update repeatedly. Repeated retries may trigger server-side rate limits and mix multiple attempts together in the log. In v2rayN 7.x, check the log area at the bottom of the main window for the request result. If it is hidden, open it through “View” → “Log”. Record the request time, HTTP status, timeout message, and number of returned nodes.
| Observed result | Most likely issue | Next step |
|---|---|---|
| 401, 403, or invalid URL appears immediately | Subscription credentials expired, the URL was reset, or the address was copied incompletely | Return to the subscription provider and obtain the complete URL again |
| Times out after about 10–30 seconds | The direct route is unreachable, DNS is failing, or the update requires a proxy | Connect to a working node first, then update through the proxy |
| Reports success but shows 0 nodes | The response is a login page, error page, or incompatible content | Check the response type and confirm the subscription format |
| The core cannot run after the client starts | A local listening port is already in use | Check the ports currently configured, such as 10808 and 10809 |
Bottom line: distinguish “download failed” from “parsing failed” first
A request timeout occurs before the subscription data arrives, so investigate the network path. If data was received but no nodes appeared, inspect the response and subscription format. These two problems require different fixes.
Expired subscription links and abnormal responses
Subscription URLs usually contain a long string used to identify your account. One missing character, automatic truncation by a chat app, or spaces added at either end can cause the server to return an error. Replace the entire URL when editing a subscription rather than changing only its ending. If the same URL stops working on two devices while other websites remain accessible, first consider updated subscription credentials or a temporary server-side issue.
Browser testing is only a supplementary check. Some subscription URLs download text when opened directly, some display encoded content, and some servers require a specific client identifier. If a browser shows a login page or an ordinary webpage, the client may try to parse that HTML as a subscription, resulting in “update succeeded but no nodes” or “parsing failed”. Never show a complete subscription URL in public screenshots, support tickets, or group chats, as it may contain account access credentials.
Error: The remote server returned an error: (401) Unauthorized
Cause and fix: The server rejected the current subscription credentials. Obtain the subscription URL again, edit the corresponding group under “Subscription Groups”, and replace the old URL in full.
Error: The remote server returned an error: (403) Forbidden
Cause and fix: The server rejected the request due to its policy, or updates may have been attempted too frequently. Wait 10 minutes before trying again. If the error persists, confirm the account status and whether the subscription URL has been reset.
Error: subscription content decode failed
Cause and fix: The received content could not be parsed as a subscription. Check whether the URL returns a login page, error page, or blank content, then copy the complete URL again.
Error: operation timed out
Cause and fix: No response arrived within the timeout period. Confirm that ordinary internet access works, then connect to a working node and choose the option to update through the proxy.
Troubleshooting v2rayN step by step
On desktop, the most effective approach is to follow a fixed order: URL, update route, core status, ports, and system time. Do not delete all configurations at the start. Removing a group also removes old nodes that may still work, while keeping them helps verify whether updating through a proxy is available.
Verify the group URL
Open “Subscription Groups” → “Subscription Group Settings”, select the failed group, and check its name and URL. Remove spaces at both ends and make sure the address was not copied only up to the line break.
Try a direct update first
Open “Subscription Groups” on the main screen and choose the update option that does not use a proxy. If it times out after 10–30 seconds, record the time shown in the log instead of clicking repeatedly.
Update through a proxy
Select a currently working node and start the core. Confirm that the system proxy is active, then update through the proxy. Afterward, compare the node count and update time with the values from before the update.
Check the core ports
Go to “Settings” → “Parameter Settings” and check the local SOCKS and HTTP listening ports. A common pair is 10808 and 10809. If the log says the address is already in use, switch to unused ports and restart the core.
Sync the system clock
Open the system date and time settings, enable automatic time synchronization, and sync immediately. A difference of several minutes can affect HTTPS requests and node connections. After syncing, exit v2rayN completely and start it again.
A port conflict does not always directly cause subscription downloads to fail, but it can make updating through a proxy impossible by removing the local proxy channel. For example, if v2rayN is configured to listen on 127.0.0.1:10808 while another running program already uses that port, the core cannot start properly. The system proxy may appear configured, but no process is actually receiving requests. The log message “address already in use” is more useful for diagnosis than browser behavior.
If you change the port, also check the system proxy mode. Changing the SOCKS port from 10808 to 10818 while the system still points to the old port will leave both browser and subscription requests failing. After making the change, restart the core and toggle the system proxy off and on again so the system setting matches the client’s current listening port.
Bottom line: do not delete the subscription first if old nodes still work
Keep a node that has been verified to connect and use it to update through the proxy first. Only clean up duplicate groups and expired records after confirming that the new URL returns valid nodes.
v2rayNG and Android troubleshooting essentials
v2rayNG uses the Xray core, and subscription updates still involve two stages: downloading and parsing. On Android, battery-saving policies, background network restrictions, and the current VPN connection can also affect the process. Keep v2rayNG in the foreground while troubleshooting, avoid locking the screen temporarily, and confirm that the current network can access ordinary websites.
In v2rayNG 1.10.x, open subscription settings from the subscription entry on the main screen and check the relevant item. Menu labels may appear as “Subscription Settings” or “Subscription Group Settings” in different minor versions, but the fields are the same: remark, subscription URL, enabled status, and update options. Save, return to the main screen, and update the subscription again.
Keep the app in the foreground
Open v2rayNG and keep the screen on. Confirm that the system has not restricted its background data. Do not switch between Wi-Fi and mobile data during the update.
Check the subscription item
Open “Subscription Settings”, select the target subscription, verify the complete URL, and confirm that the item is enabled. Save and return to the main screen.
Try the proxy route
If a direct update times out, start an existing working configuration first and confirm that the connection status at the top is established. Then update the subscription again.
Check the update time
After the update finishes, check the node count, group name, and latest update time. If it only says “Completed” while the count remains 0, inspect the returned content instead of assuming the update succeeded.
Set the automatic update interval
More frequent automatic updates are not always better. Most personal subscriptions do not need to refresh every 5 minutes. Short intervals create extra requests and may trigger server-side rate limits. For devices used daily, start with 360 minutes; if nodes change less often, use 720 or 1440 minutes. If a laptop frequently sleeps, scheduled tasks may be skipped during sleep, so run one manual update after waking.
| Use case | Recommended interval | Notes |
|---|---|---|
| Nodes change frequently | 360 minutes | Up to four automatic checks per day, balancing freshness and request frequency |
| Stable daily use | 720 minutes | Two checks per day, suitable for most desktop and Android devices |
| Backup device | 1440 minutes | One check per day; you can still refresh manually before use |
| Currently troubleshooting | Temporarily disabled | Prevents background tasks from overwriting logs or repeatedly triggering the same error |
v2rayN automatic updates
Open group settings
Go to “Subscription Groups” → “Subscription Group Settings”, then select the subscription group to refresh automatically.
Enter the update interval
Enter the number of minutes in the automatic update interval field. For everyday use, start with 720 rather than setting it to 1 or 5 minutes for testing.
Choose the update route
If the subscription frequently times out over a direct connection, confirm before saving that updates will use the current proxy. When the automatic task runs, the core and a working node must also be available.
Verify one update
After saving, run a manual update first to confirm that the URL, route, and parsing all work. Then check whether the next scheduled time changes; do not rely on the configured value alone to determine whether the task ran.
v2rayNG automatic updates
Find the subscription auto-update option under “Settings” or “Subscription Settings” in v2rayNG. Enable it and set the interval available in your current version. If the interface uses hours instead of minutes, 360 minutes equals 6 hours, 720 minutes equals 12 hours, and 1440 minutes equals 24 hours. After saving, allow the app to use background data. If the system pauses it in battery-saving mode, the task may be delayed until the next time the app is opened.
- Run one manual update successfully before enabling automatic updates.
- Check the node count after an automatic update so an empty response is not mistaken for a valid result.
- Do not schedule multiple subscriptions to refresh at the same minute; stagger their check times.
- If 403 errors continue, pause automatic updates first and wait at least 10 minutes before testing again.
Bottom line: 720 minutes is a good starting value
Updating twice a day is usually enough to catch node changes and makes it easier to identify when a problem began. Shorten the interval to 360 minutes only when you know the subscription changes more frequently.
Common issues and final checks
Finish with one complete verification after configuring everything: update manually, record the node count, start the core with one node, confirm the system proxy status, and watch the log for recurring errors. The full chain is restored only when both subscription updates and node connections work. If the subscription succeeds but every node times out, investigate node parameters, network quality, and routing rules.
What should I do if a subscription update times out?
Use an ordinary webpage to confirm that the network works, then start an old working node and update through the proxy. If both direct and proxied updates time out after about 30 seconds, verify the subscription URL and service status again.
Why did the update succeed but return no nodes?
Compare the node count before and after the group update, and check the log for parsing failures. If the response is a login page, blank text, or an ordinary webpage, the client may have completed the download without generating nodes.
Why do I need to connect to an old node first every time?
The subscription URL may be unreachable through the current direct connection. Keep a working node as an update route and select the proxy update method in the subscription group settings.
Why did automatic updates not run after I enabled them?
Check the interval unit, whether the client is running, whether the device is asleep, and whether background network access is allowed. Temporarily set the interval to 360 minutes and observe one scheduled cycle instead of testing repeatedly every few minutes.
Why can I still not connect after changing the port?
Confirm that the core is actually listening on the new port and that the system proxy points to the same port. For example, changing it to 10818 will not work if the system still points to 10808. Restart the core and toggle the system proxy again.
If you need to reinstall the client, first record the subscription group names, update methods, and local ports. After installation, restore only the necessary settings. Verify one subscription first, then add the other groups gradually. This prevents an incorrect port, expired URL, or duplicate routing rule from the old configuration from coming back all at once.