Fix Clash Subscription Update Errors: Expired Links, Format Issues, and Auto-Update Settings

First, identify the failure: subscription download or config loading

A Clash subscription update typically involves three steps: the client requests the subscription URL, parses the response, and passes a valid config to the core. An “update failed” message doesn’t necessarily mean your nodes are down; the previous config may still be running normally in memory. Conversely, a successful download doesn’t guarantee the current core can load the new config.

Open the client’s “Logs” page, then go to “Profiles” and update the affected subscription. Some clients call this page “Subscriptions”; check the label in your app. Note the time, error keywords, and subscription’s last updated time. Don’t delete configs, switch cores, and reset network settings all at once.

• Request failed: Common messages include timeout, no such host, 403, and 429. Start by checking the URL, network, and server response.
• Parsing failed: Keywords such as yaml, unmarshal, and invalid config point to a problem with the response format or config content.
• Loading failed: If the download completes but the client reports an unsupported proxy type or fails to apply the config, check core compatibility.

Expired links and access restrictions: diagnose by HTTP status

Copy the subscription URL, not the provider’s website address

Sign in to your subscription provider and check your plan’s expiry, traffic status, and whether you’ve reset the subscription link. A reset may immediately invalidate the token in the old URL. Choose the subscription option for Clash or mihomo. Don’t copy a login page, account homepage, QR code image URL, or download link tied to a temporary login session.

A full URL often includes query parameters. Don’t remove anything after ? or accidentally include punctuation, quotation marks, or line breaks from a chat app. If you suspect the old link has expired, keep the existing subscription and test the new URL in a separate entry. Remove the old one only after the new config loads successfully.

A URL opening in your browser doesn’t mean the client can update it

Your browser may include login cookies, pass a human-verification check, or use a different proxy route from the client. Subscription requests from the client generally don’t inherit browser session data. If the URL looks fine in a browser, that only confirms the browser’s request succeeded—not the result shown in the client logs.

If the provider requires specific request headers or a particular client type, use the official subscription link in its documentation. Don’t keep changing the User-Agent at random; this can alter the server’s response format and turn an access problem into a format issue.

Incompatible formats: distinguish full configs, proxy lists, and core support

Subscriptions don’t all use the same file format. A full Clash YAML config usually includes proxies, proxy-groups, and rules. A proxy provider file usually contains only proxies and is referenced by proxy-providers. Some URLs return a list of share links or encoded text. Don’t assume every client can load these directly as a complete config.

Check the error message, one issue at a time

1. Response starts with HTML: If you see <!DOCTYPE html> or a login prompt, you received a webpage, not YAML. Check the subscription link and access permissions.
2. YAML line number reported: Check the indentation, colons, and quotation marks around that line. YAML uses spaces for indentation, not tabs. Don’t paste full-width punctuation from a rich-text editor into field names.
3. Proxy group missing or reference not found: Check whether the group names referenced by your rules and the node names in each group actually exist. Downloading a proxy list won’t automatically create all your routing rules.
4. Unknown proxy type or field: Check which core and version are actually running. The client version and core version are separate; you can usually find them under “About” or in the core settings.

mihomo extends the Clash config ecosystem, but older Clash cores don’t support every newer protocol and option. If a subscription is specifically designed for mihomo, use a compatible client and core. Save the full error line and back up your config before upgrading. Don’t delete unfamiliar protocol fields just to silence an error.

Your own proxy may be blocking the update: test direct and proxied connections separately

A common catch-22: the client needs the current proxy to update the subscription, but the current node is down—and you need the subscription to get new nodes. Both websites and subscription requests may time out. The reverse can also happen: the subscription domain can’t be reached directly on your network, but the client tries to update without a proxy by default.

First, find out which process makes the request. The client usually downloads a full remote config; the core manages remote proxy lists under proxy-providers. A client’s “Update through proxy” option may not control requests for core-managed proxy lists. Switching Rule, Global, or system proxy mode doesn’t necessarily change the route used by the update process.

1. Look for options such as “Update through proxy” or “Update via proxy” in the target subscription’s edit menu or client settings. Some clients don’t offer a separate toggle; check their release notes or documentation.
2. If the update currently uses a proxy, select a known-working node and try again. If it still fails, test once without a proxy.
3. If the update currently connects directly and the logs show a timeout to the subscription domain, try a working proxy. You can also temporarily switch to a phone hotspot to check whether your current network is restricting access.
4. Restore the settings you need after testing and note which route worked. Change one thing at a time so network changes don’t get mixed up with config changes.

Don’t confuse port, DNS, and certificate errors

connection refused 127.0.0.1:7890 means a request tried and failed to connect to port 7890 on your computer. Check whether the core is running and whether mixed-port is actually set to 7890. If you changed it to 7897, update the proxy settings for subscription requests too; they must not keep pointing to the old port.

