How to Import a Clash Subscription: URL, Local YAML, and Base64 Explained

First, identify the subscription URL, config file, or proxy list

Once you have a subscription, check whether the provider offers a dedicated entry for “Clash” or “Clash Meta / mihomo,” then open your client’s config page. Don’t confuse the provider’s web dashboard URL with a single proxy link or a subscription URL. They may all look like text, but clients handle them differently.

A URL is an address for retrieving content, YAML is a config format, and Base64 is an encoding method. They’re not interchangeable options: an HTTPS subscription URL can return YAML or a Base64-encoded proxy list. If an import fails, check what the URL actually returns—not just whether it starts with https://.

Import by URL: save the remote config, then select it as active

Copy the correct subscription URL for your client

1. Sign in to your subscription provider’s dashboard and look for “Subscription” or “Export Config.” Choose the format for Clash or mihomo. If the provider only offers a generic subscription, first check whether your client can convert it.
2. Use the page’s copy button to get the complete URL. When copying from a chat app, watch for stray periods, line breaks, or quotation marks. Make sure you include any access parameters after ?.
3. Open your client’s config list, choose “New,” “Add,” or the plus button, then select the remote URL option. Give the config a recognizable name, such as “Daily subscription.”
4. Paste the URL and save. Wait for the first fetch to finish. If the client shows an error, note the status code or parsing details; don’t keep adding the same URL repeatedly.
5. Select the new entry in the config list and make sure it’s active. Open the proxy page, check that the proxy groups appear, then choose an available node.

“Download complete” only means the client retrieved the config—it doesn’t mean your system traffic is using the proxy. After importing, enable the system proxy for your needs, or configure TUN if you need to route traffic from more apps. For the first test, use one traffic-routing method and confirm it works before adding more. This makes it easier to tell import issues from routing issues.

Set an update interval and know what’s being refreshed

If your client supports automatic updates, start with an interval of 24 hours. Some clients use hours; others use minutes, in which case enter 1440 minutes. Treat this as a starting point and follow your provider’s request limits. Refreshing too often may trigger rate limits.

Also distinguish between refreshing the entire remote config and refreshing proxy-providers within it. The client’s config manager handles the former; the core fetches provider nodes according to each provider’s interval setting. In a provider, interval: 86400 means 86,400 seconds. It doesn’t make the client download the main config again every day.

Import a local YAML file: make sure it’s a complete config

If you have a .yaml or .yml file, choose the file import option on the config page and select it in the file picker. Before importing, open it in a plain-text editor. If it starts with <!DOCTYPE html>, a login page, or an error message, you saved a web page rather than a config. Changing the file extension to YAML won’t change its contents.

Check the config’s three key parts

• Proxy sources: proxies defines proxies inline, while proxy-providers imports a collection of proxies. A proxy provider file usually contains only a list of proxies; it isn’t a complete main config.
• Proxy selection: proxy-groups organizes options such as manual selection and automatic latency testing. Every policy name referenced by a rule must exist in the config.
• Routing rules: rules determines how connections are routed. Rules are evaluated in order, and the first match takes precedence. If a rule points to a group that doesn’t exist, the config may fail to load.

Here’s a minimal example to illustrate the structure. It contains no remote proxies, and all connections go DIRECT, so it can’t be used to test whether a remote proxy works. 7890 is an example mixed port, not a universal client default. Use the listening port shown in your client.

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

proxies: []

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

rules:
  - MATCH,Manual Select

YAML is indentation-sensitive. Use spaces, not tabs, and keep indentation consistent at each level. Don’t replace every colon in a text editor, and don’t let document software turn straight quotes into curly quotes. Quote names or passwords with special characters according to YAML syntax.

Keep the original file and a fallback config

Some clients copy imported files into their own config directory; others can reference files in their original location. Changes to the original file may not update the active config—you may need to import it again or reload it. Keep a working config as a fallback, and make a copy before changing DNS, rules, or proxies.

Local files usually don’t update the entire config automatically like remote subscriptions do, but remote providers referenced by the file may still fetch updates online. Conversely, edits to a file downloaded from a remote subscription may be overwritten the next time it refreshes. To keep custom rules long-term, use your client’s override, merge, or patch feature where available.

Base64: decoding gives you proxies, not a Clash config

Many generic subscriptions encode a list of proxy links as a single Base64 string. Decoding it may reveal several links such as ss://, vmess://, or trojan://—not a YAML config with rules and proxy groups. Base64 is just an encoding, so anyone with the text can decode it.

For example, decoding c3M6Ly8= gives you ss://. This illustrates how the encoding works, but it isn’t a usable proxy link. A real subscription also contains server addresses, ports, and authentication parameters. Some protocol links use another layer of encoding, so a single decode won’t fully parse them.

Choose a conversion method in this order

1. First, look for the provider’s Clash export. An export made for your target client typically includes proxies, groups, and rules, saving you from filling in missing pieces by hand.
2. Next, check what your client can import. Paste Base64 content directly only if the importer explicitly supports generic subscriptions or proxy links. A client using the mihomo core doesn’t necessarily support every subscription format in its GUI.
3. If conversion is necessary, use a trusted environment. Prefer a local tool or a service recommended by your provider. After conversion, check the number of proxies, protocol fields, proxy group references, and final rules before enabling the config.

A converter doesn’t just change the extension of an encoded text file. It has to parse each proxy protocol, map the proxy fields to Clash / mihomo, and add the groups and rules required by a main config. Conversion can’t add support for protocols or options that the target core doesn’t support. Check the actual core and version on the client’s About page, then compare the config syntax with that core’s documentation.

Import failed? Troubleshoot network, content, and config syntax in order

Check the client log or import error details before deciding what to try next. Network request failures, unexpected response content, and config syntax errors are different problems with different fixes. Being able to open your provider’s dashboard in a browser doesn’t mean the client can fetch the subscription. The dashboard may rely on a login cookie, while the subscription endpoint should use its own access credentials.

“Update through proxy” is for cases where you have a working proxy but can’t reach the subscription server directly. If you don’t have a working config yet, enabling this option can create a dependency loop: you need to update to get proxies, but you need a proxy to update. In that case, use an accessible URL from your provider or retrieve the config over a trusted network and import it locally.

After importing, verify the config, proxies, and traffic routing separately

1. Make sure the config is active. Check the active config name, last update time, and load log. An entry appearing in the config list doesn’t mean the core is using it.
2. Check the selected proxy group. Open the proxy page, find the group used by the relevant rule, and select a node. A successful latency test only confirms that a specific test request worked; it doesn’t guarantee access to every website.
3. Check how traffic enters the proxy. If you use the system proxy, make sure the client’s listening port matches your system settings. For example, if the client shows a mixed port of 7890, the app should connect to 127.0.0.1:7890. Don’t copy a port from another machine.
4. Check which rule matches. Open the target website and inspect the connection log for its domain, matching rule, proxy group, and actual outbound route. If no request appears at all, first check whether the app is using the proxy—don’t keep changing subscriptions.

If an app needs TUN to route its traffic, grant the required permissions and configure routing and DNS as instructed by your client. TUN is a traffic-routing method, not a subscription converter; DNS hijacking won’t turn a Base64 proxy list into a complete config. Test config retrieval, core loading, and traffic routing separately to pinpoint the problem.

For routine maintenance, keep a fallback config, note the update interval, and check proxy group names whenever a subscription changes. If your provider renames a group, custom rules and overrides may still reference the old name. Check those references before changing rules to avoid repeatedly troubleshooting a config that stops loading after a successful subscription update.