First, identify the failure: download, parsing, or config loading

A “subscription failed” message in a Clash client doesn’t necessarily mean the link has expired. Importing a subscription typically involves requesting the URL, receiving its contents, parsing the config, and loading it into the core. The failed step determines whether to check your network, the text format, or core compatibility.

  1. Keep your working config. Don’t delete the old subscription or overwrite your only local backup. Your existing config may still work even if an update fails.
  2. Capture the full error. Check the client’s logs or import message for the time of failure, HTTP status code, error field, and line number. A screenshot that only says “failed” won’t help pinpoint the issue.
  3. Check the client and core. Note the client name and version, and whether its core is Clash Meta (now called mihomo). The client version and core version are not the same thing.
  4. Change one thing at a time. Check the link and response first, then inspect the YAML, and finally look at proxy groups and rules. Manually update after each change so you don’t alter several settings at once.

Use the error message to decide what to check first

Different clients may word errors differently, but most underlying issues fit into the categories below. A status code only describes the server’s response; on its own, it can’t confirm your account balance, subscription expiry, or device limit.

Error or symptom Check first What to do next
401、403 Authentication failed, access restricted, or request blocked Copy the subscription link again and check your account status and your provider’s notices
404、410 URL is invalid, path has changed, or resource has been removed Get the current link from your account dashboard instead of using an old bookmark
429 Too many requests Stop refreshing and wait as directed by the server before trying again
timeout、no such host Connection timed out or DNS lookup failed Try another network and compare update results with and without a proxy
x509 or certificate error Incorrect system time, certificate chain issue, or HTTPS interception Correct the system time and check network authentication and certificate settings
yaml: line … Invalid text syntax, or the response isn’t a config Inspect the response and the surrounding lines
unsupported proxy type The core doesn’t support the proxy protocol or combination of fields Compare the config’s requirements with the core in use
A proxy group or rule refers to something that doesn’t exist Names don’t match, nodes were filtered out, or the config is incomplete Trace references between nodes, proxy groups, and rules

Check the subscription link: copy the full URL and verify your account status

Rule out copy errors and the wrong subscription endpoint

Go back to your provider’s dashboard and use the copy button for the subscription link. Check that the URL starts with https:// and doesn’t end with a newline, space, or punctuation. Don’t remove parameters after the question mark, and don’t mistake a shortened URL shown in a chat app for the full address.

  • Distinguish the dashboard from the subscription endpoint: Being able to open your account page doesn’t mean you have the config URL that a client can fetch.
  • Distinguish a single node from a subscription: Schemes like ss:// and vmess:// may be node-sharing URIs, not complete Clash configs that can be updated directly.
  • Check whether the link was reset: An old link may stop working after a password change, subscription token reset, or service migration.
  • Check your account status: Look for an explicit notice in your dashboard about expiry, exhausted traffic, or suspended service. Don’t infer account status from the client error alone.

Why does the link open in a browser but fail in the client?

Your browser may have a login cookie or may have completed a web security check automatically; the client’s request usually has no such login state. A browser may show “access granted” while the actual response is a login page, CAPTCHA, or subscription information page. Check whether the response contains config text rather than merely checking that the page opens.

Even with a 200 status code, the response may start with <!DOCTYPE html> or contain JSON with an error message. In that case, the YAML error is only a downstream symptom; the real issue is endpoint access or account authentication.

Check the subscription format: a Clash config isn’t the same as a list of nodes

A complete Clash config is usually a YAML mapping with top-level fields such as proxies, proxy-groups, and rules. Other subscriptions may return a Base64-encoded node list or a config intended for another client. They may all be called “subscriptions,” but that doesn’t mean they can be imported the same way.

Complete configs, proxy provider files, and single nodes

  • Complete config: Usually imported through the client’s config or subscription manager, and includes runtime settings such as proxy groups and rules.
  • Proxy provider file: Referenced through proxy-providers and usually contains a proxies list. It isn’t a complete setup on its own.
  • Single-node URI or encoded list: Requires explicit support for that import method in the client. If it isn’t supported, ask your provider for a Clash- or mihomo-compatible format.

Use the endpoint your provider specifically recommends for your client or core. Some providers return different formats depending on the request’s User-Agent, so the same URL may respond differently in a browser and a client. Don’t spoof request headers and hope for the best; check your provider’s setup instructions first.

Check the YAML: start with the line number, then inspect the line above

Only troubleshoot YAML after confirming that the response really is a config. Save it locally and open it in an editor that displays line numbers, spaces, and tabs. The line flagged by the parser is where it could no longer continue; the actual mistake may be a quote, colon, or indentation on the previous line.

