Clash Subscription Update Failed: Common Causes and Auto-Update Intervals

First pinpoint whether the failure is in downloading, parsing, or applying the config

“Update failed” on Clash mobile doesn’t point to a single problem. A subscription update typically involves requesting the URL, downloading the response, parsing the config, saving the file, and applying the config. Working nodes don’t prove the subscription URL is still valid; a successful download doesn’t mean the current core can load the new config. Identify the failing step before deciding whether to replace the link, change the network path, or address a compatibility issue.

1. Keep your working config. Note its name, the last update time, and the client you use. If the client supports exporting, save a local copy first. It may contain node passwords, so store it somewhere secure.
2. Try one manual update. Open the subscriptions or configs list and update the relevant entry. Record the full error message. Don’t repeatedly refresh all subscriptions at once.
3. Check the logs for the same time. Note the failure time to the nearest minute and distinguish HTTP status codes, connection timeouts, TLS certificate errors, and YAML parsing errors.
4. Change one thing at a time. For example, switch only between Wi-Fi and mobile data, or change only whether the update request uses a proxy, then compare the results.

A status code is a clue, not a final diagnosis. For example, 403 may be triggered by a website’s security rules; it doesn’t necessarily mean the subscription has expired. Check the provider’s dashboard, client logs, and service announcements together.

Invalid subscription link: check the token, expiration, and response

Copy it again from the provider’s dashboard—don’t piece it together from chat messages

Subscription URLs often contain account-specific tokens. Resetting the URL, changing security settings, or migrating the service can invalidate an old link. When copying, keep all query parameters intact and check for trailing spaces, line breaks, smart punctuation, or text truncated by a chat app. In a URL, & separates parameters; don’t mistakenly enter it as an HTML entity.

First check the plan’s expiration date, remaining data, and subscription status in the provider’s dashboard. Then update the existing entry with the current URL shown there. If the client has no option to edit the URL, create a new subscription entry to test it. Deal with the old entry only after the new one works, so you don’t delete your only usable config.

An HTTP 200 response can still contain an error

A server response of 200 only means the request received a response. The content could actually be a login page, a verification page, an expired-plan notice, or a one-line error message. If <html> or <!DOCTYPE appears near a parsing error, check the URL and access restrictions before changing YAML indentation.

Incompatible formats: distinguish full configs from node subscriptions

“Supports subscriptions” doesn’t mean every client can read the same response. Common formats include full Clash YAML configs, proxy provider files, lists of URIs, and Base64-encoded collections of nodes. A full config typically contains fields such as proxies, proxy-groups, and rules. A proxy provider file mainly supplies nodes and may not include policy groups or routing rules.

• Importing a full config: Choose a format the provider explicitly identifies as compatible with Clash or your current core. Don’t import a subscription URL intended only for another client as a full config.
• Loading a proxy provider: proxy-providers downloads provider content, which has a different structure from a full config. Using the wrong import option can lead to missing fields or parsing errors.
• Meta / mihomo features: Some protocols, rule fields, and DNS options require a compatible core. Support varies between the original Clash, Clash Meta / mihomo, and different graphical clients.

Check the client’s About or core information page to see which core is actually in use, then compare it with the format notes from the config provider. Having Clash in an app’s name doesn’t prove it supports a particular new field. If the logs explicitly report an unknown protocol or unsupported field, switch to a compatible format provided by the service or use a client that supports the feature. Don’t delete config lines one by one and hope for the best.

The reported line number helps locate an error, but may not identify its cause

YAML relies on indentation; don’t replace spaces with tabs. The problem may be on the reported line or caused by an unclosed quote or bracket on the previous line. For a remote subscription, ask the provider to check the original content first. Editing the downloaded file on your phone is often temporary because the next update may overwrite it. For local customizations, use the client’s supported override or merge options. See the technical reference for related concepts.

Update requests bypass the proxy: working nodes don’t mean the subscription is reachable

A mobile client may download an entire subscription itself, or the core may fetch remote providers. These requests don’t necessarily use the same network route. Opening the provider’s dashboard in a browser only shows that the browser’s current route works; it doesn’t prove the client’s subscription request uses the same route.

Compare two network routes

1. Keep the old config and make sure the selected node can actually access the internet. Don’t rely on the VPN icon alone.
2. Look for an option such as “Update via proxy” or “Proxy for updates” in the subscription editor or update settings. The exact name depends on the client; don’t assume one app’s menu path applies to every mobile client.
3. If the option is available, try one manual update over a direct connection and another through a proxy, then record the results. If only the proxy works, set that subscription to update through the proxy.
4. If both methods fail, test again on Wi-Fi and mobile data. Don’t change DNS, the node, and the subscription format all at once, or it’ll be hard to tell what helped.

Switching to global mode may not change the subscription download route: the app may fetch it directly without using the core. By contrast, proxy-providers in mihomo can specify the download proxy when the relevant fields are supported. That setting applies only to the corresponding provider; it doesn’t automatically change how the client updates its entire config.

