What to do when Clash subscription updates fail: common errors and auto-update intervals

First, identify the failure: subscription download or config activation

Open the client’s “Subscriptions” or “Profiles” page, find the subscription with the error, and note its last update time. Then try a manual update. Open “Logs” and save the error from that attempt. Identify which step failed before changing your network or refresh interval, so a node outage isn’t mistaken for a subscription problem.

• Download failed: Errors such as timeout, connection refused, no such host, or an HTTP status code point to the subscription URL or network path.
• Parsing failed: Content was received, but errors such as yaml, unmarshal, or unsupported proxy type point to the response format or core compatibility.
• Activation failed: The subscription updated successfully, but switching to the config produces an error. Check rule references, proxy group names, and the merged config.
• Node connection failed: The config loaded, but node latency tests time out. That’s a node availability issue; repeatedly refreshing the subscription may not help.

Diagnose the error: timeouts, certificates, and HTTP status codes

The same “update failed” message can have very different causes. The status codes below refer to the subscription download request, not node latency tests. Check the full error in the client logs rather than relying on the red warning on the subscription card.

For timeouts, try another network path before changing rules

Try a mobile hotspot instead of your current Wi-Fi, then update the subscription manually. If it works on the hotspot but not your usual network, check that network’s DNS, access restrictions, or gateway. If updates work only through a proxy, the subscription endpoint needs an existing proxy route. If they work directly but not through a proxy, check the current proxy node and the client’s subscription download settings.

Some clients let you set a download timeout. Try changing it from 10 to 30 seconds for comparison, if the option is available. This is a troubleshooting example, not a setting found in every client. A longer timeout won’t help if the domain won’t resolve or your credentials have expired.

Certificate errors: sync your clock, then check the network

In Windows 11, go to “Settings” → “Time & language” → “Date & time,” turn on “Set time automatically,” and select “Sync now.” A system clock that’s off can affect certificate validity checks. If the error occurs only on a work or school network, test with a mobile hotspot. On managed devices that require an organization’s certificate, follow the administrator’s instructions to configure system trust.

Don’t disable certificate verification as a routine fix. Subscription content includes node addresses and authentication details, and skipping verification weakens identity checks during download. Note the distinction: skip-cert-verify in a node config controls certificate verification for that node’s connection; it does not generally fix TLS errors when the client downloads a subscription.

Check the response: YAML, Base64, or a login page

Downloading text doesn’t mean you’ve downloaded a Clash config. Common mistakes include copying an account dashboard URL, using a subscription link intended for another client, or missing the end of the URL when copying. Return to your provider’s account page and choose a subscription URL explicitly marked for Clash or mihomo. Copy it in full, without editing or removing the token.

Identify the format from the content

• Full Clash config: Usually includes proxies or proxy-providers, along with proxy groups, rules, and other settings. Fields vary depending on how the provider generates the config, so the file extension alone isn’t enough to identify it.
• Proxy provider content: Often a list of nodes organized under proxies:. It should be referenced by proxy-providers in the main config; don’t assume it can be activated as a complete config.
• Base64 node list: Decoding it may reveal lines of protocol links. This is not the same as Clash YAML. Whether a client can import or convert it depends on its implementation.
• HTML page: If the content starts with <!DOCTYPE html> or contains login, verification, or access denied text, you’ve probably received a web page rather than a subscription config.

Being able to open a subscription in a browser doesn’t guarantee the client can download it. Browsers may send login cookies that clients don’t inherit, and the browser and client may use different proxy routes. If the endpoint requires a web login or interactive verification, ask your provider for a subscription URL designed for client use.

Parsing errors: check the core before guessing at indentation fixes

For unsupported proxy type, check the client’s “About” page or core information and note the client version and core name. Different cores in the Clash ecosystem support different features, and a config generated for mihomo may not work with an older Clash core. Choose a compatible format in your provider’s settings, or use a client that supports the required protocol.

For YAML errors with line numbers, check the indentation, colons, and quotation marks at the indicated location. If a remote config overwrites local files on every update, fix the generated content upstream or adjust the client’s overwrite rules instead of editing only the cached file; otherwise, the problem will return with the next update.

Update through a proxy using an existing working node

“System proxy enabled” and “download subscriptions through a proxy” are separate settings. Subscription requests may be sent by the client itself or handled by the core; whether they use the system proxy depends on the client. Switching rule, global, or TUN mode doesn’t guarantee that the subscription download route will change.

