On this page
After obtaining or saving a subscription address, the client still needs to download and activate its configuration before you can use the nodes and rules it contains. Keep a working copy if your existing configuration still connects, then check the content returned by the new address and whether it loads. This avoids deleting a usable configuration while troubleshooting an update.
Save, Update, and Activate a Subscription in Profiles
One complete remote import
Copy the provider's link labeled for Clash or Mihomo
Copy everything from the opening https through the last parameter, without extra spaces.
Add the remote subscription on the Profiles or configuration screen
Use a name that identifies the source, and do not put the token in the name.
Click update immediately
Watch the status code, parsing message, and new update time.
Set this configuration as current
Open Proxies and confirm that policy groups and nodes appear.
If the client offers direct link, configuration link, URL Scheme, and other entry points, start with an ordinary remote link. If one method reports client error(Connect), try another import entry documented by the client, but do not leave “allow invalid certificates” enabled.
The Response Content Determines the Subscription Format
Clash cannot import an arbitrary web address; it needs a Clash- or Mihomo-compatible subscription from the provider. When the client accesses the link, the server may return YAML with proxies, proxy-groups, and rules, or it may return encoded text, a sign-in page, or an error page. The response content determines whether parsing succeeds.
Reading HTTP Status Codes and Response Content
How to read update results
| Observed result | Meaning and response |
|---|---|
| 401 / 403 | The token is invalid, the account status is abnormal, or the server denied access |
| 404 | The address path changed or the link was copied incompletely |
| 200, but the content begins with <html | The response is a sign-in, verification, or error page—not a configuration |
| 200, with proxies / proxy-groups / rules | It appears to be Clash/Mihomo YAML and can proceed to parsing |
| download failed / timeout | The client did not receive a response before the deadline; inspect the network and server |
Some subscription services return different formats based on User-Agent. A browser displaying a string does not guarantee that a Clash request receives the same content; conversely, a web page in the browser does not necessarily mean the link is invalid. Give the provider the client version, update time, and status code instead of repeatedly deleting the configuration.
parse error: Format and Core Compatibility Problems
Errors such as parse, yaml: unmarshal, or field not found mean the network request probably completed and the client failed while reading the content. Common causes include a server response formatted for another client, damaged YAML indentation, or fields unsupported by the current core.
Switching nodes usually does not help here. Preserve the first specific error line and line number, verify the client's Mihomo version, and ask the subscription provider for a compatible format. Do not manually repair dozens of fields in a remote configuration; the next update will overwrite every change.
unexpected character '<'
The response is probably an HTML page; inspect sign-in, verification, or server errors.
mapping values are not allowed
YAML indentation or syntax is damaged; ask the provider to regenerate it.
unsupported proxy type / field not found
The core version and configuration fields do not match; upgrade to a supported version or use a compatible subscription.
The Update Succeeds, but Proxies Is Empty
If the remote update reports success but the Proxies page has no nodes, the response may contain only rules, all nodes may have been filtered out, or the old configuration may still be active.
Check the selected mark in Profiles, then whether the configuration contains proxies or proxy-providers and whether proxy-groups references them. Also check whether an override script removed every node.
Nodes can exist yet all sit in an unused group, leaving the primary policy on DIRECT. Choose a policy group that actually contains nodes and pin one, then observe a request in Connections. This reveals more about whether the configuration works than the latency button alone.
Why Does the Old Configuration Still Connect?
Clash normally continues using the last successfully downloaded local copy. Existing nodes may therefore keep working temporarily after a subscription expires or the server begins returning an error. Judge update status by the “last updated” time and the current error, not simply whether web pages open.
Do not rush to delete a working old configuration. Export the error, verify the account and link status, and remove the old entry only after the new address updates successfully. Deleting the sole working copy turns a diagnosable issue into an immediate outage.
- Old nodes work, but the new update returns 401
- The server rejected the current credential; sign in to the service panel and inspect the subscription address.
- The update times out on the home network but succeeds on a mobile hotspot
- The problem is closer to the current network path than the YAML format.
- Several clients fail at the same time
- Check service notices and subscription status first; do not reinstall every device.
Check Nodes and Connections After Importing
Select the new Profile, pin a node in Proxies, and keep Rule mode. Enable the system proxy on a Windows/macOS desktop client. On Android, start the VPN through the client’s connection control and grant permission. Open a familiar page and check its domain, rule, and outbound route in Connections. A latency test does not replace a real request.
If a request reaches Clash but reports timeout, try another node. If there is no record, check the desktop system proxy or Android VPN. If it shows DIRECT, inspect the rule. A working page with a record that matches your selection confirms that the subscription has been downloaded, parsed, activated, and used to forward the request.
After a Subscription Link Leaks, Reset It and Replace the Old Address on Each Device
The token in a subscription address usually acts as a read credential. Troubleshooting needs only the error status, response type, and time, not the complete URL. Before sharing chat screenshots, screen recordings, or logs, hide credentials in the path or parameters. If you are unsure which parts are sensitive, hide the entire subscription address.
Changing only the display name of a Profile does not invalidate the old credentials. If the complete subscription has been made public, reset the address through the provider’s panel, then replace old links on devices using the steps below.
Post-exposure cleanup
Generate a new subscription address
Use the provider's reset or token refresh feature.
Update controlled devices
Replace the old URL on each device and confirm the new update time and node list.
Verify that the old address is invalid
Do not keep sending the old link in chat; check only the status shown by the service panel.
Inspect unusual usage
If you find unfamiliar devices or traffic changes, follow the provider's account-security process.
