Clash Subscription Update Failed? Common Causes and Auto-Update Settings

First, pinpoint where the update fails

A “subscription update” in a Clash client usually involves three steps: downloading remote content, parsing the configuration, and saving or loading it. A successful download doesn’t mean the configuration will work. Likewise, working nodes don’t prove the subscription URL is still valid. Start by checking the error message, then decide whether to change the URL, network route, or core.

1. Keep your working configuration. Note the subscription name, the last successful update time, and the configuration currently selected.
2. Manually update just one subscription once. Note the time, then check the corresponding entry in the client log.
3. Determine whether the error is an HTTP status, connection timeout, certificate validation failure, or a YAML or protocol-field parsing error.
4. Change one variable at a time. After changing the update route, retry before touching DNS, nodes, or the core.

Choose what to check based on the error

Use these mappings to narrow down the issue; a status code alone doesn’t confirm the cause. For example, a 403 may come from a site’s security policy, not an expired account. A 200 response could contain a login page rather than a valid subscription.

Expired or invalid URL: check credentials, expiration, and response body

First, copy the subscription URL for Clash or mihomo from your provider’s dashboard. Don’t copy a management-page URL from your browser’s address bar, or use a QR-code display page as the subscription endpoint. Keep the full query string, and remove any trailing spaces, line breaks, or punctuation.

Check these four things in order

• Account status: Check your plan’s expiration date, data allowance, and subscription access. Some services return a notice when you run out of data; others still return a configuration, but its nodes won’t work.
• Was the URL reset? Resetting a subscription token may invalidate the old URL immediately. Update the URL on the existing subscription instead of repeatedly clicking Update.
• Does the URL redirect? A 301 or 302 redirect to a login page may result in the client receiving HTML. Check the final response, not just the status of the initial request.
• Has rate limiting kicked in? Frequent refreshes from multiple devices using the same URL may trigger a 429 response. Pause automatic updates, wait for the limit to clear, then resume updates one device at a time.

A successful browser download only proves that the browser’s current request route works. The browser may have a login cookie, use the system proxy, or resolve DNS differently; the client’s updater may not share those settings. When comparing results, note whether each request uses a proxy rather than stopping at “it opens in my browser.”

For errors such as expired certificate, untrusted issuer, or hostname mismatch, first check the device date, time zone, and whether the current network requires a web login. Confirm the subscription service’s certificate status before taking further action. Don’t disable certificate validation to hide the problem; subscription credentials also need HTTPS protection.

Incompatible format: tell full configurations from proxy providers

“Subscription” isn’t a single file format. Common responses include a full Clash YAML configuration, a provider file containing only nodes, or a Base64-encoded collection of share links. These formats aren’t interchangeable across import options. If parsing fails after download, first identify the content type, then check which core the client uses.

Handle YAML syntax errors separately from protocol errors

Incorrect indentation, tab characters, or unquoted special characters can cause YAML parsing errors. If the log shows a line number, check that line and the one above it in a local editor. Full subscriptions contain sensitive node details, so don’t upload them to public online YAML validators.

If the log identifies an unsupported proxy type, the problem is likely core capability, not indentation. Clash is a common name across the client ecosystem; Clash Meta later adopted the name mihomo. Clients may bundle different cores and versions. Changing the name shown in the UI won’t add support for a newer protocol to an older core. Check the actual core in the client’s About or core information page.

When fixing the issue, use the format provided for your client by the service, or switch to a client that supports the target configuration. Don’t simply delete the unsupported protocol fields: parsing may succeed, but connections can still fail. Local edits to remote configurations may be overwritten on the next update; use the client’s override or merge feature for changes you need to keep.

Wrong proxy route: distinguish the system proxy from the subscription downloader

Turning on the system proxy doesn’t guarantee subscription downloads use it. A client may use a separate HTTP downloader, with options such as “Use proxy,” “Update through proxy,” or “Use system proxy.” Providers managed by the core use a different request path. TUN can route some traffic differently, but that doesn’t mean every update request will use a particular node.

Compare the routes with two controlled requests

1. Keep a working configuration and select a node with a working connection. Check the client’s local proxy listening port.
2. In the subscription’s edit page, note the current settings. Turn off the proxy option dedicated to subscription updates, run one manual update, and check the log.
3. Turn the proxy option back on and update again. Compare connection timeouts, HTTP status, and the final parsing result.
4. If direct access works but proxy access fails, check the exit node and routing policy. If proxy access works but direct access fails, keep the working update route.

