FlClash Subscription and Connection Guide

Before You Begin: Install the Client and Prepare a Subscription

First, choose the installer for your operating system on the client download page, install it, and open the app. On macOS, pick the installer for Apple Silicon or Intel; on Android, choose the one for your device architecture. When you first open the app, make sure you can access the dashboard and Config page, and leave the default settings in place for now. The installer provides the client; the subscription provides nodes, proxy groups, and rules. You need both.

This guide assumes you already have a subscription link. Your service's account portal usually provides it; choose a format explicitly marked as compatible with Clash or mihomo. A regular webpage URL, login link, or single-node share link may not work as a complete subscription. If you don't have one yet, read where to find and how to choose a subscription. Check the service details and configuration format before continuing.

Before you begin, close any other proxy or VPN apps that are capturing network traffic, and keep your Wi-Fi or mobile data connection active. Subscription URLs often contain account identifiers, so treat them as sensitive information. Hide the full URL and QR code in screenshots, screen recordings, and support requests. Once you're ready, add the subscription on the Config page to avoid duplicate imports and traffic-capture conflicts.

Step 1: Import and Enable a Subscription

Open Config and Add a Remote Subscription

Open Config from the FlClash sidebar or bottom navigation and look for a plus sign or Add option. If the app offers import methods such as URL or file, choose URL or remote configuration for an existing subscription link. Give the configuration a recognizable name, such as “Everyday subscription,” then paste the full URL copied from your service. Before submitting, check for extra spaces, line breaks, or punctuation added by a messaging app.

A subscription URL may look like https://example.com/sub?token=xxxx. This is only a format example; use your own URL. The parameters after the question mark are part of the address, so don't copy only the domain or remove them. When everything looks right, click Save or Import and wait for the client to download and parse the configuration. Don't click repeatedly, or you may create multiple configurations with the same name.

If you have a local YAML configuration file, use the file import option and select it from your device. Local files and remote subscriptions are updated differently: the client can fetch a remote subscription again, while a local file usually needs to be reimported or replaced. For your first setup, stick to one source, get the basic connection working, and organize other configurations later.

Select the Configuration and Check Its Nodes and Proxy Groups

After a successful import, the new configuration should appear on the Config page. Select its card or enable option to make it the active configuration; the selected state may be shown with an outline, check mark, or status label. Simply seeing the card doesn't mean it's enabled. Next, open Proxies and check that the proxy groups and node names are listed. If they are, the client has read the proxy definitions and you're ready to continue.

If the download fails, first check that regular webpages load, then copy the URL again from your service's account portal and confirm the subscription is still valid. If parsing fails, check whether the format is compatible. A login page or error message returned by the website may also be read as a configuration. Keep the error message for now; there's no need to change DNS, rules, or core settings. See the Troubleshooting guide for more detailed steps.

If the configuration's Edit or More menu includes an auto-update option, set an interval recommended by your service, such as every 24 hours. Auto-update fetches the subscription again; it doesn't automatically switch the active node or guarantee new nodes will appear. After a manual update succeeds, make sure the configuration is still enabled before choosing an outbound mode.

Step 2: Choose a Proxy Mode and Available Node

Start with Rule Mode

Return to the dashboard and find Outbound Mode, or a selector with Rule, Global, and Direct options. Choose Rule for your first setup. In this mode, the active configuration's rules determine whether each request goes direct, through a proxy, or to another policy. Rules come from the subscription, so routing can vary between subscriptions. Rule mode does not send all traffic through the proxy.

Global mode is useful for a quick comparison: requests received by the client are typically handled by the Global policy group, but make sure that group is set to a proxy node rather than Direct. Direct sends requests straight to their destinations. These modes only control how the client handles requests it has received; they don't replace system proxy settings or VPN traffic capture. Even in Global mode, traffic that never reaches the client won't be rerouted.

Choose the Outbound Route on the Proxies Page

Open Proxies and find the policy group responsible for proxy traffic in your configuration. Group names are set by the configuration author and might be “Node Select,” “Proxy Select,” or something else—not necessarily PROXY. Expand the group and select a node, or choose an automatic selection group provided by the configuration. If the group contains nested groups, check their selections too; an outer group may point to a proxy group whose inner selection is still Direct.

If the app offers a connection test, run it once and see whether the node responds. A successful test can help narrow down candidate nodes, but it doesn't mean every website or app will work; the test destination may differ from the one you're trying to reach. If a node doesn't respond, try another candidate first. Avoid changing the mode, DNS, and subscription all at once so you can identify what affects the result.

