How to Import a Clash Subscription URL: Full YAML, Proxy Lists, and Share Links Explained

1. Identify the input before choosing an import method

“Import from copied link” works only when the client recognizes the input. A subscription URL is an address used to fetch content; YAML is a structured configuration format; a single-node share link carries the parameters for one proxy. These are different layers: the same HTTPS address might return a complete config, a proxy list, or a login page. Opening a URL in a browser does not mean Clash can load it as a configuration.

The client handles the interface, subscription downloads, and config management. Clash or Clash Meta (mihomo) cores parse valid configs, establish proxy connections, match rules, and handle DNS. Some clients support format conversion, but that does not mean every Clash client can import every share link directly. Before you start, record the client and core versions from the About or core information page; neither can substitute for the other.

What you have	Typical characteristics	Where to import it
Remote subscription URL	Starts with `https://` and may include authentication parameters	Remote config, URL import, or create subscription
Local YAML file	Usually `.yaml` or `.yml`, containing structured text	Local config, import from file
Proxy provider content	Often has `proxies:` at the top level, without proxy groups or rules	Referenced by `proxy-providers` in the main config
Single-node share link	Starts with `ss://`, `vmess://`, `trojan://`, and similar schemes	The client’s explicitly provided node import or conversion tool

2. Importing a subscription URL: download, select, and apply

Start with a subscription URL compatible with the active core

In the subscription provider’s management panel, choose the Clash or mihomo output that matches the client core. Do not copy the URL from an account-center page, and do not mistake a one-click import protocol that launches a client for an HTTPS subscription URL. If the provider distinguishes legacy Clash from mihomo, choose based on the core actually running—not the name of the desktop shortcut.

Check the copied URL: it should not contain surrounding quotes, spaces, or punctuation added by a chat app. Keep the original authentication parameters; changing them may cause the server to reject the request.
Create a remote config: open the client’s “Config” or “Subscriptions” page, find the URL field or remote-config creation option, paste the URL, and download it. Button labels and layouts vary between clients.
Check the import result: confirm that a new entry appears in the config list, then check its update time, proxy count, and any download errors. A config name appearing by itself does not prove that the content was parsed correctly.
Select and apply it: set the new entry as the active config. Some clients continue using the old config after import, so you may need to click the config card again or choose Apply.
Check the running state: verify that the core is running, proxy groups are present, and there are no unknown-protocol or missing-target errors before testing the connection.

Using the legacy Clash for Windows interface with a Profiles page and URL field as an example, the usual path is Profiles → URL field → Download, followed by selecting the corresponding config card. This is only an example of a legacy interface; it does not mean the software is still maintained and does not apply to every client. In newer clients, look for the feature that represents “remote config.”

For the first import, do not enable TUN, change DNS, and replace every rule at the same time. Confirm that the config loads first, then verify how traffic is intercepted so the fault stays isolated to one layer. If downloading the subscription requires an existing proxy, use a working older config or a network path supported by the provider; a new config cannot solve its own download problem before it has been downloaded.

3. Local YAML: check content integrity and references

Local import is useful for offline configs, backup recovery, and manual editing. The file extension is only a clue: renaming a web page to config.yaml does not turn it into a config. Open the file in a plain-text editor and check for <html>, login prompts, or API error messages. YAML indentation uses spaces, not Tabs. Make sure the editor shows the real extension so you do not save it as config.yaml.txt.

A complete config is more than “having proxies”

A config capable of handling the intended proxy routing usually needs proxies or proxy providers, proxy groups, rules, and appropriate listener settings. Which fields are required depends on core defaults and how the client generates configs, but rule targets must resolve: if a rule points to Proxy, a proxy group or node with that exact name must exist. Do not infer this from a label shown in the interface.

# Config example: validates structure only; contains no remote proxy nodes
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

proxies: []

proxy-groups:
  - name: Proxy
    type: select
    proxies:
      - DIRECT

rules:
  - MATCH,Proxy

After importing a local file, do not assume it retains the original subscription’s automatic update relationship. The client may copy the file into its own config directory or reference the original path directly; editing the file on your desktop may not affect the active copy. Use the current config’s edit or view function to confirm which content is actually in use, then edit and reload it. Before making changes, save a dated backup such as config-backup-2026-06-16.yaml.

If the file uses proxy-providers or rule-providers, the local YAML is only the entry point; external resources may still need to be downloaded at startup. Copying the main file does not copy all dependencies. Check provider paths, remote URLs, and cache availability. When moving a config from another device, especially, do not copy its absolute paths unchanged.

4. What to do with a proxy list or share link

A proxy list must be organized by a main config

A YAML file with only top-level proxies: is commonly used as a proxy provider. It describes available proxies but may not define the local port, proxy groups, or routing rules the application needs. Importing it as the main config may cause some clients to fill in the missing structure, while others show only the proxies or fail outright. A client’s auto-completion behavior is not a universal format convention.

In cores that support providers, the main config usually defines a named resource under proxy-providers, then a proxy group references it with use. The provider name must match, and the remote resource must use a node format supported by the core. Simply placing an ordinary subscription URL in this field does not mean the core will decode any Base64 node subscription. Check the relevant fields against the proxy reference in the configuration guide.

Share links require both parser and protocol support

