Import errors and empty node lists after updates usually trace to four causes: expired links, server response format, User-Agent limits, or local network issues. This article gives a checklist ordered by likely cause, with judgment methods and fixes for each.
The subscription feature in Clash-family clients (original Clash, Clash Meta, and its core mihomo) works by periodically sending an HTTP(S) GET request to the subscription link. The server returns a plain-text config or a Base64-encoded node list, and the client parses that response into proxies, proxy-groups, rules, and other structures, then writes them to a local cache file. Three parties are involved: the subscription server, the transport path (local network and DNS), and the client's parser. A problem in any one of them shows up as "import failed" or "empty node list after update," but the underlying causes are completely different — blindly reinstalling the client or repeatedly hitting "update" rarely fixes anything.
Common errors fall into four patterns: first, importing the subscription directly triggers a "parse failed" or "invalid format" message; second, the subscription imports fine but updating times out or the connection is refused; third, the update "succeeds" (no error dialog) but the node list ends up empty or stays unchanged; fourth, some nodes connect while others fail, which usually has nothing to do with format and is simply dead nodes. This article checks from outside in: the link itself, the server response content, request-header restrictions, and finally local network and client settings — go through them in order.
This is the most common cause and the easiest one to overlook. Most subscription providers set an expiry date or a traffic-reset cycle on links; once that's hit, the link still "exists" but the server returns an error page or empty content, and the client naturally fails to parse an unexpected response. Check it like this:
Paste the link into your browser's address bar. If it returns a login page, an error message, or a plan-expired notice, the problem is on the provider's account side, not the client — contact the provider to renew, rather than debugging Clash itself.
A normal subscription response is usually a few hundred bytes to a few dozen KB of text. If the browser shows a blank page or the byte count is tiny (under a few dozen bytes), the account has likely run out of traffic or the link has been revoked server-side.
Copying links from group chats or messaging apps can add trailing spaces or line breaks, or the link may get auto-converted into a short URL. Paste it into a plain-text editor first and visually verify the scheme (http/https), domain, and path parameters are intact before pasting it into the client.
Some providers set a minimum interval between updates for the same link (e.g., only once per hour). Hitting "update" repeatedly within a short window can be flagged as abnormal and rejected. Wait 10–15 minutes and try again to rule this out.
If the link opens fine and returns non-empty content but the client still reports a parse failure, the issue is usually a mismatch between the response format and what the client expects. Clash supports two subscription formats: standard YAML config (a complete file starting with fields like proxies:, proxy-groups:, rules:), and Base64-encoded node lists (common for bulk-packed Shadowsocks/Vmess share links), where the latter needs to be decoded by the client or a subscription-conversion service into protocol fields.
Check by copying the full subscription content and looking at the opening characters: if it's an irregular jumble of letters and numbers (a typical Base64 signature) but you're on original Clash or Clash Meta in strict mode and the provider hasn't supplied a conversion parameter, the client will try to parse the gibberish as YAML and fail. This usually requires appending a target-format parameter to the subscription URL (parameter names vary by panel, commonly &target=clash or &flag=meta — check the provider's docs); if no such parameter exists, a subscription-conversion service can generate a Clash-compatible format for you to import instead.
Another format issue is bad YAML indentation or malformed fields. Some providers manually append custom rules or a DNS block to the config; if the indentation is wrong (tabs instead of spaces, or inconsistent list-item indentation), Clash Meta's parser will error out at that specific field and abort the import. The client can't auto-fix this — you'll need the provider to correct the source file. As a workaround, strip the custom rules section and keep only the proxies block to test whether it imports, which helps pinpoint the problem field.
Some subscription providers inspect the User-Agent header to identify the client type and return a different node count or config content accordingly (e.g., distinguishing Clash, Surge, Shadowrocket). If the server only recognizes a whitelist of specific User-Agent strings and the client's request header isn't on it, the server may return a stripped-down response, an error page, or refuse the connection outright — showing up as "fewer nodes after update" or "update failed."
The default User-Agent string sent by original Clash clients differs from that of Clash Meta/mihomo cores, and it can also change after a client upgrade — which is why some users see subscriptions suddenly break right after updating their client. Steps to check:
Most Clash Meta GUI clients provide a User-Agent field in subscription settings, letting you manually enter whatever string the provider requires (e.g., mimicking clash-verge or a specific version format). Fill it in and try updating again.
Some subscription panels trigger anti-leech protection on unusual User-Agent strings or high-frequency requests, returning a 403 status. The client UI usually just shows "update failed" without a reason, so you'll need to check the provider's backend logs or ask support.
If your machine sits behind an upstream proxy or a corporate gateway, outbound headers may get rewritten or stripped, so the User-Agent that reaches the subscription server has already changed. Temporarily disable the system proxy or switch to a proxy-free network to test the update directly for comparison.
If the first three steps all check out and the subscription still won't update, the problem has narrowed down to your local network environment and the client's own settings. The three most common causes here: abnormal DNS resolution, a conflict between the system proxy and the subscription-update request, and route hijacking under TUN mode.
Abnormal DNS resolution means the machine can't resolve the subscription domain properly — this often happens after switching to a custom DNS server, enabling certain DNS-based ad-filtering rules, or when the router itself is hijacking domain lookups. In that case, the update request fails right at the resolution step, and the error is usually "connection timed out" rather than "invalid format." Use your OS's built-in domain lookup tool to check whether the domain resolves to an IP correctly; if it doesn't, try switching to a public DNS resolver or setting a domain-specific resolution rule for the subscription domain in the client's DNS settings.
System proxy conflicts are common on Windows and macOS: if the subscription-update request itself gets intercepted and rerouted by the client's own proxy rules, you get a circular situation — "using the proxy to update the proxy's own config" — and some versions will, due to rule-group evaluation order, route the update request through an unavailable node and time out. Check whether the client has a direct-connect rule that specifically exempts subscription-update traffic, or temporarily disable the system proxy and manually trigger an update to test.
Under TUN mode this gets more complicated, since TUN takes over system-level global traffic routing — if the rules aren't configured correctly, even the client's own management requests (like a subscription update) can get misrouted into the proxy chain. To check, temporarily disable TUN mode and test the update with only the system proxy mode active. If it succeeds with TUN off, the issue is a missing exception rule under TUN (such as a process-name exemption or a direct-connect whitelist for the client's own process).
Putting the four steps together, the full troubleshooting order should be: first open the subscription link directly in a browser to confirm the account status on the server side; then check whether the returned content is YAML or Base64 and whether the format parameter matches your client; then check for a User-Agent whitelist restriction and set a custom header if needed; and only then check local factors like DNS, system proxy, and TUN exception rules. This order is ranked by "likelihood of being the actual cause," which cuts down on most of the wasted troubleshooting steps.
To reduce the impact of subscription failures, it's worth building three habits: first, don't wait until the subscription fully fails before checking — most providers show remaining days or traffic in their panel before expiry, so checking regularly lets you get ahead of it; second, keep a locally exported copy of a past working config as a fallback, so even if the update fails you can keep using the old config until the issue is resolved; third, keep track of your current client and core version (Clash Meta/mihomo update frequently, and parsing strictness for certain fields changes between versions) — when something breaks, check the changelog to see if it's a known parsing-behavior change rather than re-debugging an already-documented issue.