How to Set Clash Subscription Auto-Update Intervals (and Fix Update Errors)

First, know the difference: subscription updates, node testing, and connection status

Clash subscription auto-updates work by having the client periodically fetch a remote subscription URL and use the response to update its local configuration or node list. This is not the same as testing node latency or periodically switching your exit node. If the provider hasn’t changed the subscription, a successful update may leave the node count exactly as it was—and that’s normal.

Before changing anything, check what manages the subscription. Desktop clients such as Clash Verge Rev typically manage remote configurations through the UI. Deployments running the mihomo core directly may fetch nodes through proxy-providers. Both may have an “update interval” setting, but they control different things, use different units, and run on different schedules.

• Remote configuration updates: Download a complete configuration, potentially changing nodes, proxy groups, rules, and DNS settings.
• Node provider updates: Refresh only the node list for a specific proxy-providers entry; this won’t automatically replace the rules in the main configuration.
• Health checks: Test whether nodes are reachable. health-check.interval sets the check frequency, not the subscription download frequency.

Where to find auto-update settings in Clash Verge clients

The steps below use the common Clash Verge Rev interface. Depending on the release, you may find the option in the subscription card’s right-click menu or its More menu. The field may be labeled “Update interval” or “Auto update.” Make sure you’re editing a remote subscription, not a local YAML file.

1. Select “Subscriptions” in the left sidebar, find the subscription card you use, and note its last update time.
2. Right-click the subscription card and choose “Edit”. In versions with a More menu, open the editor from that card’s menu instead.
3. Check that the subscription URL is still the one provided by your service, then find “Update interval” and enter a value in the units shown.
4. If there’s a separate auto-update toggle, turn it on and save. For fields measured in minutes, enter 720 for 12 hours or 1440 for 24 hours.
5. Return to the subscription card, click “Update”, and check for download or parsing errors. Then confirm that the last update time has changed.

Don’t confuse “Edit” with “Edit file”: the former usually saves the URL, name, and schedule, while the latter changes the configuration text. Adding interval: 720 to the top level of a full configuration won’t replace the client’s own subscription scheduler.

Why isn’t the subscription updating automatically, even after I set an interval?

Scheduled tasks in desktop clients typically require the application to keep running. Closing the window while leaving the app in the system tray is different from quitting it from the tray. The client also can’t make scheduled network requests while the computer is asleep. Whether it catches up immediately after waking depends on the client, so don’t assume it will update based only on the schedule set before sleep.

• Keep the client running and confirm that a manual update succeeds first.
• “Launch at startup” and “Update at startup” are separate options. Enabling the former doesn’t mean the latter will run.
• Make sure you edited the right subscription card, especially if multiple cards have the same name, and confirm that the one you changed is the active configuration.
• Don’t assume 0 means “update now.” It may disable scheduled updates or use a default value; check the field description in your client.

Choosing an update interval: 6, 12, or 24 hours

Choose an interval based on how often the subscription changes, not on speed test results. Higher node latency doesn’t necessarily mean the subscription is outdated. Updating may help if nodes have gone offline and the provider has published replacements.

These are configuration recommendations, not guarantees from the provider. Unless you have a specific need, don’t set updates to every minute: that’s 1,440 requests a day, and multiple devices sharing a URL add to the total. This could trigger rate limits. If several nodes fail at once, try one manual update; clicking Update repeatedly won’t make the provider recover faster.

If the subscription response or your provider’s instructions specify a recommended interval, check whether the client applies it. Don’t infer the units from a default value shown during import, especially when migrating from an older client.

mihomo proxy-providers: interval is measured in seconds

When maintaining a mihomo configuration yourself, set interval under the specific HTTP provider; the unit is seconds. This example fetches nodes every 12 hours and runs a health check every 5 minutes. These schedules are independent.

proxy-providers:
  remote-nodes:
    type: http
    url: "https://subscription.example.net/nodes.yaml"
    path: ./providers/remote-nodes.yaml
    interval: 43200
    health-check:
      enable: true
      url: "https://www.gstatic.com/generate_204"
      interval: 300

proxy-groups:
  - name: Subscription
    type: select
    use:
      - remote-nodes

subscription.example.net is a documentation-only domain and won’t return nodes. For a real deployment, replace it with your provider’s URL and make sure the response matches the provider format. A full Clash configuration and a node-only provider file aren’t interchangeable in every situation. Choose a health-check URL that’s reachable from your network.

