Automatic subscription updates: know what is being updated

Clash subscription auto-update means the client or core periodically requests the subscription URL and processes the configuration or proxy list returned by the server. It does not update the client app, nor does it test the speed of every proxy. Before setting an update interval, check whether you use a remote subscription or a local YAML file imported from your computer.

  • Remote configuration subscription: Usually managed by the client, it may include proxies, proxy groups, rules, and DNS settings. Which changes take effect depends on the client’s merge and override behavior.
  • Local configuration file: A file stored on disk has no remote source. Scheduling checks cannot add new proxies if there is nothing to fetch.
  • Proxy providers: mihomo’s proxy-providers can fetch proxies independently. Their update frequency is controlled by each provider’s configuration.
  • Rule providers: rule-providers update rule sets; they do not refresh the proxies in your subscription account.

Where to set automatic updates in popular clients

Clients don’t share a single subscription management interface, and button labels may change between versions. Open the subscription or configuration list, find the remote configuration you actually use, and open its edit menu. Don’t look only in general settings, or mistake the app’s update-check setting for the subscription update setting.

Clash Verge Rev: edit the subscription card

  1. Open “Subscriptions” in the sidebar and check which remote subscription card is active.
  2. Open the card’s More menu, select “Edit,” and look for the update interval or auto-update setting.
  3. Check the unit shown beside the field. If it’s in minutes, use 360 as a starting point for updates every 6 hours; don’t enter 21600, which is the value in seconds.
  4. After saving, click “Update” on the same card to confirm the remote URL works, then check that future automatic updates run as expected.

If the card has no remote URL, make sure you haven’t selected a local configuration by mistake. Global scripts, overrides, and the original remote subscription are separate layers. If the result isn’t what you expected, check those local transformations instead of repeatedly importing the link.

FlClash: check update options in configuration details

Open “Configurations,” then open the edit or details view for the remote configuration. Check the auto-update toggle, update interval, and subscription URL. Labels vary by version and platform, so use the unit shown in the interface. If your version only supports manual refreshes, use the refresh option for that configuration. Don’t add an auto-update field to the top level of the YAML yourself.

Clash for Windows: find the legacy Profiles interface

If you still use the legacy Clash for Windows, remote subscriptions are listed under Profiles. Open a subscription card’s context menu to find editing and update options. This client is no longer maintained, and button locations in older guides may not apply to current clients. Before migrating, save your subscription source and any local overrides, then choose a client for your system in the download center.

Choosing an update interval: start at 6 hours, then adjust as needed

Follow your subscription provider’s guidance when available. Otherwise, updating every 6 hours is a reasonable starting point, not a universal rule. These are recommendations, not client defaults or results from network testing.

Use case Suggested starting interval When to take additional action
Everyday use with infrequent proxy changes 6–12 hours Manually update once after a proxy-change notification
Provider frequently changes proxies 1–3 hours First confirm that the provider allows requests this often
Occasionally used backup subscription 24 hours Manually refresh and test the connection before using it
Renewal, reset link, or plan migration No need to keep the interval shorter Manually update as soon as you confirm the URL is valid

Setting the interval to 1 minute usually won’t help. The server may have nothing new to return, but it will receive more requests and may respond with a 429 rate limit. If requests keep failing, shorter intervals only create more error logs; they won’t fix an invalid URL or DNS issue.

Don’t mix up minutes, hours, and seconds

  • 6 hours = 360 minutes = 21600 seconds.
  • 12 hours = 720 minutes = 43200 seconds.
  • 24 hours = 1440 minutes = 86400 seconds.

Don’t assume 0 always disables updates: a client may interpret it as off, use a default value, or reject it. Use an explicit toggle where available, and read the field’s hint. Reopen the edit window after making a change to confirm the value was saved.

mihomo interval vs. client-scheduled refreshes

If you import a complete subscription in a graphical client, you can usually set the update interval in the client. If you manage your own mihomo configuration and fetch proxies using HTTP proxy-providers, you’ll also encounter the core-level interval setting. It’s measured in seconds, unlike the minutes that some client interfaces use.

For example, to have an existing HTTP proxy provider fetch updates every 6 hours, adjust this line in the provider’s existing configuration. This is a partial field example, not a complete, standalone configuration. Keep the existing subscription URL, path, and other required fields.

interval: 21600

