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

First, determine whether the subscription download failed or the config failed to load

A Clash subscription update typically has three stages: the client requests the subscription URL, saves the response as a config, and the core validates and loads it. An “update failed” error can occur at any stage. If your nodes still connect, the old config may still be in use; that doesn’t mean the new subscription downloaded successfully. Likewise, a changed “last updated” time doesn’t necessarily mean the new config loaded correctly.

Open the client’s “Config” or “Profiles” page, find the active subscription, and click “Update” once. Then check “Logs” for errors at the same time. Menu names vary by client and version. Look for the update action on the subscription itself, not a latency test in the node list.

1. Save the exact error: For example, context deadline exceeded, 403, x509, or yaml: line 12. “Failed” alone isn’t enough.
2. Check how widespread the issue is: If only one subscription fails, check its URL and the provider’s server. If subscriptions from multiple providers fail, check your network, system clock, and client settings.
3. Keep a working copy of your config: Export or back up the current config before changing how it downloads. Backups may contain node passwords, so store them securely.

Diagnose the error: timeouts, status codes, and parse failures

These clues help narrow down the cause, but aren’t definitive. For example, 403 can come from a security gateway, not an expired account. A timeout can occur during DNS lookup, connection setup, the TLS handshake, or while waiting for the response body. Keep the log lines around the error, but don’t share authentication details from the request.

Subscription download timed out? Check which network path the request uses

A URL opening in your browser doesn’t guarantee the client can download it

Your browser may use the system proxy, its own secure DNS, or an authenticated session. The client’s subscription downloader may connect directly or use separate proxy settings. So “the browser can download it, but Clash can’t update” is entirely possible. Check the client’s config page for an option like “Update through proxy,” then see whether the logs show a connection to the subscription server or a local proxy port.

• Direct request times out: On the same device, switch to a mobile hotspot and try updating again. If that works, the issue is more likely related to DNS, the network’s outbound route, or access policies on your original network.
• Update through proxy fails: First confirm that the selected node can reach ordinary websites. If all your old nodes are down, relying on them to download a new subscription creates a catch-22.
• The error points to a local port: For example, 127.0.0.1:7890. Check that the core is running and that the mixed proxy port is actually 7890. This is only a common example; use the port shown by your client.

Don’t enable “Allow LAN” just to refresh a subscription. Local programs can usually access a proxy through the loopback address without exposing a port to your local network. TUN is not a requirement for subscription updates either: TUN handles network traffic routing, and whether subscription downloads use that route depends on routing rules, process exclusions, and the client implementation.

Run one controlled comparison instead of clicking repeatedly

Keep the same subscription URL and test, in order: direct on your current network, through a working proxy on that network, then on another network. Change only one condition at a time. If the client has a download timeout setting, increase it if it’s unusually short. But a longer timeout won’t fix DNS failures, invalid credentials, or a server refusing access.

Parse failure? Make sure you downloaded a Clash config

Subscription URLs don’t all return the same kind of content. A full Clash config typically includes fields such as proxies, proxy-groups, and rules. A proxy-provider file may contain only proxies and is intended for use as a proxy collection. Another common format is an encoded list of node URIs, which can’t simply be loaded as a full YAML config.

Identify the response before editing YAML

1. In your provider’s dashboard, choose a subscription endpoint explicitly labeled for Clash, Clash Meta, or mihomo, and check that its format is supported by your client’s core.
2. If the response starts with <!DOCTYPE html>, a login page title, or a CAPTCHA page, you downloaded a web page. Check for a login redirect, access restrictions, or an incorrect endpoint.
3. If the response is a list of node links such as vmess:// or ss://, use an import method explicitly supported by your client or ask your provider for the right format.
4. If the log names a YAML line number, check that line and the few lines above it in a local copy for indentation, colons, and quotes. YAML indentation requires spaces; don’t use tabs.

Changing a file extension to .yaml doesn’t convert its contents. Avoid submitting a full subscription URL to an untrusted online converter: the service can read the nodes and authentication details in it. Prefer your provider’s supported output format or a trusted local tool.

Valid syntax doesn’t guarantee core compatibility

If the log reports unsupported proxy type or points to an unsupported field, the config may use a protocol or option that your current core doesn’t support. That’s a compatibility issue, not a download failure. The original Clash, Clash Meta, and later mihomo cores don’t support exactly the same features. Check the core name and version on the client’s “About” or core information page, then choose a compatible subscription format. The app’s name alone isn’t enough to determine compatibility.

