Clash Subscription Not Working? Causes and Fixes

First, tell download failures from configuration parse errors

A failed subscription update doesn’t necessarily mean the link has expired. Start by pinpointing where the process fails: did the client receive a response, is that response a Clash configuration, and can the current core recognize its fields? Checking in this order is more useful than repeatedly reinstalling the app.

Keep your working configuration, then create a separate one for testing. Don’t delete all your nodes or change DNS, TUN, and proxy mode all at once. Change one thing at a time, and note when you update and the exact error message.

Cause 1: Expired links, invalid tokens, or incomplete copies

Copy the link again from the provider’s dashboard—don’t piece it together from chat messages

Open your subscription provider’s account page and check your plan status, expiration date, and remaining data, then locate the subscription link. Some services invalidate the old URL as soon as you reset a subscription. Being able to sign in doesn’t mean the old token is still valid.

1. In the dashboard, select a subscription format compatible with Clash or your current mihomo client, then use the copy button to get the full URL.
2. Open the client’s configuration editor and check that the URL starts with https:// and has no extra spaces, line breaks, or punctuation at the end.
3. Keep all original query parameters. Don’t remove anything after the question mark or truncate parameters after &.
4. Save it as a new configuration and run an update manually. Check whether the status changes from failed to successful and whether the last-updated time changes.

If the copied link contains the literal text &, you may have copied escaped source from the webpage. Go back to the provider’s copy button and get the link again instead of guessing which parameters to change. After importing by QR code, confirm that a configuration was actually created; a successful scan alone doesn’t mean the subscription works.

What HTTP status codes mean

401 usually means authentication failed. 403 may indicate an access restriction or a security filter. 404 can mean the URL changed, the path is wrong, or the server is hiding an invalid resource. A status code alone can’t confirm that your plan has expired. For 429, stop retrying and wait as directed by the server. With 5xx errors, check the provider’s service status.

Cause 2: The response isn’t a Clash configuration

Opening a subscription URL in a browser only confirms that the request received a response. It could be a sign-in page, CAPTCHA, error message, or a node list for another client. Even an HTTP 200 response doesn’t mean Clash can parse it.

Check the actual response in your browser

1. Open the copied subscription URL on your own device. Don’t use a public web proxy to access it.
2. If a file downloads, open it in a local text editor. If the content appears in the browser, check the opening lines and main fields.
3. A sign-in form, CAPTCHA, <html>, or <!DOCTYPE html> means you received a webpage, not a configuration.
4. If the response contains multiple links such as ss:// or vmess://, or a block of encoded text, go back to the dashboard and choose the Clash format. Renaming the file to .yaml won’t convert it.

A complete Clash configuration commonly includes proxies or proxy-providers, along with fields such as proxy-groups and rules. But the presence of proxies alone doesn’t prove a configuration is valid: configurations using remote proxy providers may not embed nodes directly.

Also distinguish a full configuration subscription from a proxy-provider file. A provider file often starts with proxies: and is referenced by proxy-providers in a main configuration. It may not include the proxy groups and rules needed for everyday use. Importing it in the wrong place can leave you without proxy groups or produce unexpected behavior.

Cause 3: Network, DNS, or TLS blocks the update request

If you see a connection timeout, DNS lookup failure, or certificate error, troubleshoot the request path first—don’t edit the YAML right away. The client may not have downloaded the configuration at all, and changing routing rules usually won’t fix that download attempt.

Compare two networks, changing only one variable

1. Note the full error message, keep the same URL, and try updating once over Wi-Fi.
2. Switch to mobile data and try again. If the update fails on only one network, focus on that network’s DNS, captive portal, or access restrictions.
3. If you already have a working configuration, compare update results with the service stopped and running. Depending on the client version, subscription requests may use a proxy or take a different network route.
4. Check your system’s Settings → System → Date & time and turn on automatic time. Menu names vary by phone manufacturer. A significantly incorrect date can cause certificate validity checks to fail.

no such host points to a DNS resolution problem, connection refused means the connection was rejected, and i/o timeout means the request timed out. For x509 errors, check the certificate and system time. These details are more useful for troubleshooting than a generic “update failed” message.

