Clash Windows Edition: Import a Subscription to Connection Verification

First, make sure you have a subscription URL that is still valid. Providers usually generate it for you; it may begin directly with https://, or you may need to click “Copy subscription” in the provider’s management portal. The URL of the current page, a single node’s share link, or a login address is not necessarily a subscription that Clash can read. The most reliable check is whether the provider explicitly offers a Clash, Mihomo, or universal subscription entry.

Copy the complete URL. Chat apps and document tools may display only the beginning of a link even when the copied result is complete; other tools may append spaces or line breaks. Before importing, paste the address into a plain-text editor and check that the beginning, parameters, and ending are intact. A subscription URL is a configuration entry point, so do not post it in public comments, screenshots, or public repositories.

If the client already has a working profile, keep it instead of overwriting it. Most graphical clients support multiple Profiles, so import the new subscription as a second profile. If parsing fails, you can switch back to the old profile and keep working. The goal of a first-time setup is not to rewrite rules, but to have one complete configuration loaded successfully by the core.

Once ready, work only on the Profile. Do not enable the system proxy or change DNS, ports, and TUN at the same time. Fewer variables make it much easier to identify the failing layer.

After opening the client, look for a page named something like Profiles, Config, Subscription Management, or Configuration Files. Windows clients commonly place Profiles in the left navigation; some mobile clients put an add button in the top-right corner of the home screen. Find the URL field, paste the subscription URL you copied, then click Download, Import, Update, or Confirm. This downloads the remote configuration; it does not start the proxy.

Under normal conditions, the client adds a profile card within a few seconds. The card may show a profile name, update time, file size, or update interval. Click it to make it the active Profile. A successful download is not enough: some clients continue using the old profile after import, so check whether the selected marker, Active label, or highlighted border has moved to the new profile.

Next, open the Proxies, Proxy, or policy-group page. If you can see multiple policy groups and selectable nodes, the configuration has at least been parsed successfully. Common group names include “Node Selection,” “Auto,” and “Streaming,” while providers may use their own names. The names are not fixed; what matters is that the page is no longer empty and at least one main policy group can be expanded.

proxies:
  - name: example-node
    type: ss

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - example-node

rules:
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

The structure above is only a way to check whether the configuration is complete: proxies provides nodes, proxy-groups organizes selection logic, and rules determines where traffic goes. Graphical clients usually do not display the full YAML directly, but an imported profile should at least produce proxy groups. If only a profile name appears and Proxies is completely empty, the subscription may be incompatible, returning webpage content, or expired.

When import fails, start with the client’s original error message. A timeout usually means the subscription URL is temporarily unreachable; an unexpected status code may indicate an expired link or missing parameters; a YAML parsing error means the server returned an invalid configuration format. Do not click Update dozens of times or reinstall the client immediately. Copy the subscription URL again and retry once. If it still fails, determine whether the error occurred during “download” or “parsing,” then check the relevant issue in the Help Center.

After the configuration loads, find the Mode, mode, or operating mode setting. For first-time setup, choose Rule. Rule mode matches the configuration’s rules from top to bottom and sends requests to DIRECT, PROXY, REJECT, or a specified policy group. Local services can connect directly, destinations that require a proxy go through a node, and blocking rules terminate connections in the core. For everyday use, this better matches how the configuration is designed than Global mode.

Global sends most traffic through a single proxy policy. It is useful for briefly checking whether a rule is sending a site the wrong way, but it is not the best default for first-time setup. Direct attempts to connect traffic directly and is typically used to temporarily bypass the proxy path or run a comparison test. Clients may label the three modes Rule, Global, and Direct, or translate them as Rule, Global, and Direct connection; the meanings are essentially the same.

After choosing Rule, open Proxies and work with the policy groups. Find the main selection group responsible for the final exit; it is often, but not always, named PROXY. Expand it and choose an available node. If the configuration includes an Auto or URL-Test group, you can select that group and let its own test rules choose the exit. There is no need to test every node now, and a single latency figure is not a reliable measure of real-world speed. Latency measures one round trip to a test address, not bandwidth or sustained stability.

If the main group contains regional, application, or automatic groups, follow the selected path all the way down and confirm that it reaches a real node. A common dead-end is selecting another policy group at the top level while the nested group has no usable nodes. Graphical interfaces usually mark the current item with a checkmark, dot, or highlight. Continue to the bottom until you can see a specific node name.

