Keep your working config, then try one manual update
A failed Clash subscription update doesn't mean your current nodes have stopped working. Clients usually keep using the last successfully downloaded config. If your existing nodes still work, stay connected while you troubleshoot the update path. Don't start by deleting the subscription, clearing the config folder, or repeatedly reinstalling the client—you could remove the working config too.
- Open “Profiles” or “Configuration,” confirm which subscription is active, and note when it was last updated.
- Use the client's export or backup feature to save your current config. It may contain node passwords or subscription tokens, so store it only on a trusted device.
- Click “Update” for the affected subscription, then open the logs and note the full error, time, and HTTP status code.
- Check whether the failure affects the entire subscription or a
proxy-providersentry within the config. They may use different downloaders and update schedules.
Use the error message to pinpoint the failure
First check whether the download received a response, then whether the response could be parsed. Clients may translate or wrap the underlying error, so use the detailed log to diagnose it. A status code alone doesn't prove that your account has expired—check your subscription provider's dashboard and the response content too.
| Log message or symptom | Check first | Next step |
|---|---|---|
401 / 403 | Token, access restrictions, account status | Sign in to your provider's dashboard and copy the dedicated subscription URL again. Check whether you need to select a client type. |
404 / 410 | Outdated endpoint or revoked link | Check the endpoint currently provided by the service. Don't guess at changes to the URL path. |
429 | Too many requests | Stop retrying repeatedly. If the response includes a Retry-After header, wait for the specified time. |
500 / 502 / 503 | Server or gateway error | Keep your current config, try again later, and check for service announcements. |
no such host | Subscription domain lookup | Check your DNS settings, domain spelling, and network. |
timeout / deadline exceeded | Routing, proxy exit, response time | Test the update once over a direct connection and once through a working proxy. |
x509 or TLS error | System clock, certificate chain, network interception | Sync your system clock and check for captive portals or HTTPS inspection software. |
| YAML parse error | Response type and config compatibility | Check whether the download returned HTML, a node list, or an incompatible config. |
An HTTP 200 only means the server returned content—it doesn't mean that content is a usable Clash config. A captive portal might return a login page, or an API might return an error in JSON that the client later reports as a YAML or field-type error.
Fixing expired links and invalid tokens
Copy the full URL again; don't assemble the parameters yourself
In your subscription provider's dashboard, copy the endpoint for “Clash” or “Clash Meta / mihomo,” then replace the old remote URL in your config. An expired account, reset subscription token, or migrated subscription domain can all invalidate an old link. A QR code is just another way to share a URL—scanning it won't bypass token validation.
- Check that the URL doesn't include extra spaces, line breaks, or non-ASCII punctuation at either end. Copying it from a chat app can also corrupt the original parameters—for example,
&may be altered. - Don't use a web dashboard URL as a subscription URL. A page that you can sign in to in a browser may not be downloadable as a config by the client.
- If the new and old links use different tokens, test the new link on one device before updating your others. Repeatedly resetting the token will invalidate links on all your old devices.
- Never post your full subscription URL in public screenshots, online conversion tools, or discussion forums. When troubleshooting, share only the domain and error type; redact credentials in the path and query parameters.
A 403 can also come from server-side protection or client identification restrictions. If your dashboard confirms that the account is active, check the provider's client compatibility notes instead of repeatedly changing DNS. DNS can't restore access that the server has denied.
Choosing between a direct connection and a proxy
First find out which network path the client's subscription downloader uses. A browser's successful connection through the system proxy doesn't mean background downloads use that same proxy. Some clients have a separate “Update via proxy” option; others use their own network stack. TUN mode can capture more traffic, but doesn't guarantee that every background update request goes through the selected node.
Run two controlled tests instead of retrying repeatedly
- Keep your current working node, run one manual update, and note whether it times out.
- If the client offers “Update via proxy,” enable it and try once more. If there's no such option, check the client's documentation—don't assume the system proxy will work.
- If only the proxy route works, keep using it for updates. If only a direct connection works, check whether the subscription provider restricts the selected proxy exit.
- If both routes fail, check DNS resolution, server status, and your local firewall instead of switching nodes blindly.
On desktop, you can also use curl for comparison. The command below prompts for the URL locally, so the token won't be saved in your command history. The output file also contains sensitive information; delete it after checking. This example requires an environment with Bash and curl.
read -r -s -p 'Enter subscription URL: ' SUB_URL
printf '\n'
curl --noproxy '*' --connect-timeout 10 --max-time 30 \
-D subscription.headers -o subscription.body "$SUB_URL"
unset SUB_URL
Here, 10 seconds is the connection timeout, and 30 seconds is the total request time limit—not a measured latency. --noproxy '*' bypasses curl's proxy settings, but not system routing or an active TUN. To test a genuinely non-TUN route, note your current settings first, then temporarily turn off TUN.
To make curl use a local proxy, use the HTTP or mixed port shown in your client. For example, use --proxy http://127.0.0.1:7890 only if the client is actually listening on 127.0.0.1:7890. Don't use the controller port as a proxy port; the listening address varies by config.
Certificate errors and incompatible formats
For TLS errors, check your system clock first
If you see certificate has expired, certificate is not yet valid, or unknown authority, open your system's date and time settings and enable automatic time sync. Then check whether public Wi-Fi requires web sign-in, and whether security software is intercepting HTTPS connections.
If certificate errors keep affecting just one subscription domain while other HTTPS services work, ask the provider to check the certificate's validity and intermediate chain. skip-cert-verify in a node config is not a general fix for subscription downloads; it won't resolve certificate problems on the subscription server. Don't leave certificate verification disabled as a troubleshooting workaround.
Check the format after you receive the content
- Full Clash YAML: Usually includes
proxies,proxy-groups, andrules, and may reference external resources through providers. Load it in a compatible client. - Base64 node list: May decode to multiple lines of proxy URLs, but isn't a complete Clash config. Choose the matching format in your provider's dashboard if available.
- Provider YAML: Often contains only a set of nodes under
proxies. It's intended forproxy-providers, not as a complete traffic-routing config by default. - HTML or JSON error response: Fix the login, permissions, or gateway issue first. Changing YAML indentation won't help.
Clash refers to an ecosystem of clients and cores. The project formerly known as Clash Meta is now maintained as mihomo. Older cores may not support newer protocols or fields. If the log reports an unsupported proxy type, check which core is actually running and the provider's compatibility requirements—not just the desktop app's name. Back up your config before editing, and use spaces rather than tabs for YAML indentation.
Where to set auto-update intervals in each client
GUI clients usually handle scheduled refreshes of the entire remote config. There is no universal top-level interval setting that controls subscriptions in every client. Open the settings for the relevant subscription and check the unit shown for the interval field. The paths below are common examples; labels, button locations, and field names vary across versions and localizations, so follow the interface in your installed version.
| Client | Typical steps | Notes |
|---|---|---|
| Clash Verge Rev | “Configuration” → right-click the remote config or open its more menu → “Edit Info” → “Update Interval” | This changes the refresh interval for that config entry. Check the unit shown in the UI, then save. |
| Clash for Windows | “Profiles” → right-click the remote config → “Settings” → “Update Interval” | This project is no longer maintained. The legacy UI and compatibility can vary; back up your config before considering a migration. |
| Clash for Android | “Configuration” → open the editor for the remote config → “Auto Update” or the update interval field | This project is no longer maintained. Background refreshes can also be affected by system battery limits and app background permissions. |
| Other mihomo GUI clients | “Configuration / Subscriptions” → “Edit” or “Settings” for the relevant entry | If there's only a manual update button, don't assume scheduled refresh is supported. Check the features in your version. |
Choosing an update interval
For a typical node subscription, start with an interval of 6 hours—enter 360 minutes or 21600 seconds, depending on the field's unit. This is a starting point, not a requirement for every service. Follow your provider's minimum interval if specified. For a small, stable node list, you can switch to every 12 or 24 hours.
Don't set the interval to 1 minute to “fix” a failed update. Permission, certificate, and format errors won't disappear with more frequent requests, and you may trigger 429 responses. The meaning of an interval of 0 also varies: some clients disable automatic updates, while others may restore a default. Check the field's help text.
mihomo provider updates are a separate layer
If the full config downloads successfully but the node list doesn't change, check proxy-providers. mihomo HTTP providers use an interval in seconds to fetch external node files. This is separate from the GUI client's refresh of the entire subscription.
The example below is a local provider snippet for an existing config. The file must already exist and contain a valid set of nodes. It doesn't fetch remote updates; adding an interval alone won't turn it into an HTTP subscription:
proxy-providers:
local-nodes:
type: file
path: ./providers/local-nodes.yaml
For an existing HTTP provider, keep its actual url and any other required fields. Set interval: 21600 within that provider to refresh the node file every 6 hours. Don't put this line under rules or at the top level of the config and expect it to refresh the entire subscription.
proxy-providers.name.interval: Controls how often the node set is downloaded from this HTTP provider, in seconds.health-check.interval: Controls how often provider nodes are checked for health; it doesn't download new nodes.rule-providers.name.interval: Sets the update interval for the corresponding HTTP rule set; it doesn't refresh the node list.
The next remote subscription refresh may overwrite provider settings you edited manually. To keep changes, use the client's supported override, merge, or extension features, and check the effective config. A successful save in the editor alone doesn't prove the running core has applied the new value.
Verify that updates are working again
- Check the download: Confirm the last-updated time changed and the logs show no new HTTP, TLS, or parsing errors.
- Check the active config: Make sure the newly updated config is selected, not a local copy with the same name.
- Check the proxy group: See whether the node list changed. If your previously selected node was removed, choose a working exit again.
- Check the connection: Open a service that requires a proxy and check the matching rule and exit in the connection log. A successful subscription update doesn't mean traffic is being routed as expected.
- Check the next interval: Note the current time and update interval, then check the timestamp after the next cycle to confirm the scheduled task ran.
Keep one reliable recovery path: back up your current config, save the subscription endpoint, and know where to trigger a manual update. If the problem persists, send the provider or client maintainer redacted logs, client and core versions, the time of the error, and the results of direct and proxy tests. Never share your full subscription URL or a config containing credentials.