Import a Clash Subscription
and Set Up the Connection

Step 01 · Profile

Import a Subscription and Activate the Profile

Open the client’s “Configuration” page in the sidebar and look for “Add,” “Import,” or a plus button. Get a Clash / mihomo-compatible subscription URL from your provider, paste the full URL into the address field, then click “Download” or “Import.” Enter the subscription URL here—not the provider’s homepage, sign-in page, or checkout page. The client needs to retrieve a configuration from this address, so a website opening in your browser doesn’t mean you have a working subscription.

To import from the clipboard, copy the entire URL, switch back to the client, and choose “Import from Clipboard.” Check that the field contains no extra text, spaces, or line breaks, and watch for a truncated URL—especially if it was forwarded in a messaging app. Subscription URLs often contain account access credentials, so treat them as sensitive. Before sharing error details, redact the full URL and any sensitive information in screenshots.

After the URL download finishes, select the profile card

Once the download finishes, the profile list will usually show a named card. Click the card or its “Enable” button until you see a selection marker, a current-profile indicator, or another clear sign that it’s active. Importing a profile and using it are separate steps: seeing a file in the list only means it’s been saved. You still need to select it so the core loads its proxy groups and rules. Then open the Proxies page and check for the groups defined in the profile. If you still see the old groups, go back and confirm the right profile is selected.

The client may validate the configuration or reload its core the first time you activate a profile. Wait for that to finish before continuing. If you see a parsing error, check whether it mentions YAML, indentation, a field type, or a line number. Don’t delete the flagged line just to force startup—it may be referenced by other proxy groups. Instead, download the Clash-format subscription provided by your service and confirm that your client’s core supports it.

Local Files and Subscription Updates

If you have a config.yaml or .yml file, choose “Import from File” and select it. Only drag a file into the profile area if the client explicitly supports drag and drop. Local files are useful for migration and temporary testing, but they usually won’t update when your provider changes the remote subscription. If URL profiles support scheduled updates, open the profile’s edit menu and set an update interval based on your provider’s instructions. After updating, make sure the intended profile is still active.

If a download times out, first check that your device has a working internet connection and that the subscription is still valid, then try again. Don’t start by changing DNS, TUN, and ports all at once. If the download returns a webpage or reports missing configuration content, check the subscription type on your provider’s site. For help with format conversion and subscription errors, visit the Help Center. Once the profile is active and its proxy groups appear on the Proxies page, move on to choosing a mode.

Step 02 · Routing

Choose Rule Mode and a Proxy

Open the Overview or Proxies page, find the mode setting, and select Rule / Rule. This controls how requests reaching the core are routed: in Rule mode, the core checks the profile’s rules in order. A request may connect directly, go through a proxy group, or be rejected. When you’re getting started, keep the subscription’s existing rules. Test the connection first, then consider adding your own rules. That makes it easier to pinpoint what changed if something goes wrong.

“Global / Global” usually sends traffic reaching the core through the global proxy policy; it can be useful for a quick comparison. “Direct / Direct” usually connects traffic reaching the core straight to its destination. Neither option turns off the client or replaces the system proxy setting. Keep in mind that Global mode does not capture traffic from every app automatically. Whether an app’s traffic reaches the core still depends on how it’s routed, such as through the system proxy, an explicit proxy setting, or TUN.

Expand the Proxy Groups and Choose an Exit

On the Proxies page, find the group your profile uses for proxied traffic and choose an available proxy from the current subscription. Group names come from the subscription and may be in any language, so don’t look for one specific name. A group can also point to another group. After choosing a top-level group, check the nested groups until you can identify the proxy the request will ultimately use.

If your profile includes an automatic selection group, you can use it to let the core choose a member according to that group’s test logic. A manual selection group keeps the proxy you choose, which is useful when you need a fixed exit. Run the client’s connectivity or latency test, wait for the results, then select a member that passes. A timeout only means that this test didn’t succeed; the test address, network, or proxy could be responsible. A successful test is useful as a reference, but it doesn’t replace visiting the site you want to reach.

Keep the Default Rules to Avoid Changing Multiple Variables

For your first connection, make only two changes: set the mode to Rule and choose an available proxy for the relevant group. Leave rule order, DNS mode, and connection ports alone for now. If a site takes an unexpected route, check its matched rule in the connection log before deciding whether to add an override. Rule-based routing depends on each request’s destination and matching conditions. A site’s region or the browser’s display language alone won’t tell you which proxy it uses.

This guide doesn’t cover proxy group types or writing rules. For automatic selection, failover, and rule-set subscriptions, see the mihomo Advanced Configuration Guide. For now, note the current mode and proxy group selection, and leave the other settings unchanged. Next, you’ll route traffic through the client. Keeping the changes limited makes it easier to trace any problems back to their source.

Step 03 · Traffic Routing

Enable the System Proxy or VPN Connection

Return to the client’s main screen, confirm the core is running, then enable traffic routing for your platform. Starting the core, choosing a mode, and routing system traffic are three separate steps: the core handles requests, the mode controls routing, and traffic capture sends app requests to the core. An open client window or Rule mode alone doesn’t mean your browser is using the proxy.

macOS and Windows: Start with the System Proxy

Find and enable “System Proxy” on the client’s home page, in Settings, or in the menu bar. On macOS, some clients offer a quick toggle in the menu bar. If the system asks you to authorize a helper service, check the app name and purpose before following the prompt. Once enabled, the local proxy address may appear in your system’s network settings. You generally shouldn’t need to re-enter all the system proxy details yourself; let the client manage the setting and restore it when needed.

