FlClash Getting Started
Subscriptions, Proxy Modes, and Connection Checks

Step 1: Import a Subscription

Open FlClash’s Config page and find the option to add a config. For a remote subscription, choose import by URL and paste the full subscription address from your provider. Give it a recognizable name, such as “Everyday,” for local organization; the name does not affect connectivity. Before saving, check for spaces, line breaks, or punctuation added by a chat app at either end of the URL.

Treat your subscription URL like a password: it usually contains private access credentials. Don’t post the full link on public forums or show its parameters in screenshots. An account page that opens in a browser is not necessarily a subscription URL. Use the subscription link your provider specifically identifies for Clash or mihomo. If several formats are available, choose one supported by the client’s core.

Check Download, Parse, and Enable Status

After saving or importing, wait for the client to fetch the config. On success, the config list should show the name you entered. Some interfaces also show an update time or subscription details, depending on what the server returns. Seeing the entry does not always mean it is active: select it or use its Enable option to make it the current config. Then open the Proxy page and check that the proxy groups and their nodes are visible.

This step is complete when the config is selected and its contents are loaded on the Proxy page. If you see a config name but not the expected proxy groups, check the import result before enabling TUN. Some subscriptions provide nodes only and rely on a client config template to add rules; others are complete configs. The interface can differ, so follow your provider’s instructions and check what actually loaded.

Importing a Local File and Fixing Import Errors

To use a local config, choose file import and open the actual YAML file in your system’s file picker. Don’t save a web page and import it as a config; a web page is not a proxy config. After importing, select the config and check the Proxy page. If it references external rule sets or proxy groups, the client may need to download those resources on first load, so make sure they are reachable.

If the request times out, first check whether your current network can reach the subscription service. If parsing fails, check whether the response is a login page, expiration notice, or error page. Don’t repeatedly add the same config, creating duplicates, or send a private subscription to an unknown converter site. For a step-by-step format check, see Subscription Import Failed? How to Troubleshoot Parse Errors.

After importing, keep this config as your test case. For now, don’t add a second subscription or import extra overrides. That keeps the source of the proxy groups clear in the next step and makes it easier to undo changes if something goes wrong.

Step 2: Choose a Proxy Mode

Return to the home or Settings page and find “Mode” or “Outbound mode.” For your first setup, choose “Rule,” corresponding to mode: rule. Rule mode routes requests according to the match order in the config—to direct, a proxy group, or another outbound. It doesn’t decide based on which apps you use most, and it doesn’t guarantee that every site will go through the proxy.

Mode and node selection are two separate settings. Choose Rule mode first, then open the Proxy page and find the main group used by the rules. Group names come from the config and can be anything, so don’t look for a specific entry named “Main Node.” Expand the group and select an available node to make it the group’s active choice.

Choose a Specific Outbound Before Trying Auto-Select

For your first test, manually select a specific node in the group. If the main group points to another group, expand it again and confirm the final selection is an available node—not DIRECT or a reject outbound. Auto-select groups choose a member based on their health checks and are useful once your config is stable. During initial troubleshooting, a fixed node makes it easier to tell what each change affects.

If the client offers a latency test, run it as a quick check. The result only reflects that node’s connection to the test endpoint; it doesn’t show whether every destination is reachable or whether browser traffic is using the proxy. A failed test may be caused by the endpoint, node, or network. Even after a successful test, continue with the connection and real-world access checks below.

When to Use Rule, Global, or Direct Mode

Global mode typically sends requests entering the core to the global proxy group. Use it briefly to check whether a problem is related to routing rules, and verify the group’s selected outbound—it may be set to direct. Direct mode typically connects requests entering the core straight to their destinations. It’s useful when you specifically need a direct connection. Direct mode does not exit the client or automatically undo your operating system’s proxy settings.

For everyday use, keep Rule mode and avoid changing rule sets, DNS, and node protocol settings at the same time. Even if the interface shows Rule mode, app traffic is not necessarily reaching the client yet; the next step is to connect and choose how traffic enters. For details on proxy-groups, rules, and rule matching order, see the Config Reference.

This step is complete when Rule mode is selected and the proxy group used by the rules has a specific outbound. Don’t expect every site to show a changed IP: Rule mode allows some requests to connect directly.

Step 3: Connect

Return to the home page and switch on the connection to start the core and load the current config. Depending on the version, connecting may also enable the system proxy, or it may have a separate toggle. Check both that the core is running and that app traffic is being routed through it. An enabled home-page toggle alone doesn’t prove your browser is using the proxy.

Desktop: Enable the System Proxy First

On Windows, macOS, or Linux, find the System Proxy setting and enable it; leave TUN off for now. The system proxy directs requests from apps that follow the OS proxy settings to a local listening port. A browser is usually a good first test, but some apps have their own proxy settings or ignore system settings entirely. Handle those separately after basic connectivity is confirmed.