no such host usually points to a DNS resolution problem. For x509 or certificate validity errors, first check the date, time, and time zone in Windows, then consider HTTPS inspection on the network or an issue with the server’s certificate. Don’t disable certificate verification to hide the problem. A connection timeout doesn’t automatically mean DNS is at fault; use the logs to see whether the failure occurred during DNS lookup, connection, or the TLS handshake.

Auto-update intervals: set client subscriptions and proxy lists separately

The client manages scheduled updates for full subscriptions

Open “Profiles” or “Subscriptions,” then look for “Edit,” “Edit profile,” or update settings in the target entry’s right-click or more menu. Check whether auto-update is enabled and what unit the interval uses. Menu names vary by client; don’t assume one app’s settings path applies to every Clash client.

• If your provider doesn’t specify an interval, start with an update every 12 hours. If the setting uses minutes, enter 720; if it uses hours, enter 12.
• Once a day is 1440 minutes or 24 hours. Check the unit as well as the number.
• Don’t assume 0 means “update now.” It may disable updates, use a default value, or mean something else; check your client’s documentation.
• If your client supports the server’s suggested update interval, follow the provider’s guidance where possible. Not every client recognizes or applies this recommendation.

When a desktop client exits, its in-process scheduled tasks usually stop running. Subscriptions also won’t update as usual while Windows is asleep. Running the core as a background service doesn’t mean the client process responsible for full subscription updates is still active. If you need scheduled refreshes, keep the client running and check the last update time after waking or restarting your computer.

proxy-providers interval is measured in seconds

If you use mihomo remote proxy providers, interval is a core config setting measured in seconds. This snippet illustrates how the fields relate; it’s not a complete subscription. The example domain isn’t a real service, so replace it with a trusted URL of your own.

proxy-providers:
  remote-nodes:
    type: http
    url: "https://example.com/nodes.yaml"
    path: ./providers/remote-nodes.yaml
    interval: 86400

Here, 86400 means 24 hours, 43200 means 12 hours, and 3600 means 1 hour. A proxy group must also reference the provider with use, and the response must match the proxy provider format. Don’t add this field directly to the top level of your YAML and expect it to control full subscription refreshes in the client.

In a proxy provider, health-check.interval sets how often nodes are checked for availability; it doesn’t set the subscription download frequency. Changing the health check to 300 seconds only affects that check—it doesn’t mean the node list is fetched every 5 minutes. For lasting changes, use the client’s supported override or merge features so the next subscription update doesn’t overwrite your local edits.

Force a manual refresh: keep the old config and verify the new one

Manually updating a subscription helps confirm whether a link is working again or fetches a config after the provider announces node changes. “Force refresh” isn’t a standard menu label: some clients only offer “Update,” while others have “Update all” or an option to ignore the local update interval. It won’t necessarily bypass server-side caching or fix an invalid token.

1. Save the current state: Note the active config name, last updated time, and working nodes. If needed, export a backup to a protected folder on your computer.
2. Update only the target entry: Select “Update” for that subscription in the profile list. This makes it easier to diagnose the problem if multiple subscriptions fail at once.
3. Check the result: Match the log timestamps to confirm the request completed. Check whether the last updated time changed and whether any parsing or core loading errors appeared.
4. Confirm it’s active: If the client doesn’t reload automatically, select and apply the updated config manually. Then check that the proxy groups are present and the routing mode is as expected.
5. Test it in practice: Test one site that should connect directly and one destination that should use a proxy. Check the connection log to confirm the matched rule and exit node; a change in node count alone isn’t enough.

If the update time changes but the node list doesn’t, the upstream content may simply be unchanged; that doesn’t necessarily mean there’s a caching problem. Adding random query parameters to the URL isn’t a universal fix and may invalidate signed links. If the new config fails to load, save the logs and switch back to a working config instead of repeatedly deleting the entire config directory.

Still failing? Gather these details

Before contacting your subscription provider or client project, prepare a short diagnostic summary. It’s usually more helpful than saying “it won’t update.” Include the original error text, but don’t share your subscription URL, authorization headers, or node credentials.

• Environment: Windows version, client name and full version number, and the name and version of the core actually running.
• Time of failure: For example, a manual update at 9:20 AM local time. Include your time zone so the provider can find the relevant server logs.
• Failure stage: Did the request fail, did YAML parsing fail, or did the download succeed but applying the config fail?
• Comparison results: Did direct access work? Did a working proxy work? Did the problem persist after switching to a hotspot?
• Schedule settings: Is auto-update enabled? Include the interval and unit, and note whether the client was closed or the computer was asleep when the issue occurred.

Follow the same troubleshooting order: check the link and account status first, then the response format, then compare network routes for the update request, and finally check scheduled tasks. This helps separate provider, client, and core issues—and avoids resetting all of Windows’ network settings over a temporary subscription problem.