If updates require a proxy but your only configuration is broken, you can get stuck in a loop: you need a connection to update, but need an update to connect. Try using another trusted network to fetch the configuration, or import a local file as instructed by your provider. Don’t permanently disable certificate verification to get around an error, and don’t change an HTTPS URL to HTTP without a good reason.

If the configuration downloads but the logs show a proxy-provider or rule-provider fetch failure, a resource request failed afterward. Note the resource type and domain, then check their connectivity separately. A successful main subscription update doesn’t guarantee that every remote resource has updated.

Cause 4: YAML syntax or core compatibility errors

If the error includes a line number, check that line and the indentation above it

YAML uses spaces to define nesting. Tabs, non-English colons, missing quotation marks, and misaligned list items can all cause parse errors. The reported line may only be where the parser noticed the problem, so check the preceding lines too.

• Use consistent indentation for fields at the same level. The examples below use two spaces; don’t mix in tabs.
• Use an English colon to separate fields, with a space after it as required by YAML syntax.
• If a node name contains special combinations such as : or #, wrap the string in matching quotation marks.
• Node names and group names referenced by proxy groups must match exactly, including capitalization and spaces.
• Don’t define keys such as rules more than once at the same level; parsers may handle duplicate keys differently.

The examples below show how to write lists and strings. They aren’t complete proxy configurations you can use as subscription replacements:

proxy-groups:
  - name: "Manual Select"
    type: select
    proxies:
      - DIRECT

rules:
  - "DOMAIN-SUFFIX,example.com,DIRECT"
  - "MATCH,Manual Select"

If the error started after editing the file locally, restore the copy you had before editing. If the remote subscription itself is broken, ask the provider to fix it. Changes to a local cache may be overwritten the next time you update.

Valid YAML doesn’t guarantee support in your current core

The original Clash and Clash Meta (now called mihomo) don’t support exactly the same configuration features. For example, a node with type: hysteria2 requires a core that supports that protocol. An older original Clash core won’t recognize it just because the file is valid YAML.

In the client’s About or core information page, note the client name, app version, and core version, then compare them with the requirements listed by your subscription provider. Similar-looking app interfaces don’t guarantee the same core, and updating a subscription won’t add protocol support to an older core. If you need a different client, start with the client guide, then choose a format supported by your new client.

Run through a complete check in your Android client

Using the classic Clash for Android interface as an example, go to Configuration → tap + in the upper-right corner → URL, enter a name and subscription URL, then save. To edit or update an existing configuration, open its menu. Button names may vary between forks, so follow the interface you see. Don’t confuse the node import option with the full configuration import option.

1. Update first: Wait for the request to finish and note the success time or full error message. Tapping update repeatedly won’t fix a format issue and may trigger rate limits.
2. Select it next: Make sure the newly updated test configuration is enabled, not an older one in the list.
3. Start the service: Return to the home screen and start the service. When prompted, grant Android VPN permission and check for configuration loading errors.
4. Check proxy groups: Open the proxy screen, make sure the expected nodes appear in your groups, then select a node and test the connection.
5. Test a real site: Open a website you want to access. A successful latency test only shows that its test target was reachable at that moment; it doesn’t confirm that every site and rule is working.

If the update succeeds and the service starts but websites still won’t load, subscription parsing has probably succeeded. Next, check proxy mode, node status, DNS, and app access controls. Switching to TUN or changing mixed-port isn’t necessary to fix YAML syntax; troubleshoot the actual connection problem instead.

Still stuck? Share these redacted details

When contacting your provider or client maintainer, clear reproduction steps are more useful than simply saying “the subscription is broken.” Prepare these five details:

• Client name, app version, core name and version, and Android version.
• Exact time of failure, whether you were using Wi-Fi or mobile data, and whether the service was running.
• The full error message and line number. Redact tokens, passwords, and personal domains from logs as needed.
• What the browser returned: configuration text, a downloaded file, or a sign-in or error page.
• What happened with the same link on another network, and when it last updated successfully.

Check in this order: link status → response format → network request → syntax and core compatibility. This usually narrows the issue down to a specific layer. Keep a working copy, change one thing at a time, and verify using the exact error message and update result to avoid repeated guesswork.