1. Enable the old config if it still works, select a working node, and confirm that a regular HTTPS request succeeds.
2. Open “Subscriptions” or “Profiles,” then open the target subscription’s edit or update menu. Look for options such as “Update through proxy” or “Use proxy.” Names and locations vary by client version.
3. If the option is available, enable it, update once, and check the result in the logs. If it isn’t, consult the client documentation rather than guessing at hidden settings.
4. After a successful update, check the timestamp, node list, and config activation status before deciding whether to keep using that download route.

On a Windows PC where the local mixed port is set to 7890, you can run these two checks in PowerShell. If the client shows a different port, use the one shown in its interface.

Test-NetConnection 127.0.0.1 -Port 7890
curl.exe --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 30 -I https://clash13.com/

The first command checks whether the local port accepts connections; the second tests an HTTPS request explicitly routed through the local HTTP proxy. A site response only confirms the result of that request. It doesn’t prove the subscription endpoint is reachable or that the client uses the same route for subscription downloads. If the proxy requires authentication, provide the credentials configured locally.

Auto-update intervals: subscriptions vs. providers

Auto-updates happen at two levels: the client can periodically download the full remote config, while mihomo can refresh proxy providers listed inside it. Both can run at once, but they aren’t interchangeable. The update time shown on a client’s subscription card doesn’t necessarily mean a provider was just refreshed.

Full subscription: set the interval in the client

Go to “Subscriptions” or “Profiles” → the target subscription’s menu → “Edit,” then look for auto-update and interval settings. Check the units shown next to the field: if it’s in minutes, 360 means 6 hours; if it’s in seconds, it means just 6 minutes. If the client doesn’t offer auto-updates, adding interval at the top level of a YAML file won’t add the feature.

• Everyday use: Start with 6 or 12 hours (360 or 720 minutes), then adjust to your provider’s requirements.
• Infrequent node changes: Choose 24 hours, or 1,440 minutes, to avoid unnecessary requests.
• Troubleshooting: Try one manual update and check the logs. Don’t temporarily set the interval to one minute.

These are configuration recommendations, not client defaults. Scheduled tasks may not run while a computer is asleep, the client is closed, a phone restricts background activity, or the network is disconnected. Whether missed tasks run after service resumes depends on the client. If the interval has passed without an update, first check whether the app has been running continuously rather than assuming the server is down.

Proxy providers: interval is in seconds

For mihomo HTTP proxy providers, interval under the relevant provider in proxy-providers is measured in seconds. Six hours is 21600 seconds, 12 hours is 43200, and 24 hours is 86400. When editing the config, keep the provider’s existing URL, path, and other fields; change only the refresh interval.

The interval under a provider’s health-check controls node health checks, not subscription downloads. Setting the health check to 300 seconds doesn’t refresh the node list every five minutes. Don’t copy a provider interval in seconds into a client field labeled in minutes.

Force a manual refresh: verify the result before clearing cache

Not every client has a button called “Force refresh.” Some offer only “Update”; others also have “Update all” or “Update proxy providers.” First decide whether you need to refresh the full remote config or a provider within it. Updating the outer config won’t necessarily download all providers again immediately.

1. Back up and note details: Save the current working config and record the target subscription name, last update time, and node count before updating.
2. Run one update: Select “Update” for the target subscription and wait for it to finish. If you see 429, stop clicking.
3. Confirm it loaded: Check the logs for successful download, parsing, and loading. If the client requires you to activate the new config manually, switch to it.
4. Check the content: Look for known changes to nodes or rules. An unchanged node count doesn’t mean the update failed; the server may have returned unchanged content.
5. Clear cache only as a last resort: If the URL is correct and the response is valid but the client keeps using old content, follow that client’s documentation to clear the relevant cache. Don’t delete the entire config directory.

Don’t append random parameters to a subscription URL to “bust the cache.” Some services use signatures or strictly validate query parameters, so changing them can invalidate the link. A 304 Not Modified response usually means the server considers the existing cache valid; it doesn’t by itself mean the update failed.

Still failing? Gather details others can reproduce

Start with a small set of comparisons: test the same subscription on your usual network and a mobile hotspot, then try direct and proxy downloads. Run each test once and note the time and error. These four results can help distinguish network routing, subscription service, and client issues—and are more useful than clicking Update ten times.

• Note your operating system, exact client version, and core name and version. “Latest version” isn’t enough.
• Record the subscription download error code, whether parsing succeeded, and the local time and time zone when it failed.
• State whether the system proxy, TUN, and subscription updates through a proxy are enabled.
• Share a redacted error excerpt. Never post the full subscription URL, node passwords, or unredacted config.

Once updates work again, set a reasonable auto-update interval and keep a verified working config. Subscription updates fetch config; node connectivity, rule-based routing, and whether apps use the proxy need to be checked separately. Troubleshooting each step on its own makes it easier to start at the right point next time.