• interval: 43200: Controls updates to the provider’s remote content, not downloads of the entire main configuration.
• health-check.interval: 300: Controls node checks; it doesn’t download new nodes.
• path: Sets the local cache file. The account running the core needs write access to the relevant directory.
• use: Lets a proxy group reference this provider. Declaring a provider without referencing it won’t automatically add its nodes to a group.

After editing the main configuration, reload it in mihomo for the new interval to take effect. If a client generates the main configuration through subscription updates, direct edits to the downloaded file may be overwritten on the next update. Use the client’s supported override or merge mechanism to preserve local changes.

Common subscription update failures: troubleshoot by error type

1. Timeout or DNS resolution failure: check the network path to the subscription URL

A page loading in your browser only confirms that the browser’s current network path works. The client may send subscription requests in the background, without using your browser extensions or the same system proxy. Start by noting the subscription domain and error in the logs, then determine whether it’s a DNS resolution failure, TCP connection timeout, or TLS handshake failure.

You can check the HTTP status and content type returned by the URL on your own machine, but don’t upload the full subscription URL to a public testing site. If the browser returns a login or verification page, the client can’t parse it as a Clash configuration—even if the status is 200.

2. The current proxy is unavailable: the update request depends on a failed node

Some clients offer download options such as “Update through proxy.” If routing rules send the subscription domain through a currently unavailable node, the update depends on that same failed node, creating a bootstrap problem. Switch to a known-working node and try a manual update first. If the subscription URL supports direct connections, you can also use direct updates if your client allows it.

Don’t immediately turn off all proxy settings. If the subscription site is only reachable through a proxy, forcing a direct connection will make the failure recur. TUN mode doesn’t guarantee that subscription requests use the proxy either; the route still depends on routing, rules, and how the application makes requests.

3. Local proxy port issue: verify the configured and listening ports match

Suppose the client’s mixed port is set to 7890, but an external tool still connects to the old port, 7897. The connection may be refused. These numbers are just examples for troubleshooting. Check the current client settings for the actual port; neither value is a universal default.

• Check whether two proxy clients are running at once and one is occupying the port you expect to use.
• Look for address already in use or connection refused in the logs.
• After changing the port, also check your system proxy, browser proxy extensions, and the HTTP_PROXY and HTTPS_PROXY environment variables in your terminal.

A port conflict doesn’t necessarily prevent subscription downloads; it only causes a failure if the update request uses that local proxy port. If the logs show the server returned 403, check URL permissions instead of repeatedly changing ports.

4. 401, 403, 404, or 429: check access, the URL, and rate limits

401 usually indicates an authentication issue. 403 may indicate an access restriction or site protection, 404 may mean the path is no longer valid, and 429 means too many requests. None of these status codes alone proves that your plan has expired; check your provider account and the response body.

Copy a fresh subscription URL for Clash or mihomo from your provider account, then check whether the subscription was reset, your account has expired, or you’ve used up your data. If you get 429, stop retrying repeatedly. If the response includes Retry-After, wait for the indicated period and increase the auto-update interval across your devices.

5. Download succeeds but parsing fails: check the response format and core support

A parsing error isn’t the same as a network timeout. Check whether the response is YAML, whether you copied a web sharing link by mistake, or whether it’s in a format intended for another client. New protocols or fields may also require a newer mihomo core. The fact that a graphical interface opens doesn’t mean the core can recognize every node type.

Don’t delete a working configuration before backing it up. Keep the current configuration, then check the downloaded content and the error line number. When troubleshooting YAML, use spaces for indentation and keep indentation consistent at each level. Quote URLs that contain special characters.

Verify your changes and protect your subscription URL

After setup, verify both a successful manual download and at least one scheduled update. The first confirms that the URL and current network work; only the second confirms that auto-update is active. Don’t judge by the node count alone—a server may return identical content.

1. Note the subscription name, last update time, and configured interval, such as 720 minutes.
2. Run a manual update and check the logs for download, parsing, or configuration loading errors.
3. Keep the client running through a full update interval, then check the last update time and relevant logs.
4. If the download succeeds but the nodes don’t change, confirm which configuration is active and whether it references the provider. Then check whether the server actually published new content.
5. Once verified, keep the normal interval. Don’t leave a temporary test interval in place long-term across multiple devices.

Use a consistent troubleshooting order: identify what’s being updated and the interval units → try a manual update → check the error type → inspect the request path → verify that the scheduled update runs. For help with system proxies, rule modes, or TUN settings, see Troubleshooting. If you’re importing a subscription for the first time, start with the setup guide.