Single-node URI: links such as ss:// carry the parameters for one node, not complete routing rules. Use them directly only when the client explicitly supports importing that type.
Multi-line URIs or Base64 text: these may be generic node subscriptions, but they are not complete Clash YAML. Use a provider-generated compatible format or convert them with a trusted tool.
Protocols and transport parameters: after conversion, verify the protocol, port, TLS, SNI, transport path, and other settings. A legacy Clash core is not the same as mihomo, so do not assume they support the same protocols and fields.

When you see “unknown protocol,” first check the support matrix for the active core. If the connection handshake fails, compare the original parameters. Do not remove unrecognized fields just to suppress the error; that field may contain a transport or authentication parameter required by the server. If you need another client, check the platform and core relationship in the client selection guide before migrating the config.

5. Subscription update failures: troubleshoot by response, parsing, and connection

“Update failed” covers at least three types of problems: the request returned no usable content, the content could not be parsed, or parsing succeeded but the proxies could not connect. A failed latency test does not necessarily mean the subscription update failed; likewise, a successful HTTP request does not prove the config is correct. Check the config update time and download log first, then core errors, and test an actual connection last.

Signal	Check first	Next step
HTTP 401 or 403	Expired token, account permissions, or access restrictions	Get a new subscription URL and check the account status; 403 may also come from access protection
HTTP 404	URL path changed or copied incompletely	Compare it with the address currently generated by the provider; do not guess the path manually
HTTP 429	Too many refresh attempts	Stop repeated retries and wait according to the response or the provider’s rules
HTTP 200, but parsing fails	A web page, error JSON, or incompatible node format was returned	Inspect the start of the response and the error line locally, then confirm the compatible output format
DNS failure or connection timeout	DNS resolution for the subscription domain and the route used for downloading	Check local connectivity, the existing proxy, and the proxy setting used for subscription updates
TLS certificate error	System time, certificate chain, captive portal, or network interception	Correct the system time and confirm network status; do not treat disabling certificate verification as a standard fix

If the browser downloads the file successfully but the client fails, also check redirects, login cookies, request headers, and the provider’s client-identification policy. A logged-in browser may receive the file while the client receives a login page; conversely, the server may return different content based on the User-Agent. The solution is to obtain the subscription endpoint intended for the target client, not to copy a browser login session into unrelated software.

For messages such as yaml: line 12, inspect line 12 and the line above it for indentation, quotes, and colons. The reported line is often where the parser noticed the problem, not where it was originally introduced. If the remote content itself is faulty, contact the provider or switch to a supported output format. A temporary local fix may be replaced by the original bad content at the next update.

6. Updates overwrite local changes: separate subscriptions from overrides

A remote subscription is usually a source file that can be downloaded again. Adding rules, changing ports, or renaming proxy groups directly in it may be overwritten at the next update. This is a consequence of how content is refreshed, not necessarily a failed save. The client’s runtime config may also be generated by merging “subscription content + global settings + overrides,” so after editing one layer, confirm the value that ultimately takes effect.

Keep the subscription source intact: leave the remote URL and automatic updates in the remote-config record instead of turning the only copy into a hard-to-recover manual version.
Store changes separately: if the client provides overrides, merge settings, or scripts, use them for custom rules and settings; follow that client’s implementation for execution order.
Check array behavior: rules and proxy-groups may be replaced, prepended, or appended. Do not assume every merge mechanism behaves the same way.
Review rule order: rules are usually matched in order, so a custom rule placed after MATCH generally will not take effect. The proxy group referenced by a rule must also continue to exist after an update.
Run one manual update: compare the effective config before and after the update, confirm that the subscription refreshed successfully and custom settings remain, then enable scheduled updates.

7. Minimum verification checklist after import

A successful import should be verified at three levels: config, core, and an actual request. Do not replace basic checks with “test every node.” The latency-test target may be unreachable while a browser can still access other sites through that node; the opposite can also happen, with the test succeeding while the application bypasses the proxy.

Config layer: the new config is selected, its update time matches this operation, the target proxy group exists, and the group has the expected node selected rather than DIRECT.
Core layer: there are no parse failures, port conflicts, or unknown-protocol errors. Check the actual listening port instead of copying 7890 from a tutorial.
Interception layer: a desktop system proxy mainly affects applications that follow system proxy settings. TUN involves a virtual network adapter, routing, and permissions; on mobile, it usually requires VPN authorization. Neither can fix an invalid subscription format.
Request layer: visit a known working website and check the connection or log page to see whether the request entered the core, which rule matched, and which proxy policy was ultimately used.

Use an explicit proxy request to isolate system-proxy issues

If curl is installed on the desktop and the core is actually exposing an HTTP or mixed proxy on local port 7890, run the diagnostic command below. On Windows, use curl.exe to avoid parameter differences caused by same-name aliases in some PowerShell environments.

curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com

The 10-second value is the connection timeout, and 20 seconds is the overall request timeout—not measured latency. Receiving an HTTP response means the explicit proxy request completed its response phase, but it does not prove that a remote node was used; the rules may still choose a direct connection. If 127.0.0.1:7890 cannot be reached, first check the listening port and core status. If the explicit request succeeds but the regular browser does not, check the browser proxy settings and other interception conflicts.

Finally, save a redacted copy of the error, the client and core versions, the input type, and the reproduction steps. Before making further changes, review connection verification in the quick start guide and change only one variable at a time. This makes it clear whether the problem lies in fetching the subscription, parsing the config, or the proxy path, instead of losing clues through repeated imports and reinstalls.