Common syntax errors and how to fix them

  1. Indent with spaces. Use 2 spaces per level and don’t use tabs for indentation. Fields at the same level must line up.
  2. Put a space after the colon. mixed-port: 7890 is a key-value mapping; mixed-port:7890 does not express the same structure.
  3. Use standard English punctuation. Full-width colons, curly quotes, and full-width spaces can change the syntax. Don’t edit configs in a rich-text editor.
  4. Check the hyphens in lists. Each item in a list such as rules needs - ; don’t omit the space after the hyphen.
  5. Avoid duplicate top-level keys. Don’t add a second dns or rules section with the same name. Parsers may handle duplicate keys differently.

The example below shows the syntax for basic fields only. It contains no remote nodes and is not a subscription replacement. It demonstrates the hierarchy of ports, modes, nested fields, and a rule list:

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

dns:
  enable: true
  nameserver:
    - 1.1.1.1
    - 8.8.8.8

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,DIRECT

Here, 7890 is an example listening port, not a subscription download port. Changing it usually won’t fix a remote subscription parse error. The example DNS addresses may not be reachable on every network; choose addresses suited to your network for a real config. Don’t overwrite your existing DNS settings just to fix indentation.

Passing YAML syntax checks doesn’t mean all references are valid

Readable YAML doesn’t guarantee that the core can load the config. If a rule says MATCH,Proxy, the config must contain a valid outbound target named Proxy, such as a proxy group. Group names must match exactly, including capitalization, spaces, and symbols. If node filters exclude every candidate, check that the proxy group still has a valid option to select.

Local edits to a file generated by a subscription may be overwritten the next time it updates. For changes you need to keep, use the client’s supported override, merge, or extension mechanism, and confirm its scope first.

Check the network: test subscription downloads separately from node connections

A working node connection doesn’t mean the subscription domain is reachable; a successful download doesn’t mean every node works. If the logs show a timeout, DNS lookup failure, or TLS error, fix the request path first. Don’t immediately change proxy protocols or routing rules.

  1. Confirm ordinary websites are reachable. Public Wi-Fi may require browser sign-in first. An incorrect system date or time zone can also cause HTTPS certificate checks to fail.
  2. Compare networks. For example, switch from home broadband to a mobile hotspot and manually update once in the same client. Change only the network and leave other settings alone to see whether the current network is the issue.
  3. Test direct and proxied updates separately. If your client lets you choose how subscription updates connect, test both options. Some clients don’t route update requests through the system proxy, so the system proxy toggle alone doesn’t tell you which route is being used.
  4. Check for a stale local proxy. In Windows 11, go to Settings → Network & Internet → Proxy to check the manual proxy address. If it still points to 127.0.0.1:7890 when that service is stopped, requests using that setting may fail. The actual port depends on your client.
  5. Avoid an update deadlock. If you need your existing proxy to download the subscription, keep a working config before updating. Deleting the old config may leave the subscription request with no working route.

If you get 429, stop repeatedly clicking Update. If the server provides Retry-After, wait as instructed. For 5xx errors, note the time and status code before contacting your provider. Repeated refreshing usually won’t fix a server-side error and may trigger further restrictions.

After import: verification and support checklist

A successful import only means the config was accepted; it doesn’t mean it’s handling your traffic. First confirm which config is selected, then check proxy groups, routing mode, and the system proxy or TUN status. TUN captures traffic; it isn’t a switch for fixing subscription text format errors.

Verify the result at three levels

  • Config: Confirm the update time changed, nodes and proxy groups appear normally, and the logs no longer report syntax or reference errors.
  • Connection: Select a node and test connectivity. A failed latency test and a subscription parse error happen at different stages; record them separately.
  • Traffic: Visit a site expected to use the proxy, then check the connection log for the matched rule and actual outbound route. In rule mode, some requests going direct is normal.

Still failing? Include these details when asking for help

When contacting your provider or client maintainer, include the client version, core version, operating system version, time of failure, HTTP status code, and the full error with sensitive details redacted. If YAML line numbers are shown, include the redacted contents of that line and the three lines before and after it. For network issues, report the results of tests using a direct connection, a proxy, and a mobile hotspot.

Don’t just say “Clash isn’t working,” and never post your full subscription file publicly. Specify whether the issue is a “request failure,” “parse error,” “load error,” or “connection failure” to cut down on back-and-forth. To check traffic capture settings, see the System Proxy Setup Guide. For config fields and connection issues, continue with the config.yaml section of the troubleshooting guide.