Before connecting, quit other VPN or proxy apps that control the system proxy to prevent them from repeatedly overwriting each other’s settings. If your browser has a proxy-switching extension, check that it isn’t forcing a different address. For the first test, use just one proxy route. Don’t enable multiple extensions, a manual proxy, and TUN at once and try to guess which one worked.

If you see a port-in-use error, check the mixed port shown in Settings. A common config uses mixed-port: 7890, but your subscription, client, or existing settings may use a different port; use the value shown in your config. First close the other client using that port. If you need to change the port, update any proxy address manually configured in your apps as well. Switching remote nodes won’t fix a local port conflict.

Android: Grant System VPN Permission

The first time you connect on Android, the system usually displays a VPN connection request. Confirm that the requesting app is the client you just installed and intend to use, then allow the connection. Return to the client and check that it is running. If another VPN is active, disconnect it before starting this one; two system VPNs cannot run at the same time as a basic setup.

If the app has per-app proxy settings, make sure your test browser is included. Otherwise, the browser may connect directly even when the client is running normally. The system VPN icon only confirms that a system tunnel is up; it doesn’t prove the remote node, rules, and DNS are all working. Continue to Step 4.

When to Enable TUN

Consider TUN only after the browser works through the system proxy but an app still ignores proxy settings. Desktop TUN routes more traffic through a virtual network adapter and may require administrator privileges or client service support. Its routing and DNS behavior also depend on your config. Don’t treat TUN as a fix-all for connection problems, and don’t keep toggling it when the node itself is unavailable.

If startup fails, open the logs and find the first clear error after you clicked Connect. A config load failure, occupied listening address, and insufficient permissions are separate issues and need separate fixes. If the error is long, keep the relevant fields and redact private details. For more help, see How to Diagnose mihomo Log Errors.

You should now have an active config, Rule mode selected, a chosen node, and one clear way to route traffic. Leave these settings as they are. Next, make a new request and see how it is actually routed.

Step 4: Verify It Works

Open a new browser tab and visit a destination you want to test that your current network can reach. Don’t rely on a page that was already loaded: it may be served from cache, and existing long-lived connections may still use the old route. If needed, close the old tab and reopen the site so the client can observe a fresh request made after your settings changed.

Match the Page Load to the Connection Log

While loading the site, open the client’s Connection page and find the request by domain or recent activity. Check the destination, matched rule, and actual outbound. If the config routes that destination directly, seeing a direct connection is expected. To test a proxy node, choose a destination that the current rules actually send to a proxy group; don’t expect every request to show the same outbound.

An IP lookup site can help, but first check which outbound the lookup request uses. If its domain is set to direct by a rule, seeing your local network’s IP doesn’t mean the client has failed. A more reliable check is that the new request appears in the connection log, matches the expected rule, uses the expected node, and the page loads. A latency test or the client’s running status cannot replace these checks.

If It Fails, Check Routing, Rules, Then the Node

If the page fails to load and no new request appears in the connection list, first check that the system proxy is enabled, that the browser isn’t using its own proxy, and that Android’s per-app settings include the browser. Also rule out cached pages and existing connections. Focus on traffic routing first; don’t change DNS if the request may not have reached the core.

If the request appears but uses the wrong outbound, return to Step 2 and check the mode and proxy group selection. A rule may send the destination to another group, or the group may still be set to direct. If the outbound is correct but the log shows a timeout, keep the mode unchanged and try a known-working node. Check DNS only if you see a clear name-resolution error. For details on config fields and Fake-IP, see the Config Reference; there’s no need to rewrite these settings during your first setup.

Change one setting at a time, then retry the same destination and note the result. That’s the only way to tell whether switching nodes or changing the traffic-routing method fixed the issue. If you change subscriptions, enable TUN, switch to Global, and edit DNS all at once, you won’t know what helped—and restoring the original settings may cause another outage.

After Verification: Everyday Use

Once everything works, keep the active config and update it as your subscription provider recommends. Refresh the existing config instead of adding a new one each time. After an update, check the proxy groups again; node names or group members may have changed, so you may need to select a node again. Update intervals depend on the client and provider. Don’t set frequent refreshes without checking their limits.

When you’re done, turn off the system proxy or use the client’s normal disconnect option to stop routing traffic, then exit the app. If the app quits unexpectedly and your browser suddenly loses access, check whether the system proxy still points to a local port that is no longer listening. On Android, confirm that the VPN is disconnected. Exiting the client and undoing OS network settings are not always the same thing.

Success criteria: The current config works, the mode and proxy group selection are clear, and a new request matches the expected rule and loads successfully. Once you reach this point, add TUN, LAN sharing, or custom rules one at a time. You don’t need to configure everything to finish this getting-started guide.

For help with config fields and merge behavior, see the Config Reference. To review installation permissions and initial settings, read the First-Install Setup Checklist. Use the four steps on this page to recheck your setup after changing devices or importing a config again.