Once the mode and node are selected, leave the other settings unchanged. In particular, do not switch Fake-IP, Sniffer, IPv6, and DNS options all at once. Subscriptions usually include baseline settings suited to their rules; changing several options turns a simple connection test into a multi-variable troubleshooting task. Full explanations of protocols, core relationships, and configuration compatibility are available in Technical Reference; this page keeps only the choices needed to get connected.

Return to General, Home, or Settings and enable the System Proxy switch. Windows clients typically write the system proxy to the current user’s network settings, after which browsers and desktop apps that honor system proxy settings send requests to Clash’s local port. macOS clients may switch the system proxy from the menu bar; Android and iOS usually establish a connection through the system VPN interface and require confirmation the first time they are enabled.

Watch the client status after enabling it. The core should remain in a Running, Started, or similar state, and the system proxy switch should not turn itself off immediately. If the system requests network, VPN, or firewall permission, first confirm that the requester is the installed client, then grant the required access for the platform. After necessary permissions are denied, the interface may say connected even though application traffic never reaches the core.

For the first test, use the system proxy alone. Browsers usually read the new proxy settings immediately, but some long-running applications cache old connections and need to be fully closed and reopened. Do not enable TUN immediately. The system proxy does not cover programs that ignore proxy settings, some command-line tools, or certain game traffic. TUN can take over a broader network path, but it also adds virtual adapters, routing, and permission requirements. First prove that the node, subscription, and rules work, then decide whether TUN is needed.

If TUN is genuinely required, find the TUN Mode, virtual adapter, or enhanced mode switch. Windows may require administrator privileges, while mobile platforms use the system-provided VPN channel. After enabling it, check the client logs for repeated virtual adapter creation failures, route write failures, or permission errors. Whether System Proxy and TUN should run together depends on the client: some coordinate them automatically, while others recommend using TUN alone. Follow the current client’s interface guidance rather than copying steps from another client.

After connecting, do not close the client window or terminate its background process. The system proxy only points traffic to a local listening port; the running Clash or mihomo core handles the actual connections. If the core exits while the system proxy remains configured, the browser may report that every page is unreachable. This does not necessarily mean the subscription is invalid—restart the client or disable the leftover system proxy.

mode: rule
mixed-port: 7890
allow-lan: false

dns:
  enable: true
  enhanced-mode: fake-ip

These fields describe the common relationship: mode sets the routing mode, mixed-port is the local proxy listening port, and the DNS module handles name resolution. The actual port and DNS settings should come from the current configuration; do not edit them just to match an example. Once the client can start the core and take over system traffic, move on to verification.

Verify the setup in three layers. First, check the core status: the client shows no persistent errors, and the current Profile, Rule mode, and node remain selected. Second, check system traffic: open a browser and visit a site that normally works directly, then visit a destination that the subscription rules should send through the proxy. Third, check rule matches: open Connections, connection records, or logs and confirm that the requests appear with the expected policy.

A webpage loading by itself does not prove that routing is correct. It may have come from cache or may have been reachable directly all along. Connection records are more conclusive: the matched rule, policy group, or final node usually appears beside the destination domain. Expected direct requests should show DIRECT, proxied requests should reach the main proxy group or a specific node, and blocked requests should show REJECT.

If the client offers log-level settings, leave the default level for a normal verification. The connection list is usually easier to read than a scrolling log. Refresh the target page, then immediately return to the client and check the newest records. If the domain is hard to find, use page search or sort by time. If no new connections appear at all, first check that the system proxy is truly enabled and that the application honors system proxy settings.

Then run a rollback test: turn off System Proxy or disconnect the mobile VPN, and refresh the page you just tested. The result for a destination that should use the proxy should change, and the client’s connection list should stop showing new requests. Re-enable the connection and test again. This comparison helps rule out browser cache, another proxy tool still running, or an old proxy setting left in the system.

Finally, test everyday applications selectively instead of opening everything at once. Start with the browser, then test one regular client; leave command-line tools, virtual machines, containers, and LAN devices for later. These environments may use their own DNS, network namespaces, or proxy settings, so their problems may not involve Clash’s main connection. For first-time setup, correct browser routing and connection records establish a reliable baseline.