Note the current mode and selected policy group. At this point, you should have a clear setup: one enabled configuration, Rule mode selected, and a node chosen in the group responsible for proxy traffic. Learn about the differences between automatic selection, failover, and load balancing in the quick reference. For more on protocols and core compatibility, see the protocol guide. For now, keep the subscription's default settings.

Step 3: Start the Client and Enable Traffic Capture

On Desktop, Test with the System Proxy First

Return to the dashboard, click Start, and wait for the running status. Some versions start the core when you enable traffic capture, so follow the status shown in your app. On desktop systems such as Windows and macOS, find and enable the System Proxy setting, then test with a browser that follows system proxy settings. Running the client and enabling the system proxy are related but separate: the client handles traffic, while the system proxy tells apps to send requests to it.

If your browser has a separate proxy extension, disable its traffic routing or set it to use the system settings so it doesn't keep pointing to an old port. Support for system proxy settings varies across Linux desktops and apps, so check whether your browser reads the desktop proxy settings. For your first test, don't combine multiple browser extensions with a manually configured proxy address; keep the request path simple.

System proxy settings affect only apps that honor them. Some command-line tools, games, and standalone network apps may ignore them. Consider TUN mode only if you need to capture traffic from those apps. TUN routes traffic through a virtual network interface and usually requires administrator access, a helper service, or additional system permissions. Requirements vary by operating system. Verify the browser connection first, then expand traffic capture to make problems easier to diagnose.

On Mobile, Check VPN Permission and App Coverage

On Android, tapping Start usually brings up a system VPN connection prompt. Confirm that the requesting app is your client, approve the permission, then return to the app and check its status. VPN permission creates a local traffic-capture tunnel; it doesn't select a remote node. You still need to complete the configuration and policy selection in the first two steps. If another VPN app is running, disconnect it before starting FlClash again.

If per-app proxying is enabled, make sure the browser you're testing is included in the captured apps. Apps on the bypass list won't pass through the client as expected. On iOS with Clash Plus, follow the app's prompts to add a VPN configuration and approve it in system settings, then check the outbound policy after connecting. The VPN icon in the status bar indicates that a connection is active, but verify it with actual access results and connection logs.

If startup fails, read the message and address that issue first: resolve missing permissions in system settings, or check for another proxy app running in the background if a port is already in use. Treat “can't start” and “webpages won't load after starting” as different problems. The first concerns local operation or traffic capture; the second requires checking nodes and request logs. Once the client is running and traffic capture is enabled, move on to the final step.

Step 4: Verify Access and the Actual Outbound Route

Generate a Fresh Browser Request

Open a new browser tab and visit an HTTPS page you normally use that should follow your proxy rules. Wait for the main content to load, then open FlClash's Connections page or equivalent request log and look for the domain you just visited. An existing page may use cached content or reuse an old connection, so checking the current tab alone isn't conclusive. Refresh it or close the tab and reopen it if needed.

In the connection details, check the matched rule, policy group, and final outbound node; the fields shown vary by version. If the domain should use a proxy under your configuration, confirm the log points to the expected proxy policy rather than assuming everything is working because the page loaded. Then visit a destination explicitly set to Direct in your configuration and check its route. In Rule mode, seeing both proxied and direct connections is normal; what matters is whether the results match your rules.

To check your exit IP, you can use a lookup page you trust as an additional test. A changed IP shows only the route used for that lookup request; it doesn't prove that every app is being captured or that your rules are routing correctly. Never enter your subscription URL on an IP lookup site. For a reliable check, confirm all three: the page loads, the request appears in the client, and the selected policy matches what you expect.

Recheck the Relevant Step Based on What You See

If a webpage won't load and there are no corresponding requests on the Connections page, return to Step 3 and check the system proxy, VPN permission, browser-specific proxy settings, and per-app settings. If a request appears but uses Direct, return to Step 2 and check the mode and policy group. Rule mode allows direct connections; seeing DIRECT alone doesn't mean the client is broken. Once the basic connection works, address any rules needed for specific domains.

If requests use the selected node but keep failing, try another node and check that your subscription service is available. If only certain sites fail while others work, note the affected domains and error messages, then use the Troubleshooting guide to investigate. Change one setting at a time and test again. Keep the last working configuration so you can trace the cause instead of losing track after several changes.

If your browser reports a certificate error, check the device's date and time, the domain, and the network. Keep the browser's security protection enabled; don't bypass certificate warnings to complete the test. DNS, certificates, and protocol-specific issues are beyond this initial connection walkthrough; see Troubleshooting for more. For details on protocol choices and core differences, read the protocol and core technical reference.