Clash Subscription URL Import Guide: YAML vs. Base64 Formats

Before importing, know the difference between subscription URLs, config files, and node links

Clash subscription imports often fail not because the network is down, but because different types of content are entered in the same place. A subscription URL is an address used to fetch content; YAML is a format for structuring configuration; Base64 is an encoding method. These are different layers, so a similar-looking link does not mean the formats are compatible.

• Remote subscription URL: Usually starts with https://. The client fetches a config or node list from it. The URL may contain an account token, so treat it like a credential.
• Local config file: Common file extensions include .yaml and .yml. Import it through the “Import file” option or local config menu. Importing a local copy generally does not fetch future updates from the original provider.
• Individual node share link: For example, a link starting with ss://, vmess://, or trojan://. Some clients have a separate parser for these links, but that does not mean the Clash core can read one directly as a complete YAML config.

Before you begin, note the client name and the core listed on its About page. Clash, Clash Meta (now called mihomo), and other proxy cores do not support exactly the same protocols and fields. If your provider offers options such as “Clash,” “Clash Meta,” and “Universal subscription,” choose the format that matches your core before copying the URL.

How Clash YAML configs differ from Base64 subscriptions

A full Clash YAML config typically defines nodes, proxy groups, and rules using fields such as proxies, proxy-groups, and rules. It may also use proxy-providers to reference external node sources. A Base64 node subscription typically encodes a set of share links as a single text string. It usually does not include the full Clash routing rules or proxy group structure.

Full configs and provider files are not interchangeable

A file containing only proxies: may be a valid node source, but not a complete, ready-to-use config. If you load it as a full config, it may parse successfully yet lack the expected proxy groups and rules. Conversely, importing a full config through an entry point that accepts only node sources may produce a format error. Check what the import option expects; the file extension alone is not enough.

Here is a minimal local config to help you recognize the structure. It contains no proxy nodes, and all connections go direct. It illustrates YAML hierarchy; it is not a replacement for a provider subscription that routes traffic.

mixed-port: 7890
mode: rule
log-level: info

proxy-groups:
  - name: Manual Select
    type: select
    proxies:
      - DIRECT

rules:
  - MATCH,Manual Select

Base64 decoding does not convert content into a Clash config

Base64 decoding restores the original text; it does not generate proxy groups, DNS settings, or routing rules. Actual format conversion requires parsing the node fields and generating a config accepted by the target core. Even if conversion succeeds, nodes will not work if the target core does not support their protocol or parameters. Ask your provider for a native Clash or mihomo format first to avoid losing fields during conversion.

Import a Clash subscription URL: from copying the link to activating the config

Button labels vary between client versions. The steps below use the remote import flow on the “Subscriptions” or “Profiles” page. If an option accepts files only, go back one level and look for a URL field. Do not save the link as a text file and pass it off as YAML.

1. Copy the URL for the right format. In your provider account, choose the Clash or Clash Meta/mihomo option. Copy the subscription URL—not the account home page, payment page, or documentation link. Check that no spaces, line breaks, or non-English punctuation were added at either end.
2. Open the remote config import option. Go to the client’s “Subscriptions” or “Profiles” page. If there is a URL field, paste the link and select “Import.” If the interface uses “Add new,” choose the remote option, enter the URL, and save. Do not select a local file option.
3. Wait for the download and parsing to finish. Check whether a config card appears, whether an update time is shown, and whether the notification area reports a YAML parsing error. A card appearing does not necessarily mean the download completed; check its status.
4. Select and activate the new config. You can keep multiple configs in the list, but only the selected one is active. After importing, check which config is selected, then open the proxy page to confirm the expected nodes and proxy groups are there.
5. Use Rule mode and select an outbound. Set the operating mode to “Rule,” then choose a node in the selection group defined by the subscription. Some subscriptions select DIRECT by default; traffic going direct does not mean the node is broken.
6. Verify app traffic. For system proxy mode, enable “System Proxy” in the client and test with a browser that honors system proxy settings. If you use TUN to capture traffic, check TUN permissions and routing separately; importing a subscription does not enable TUN automatically.

