Clash Subscription Import and First Connection

Before you begin, install a graphical client and obtain the Clash or Mihomo subscription URL provided by your service provider. It is usually a link beginning with https://; the client uses it to retrieve proxy nodes, proxy groups, rules, and some DNS settings. A regular web subscription, a link intended for another client, or a link containing only one node may not import directly. If the format is unsupported, return to the provider’s dashboard and choose a subscription format explicitly labeled Clash, Clash Meta, or Mihomo.

If you have not installed a client, start with the download page and choose your operating system. Windows and macOS users generally want a desktop client with a graphical interface; Android and iOS users need a mobile client that can use the system VPN interface; Linux desktop users can use a graphical client, while servers and routers are usually better suited to a separate Mihomo core deployment. This guide focuses on graphical clients, not server startup flags or control-panel deployment.

Keep the subscription URL intact when copying it. Chat apps may truncate long links or treat the final characters as punctuation. Use the copy button on the service page whenever possible, then paste the URL directly into the client. Subscription URLs often contain access credentials, so treat them like account credentials and do not post them on public forums, in screenshots, or on log-sharing pages. If the link has expired, generate a new one from the provider’s site instead of repeatedly editing its contents.

After opening the client, go to the “Subscriptions,” “Profiles,” or Profiles page. Find an entry such as “Import from URL,” “New Subscription,” or another add option referring to a link, then paste the copied subscription URL into the URL field. Use a short, recognizable name such as the service name or use case; if the client reads the subscription name automatically, you can keep that result. Click Download, Import, or Save and wait for the request to finish.

After a successful import, a new subscription entry should appear in the profile list. Most clients show the profile name and update time, and some also show the automatic update interval. Do not enable the system proxy yet. First select the profile and make it active. Then open Proxies or the proxy-group page; you should see groups such as “Node Select,” “Auto Select,” and “Direct.” The rules page should also contain types such as DOMAIN, DOMAIN-SUFFIX, GEOIP, and MATCH. Seeing these items means the client has parsed the configuration correctly.

If adding the subscription creates only an empty entry or the proxy page contains no groups, manually update it once. If it is still empty, check that the URL is complete, the subscription has not expired, and the server returned a YAML configuration supported by the client. Opening the subscription URL in a browser may show text, start a download, or return an access restriction; none of these outcomes replaces the client import result. The final test is whether the client can parse the proxy groups and rules.

Some clients can import a local YAML file directly, usually through “Import File” or by dragging the file into the profile list. A local file will not receive automatic server updates, so you must download it again when nodes or rules change. For a first setup, a URL subscription with a reasonable update interval is usually better. Updates do not need to run too often; follow the service provider’s recommendation.

Once the configuration is active, open the “Mode” or Mode page. Common options include Rule, Global, and Direct. For a first setup, choose Rule mode. It processes requests according to the configuration’s top-to-bottom rule order: traffic matching a direct rule uses DIRECT, traffic matching a proxy rule goes to the specified policy group, and requests that match nothing earlier are handled by a final rule such as MATCH.

Global mode sends most capturable traffic through one unified policy. It is useful for briefly checking whether the proxy path itself can be established, but it is not a reliable way to verify routing rules. Direct mode temporarily bypasses the proxy. You can switch modes briefly for comparison while troubleshooting, but return to Rule mode for everyday use; otherwise the configured region, domain, and application routing rules will not work as designed.

After selecting Rule mode, open “Proxies,” “Proxy Groups,” or Proxies. You will usually find two types of groups: one lets you manually choose a node or run an automatic test, while the other is referenced by rules and forwards traffic to the first type. Find the selection group that handles most proxy traffic and choose an available option. Do not change every group one by one. Start with the main group named “Node Select,” “Proxy,” “Proxy,” or identified by the provider’s instructions; streaming, regional, and app-specific groups can be adjusted after the first connection succeeds.

DIRECT in a proxy group means connecting to the destination without a proxy chain; REJECT means refusing the request; a specific node name means sending traffic through that proxy. Policies such as Auto Select or URL-Test run tests and choose a result according to the configuration, but test URLs and timing vary by client. For the first setup, just confirm that the main proxy group has an available selection rather than an unavailable or empty state. There is no need to run tests manually over and over.

Which policy a rule matches and how proxy groups are nested depends on the subscription configuration. This guide does not edit rule files. For custom routing between destinations in mainland China and outside China, rule sets, or proxy-group types, continue with the Advanced Configuration Guide. Keeping the subscription’s original structure reduces variables during the first connection.

