Clash Configuration Guide: From Subscription Import to Connection Verification

Subscription

Import subscription configuration

First, prepare the subscription URL provided by your subscription service. It is usually a link beginning with https://, obtained through a copy button or generated from the provider’s dashboard after selecting Clash, Mihomo, or a compatible general subscription format. Treat the URL as a configuration entry point: verify that its source is trustworthy and avoid posting it publicly in forums, screenshots, or shared documents. This guide does not require manual node editing; the basic workflow only requires the client to access and parse the configuration.

After opening the client, look for a page named Profiles, Config, Subscription Management, or Profiles Management. On desktop, this entry is usually in the left navigation bar; on mobile, you may need to open the menu first. Find the subscription URL field, paste the complete address, and enter an easy-to-recognize name such as Daily Config or Personal Subscription. The name only distinguishes configurations locally and does not change the subscription content. Remove any extra spaces or line breaks, then click Save, Add, or Import.

After saving, the subscription usually appears in the configuration list. Do not enable the system proxy yet; first check the status shown in the list. A newly added configuration may show Waiting for Update, Inactive, or only its name, which does not mean that the nodes are ready to use. Click the update button beside the entry or open its details and run an update. The client will request the subscription URL, download the configuration, and try to parse the YAML content. Keep the network connected during the update. If it times out, wait briefly and try once more.

After a successful update, the list will usually show information such as the update time, configuration size, node count, or availability. Fields vary between clients; the key point is to confirm that the configuration was retrieved from the subscription URL and can be parsed by the current core. Then click Enable, Set as Current, or Activate for that configuration so it becomes the active one. Only after this step will the strategy groups and proxy mode use the newly updated content.

If the update fails, first check that the subscription URL was copied in full, then confirm that the current network can open it. If the browser can access it but the client still reports a parse error, the response may not be in a Clash-compatible format, or the subscription service may have returned an error page temporarily. Keep the previous working configuration instead of repeatedly deleting files. Follow the checks under installation and configuration issues to review the format, permissions, and update time. Once the configuration is activated successfully, continue to step two and choose a proxy mode.

Mode selection

Choose a proxy mode

After activating the configuration, open the client’s Run Mode, Mode, or proxy mode page. Common options include Rule, Global, and Direct; localized interfaces may show their translated equivalents. These options determine how connections are routed, not whether the nodes themselves are online. For first-time setup, Rule mode is usually the best choice because most subscription configurations already include domain, address, and fallback rules, allowing everyday traffic to follow the strategy groups defined by the configuration.

After selecting Rule, return to the Proxies, Proxy, or strategy group page. You will typically see one or more groups, such as Proxy, Node Selection, Auto Select, or regional groups. Open the outermost group and confirm that it contains selectable nodes or strategies. If the group is empty, return to step one and check whether the current configuration actually updated successfully. If nodes are present but all unavailable, review the client’s latency tests, connection logs, or subscription service status instead of mistaking an empty or unavailable group for a mode configuration error.

Global mode is useful for short diagnostic tests: it sends most requests directly through the selected proxy strategy, reducing variables introduced by rule matching. If a target cannot be opened in Rule mode, temporarily switch to Global and test with a clearly available node. If Global works but Rule does not, the issue is usually in the rules, strategy group, or DNS handling rather than the node itself. Switch back to Rule after testing so everyday traffic does not all use one strategy.

Direct mode bypasses the proxy, making it useful for checking whether the local network works or comparing the same address over direct and proxied routes. Note the current mode before switching to Direct, then restore Rule after testing. Do not change the mode, node, and system proxy toggle simultaneously; otherwise, even if the result changes, it will be difficult to identify the cause. For details on mode behavior, rule order, and strategy group relationships, continue with the rule-based routing chapter in the beginner-to-advanced guide.

Step two is complete when Rule is selected and a specific node or strategy is chosen in the proxy group. The client now has a routing path ready, but it may not yet be handling system traffic. The next step is to check both the node connection and the system proxy toggle; this is where desktop and mobile workflows differ most.

Connection

Establish a proxy connection

First, select a node or available strategy in the proxy group. If the interface offers latency testing, you can test an individual node, but the result only reflects the test address and time; it does not guarantee access to every website. After selecting a node, check for a highlight, checkmark, or current-selection indicator. If the group is set to automatic selection, confirm that the automatic strategy has actually chosen a member before continuing.