Suppose your local HTTP or mixed listener uses port 7890. You can explicitly set the proxy address to http://127.0.0.1:7890. Port 7890 is just an example, not a default for every client. Use the port shown in the client’s settings. SOCKS, HTTP, and controller ports aren’t interchangeable.

If the same URL works on mobile data but times out on your current Wi-Fi, check for a captive portal, DNS resolution issues, and access to the destination site. Switching networks is a diagnostic step; there’s no need to enable TUN or rewrite all your DNS settings at the same time. If you test DNS, record the results before and after the change so a temporary fix isn’t mistaken for a permanent one.

Auto-update intervals: configure client subscriptions and providers separately

Clients usually handle scheduled downloads of full remote configurations. For mihomo HTTP proxy providers, settings under proxy-providers control updates. Both can be in use, but their timing units and runtime requirements differ. Don’t add interval at the top level of a full configuration and expect the client to recognize it automatically.

Where to check in each client

• Clash Verge Rev: Open “Subscriptions,” open the menu on the remote subscription card you want, then go to its information editor. Check the subscription URL, update interval, and download proxy options. Field names may vary by version; use the units shown on screen.
• Clash for Windows: Find the remote configuration under “Profiles,” then use its context menu to check configuration editing and update options. Forms and settings differed across older versions, so don’t assume another client’s menu path applies here.
• Clash for Android: Open “Configurations,” edit the relevant remote configuration, and check the automatic update toggle and interval. Also make sure the system isn’t restricting background activity for the app; setting an interval doesn’t guarantee updates will run on time while the device is asleep.
• Running mihomo directly: Check proxy-providers in the main configuration. For HTTP providers, interval is measured in seconds. Scheduled downloads of the full main configuration file still require an external manager.

Note the version on the client’s About page before following the instructions for that version. If you can’t find “Update through proxy,” don’t assume it’s enabled by default. Check the settings documentation for that version or use the logs to confirm how the updater behaves.

Convert the units to avoid excessive requests

For a personal device, start with a 6-hour interval and adjust it based on your provider’s recommendations. If the client runs continuously and updates exactly every 6 hours, each subscription generates about 4 scheduled requests a day. Every 10 minutes means about 144, not counting manual updates or retries. For subscriptions whose nodes rarely change, frequent refreshes usually just increase request volume.

If you already have an HTTP provider named primary, the snippet below shows only its interval and download route settings. It’s a merge snippet, not a standalone configuration. Keep existing fields such as type, url, and path:

proxy-providers:
  primary:
    interval: 21600
    proxy: DIRECT

In mihomo versions that support this field, a provider’s proxy selects the outbound used for downloads; DIRECT means direct access. If you use a proxy or policy group, its name must exist in the current configuration. Avoid relying on a node that’s available only through this provider. This field doesn’t control how an external client downloads a full subscription.

The node health-check timer health-check.interval checks node availability; it doesn’t download the node list again. Similarly, the update interval for rule-providers applies to rule sets, not subscription nodes.

After saving, verify the update time, node changes, and configuration load

After setting up auto-update, run one manual update to confirm the route, then check whether the next scheduled update runs. Device sleep, an exited process, Android background restrictions, and the client’s scheduling mechanism can all delay execution. An update interval isn’t a precise system-level timer.

1. Confirm the download completed: Check the target subscription’s update time and logs. Don’t rely only on a brief success notification in the UI.
2. Confirm the right item updated: Check that the updated subscription is the currently selected configuration and that providers have refreshed.
3. Confirm the content works: Check that the node list and proxy groups are still valid. An unchanged node count doesn’t necessarily mean the update failed; the server may simply have returned the same content.
4. Confirm the configuration loaded: Check that the configuration was applied successfully and whether your previously selected node was removed or renamed. Select an exit node again if needed.
5. Confirm scheduled updates run: Record one scheduled update time and its actual run time. If manual updates work but scheduled ones don’t, check the auto-update toggle, background permissions, and whether the client is running.

What to include if it still fails

When contacting your service provider or client maintainer, include the client, core, and operating system versions, the time the error occurred, the HTTP status code, and the difference between direct and proxy tests. Remove subscription URLs, node passwords, and authorization headers from logs before sharing them. This is enough to distinguish a server denial from a download-route or configuration-parsing issue.

Follow a consistent order: check the URL and permissions, verify the response format, compare update routes, then choose a sensible interval. Auto-update only helps once a manual update works reliably; shortening the interval won’t fix an expired URL or incompatible configuration.