Return to the client home or settings page and confirm that the core is running. Some clients start it automatically; others require clicking “Start,” “Connect,” or a power-shaped button. Once the core starts successfully, the client usually shows the active profile and lets you enable the system proxy, VPN, or TUN switch. If startup fails immediately, check the client log first. Common causes include invalid configuration syntax, an occupied listening port, or insufficient system permissions.

Windows and macOS graphical clients typically use the “System Proxy” for the first connection. When enabled, the client points the operating system’s HTTP and HTTPS proxy to a local listening port. Browsers and apps that follow system proxy settings then send requests to Clash. This path is easy to understand and is suitable for initial verification. If the client asks for a helper program or system permission, approve the system prompt, then check the network settings to confirm that the client-managed proxy address is present.

Android and iOS clients generally use the system VPN interface. After you tap Connect, the system displays a VPN configuration or connection permission prompt; once approved, a VPN indicator usually appears in the status bar. This permission allows the client to create a local network tunnel, but it does not mean the correct policy has been selected, so keep the active subscription and Rule mode in the client. If Android frequently stops the connection after you switch apps, check the client’s background-running and battery-optimization settings. For a fuller troubleshooting sequence, see the Help Center.

On Linux desktops, the exact approach depends on the client and desktop environment. A client with system-proxy integration can use its switch directly; if it only starts a local port, enter the client’s HTTP, SOCKS, or mixed-port address in the desktop network settings or target application. Command-line programs may not read desktop proxy settings, so configure environment variables according to the program’s supported method. For initial verification, use a browser with clear system-proxy support before handling individual command-line applications.

TUN mode can capture more traffic that does not follow system proxy settings, but it involves a virtual network adapter, routes, DNS, and administrator permissions. You do not need to enable the system proxy and several capture methods at once for the first connection. Start with the platform’s default connection method. Only switch to the TUN section of the Advanced Configuration Guide when a specific app cannot use the proxy, UDP traffic must be captured, or system-proxy coverage is insufficient. This makes it easier to tell whether the issue comes from the proxy node, the rules, or system-level traffic capture.

Do not judge the result only by whether the client button changes color. Open a browser and first visit a site that normally loads, then visit a site that the current configuration should send through a proxy policy. Once the page loads, immediately return to the client’s “Connections,” “Logs,” or Connections page. You should see the domain request from the browser, along with its matching rule, policy group, and final route.

The key question is not how many requests appear, but whether each destination entered the expected policy. For example, a domain configured for direct access should show DIRECT, while a proxied domain should show the main proxy policy or its selected node. If every request shows DIRECT, confirm that Direct mode is not enabled. If every request uses the same node, check whether Global mode was selected. If the Connections page shows no new records at all, the browser may not be using the system proxy, the mobile VPN may not be established, or the browser may have its own proxy settings separate from the system.

System network behavior can provide supporting evidence, but avoid relying on a single IP lookup page. Rule mode intentionally allows different domains to use different exits, so a direct address shown by one page does not mean that all proxying has failed. A more reliable method is to compare the browser request, the client connection record, and the rule match together. To check DNS behavior, look for domain-resolution requests in the client log. With Fake-IP enabled, the address behavior differs from ordinary DNS mode; see the Fake-IP section of the Advanced Configuration Guide for details.

After verification, close and reopen the browser and test again to confirm that a new process still reads the system proxy. Then restart the client and check whether the active subscription, mode, and policy selection were saved. Some clients remember the system-proxy state; others restore only the core and do not modify the system proxy automatically. This is an implementation difference. Once you know how your client restores state, you can quickly determine whether a post-restart failure is caused by the core not starting or by system traffic capture not being enabled.

Do not change the subscription, mode, DNS, TUN, and system proxy all at once. Confirm one layer at a time so you can identify which change produced the result. Start with subscription parsing, then check policies, the core, and system traffic capture, and only then inspect a specific site or app. The sequence below follows the setup flow above.

After these four steps, the basic Clash path is working: the subscription supplies the configuration, Rule mode determines routing, the system proxy or VPN captures requests, and connection records verify the result. For subscription update failures, port conflicts, UWP loopback, mobile background shutdowns, and DNS issues, open the Help Center based on the symptom. To modify proxy groups, rule sets, DNS, TUN, or local overrides, see the Advanced Configuration Guide.