The health-check.interval under the same provider sets the health-check frequency, not the subscription fetch interval. Rule providers can also have their own interval, but that updates rule files. When you see the same field name, check which section it belongs to before changing its value.

Subscription update failed: check the URL, network, and format

When an update fails, note the exact error, when it happened, and which network you’re on. Keep the original subscription card so you don’t delete a working configuration while troubleshooting. One deliberate manual update is more useful than clicking refresh ten times in a row.

401, 403, 404: check the subscription source first

  • 401: Usually related to authentication or a token. Check your account status and whether the URL has been reset.
  • 403: May indicate access restrictions, security measures, or an account permission issue. The status code alone doesn’t prove that your account has expired.
  • 404: Check whether the URL was truncated, the path changed, or you’re using the provider’s website login URL by mistake.

Copy the subscription URL again from your provider’s account page, and check for leading or trailing spaces and line breaks. Subscription URLs often contain account tokens, so don’t share them in group chats, screenshots, or online conversion tools. If a URL is exposed, reset it in your provider’s dashboard and update the saved source in your client.

Timeout, DNS, TLS: check the network used to fetch the subscription

timeout means the request didn’t complete in time; no such host usually points to a DNS lookup failure. For TLS certificate errors, check your system date and time and the network you’re using. Hotel or campus Wi-Fi may also redirect requests to a login page before you complete its sign-in process.

  1. Check that regular websites open normally and complete any sign-in required by your current network.
  2. Check your system time. Temporarily disable other proxy or VPN tools to rule out conflicts.
  3. If the client offers “Update through proxy” or a similar option, check which route the request uses and test again. Subscription requests don’t necessarily follow the same settings in every client.
  4. Try again using your phone’s hotspot. If it works there but not on your usual network, investigate that network’s DNS, sign-in requirements, or access restrictions first.

Don’t leave certificate verification disabled just to get rid of TLS errors. If your current proxy is down and the update request also depends on it, you can get stuck in a loop. Try a working proxy, an allowed direct connection, or another network instead of simply shortening the update interval.

YAML or parsing error: inspect the response content

A successful HTTP request doesn’t guarantee a valid configuration. The server may return a plan-expired notice, login page, or data in an incompatible format. Check the parsing details in the client logs and confirm that the URL provides a configuration format supported by Clash or mihomo. Contact your provider if needed; don’t randomly change the generated subscription file’s indentation to hide the underlying issue.

If the logs show 429, stop refreshing repeatedly and wait as instructed by the server. If no wait time is given, increase the interval before trying again. Requests from multiple devices using the same subscription may also count toward the provider’s limit.

After a manual refresh, confirm that the new configuration is active

  1. Update the right card. Find the configuration you’re currently using in the subscription list, click its update or refresh button, and wait for the result.
  2. Check the update time. Make sure it shows the time of this successful update, not the last attempt. Check the success log too, if available.
  3. Check what changed. Compare proxy names or counts with the provider’s notification. No visible changes don’t necessarily mean the update failed; the remote content may simply be unchanged.
  4. Confirm which configuration is active. Updating an inactive subscription doesn’t automatically switch your traffic to it. Some clients reload the active configuration automatically; others require you to select or apply it again.
  5. Test the current proxy group. Check the selected proxy, then run a latency test and try accessing a site. Don’t assume the connection works just because new entries appear in the proxy list.

If your traffic allowance still shows the old value after renewal, that doesn’t necessarily mean the proxy list failed to update. Traffic usage and expiration dates may come from subscription information returned by the server, and whether or when they appear depends on client and provider support. Compare your account dashboard with the update logs.

Automatic updates aren’t running on schedule: check background activity and sleep

An update interval usually isn’t a server task that runs around the clock. If your computer is off, the client is closed, or the mobile OS restricts background activity, don’t assume it will make requests on schedule. Whether an update runs as soon as the device wakes depends on how the client handles scheduling.

  • Desktop: Make sure the client process is still running, and distinguish between closing the window and quitting the app. If you need it to run at startup, enable the relevant startup setting.
  • Android: Check battery optimization and background activity permissions. A running VPN service doesn’t necessarily mean subscription updates can run as expected.
  • Devices left asleep for long periods: Manually refresh once when you start using the device again. A subscription isn’t necessarily invalid just because it wasn’t updated while the device was asleep.