Clash Subscription Update Failed: Troubleshooting and Auto-Update Intervals

First, distinguish subscription downloads from node connections

If a subscription update fails, check the error from the update request before reinstalling the client. Updating a subscription means requesting configuration from an HTTP or HTTPS URL; connecting to a node means the core uses the existing configuration to establish a proxy connection. These can involve entirely different servers, authentication methods, and network paths. A working old node does not prove the subscription URL is valid, and a successful subscription download does not guarantee every node can connect.

Another common source of confusion is the difference between a full configuration and a proxy provider. A client's subscription manager typically downloads a complete configuration and passes it to the core; proxy-providers lets supported cores download a set of nodes. These are separate layers with separate update mechanisms. Changing only interval in YAML may not affect how often the client refreshes the full subscription.

1. Note the client name, version, and core type, including whether it uses mihomo. Avoid saying only “the latest version of Clash.”
2. Click Update once manually and note when it happened and the exact error.
3. Identify whether the failure occurred during download, parsing, or configuration application.
4. Change one thing at a time. Once updates work, enable automatic refresh; avoid changing DNS, ports, and the subscription URL all at once.

Use the error to pinpoint network and URL issues

Start with the client's subscription notifications, update details, or logs. The same “update failed” message could mean a connection timed out or the server explicitly denied access. The status codes and error details below are more useful than a generic pop-up.

Compare using a different network

On the same device, try updating over your current Wi-Fi, then try again using your phone's hotspot. If the hotspot works, the issue is more likely to be your current network's DNS, outbound restrictions, or captive portal. On public Wi-Fi, a subscription request may return a sign-in page instead of YAML if you haven't completed the portal login. Being able to open the provider's homepage in a browser doesn't guarantee that its subscription subdomain or API is reachable.

If the log says connection refused, check which endpoint refused the connection. If it is 127.0.0.1:7890, check whether the local proxy port is listening before blaming the subscription server. Port 7890 is just a common example; use the HTTP or mixed port shown in your client.

Handle certificate errors and expired subscriptions separately

Certificate error: check the clock, then the network

x509: certificate has expired or is not yet valid can mean the server's certificate has expired, or that the device clock is wrong. First enable automatic date and time in your system settings, then check the year, date, and time zone before trying again. If you see certificate signed by unknown authority, check the system certificate store, HTTPS inspection on corporate networks, and whether the client's runtime environment is outdated.

Don't treat “skip certificate verification” as a permanent fix. Subscription downloads involve account tokens, and disabling verification weakens server identity checks. Also, skip-cert-verify in a node configuration usually affects TLS connections for that node; it is not a general fix for certificate errors when the client downloads a subscription. If the server certificate is confirmed to be invalid, the provider needs to fix it.

Expired URL: get a new one from your account dashboard

An expired account, a reset token, or a retired subscription domain can all invalidate the old URL. Check your plan status in the provider dashboard, choose a format compatible with your client or core, and copy the full URL. Don't copy the browser's sign-in page URL or omit anything after the question mark. Also check for line breaks added by messaging apps or trailing spaces.

• Keep a record of the old subscription before changing URLs. You can add a new profile first and remove the old one after confirming the new one works.
• A 403 response doesn't necessarily mean your account has expired; the request's source or User-Agent restrictions may also cause access to be denied.
• A page that relies on your browser's sign-in cookies to download may not work as an auto-update endpoint in a client.

How to troubleshoot a successful download that fails to parse

An HTTP 200 status only means the server returned content successfully; it doesn't mean that content is a Clash configuration. If the error includes HTML tags, DOCTYPE, or a sign-in prompt, you probably received a web page. A Base64-encoded node list or individual ss:// or vmess:// links also shouldn't be assumed to be a complete YAML configuration.

Tell full configurations and provider files apart

• Full configuration: Usually includes fields such as proxies, proxy-groups, and rules. It may also reference external nodes through providers.
• Proxy provider: A common YAML format uses proxies: to define nodes, but doesn't provide complete proxy groups and rules.
• Rule provider: Commonly uses payload: for rules and cannot be used as a proxy subscription.

Older Clash cores and mihomo don't support exactly the same protocols and fields. If the log says a proxy type isn't supported, check the core's capabilities or choose a compatible output format rather than just changing the indentation. When editing YAML manually, indent with spaces, not tabs, and align fields at the same level. A full configuration can also fail to apply if its rules refer to a proxy group that doesn't exist.