Next, open the General, System Proxy, or similar page. Windows and macOS clients typically provide a system proxy toggle that directs browsers and applications respecting system proxy settings to Clash’s local port. After enabling it, check whether the page also lists HTTP, SOCKS, or mixed ports. A common setup listens on a local address such as 127.0.0.1, but use the port shown by the current client rather than copying a number from another guide.

On Android, clients usually take over traffic through system VPN authorization. After tapping Start, Connect, or Allow VPN, a key or VPN indicator may appear in the status bar. The first launch displays a system permission dialog; verify that it refers to the currently installed client, then tap Allow. iOS clients likewise request authorization through a system network extension, so confirm the connection in both the client and system settings. Battery optimization, background restrictions, and network changes can affect mobile connections; keep these factors in mind when disconnections occur intermittently.

TUN mode provides deeper traffic interception. It is useful when some applications ignore system proxy settings, when UDP handling is required, or when more system connections need to enter the core. TUN is not necessary for the initial setup. First use the system proxy to verify a browser, subscription, node, mode, and local port. Enable TUN only if needed and follow the system permission prompts; some platforms require administrator access or a network extension. If the network behaves unexpectedly after enabling it, disable TUN to return to a known state, then investigate routing and DNS.

After selecting a node and enabling the system proxy, do not switch rapidly between multiple nodes. Wait a few seconds for the client to establish the connection and generate logs, then proceed to step four. If the system proxy toggle will not stay enabled, check whether another VPN, proxy tool, or system management policy is overriding it. If the client appears to be running but the browser has no connection records at all, first check whether the browser uses a separate proxy configuration.

Verification

Verify that the proxy is working

Verify the setup in three layers: confirm that the client is running, confirm that application requests reach the local port, and finally confirm that rules and nodes handle them as expected. Open a familiar, normally accessible webpage and check that it loads. A successful page load only proves that basic networking works; it does not by itself prove that the request used the proxy. Return to the client and inspect its connection records. Most clients show domains, rule results, and strategy groups under Connections, Logs, or Activity.

Find the request generated by the webpage you just opened and check whether it appears, then see whether the result is Proxy, Direct, or another strategy. If no record appears, the application is not sending requests to Clash. Check the system proxy, any browser-specific proxy settings, and whether the client is listening only on a different network interface. If the record appears as Direct, that is not necessarily a problem: many commonly used sites in mainland China or sites covered by subscription rules are intentionally routed directly. Test a target that should use the proxy according to the configuration, or inspect the matched route in the rule details.

If the connection record shows the request entering Proxy but the page still fails to load, check the node selected by the current strategy group, then review the error type in the logs. Connection timeouts, remote closures, TLS handshake failures, and DNS resolution failures require different troubleshooting paths. Try another node for comparison, changing only one condition at a time. If every node fails, check the system clock, network changes, subscription update time, and client core logs. If only one domain fails, inspect its rule match, DNS settings, and service status.

After confirming the request path, check the local port. The client’s settings page usually lists the HTTP, SOCKS, or Mixed Port. If a browser uses a manually configured proxy, enter the address and port currently shown and make sure the protocol matches; system proxy mode usually writes these values automatically. A port conflict or a mismatch between the port shown in settings and the port actually listened to in the logs can make the toggle appear enabled while applications remain offline. Restart the client and check for duplicate proxy processes.

Finally, use an independent network information page to inspect the egress details and compare the results before and after enabling the proxy. Do not judge success solely by the region shown on one page; also consider the client’s connection records, rule matches, and current node status. For applications that require broader traffic handling, test TUN separately by opening target applications one at a time and checking whether their connections appear. After verification, record the working configuration name, mode, strategy group, and port settings so you can restore them quickly after updating the subscription or changing clients.

If the connection still fails after all four steps, return to the last confirmed working configuration and repeat a single-node test, a temporary Global test, and a Direct comparison. The common issues page includes troubleshooting for subscription parsing, ports, DNS, and rules. For configuration fields, core capabilities, or TUN behavior, continue to the complete beginner-to-advanced guide instead of changing too many advanced parameters during the basic workflow.