For v2rayN users who have added a subscription but are seeing timeouts, certificate errors, or an empty server list after updating. Keep your existing configuration, then distinguish request failures from parsing failures. Compare one direct update with one through a proxy, then check group filters and the auto-update interval. A working server connection does not mean the subscription URL is reachable.
Find the failing step and keep working configurations
Updating a subscription is not the same as connecting to a server. v2rayN first requests the subscription URL, parses the response into server configurations, then adds them to the relevant group. DNS resolution, the TLS handshake, server-side authorization, response format, and local filters can all cause failures. Changing server protocols or routing rules at random may not address the actual problem.
Check the update entry in the main window's log. Note the time, target group, exact error, and update method used. Menu labels may vary slightly by version; look for “Subscription Groups,” “Subscription Group Settings,” and the “Update via proxy” or “Update without proxy” commands.
- Keep existing servers: Don’t clear the entire server list while troubleshooting. Back up any configurations that still work, and store the backup securely because it may contain access credentials.
- Test one group at a time: Update the current group first to avoid mixing errors from multiple subscription URLs.
- Separate the two outcomes: Timeouts and certificate errors occur while fetching the response. If the fetch succeeds but imports zero servers, check the response format and filters.
- Redact sensitive details: Before sharing logs, remove the full subscription URL, query parameters, user identifiers, and server passwords. Keep only the error type and necessary status codes.
Check the subscription URL, authorization, and response format
Open “Subscription Groups” → “Subscription Group Settings” and edit the affected group. Check its URL. Use the client subscription URL provided by your service, not an account sign-in page, plan details page, or admin page from your browser’s address bar. Leading or trailing spaces, line breaks, smart quotes, or missing query parameters can invalidate an otherwise working URL.
| What you see | Likely cause | What to do next |
|---|---|---|
| HTTP 401 or 403 | Authorization has expired, access is restricted, or a security filter blocked the request | Check your account status on the provider’s site and copy a valid subscription URL again. Don’t assume the plan has expired based on the status code alone. |
| HTTP 404 or 410 | The URL path is invalid or the resource has been removed | Check for an updated URL and make sure you copied the full path and all parameters |
| HTTP 429 | Request rate limited | Stop retrying. Follow the Retry-After response header or the waiting period specified by the provider. |
| HTTP 200, but the response is a web page | The response is a sign-in page, verification page, or error page | Check the final response and subscription format options. A successful status code does not mean the content can be imported. |
| Content fetched, but zero servers imported | The format is incompatible, the subscription is empty, or filters excluded every entry | Choose a subscription format supported by v2rayN, then check the group filters |
A single vmess:// or vless:// share link is different from an HTTPS subscription URL used for ongoing updates. Share links are usually added through an option such as “Import from clipboard,” while subscription URLs belong in a subscription group. Don’t treat arbitrary configuration text as a subscription URL, or assume encoded-looking content is compatible with your client.
Compare direct and proxy updates to identify the network path
From the “Subscription Groups” menu, try “Update all subscriptions (without proxy)” and “Update all subscriptions (via proxy)” separately. If your version offers the same commands for the current group, use those instead. Run each test once and note the result. Don’t change DNS, TUN mode, and server settings at the same time, or you won’t know which change mattered.
-
Record the direct-update result
Choose the update command that does not use a proxy. If the log says the domain could not be resolved, check your internet connection, DNS, and any network sign-in requirements. A specific HTTP status code means the request reached an HTTP endpoint; check the URL, authorization, or possible interception next.
-
Make sure the proxy works
Select a known-working server from your existing list and start the core. Verify it by accessing a real service; don’t rely only on the latency number in the list. Without a working server, proxy updates can create a catch-22: you need to update before you can connect, but need to connect before you can update.
-
Check the local listener
Open “Settings” → “Parameter Settings” and check the local listening port and whether the listener is running. If the log says a connection to a local address was refused, restore the core listener first. Use the port in your current configuration rather than copying a number from another guide.
-
Try updating through the proxy
Choose the update command that uses a proxy and compare the result for the same URL. If the proxy works but a direct update fails, the two network paths differ. If the direct update works but the proxy fails, check the current server, core, and proxy exit's access policies.
Bottom line: Stick with the working path before changing anything else
If only one update method works, use it to restore the subscription and keep the working servers. The system proxy toggle does not replace the update menu’s path selection. “Via proxy” also does not guarantee every request uses the same remote exit; behavior depends on the client and core routing.
Opening the URL in a browser is only a useful clue, not proof. The browser may use a separate proxy, an existing sign-in session, or a different certificate trust store—conditions v2rayN may not share. On hotel or public Wi-Fi, complete the network sign-in first so the client doesn’t receive a sign-in page instead of subscription data.
Fix TLS certificate errors without disabling verification
For HTTPS subscription URLs, the client checks the server certificate’s validity period, hostname, and trust chain. First correct your system date, time, and time zone. Then make sure the hostname in the URL matches the one published by your provider. Don’t replace the domain with an IP address: this can cause a certificate name mismatch or change which site the server returns.
Error: The SSL connection could not be established, see inner exception.
Cause: This is a general TLS connection failure. On its own, it doesn’t reveal whether the problem is the certificate, protocol, or an intermediary device. Fix: Check the inner exception. Verify your system time first, then investigate any certificate-chain or hostname errors.
Error: The remote certificate is invalid because of errors in the certificate chain: NotTimeValid
Cause: A certificate in the chain is outside its validity period, or your system clock is wrong. Fix: Sync your system clock and try again. If the time is correct and the error persists, report the certificate validity issue to your subscription provider.
Error: The remote certificate is invalid according to the validation procedure: RemoteCertificateNameMismatch
Cause: The requested hostname doesn’t match the domain covered by the certificate. Fix: Check the subscription domain and redirect destination. Don’t switch to an IP address or disable certificate verification to bypass the error.
The exact error text varies by operating system, runtime, and client version. If the certificate chain isn’t trusted, check for operating system updates and verify the root certificate store. If the issue occurs only on a corporate network, ask your administrator whether a managed HTTPS inspection device is in use and how to configure its trusted certificate. Never install a root certificate downloaded from an unknown site.
Update succeeds but no servers appear: check the group and filters
A “download complete” log entry doesn’t guarantee that servers appear in the list. First switch to the group you just updated and clear any search filter in the main window. Then open “Subscription Group Settings” and check that group’s filters. If it uses keyword or regex filters, temporarily clear them, save, and update again. Once you’ve confirmed the results, restore the filters one at a time.
- Check the response: The provider may return an empty subscription, an account status message, or a configuration format your client doesn’t support. Choose a format intended for v2rayN, and don’t convert it on an unknown website.
- Check the group: Confirm whether you updated the current group or all groups, and make sure you aren’t viewing servers from a different subscription.
- Check parsing messages: If some entries were skipped, check whether your client version supports their link format and protocol options. Don’t mistake a parsing failure for a network timeout.
- Check filters: Region keywords, exclusion patterns, or an invalid regex can filter out every server. Restore the full list first, then add only the filters you need.
Newly imported servers that won’t connect are a separate issue. Check the server address, port, authentication parameters, transport settings, and core logs instead of repeatedly updating the subscription. VMess and VLESS are connection protocols; a subscription is simply a way to distribute configurations. They’re not the same thing.
Set an auto-update interval and avoid excessive retries
Complete one manual update before enabling auto-update. Open “Subscription Groups” → “Subscription Group Settings,” edit the target group, and look for “Auto-update interval (minutes).” Depending on your version, it may appear as “Auto-update interval” with the unit shown beside it. Enter a value using the unit displayed and save; don’t mistake minutes for seconds. If the interface uses 0 to disable updates, enter 0 to turn off scheduled updates for that group.
These are suggested settings, not provider promises or client defaults. If the configuration rarely changes, start with 1440 minutes. Shorten the interval only if you need updates sooner and your provider allows it. If you receive a 429 response, stop clicking Update repeatedly. Setting the interval to one minute won’t fix an authorization, certificate, or format problem.
- Check the operating conditions: Auto-update requires the client to be running and the network to be available. Don’t expect updates to run on schedule while the computer is asleep, the app is closed, or the network is disconnected.
- Check which network path is used: Auto-update proxy behavior may differ between versions. Don’t assume it reuses the last manual menu selection. Check the relevant settings in your version and review the log after the next scheduled update.
- Verify one update cycle: After saving, check the next update log and group contents. If you temporarily shorten the interval to test it, follow your provider’s request limits and restore the normal value afterward.
- Keep troubleshooting details: Record the update time, method, status code, and number of entries parsed. If the problem continues, these details will help your provider or client support channel investigate more effectively than “refresh doesn’t work.”
Bottom line: Verify scheduled updates only after a manual update succeeds
Check these in order: URL is valid, request succeeds, entries are parsed, servers appear in the list, and scheduled updates run. If any of the first four steps fail, fix that step first. If all four work but auto-update fails, focus on the interval unit, whether the client is running, and the network path used for scheduled updates.