Clash Subscription and Connection Guide

Prepare the Client and a Valid Subscription

Open the installed client and make sure its main window loads normally. You’ll also need the subscription URL from your service provider. The client reads the configuration and routes connections; the subscription provides nodes, policy groups, and rules. Installing the software alone does not give you access to a proxy service. This site provides client download instructions and setup guides, but does not issue subscriptions or restore expired accounts on a provider’s behalf.

A subscription URL is usually a long link with parameters. Copy it using the button on your provider’s account page. Don’t mistake the account dashboard URL in your browser’s address bar for a subscription, or copy a link to a screenshot or QR code instead. URL parameters may be tied to your account, so protect them like a password. If you need help, share the error message or redact sensitive details before taking a screenshot.

Before your first setup, quit other proxy clients, browser proxy extensions, and active VPNs. Multiple tools managing network traffic can cause port conflicts or overwrite settings, making it hard to tell which one is active. Leave the client’s default ports, DNS, and LAN settings as they are for now; don’t apply multiple configurations you found online. If your computer already has a working configuration, export or copy a backup before continuing.

Each step below includes a completion check. Move on only after you see the expected result. If terms like “subscription,” “core,” or “policy group” are unfamiliar, start with the Quick Glossary. For field definitions, see the Configuration Reference. This page focuses on getting your first connection working.

Add the Subscription and Activate the Configuration

Open “Configuration” or “Subscription” in the client’s sidebar and look for “Import from URL,” “Add subscription,” or a plus button. If a dialog opens, select remote subscription as the type and enter a short, recognizable name if required. Paste the full URL you copied into the address field. Check for spaces, line breaks, or punctuation added by a chat app at either end, then click “Import,” “Download,” or “Save.”

The client will fetch the subscription and parse its configuration. Normally, a new configuration card appears with a name or last-updated time. Some clients activate newly imported configurations automatically; others require you to click “Use,” “Activate,” or a selection indicator on the card. Make sure the configuration is selected, then open “Proxy” and check for policy groups. A completed file download alone doesn’t mean the core is using that configuration.

If the client asks for a subscription format, choose the Clash or mihomo format explicitly supported by your provider. A regular webpage, account sign-in page, or format made for another client may fail to parse. If you see “Invalid configuration” or “No proxies found,” check the subscription type on your provider’s site first. Don’t paste the full subscription URL into an unfamiliar online converter. If the format is incompatible, ask your provider for the right subscription link.

If importing times out, check that your current network can reach the subscription server and that subscription updates aren’t set to use a proxy that isn’t working yet. For an unauthorized or expired-link error, check the subscription’s expiration and whether its URL has been reset in your account. Repeatedly retrying won’t fix an account permission issue. Don’t respond by changing DNS, enabling TUN, or reinstalling the client.

If you already have a local YAML file, select it with “Import file.” Local files generally won’t update automatically when the remote subscription changes, so importing your provider’s remote subscription is usually better for a first setup. Choose either file import or URL import; there’s no need to add the same configuration twice, which can leave you using an outdated copy later.

Step complete: A new entry appears in the configuration list, is set as the active configuration, and its policy groups are visible on the proxy page. Next, choose a mode and policy; don’t edit the configuration file yet.

Select Rule Mode and an Outbound Policy

Open the operating mode setting under “Overview,” “Proxy,” or “Settings,” and select “Rule.” Rule mode is usually labeled “Rule” in English. It routes connections according to the order of rules in the configuration: some connect directly, while others use proxy policy groups. It’s suitable for everyday use, but which sites use a proxy depends on the rules in your current subscription. The client doesn’t decide automatically based on a site’s name.

Next, open “Proxy” or “Policy Groups” and expand the main proxy group. Group names are set by the subscription author, so you might see “Proxy Select,” “Node Select,” or something else; don’t look for an exact label from this guide. If the group allows manual selection, choose a node your provider lists as available. If it’s an automatic selection group, leave the default policy for now. A group may point to another group, so check which outbound route it ultimately selects.

For your first connection, make sure the main group for sites that need a proxy isn’t set to DIRECT. DIRECT means the connection goes straight to the destination, not through a remote node. REJECT blocks the connection. Node availability checks can reveal obvious problems, but a successful test only means the test destination was reachable; it doesn’t guarantee every site will work. Keep one selection in place and verify it with a real webpage instead of switching nodes repeatedly.

“Global” mode sends connections entering the core to the global policy, making it useful for a quick comparison test. It doesn’t automatically route every app on your computer through the client, and it won’t fix an expired subscription or faulty node. “Direct” mode sends connections entering the core without a remote proxy node. Operating mode is separate from System Proxy and TUN: mode determines how traffic is routed, while the latter control how traffic enters the core.

The example below shows basic fields related to this step, for reference only; it isn’t a replacement for your subscription. A subscription usually also includes proxies, policy groups, and rules. These few lines alone don’t provide a working proxy service. Before changing rules, read the Rule Syntax Reference. To understand the difference between modes and policy groups, see the Quick Glossary.

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

Step complete: The operating mode is Rule, and the main proxy group has a clearly selected node or automatic policy. Next, enable a traffic entry point so apps can connect through the client.