Open a new browser tab and visit a site to test the connection. Most browsers that follow the system proxy setting will route new requests through the client. Existing long-lived connections may keep using the old route, so start a new request after changing settings. If another VPN or proxy app is running, pause one to prevent the two apps from repeatedly changing the system proxy. If the client reports that a port is in use, check for duplicate running instances first, then see the Help Center for steps to resolve port conflicts.

Android and iOS: Connect and Approve the System Prompt

Tap “Connect” or the start button on the mobile client’s home screen. The first time you connect, the system usually asks to establish a VPN connection or add a VPN configuration. Approve the prompt, return to the client, and wait for its status to show Connected. The system’s VPN indicator means the device has established a traffic-routing tunnel; it doesn’t mean every request will use a remote proxy. Requests matched by direct rules can still connect straight to their destinations.

If another VPN is already connected, disconnect it before trying again to avoid replacing one tunnel with another. Some Android clients let you proxy or bypass individual apps; make sure your browser isn’t excluded while testing. If the connection acts up after switching apps on iOS, check the client’s actual status instead of relying only on the status bar icon. Permission prompts vary by operating system version, so follow the options shown on your device.

TUN Mode: Enable It Only When You Need Traffic Capture

Consider TUN only if your browser works but some apps that ignore the system proxy still aren’t routed through the client. TUN captures traffic using a virtual network interface and routing settings. Desktop clients may require a service, administrator permission, or approval for a network extension. Follow your client’s instructions to grant the required permissions, then check for startup errors. Don’t treat system proxy and TUN as settings that must always be enabled together; whether to use both depends on the client and its recommendations.

Linux desktop environments don’t all handle the system proxy the same way; behavior depends on the desktop settings and the app. Command-line tools may also need a proxy set separately. For this setup, use a browser for a basic check; terminal environment variables are beyond the scope of this guide. See the Advanced Configuration Guide for TUN, DNS, and Fake-IP settings. Once this step is complete, the system proxy should be enabled or the VPN connected, with no persistent startup errors in the client.

Step 04 · Check

Verify the Connection and Routing Rules

Open the client’s Connections page and leave it visible, then visit a reachable site in your browser. Check whether a new domain or destination appears in the connection list. Short-lived connections may disappear quickly, so refresh the page and check right away, or filter the list by domain. If there’s no connection list, open Logs to check requests and errors. The goal isn’t to watch the total traffic counter; it’s to match the request you just made to a specific connection entry.

Select an entry and check the destination, matched rule, proxy chain, or exit shown by the client. Column names vary, and some clients show only part of this information. A DIRECT label means the request was handled by a direct policy. If it went through a proxy group in the profile, check which proxy was ultimately selected. A MATCH rule usually means none of the earlier rules matched, so the fallback rule was used; by itself, this doesn’t mean the configuration is broken.

Test Requests Expected to Go Direct and Through a Proxy

First visit a site that should connect directly under your subscription’s rules, then visit one that should use a proxy. Compare both results in the connection log. Use the profile and log entries as your reference instead of guessing from a site’s name. A webpage may load images, scripts, and API endpoints from multiple domains, each of which can match a different rule. Check the specific domain that failed rather than assuming that a loaded homepage means all traffic is routed correctly.

To check the exit address, you can use a trusted IP lookup service with a request that should go through a proxy, then compare it with a direct request. The lookup result depends on which rule matches its domain, so treat it as supporting evidence—not a substitute for the proxy chain in the client. Seeing the same exit address doesn’t necessarily mean the proxy failed; for example, the test request may have matched a direct rule. For a reliable diagnosis, check whether the request reached the core, which rule matched, and whether the destination loaded.

Troubleshoot in Order: Profile, Routing, and Proxy

If the connection list doesn’t show the request you just made, first confirm the intended profile is still active. Then check that the system proxy or VPN is actually enabled and that the test app hasn’t been excluded. A cached page may not generate a new network request; refresh it and check again. On Linux, or in apps with their own proxy settings, the app may not use the desktop’s system proxy, so check how it routes traffic separately.

If the request appears but times out, check whether the selected proxy matches your choice in Step 2, then try another available member of the same group. If the logs report a DNS resolution failure, connection refused, or authentication error, investigate DNS, the destination connection, or subscription access as appropriate rather than blaming every issue on the rules. Redact subscription URLs, access parameters, and private destination domains before sharing logs. For more detailed troubleshooting, visit the Help Center. Avoid changing too many settings at once during initial setup.

Turn Off Traffic Routing Before Quitting; Recheck After Updates

Once direct and proxied requests behave as expected, keep the current Rule mode and proxy selection. After a subscription update, network change, or proxy switch, run a quick check: make a new request, inspect the matched rule, and confirm the site loads. You don’t need to import the profile again each time. Return to Step 1 only if the subscription URL or configuration source changes.

When you’re done using the proxy, turn off the system proxy or disconnect the VPN in the client before quitting. On desktop, avoid force-quitting the app and leaving the system proxy pointed at a local port that’s no longer running. If your connection stops working after quitting, check the proxy status in your system’s network settings or reopen the client and turn off traffic routing. That completes the setup loop: subscription, mode, traffic routing, and verification. For custom rules, DNS, or local overrides, move on to advanced configuration.

Read the Advanced Configuration Guide · Find answers by symptom