If the downloaded config has syntax or compatibility issues, restore a backup instead of deleting unfamiliar fields one by one. Removing a proxy group, proxy provider, or rule reference can cause a new load error, such as a missing policy.

Handle certificate errors and invalid URLs separately

Seeing x509? Check your device’s clock first

Certificate verification depends on the correct date and time. On Windows 11, go to “Settings” → “Time & language” → “Date & time,” check that automatic time is enabled, and sync the clock. On macOS, go to “System Settings” → “General” → “Date & Time” and check automatic settings. Retry the update after correcting the clock; you don’t need to change the subscription format first.

• certificate has expired or is not yet valid: Check your device’s clock. If the time is correct, the server operator should check the certificate’s validity period.
• certificate signed by unknown authority: The certificate chain may be incomplete, your local trust store may have an issue, or your network may be inspecting HTTPS traffic.
• Certificate hostname mismatch: Check whether the URL was changed to an IP address or redirected to a different hostname. First, copy the HTTPS URL from your provider again.

skip-cert-verify in a node config controls certificate checks for that node connection; it isn’t a general fix for subscription downloads. Disabling certificate verification to troubleshoot increases risk and won’t fix authentication failures or YAML syntax errors.

401, 403, and account status

Sign in to your provider’s account dashboard and check that your plan is active, the subscription URL hasn’t been reset, and there are no request-rate or device limits. Use the dashboard’s copy button to avoid copying ellipses, line breaks, or punctuation from the displayed text. Don’t remove query parameters after the question mark; they often contain your credentials.

A page you can access after signing in to the provider’s website may not be a subscription endpoint the client can request directly. Clients generally don’t inherit your browser’s login cookies. The correct endpoint should return a config directly as specified by the provider, rather than requiring you to click a login button.

Auto-update intervals: distinguish client subscriptions from proxy providers

There are two separate update intervals. The client manages its saved remote config. The proxy-providers section inside a config is managed by a core that supports it. Both can be present, but one setting can’t replace the other.

Full subscription: set the interval in your client

Open “Config” or “Profiles” → find the remote subscription card → open its context menu or more menu → look for “Edit,” “Subscription settings,” or “Auto-update.” If your version offers an update interval, check the unit beside the field before saving. If those options aren’t available, check the client’s documentation. Don’t add interval at the top level and expect the interface to refresh automatically.

These are starting points, not measures of node quality. Setting the interval to one minute won’t make nodes faster and may trigger rate limiting. If multiple devices share a subscription, account for their combined requests. Updates may not run on schedule while a computer is asleep, a phone restricts background activity, or the client is closed. After waking or reopening the client, check the last successful update time and logs.

Proxy providers: interval is measured in seconds

The example below is a config snippet for a core that supports proxy providers. The example hostname illustrates the structure only; replace it with the actual proxy-provider URL from your service. This snippet is not a complete, standalone config.

proxy-providers:
  remote-nodes:
    type: http
    url: "https://example.com/nodes.yaml"
    path: ./providers/remote-nodes.yaml
    interval: 21600
    health-check:
      enable: false

Here, interval: 21600 means the provider is fetched every 21,600 seconds, or every six hours. The response must use a proxy-provider format supported by the core, typically with a proxies list. Don’t use any full subscription config interchangeably. To use the provider in a policy group, also reference remote-nodes in that group’s use list.

health-check manages node availability checks; it doesn’t download the node list again. It’s disabled in this example so you can focus on update behavior. Don’t shorten the health-check interval to speed up subscription updates; they solve different problems.

After changing settings, verify a complete update

1. Refresh manually once: Confirm the original download or parse error no longer appears in the logs, and note the last successful update time.
2. Confirm the config is active: Check that the active config is still the intended subscription and that nodes and policy groups appear as expected.
3. Check your policy selection: After updating, confirm that each policy group still selects a working node. A successful subscription download doesn’t mean every node can connect.
4. Test a real connection: Open a website you use regularly, then check the connection and logs. Troubleshoot node connection failures separately from subscription download failures.
5. Wait for one update cycle: Leave the client running and check for a new successful update record. If manual updates work but scheduled ones don’t, check the scheduled task, background permissions, and client status.

If you still need help from the client maintainer or service provider, include your operating system and client versions, core name and version, when the failure occurred, the full error, and results comparing direct and proxy downloads. This is more useful for troubleshooting than “the subscription is broken.” Keep the full subscription URL, node passwords, and account details in a private support channel.