VPN permissions, TUN routing, and app-exclusion lists on your phone may also affect the request route. In particular, if the client itself is excluded or per-app proxying is enabled, other apps working normally doesn’t rule out a network issue. If the log says no such host, check DNS resolution first. For a connection timeout, check the route, proxy exit, and server reachability.

Certificate verification failed: check the system clock, then the network

x509: certificate has expired or is not yet valid, hostname mismatches, and untrusted certificate chains are all TLS verification issues. They occur at a different stage from YAML parsing and won’t be fixed by changing a node password.

1. Enable automatic time. On Android, look for automatic time in the system’s Date & time settings. On iOS, check Settings → General → Date & Time and turn on Set Automatically. An incorrect date can make a valid certificate appear expired or not yet valid.
2. Check for public Wi-Fi sign-in. Hotel and campus networks may require web-based authentication. Complete the network’s normal sign-in first, then retry the subscription request.
3. Test on another network. If only one Wi-Fi network fails, check whether it inspects HTTPS traffic or redirects domains. Don’t install root certificates from untrusted sources.
4. Ask the provider to check its domain certificate. If the same expiration or hostname error occurs on multiple networks, the provider should fix its certificate deployment or offer a correctly configured subscription URL.

The config option skip-cert-verify usually controls certificate verification for node connections; it isn’t the same as TLS settings for subscription downloads. Don’t change node settings across the board just to dismiss a subscription error, and don’t use an unencrypted HTTP URL as a long-term workaround—the subscription response itself may contain access credentials.

Auto-update intervals: distinguish the two timers

A client’s subscription auto-update usually refreshes an entire remote config. The interval in a core’s proxy-providers controls refreshes for a specific proxy provider. Both can be active, but they’re not interchangeable. Another easy-to-mix-up field is health-check.interval, which controls how often health checks run—not when the node list is downloaded again.

Full config: start with once a day

For subscriptions where nodes change infrequently, 24 hours is a reasonable starting point. If updates are genuinely needed more often, consider every 6–12 hours, while following the provider’s rate limits. This is a configuration guideline, not a universal standard. If the server returns 429 with Retry-After, follow that wait time instead of clicking refresh every few seconds.

Check the units before setting an interval. 24 hours equals 1440 minutes or 86400 seconds. A client may use minutes or hours, while a core provider’s interval uses seconds; don’t copy the same number between fields. Check the client’s documentation for what 0 means—don’t assume it means “update immediately.”

Providers: change only the update field on an existing entry

If you use an HTTP proxy provider in mihomo and want it to update once a day, set the following line in the existing provider entry. This is a field example, not a complete config you can import on its own. Keep the existing name, URL, path, and other required settings.

# Nested under an existing proxy-providers entry; value is in seconds
interval: 86400

After making the change, first confirm the config loads, then check the logs for the provider’s last update time. Don’t put this line at the top level of the config and expect it to control the client’s entire remote subscription. If you use a local file provider, HTTP scheduled-download behavior doesn’t apply.

No updates while the phone is locked: check scheduling limits and success times

An auto-update interval usually sets how often the client or core attempts to schedule an update; it doesn’t guarantee the phone will run it at an exact time. Android battery optimization, manufacturer background restrictions, network interruptions, and iOS limits on background tasks and network extensions can all delay updates. Even if the VPN icon is visible, the app process responsible for downloading the config may not be running.

• Android: Check the app’s battery settings to see whether background activity is restricted. The location of “Allow background activity” and “Auto-start” varies by manufacturer, so follow your device’s actual menus. Keep in mind that relaxing these restrictions may increase battery use.
• iOS: Background behavior depends on the capabilities of the client you use. A regular app’s scheduled tasks aren’t a continuously running service. If needed, open the client and check for updates manually.
• Check on both platforms: Confirm that the client is allowed to update over mobile data, check whether the current network has data restrictions, and see whether the displayed time is the last attempt or the last successful update.

After changing the settings, run a manual update in the foreground and confirm the new config is saved and loads correctly. Then check the success time after one full interval; don’t just check whether auto-update is enabled. After restarting the phone, make sure the config is still selected, VPN permission is active, and the system hasn’t reset or cleared the auto-update settings.

What to record before reporting the issue

If updates keep failing, a reproducible report is more useful than repeatedly uninstalling and reinstalling the app. Clearing app data may also remove subscriptions, overrides, and policy group selections, so consider it only after backing up and exhausting other troubleshooting steps.

1. Record the client name, app version, actual core information, and phone OS version.
2. Record when the failure happened, whether you were on Wi-Fi or mobile data, and whether the request used a direct connection or proxy.
3. Keep the full error line with sensitive details redacted, such as the HTTP status code, TLS error, or config parsing line number.
4. Note whether a manual update worked, whether the full config or a provider failed, and whether the old config is still usable.
5. Report URL authorization and response issues to the subscription provider. Send reproducible download, parsing, or scheduling issues to the client’s maintainers.

Confirm all three before wrapping up: the subscription downloaded, the new config loaded, and the connection works. A changed update time alone doesn’t mean the issue is fixed if the config can’t be applied. For initial setup and permissions on mobile, see the installation and setup guide.