First, download again using the correct format provided by your subscription service. If conversion is necessary, use a trusted local tool or a conversion service you host yourself, then check that the converted configuration still includes the required proxy groups and rules. Never post a subscription URL containing a token publicly just to troubleshoot it.

Set the client's auto-update interval

Enable automatic refresh only after a manual update succeeds. A good starting point is every 6 hours: enter 360 if the field uses minutes, or 21600 if it uses seconds. This is a practical baseline, not a universal requirement. Follow your provider's minimum refresh interval if it specifies one.

Common client settings

Menu labels vary by release. Start with the subscription entry's edit window rather than looking only in global network settings. The paths below can help you find the setting; use the field and units shown in your current version.

Don't assume 0 means “update now.” Some clients use it to disable automatic refresh, while others control refresh with a separate toggle. After saving, check whether the “last updated” time changes. A changed value in the interface alone doesn't prove that the scheduled task is running.

A device that's shut down, a client that's closed, or a mobile app that's stopped by the system usually can't refresh on schedule. Whether a missed task runs after the device wakes depends on the client. If Android keeps missing refreshes, check restrictions under Settings → Apps → the client → Battery or Background activity. Menu names vary by manufacturer, and you don't need to disable all system power-saving features just to update subscriptions.

Provider intervals differ from subscription refresh intervals

With mihomo HTTP proxy providers, each provider under proxy-providers can have its own interval, measured in seconds. The snippet below shows fields to add inside an existing HTTP provider entry; it is not a complete configuration. Keep existing settings such as type, url, and path.

interval: 3600
proxy: DIRECT

This setting attempts to update the provider every 3600 seconds (one hour) and specifies a direct connection for the download. Check that your core supports the proxy field. In mihomo versions that support it, you can also enter the name of an existing, working outbound or proxy group. Don't copy these fields into an older core that doesn't support them.

• Full subscription refresh: Scheduled by the client; may replace the entire remote configuration.
• Provider refresh: Scheduled by the core; updates only the node content for that provider.
• health-check.interval: Sets how often health checks run, not how often the node list is downloaded.

If you edit a remote configuration file directly, the client may overwrite your changes the next time it refreshes. To keep changes long term, use the client's override, merge, or local configuration features, then verify the effective configuration after an update. Merge behavior varies by client, so don't rely on what you see in the editor alone.

The right order for updating subscriptions through a proxy

If the subscription domain isn't reachable directly, you can try downloading through a proxy, but you'll need an existing, working proxy route. The client usually downloads full subscriptions with its own network requests, while the core may download providers. The system proxy, TUN mode, and a subscription entry's proxy toggle are separate settings. Enabling one doesn't guarantee requests at the other layers will use a proxy.

1. Start the core with the old configuration and select a node you've already confirmed works.
2. Open the subscription entry's edit or update menu and look for “Use proxy” or a similar option. Enable it only if your version provides one.
3. If the client asks for a proxy URL, enter the actual listening HTTP or mixed port, such as http://127.0.0.1:7890. Don't enter the control API port.
4. Try updating again. Check whether the error changes from a connection timeout to a specific HTTP response, and verify the update time and new configuration contents.

If the client has no separate proxy toggle for subscriptions, check how that version handles the system proxy or TUN. Don't assume the request will be routed through either one. Whether TUN can capture these requests also depends on routing, process exclusions, and DNS settings. An HTTP proxy port is not an external control API; the common control port 9090 is for managing the core and can't be used as a subscription download proxy.

After recovery, check these five things

Don't stop at the “update successful” message. Downloading the configuration, applying it in the core, and having usable nodes are three separate outcomes. Verify each one before considering troubleshooting complete.

1. Time: The subscription's last-updated time reflects the current update, not an older record.
2. Contents: The expected proxy groups and nodes are present, and the correct profile is selected.
3. Logs: No subsequent YAML parse errors, missing proxy group references, or unsupported protocol warnings.
4. Connectivity: Test a destination that needs a proxy to confirm the current route can establish a connection.
5. Schedule: Keep the client running until the next scheduled time and check whether it refreshes automatically. If it fails, note the network and sleep state at the time.

If the problem persists, give the maintainer the client, core, and operating system versions; the time of the error; a redacted error line; and comparison results such as “direct connection failed, proxy worked.” There's no need to share subscription tokens or node passwords. Pinpointing the stage of failure is usually more effective than repeatedly deleting configurations or reinstalling the client.