The local listening port is not the subscription URL’s server port. In this example, 7890 is the mixed proxy listening port. If the log says address already in use, check whether another local proxy process is using the same port instead of repeatedly resetting your subscription token.

Subscription update intervals: client configs vs. providers

Remote config updates are usually handled by the client application: it periodically downloads the entire config again and reloads it according to the client’s logic. The proxy-providers section is updated by a compatible core, which fetches node sources separately. These are two different timers, so the “update interval” in a client setting is not necessarily the same as interval in YAML.

Client remote config updates

• After the initial import: Run one manual update first to confirm the URL works and the config parses correctly, then enable automatic updates.
• For everyday use: Start with an update every 24 hours and follow your provider’s recommendations. If nodes change frequently, consider updating every 6 hours, but avoid fetching the subscription every minute without a good reason.
• Check the units: 24 hours is 1,440 minutes or 86,400 seconds. If the field expects minutes, entering 86400 does not mean one day.
• Check when updates run: Some clients run scheduled tasks only while the app is open. Sleep, loss of network access, or background restrictions may delay an update, so check the last successful update time.

mihomo node provider updates

For mihomo HTTP node providers, interval sets how often the source is refreshed, in seconds. For example, interval: 86400 means once a day. This updates the node source referenced by that provider; it does not refresh all the rules in the parent config. The interval under health-check is for checking node availability, not for updating the subscription.

If your subscription has no proxy-providers section, do not add one just to “enable automatic updates.” Use the client’s scheduled remote config update instead. If you use nested references, check the last update time for the parent config and each provider separately.

Troubleshooting Clash subscription imports: HTTP, YAML, and core compatibility

Troubleshoot one layer at a time. First check whether the request returned the right content, then whether the current core can parse it, and finally whether the nodes can connect. The specific error is more useful than “import failed” for narrowing down the cause.

A link opening in your browser does not mean the client received the same content

Your browser may include a login cookie, while client requests usually do not. Some servers also return different content depending on the User-Agent. An HTTP 200 only means the request received a response; it does not mean the response is a Clash config. If the response starts with <!DOCTYPE html>, first check for a login redirect, access verification, or an incorrect URL. Changing YAML indentation will not fix it.

For YAML errors, inspect the source before changing rules

YAML uses spaces for indentation; tabs are not valid substitutes. Copying content through a chat app may turn an ASCII colon into a full-width colon or strip indentation. If the remote subscription itself contains invalid syntax, send the provider the relevant error line after removing sensitive details. Do not delete entire sections just to make the config start; you could lose rules or DNS settings.

Subscription works, but websites will not load

Start with the client’s connection log. If the target request is missing, check system proxy or TUN capture. If it appears, inspect the matched rule, proxy group, and actual outbound. A successful latency test only confirms that a specific probe works; it does not prove that every domain, UDP traffic, or app can connect. Subscription download, node availability, and app traffic routing are three separate checks.

Final checks for format conversion and updates

Consider subscription conversion only if your provider cannot supply the target format and your client cannot use the original one. A converter may access your full subscription URL and node credentials, so prefer a reputable tool that runs locally. Do not submit your credentials to multiple unfamiliar conversion sites just to test a URL.

1. Confirm the target core: Determine whether the output should be a legacy Clash-compatible config or a mihomo config, and check that the target core supports the protocols in use. Conversion can change how data is represented, but it cannot add support for a new protocol to an older core.
2. Check where the rules come from: Conversion may replace proxy groups and routing rules. Verify the default outbound, where the final MATCH rule leads, and whether the direct-connection rules you need are preserved.
3. Confirm how updates will work: Importing a converted local file once usually gives you a static snapshot. For ongoing updates, establish who will periodically fetch the source subscription, convert it, and reload the config.
4. Verify the update: After a manual update, confirm the success time changed, the node count looks reasonable, and the expected config is still selected. Then test one destination that should go direct and one that should use a proxy, and check their outbounds in the connection log.

For details on operating modes, DNS, or TUN settings, see the Technical Reference. If you are setting things up for the first time, start with the Getting Started Guide. Confirm the subscription format and selected config before working on traffic capture; it makes troubleshooting much more straightforward.