Enable a Proxy Entry Point and Check the Core

On desktop, check the client overview or logs to confirm the core has started and there are no configuration parsing or port-in-use errors. An open window doesn’t guarantee the core is running. If startup failed, resolve the error before enabling the proxy. The common default for a mixed port is 7890, but use the value shown in your client. Don’t change other port settings just to match the number in this guide.

Once the core is running, enable “System Proxy” in settings. This tells apps that respect the system proxy to send requests to the local proxy port. Keep the client running, then open a new browser tab for testing. If your browser has a proxy extension, disable it first; an old address in the extension can override system settings and make the browser behave differently from other apps.

On Android and iOS, connect using the button on the client’s home screen. The first time, the system asks permission to add or establish a VPN connection. Check which app is requesting access, approve it, then return to the client and check the connection status. This VPN is the system’s network entry point; you don’t need to create a separate manual VPN in system settings. If another VPN is already connected, disconnect it before starting this client.

For now, don’t enable System Proxy, TUN, and a manual browser proxy at the same time. On desktop, use System Proxy to verify the browser first; consider TUN only if you need to handle apps that ignore the system proxy. TUN uses a virtual network interface to capture traffic, and some clients require service mode, administrator privileges, or additional system permissions. Before trying it, note your current working settings, switch modes separately according to the client’s instructions, then repeat the checks in Step 04.

If no webpages load after enabling System Proxy, turn it off first and check whether your original network connection returns. If it does, check the client’s entry point, core, or node rather than layering on more settings. If it doesn’t, look for a manual browser proxy, another VPN, or a system network issue. Before quitting normally, turn off the proxy entry point first. Force-quitting the client can leave system proxy settings pointing to a port that’s no longer running.

You don’t need to enable “Allow LAN” for a first connection on your own device, or change the external controller address to listen on a public interface. Keeping the default restrictions helps avoid unnecessary network exposure. Learn more about how TUN, routing, and DNS interact in the Configuration Reference later; for now, focus on verifying the browser connection.

Step complete: On desktop, the core is running and System Proxy is enabled; on mobile, the connection has system approval. A status button only shows that the entry point is on. Check the next step to confirm it actually works.

Check Websites, Rules, and the Actual Route

First, visit a site you can normally access to make sure your basic connection still works. Then visit a target site you know requires a proxy. Use a new tab and refresh so cached content doesn’t look like a successful connection. A single site failing to load doesn’t necessarily mean the configuration is wrong; the site could be down, restrict your account, or block the current route. Check the client logs to tell the difference.

Keep the target page open and check the client’s “Connections” or “Logs” page for its domain. Confirm the request appears, then check which rule matched, which policy group was used, and whether the final route was a node or DIRECT. Details vary by client; expand the entry if you can only see a group name. A request in the logs means it reached the core. Routing is working as expected only if it took the intended route.

If the target site fails and there’s no matching connection record, check the traffic entry point first. On desktop, make sure System Proxy is still enabled and the browser doesn’t have its own proxy settings. On mobile, check that another VPN hasn’t replaced the system connection. Logs may also be missing if the log level is too low or connection logging is paused; restore normal logging and test again. An empty list alone doesn’t prove the node is unavailable.

If there’s a connection record but its route is DIRECT, and the site needs a proxy, check that Rule mode is still selected and the relevant group isn’t set to a direct policy. You can temporarily switch to Global mode, explicitly select an available node, and test again. If Global works but Rule mode doesn’t, focus on the rules or group selection. Return to Rule mode when you’re done; don’t treat a temporary comparison setting as the fix for every problem.

If the record shows a proxy node but the connection keeps timing out, try a known-working node and check your subscription account status. Consider DNS only if errors affect specific domains and point to name resolution. Don’t change ports, DNS, and TUN all at once without evidence; even if things start working, you won’t know which change helped. Change one setting at a time, repeat the same test, and note how to restore the previous setting.

You can also check your exit IP on a trusted site and compare the results with the proxy on and off. Treat this as supporting evidence: in Rule mode, the IP-check site and your target site may use different policies, so one IP lookup can’t prove all traffic uses the same exit. Prioritize the connection record for the target site, and don’t share your full exit IP in chats or screenshots.

Step complete: Everyday sites work, the target site loads, and its connection record shows the expected outbound policy. Your first setup is complete. Keep these settings for a while before trying advanced features one at a time.

Keep a Working Configuration Before Updating

Note the active configuration name, operating mode, and main policy selection. If the client supports backups, save a copy of the working configuration. Remote subscription updates may overwrite local edits. Before making ongoing changes, learn how your client handles overrides or merges; don’t leave temporary edits only in the subscription file. If something breaks after an update, first check that the configuration is still active, then see whether the policy group selection changed.

For further troubleshooting, follow the Connected but Can’t Browse? Troubleshooting Checklist from the simplest checks onward. For YAML, DNS, or policy group fields, see the Configuration File Reference. When asking for help, include your operating system, client name, the step you’re stuck on, and the exact error. Redact subscription links and account details; this is more useful than simply saying “it won’t connect.”