Troubleshooting path 2: is the network path clear at the moment of the update

A subscription update is, at its core, the client making a network request to a server. That process is directly affected by the current network environment, and once proxy mode is on, the actual request path can be more complicated than it looks.

How the system proxy relates to update requests

Most clients try to connect directly to the subscription server when updating, bypassing the currently active proxy node — this avoids the circular dependency of "using a possibly-dead node to fetch a fresh config." But if the system proxy or TUN mode on your machine is configured aggressively enough to force the client's own network requests through an unstable node too, the update request can time out as a result. Try temporarily disabling the system proxy, or switching to a direct connection, and testing the update again. If that works, the problem is in the current proxy chain, not the subscription link itself.

DNS resolution issues

If the subscription server's domain is being poisoned by local DNS or resolving to the wrong address, the connection will fail even when the link is completely correct. Try a different device, or switch to a trusted DNS server and test the same link again. If it works on a different network, the problem is almost certainly at the DNS layer.

Firewall or security software blocking

Some security software intercepts or delays network requests from unrecognized programs, especially the first time a freshly installed client tries to go online. If the update stays stuck on "connecting" for a long time with no clear error, check your firewall rules and your security software's network permission settings to confirm the client's process is allowed to access the network.

Restrictions on corporate networks or public Wi-Fi

Some corporate networks or public Wi-Fi networks restrict specific ports or protocols. Even if your regular browsing works fine, the port used by the subscription server might be blocked on its own. Switching to a phone's mobile hotspot is the fastest way to test this — if the subscription updates immediately on a different network, the current network's restrictions are almost certainly the cause, not the subscription or the client.

Troubleshooting path 3: hidden failures caused by User-Agent compatibility

This factor is easy to overlook but can have a real impact. When a subscription server receives an update request, it reads the User-Agent header to figure out which client is making the request, and uses that to decide what config format to return, which rule template to enable, or even whether to allow the update at all.

Why User-Agent can cause "looks successful but content never changes"

Some subscription services return different versions of the config depending on the User-Agent. If the User-Agent your client sends doesn't match what the server expects, the server might return a cached, stale copy — or a stripped-down config — instead of an error. The client sees a "200 success" response and reports the update as complete, but the node list was never really refreshed. This is a common cause of the second failure pattern described above.

How to confirm whether User-Agent is the issue

Most clients built on the Clash Meta (mihomo) core let you customize the User-Agent in subscription settings, or toggle between "use the core's default identifier" and "use the client's own identifier." If you suspect this is the cause, try switching the User-Agent setting and re-fetching the subscription, then compare whether the node count changes. You can also manually set a User-Agent from the terminal to test whether the same link returns different content:

After both downloads finish, compare the file contents and sizes. If they're noticeably different, the subscription service is indeed returning different content based on User-Agent, and you can pick whichever identifier works better in the client going forward.

A sensible auto-update interval for each client

Set the auto-update interval too short and you risk tripping the provider's rate limit, indirectly causing the "false dead link" symptom described above. Set it too long and node information won't refresh promptly, especially when a provider swaps nodes or adjusts rules on short notice. A few general guidelines:

• For everyday use, 12–24 hours is a reasonable interval. Most providers don't change nodes more often than that, so updating more frequently doesn't buy you much.
• Avoid setting it to a few minutes or under an hour unless the provider explicitly says it supports high-frequency updates — otherwise it's easy to get flagged as an abusive request and temporarily throttled.
• Update manually as needed — if you notice connection issues or your provider announces a change, just click update once instead of relying on the automatic schedule.
• Don't retry repeatedly right after a failure — wait a few minutes and try again; hammering it repeatedly only increases the odds of triggering a rate limit.

Some clients also support conditions like "auto-update only on Wi-Fi" or "only while charging." Mobile users who care about data usage or battery life can enable these to cut down on unnecessary background requests.

A troubleshooting order you can follow step by step

Turning the three paths above into a simple-to-complex checklist usually gets you to the root cause within a few minutes.

1. Confirm the subscription link has no stray spaces or truncation, and test it by opening it in a browser.
2. Disable the system proxy or switch to a direct connection, and try updating again.
3. Switch to a different network (like a phone hotspot) and test again.
4. Check the client's auto-update interval setting to rule out a rate limit.
5. Try switching the User-Agent setting and compare the node count before and after.
6. If none of the above turns anything up, contact your subscription provider to confirm the link and plan status.