Import a FlClash subscription
and configure your connection

STEP 01 / CONFIGURATION

Import a subscription and activate the configuration

Open FlClash and go to the Configurations page. On desktop, you'll usually find it in the left-hand navigation; on mobile, it's usually in the bottom navigation. Tap Add or the plus button, choose the URL import option, paste the full subscription URL, and give the configuration a name you can recognize. The name is only for local organization and doesn't change the service. Before saving, check that there are no extra spaces at either end of the URL. When copying from a chat message, make sure you haven't included any surrounding instructions.

A subscription URL is not your provider's homepage or account sign-in page. It should return configuration content supported by the client. If your provider offers several import options, choose one explicitly marked as compatible with Clash, Clash Meta, or mihomo. A text file containing only individual protocol links may not import as a complete YAML configuration; this depends on the client version and its import features. Check your provider's instructions rather than repeatedly retrying the same URL.

Wait for parsing to finish, then set it as the active configuration

Keep your internet connection active while the configuration downloads and parses. When it's ready, the new entry should appear on the Configurations page. Select the entry or use its activation control to make it the active configuration; seeing a configuration card in the list doesn't mean the client is using it. Return to the dashboard and confirm that the active configuration name matches the one you just imported. Then open the Proxies page and check for proxy groups and available endpoints. Group names depend on the configuration and don't need to match this guide.

To import a local file, choose file import when adding a configuration, then open the YAML file in your system's file picker. Don't save a webpage as a file and change its extension, or use a formatted document instead of a plain-text configuration. File import is for complete configurations you already have. Automatic updates depend on the file's remote resources and client settings, so don't assume a local file is linked to an online subscription.

If the import fails, stop here and troubleshoot

If the download fails, parsing returns an error, or the configuration is empty, keep the error message and check it first. For a download failure, check the URL, your current network, and whether the service is still active. For a parsing error, confirm that the response is actually a compatible configuration. A URL opening in a browser doesn't mean its contents are suitable for the client; it may have downloaded a sign-in page instead. If your old configuration still works, don't delete it yet—you'll need it for comparison. For details, see the FAQ's setup and configuration guide. If the problem persists, go to Troubleshooting: Subscription Import Failures.

Before you continue: The configuration is imported and active, and the Proxies page shows usable options. Once all three are true, choose how requests are handled and which endpoint to use.

STEP 02 / ROUTING

Choose rule mode and a proxy endpoint

Return to the dashboard, find Outbound Mode or a similar setting, and select Rule. Rule mode is a good place to start because most subscriptions include site categories and proxy groups. The client matches requests against the rules in the configuration, then decides whether to connect directly or use a proxy. Rule mode doesn't generate a routing plan for you; it applies the rules already in the active configuration. That's why choosing the right configuration in the first step matters.

Next, open the Proxies page and find the group that your rules actually use. If the group allows manual selection, choose an available endpoint and confirm that the selection indicator updates. For an automatic selection or failover group, check that it has available options and run a connectivity test if needed. A test only helps assess whether its specific target is reachable; it doesn't guarantee access to every site or tell you everything about service quality.

Understand the difference between mode and endpoint

Outbound mode determines how requests are handled; a proxy group determines which endpoint handles requests that need a proxy. Even in Rule mode, a request may connect directly if its group is set to Direct. Conversely, a site matched by a direct-connection rule will bypass the proxy even when a proxy endpoint is selected. If your configuration uses nested proxy groups, follow the current selection to the next group and check its options. Don't change a group that isn't actually referenced.

Global mode typically sends requests handled by the client to the global policy, making it useful for briefly comparing the results with rule mode. It doesn't mean every system app will use the client; that still depends on the system proxy, VPN, or TUN settings configured in the next step. Direct mode connects without a proxy, so don't use it to check whether a proxy endpoint works. For your first connection, stick with Rule mode and one available endpoint instead of switching between several modes. That makes issues easier to isolate.

Start with your subscription's rules; don't edit YAML yet

If the configuration already includes rules, leave them as they are until you've completed a connection test. Changing rule order, DNS, or proxy group names adds more variables, and subscription updates may overwrite your edits. If you need a specific site to use a proxy, first check which rule it matches, then consider a targeted change. For more on rule order, fallback rules, and proxy group references, see the usage tips section of the FAQ. You don't need to edit these fields to get started.

Note the active configuration, outbound mode, and proxy group selection so you can use them as a baseline during testing. If the proxy list is empty, go back to step one and check the configuration; switching to Global won't create missing endpoints. If endpoints are listed but every test fails, check the subscription service and your local network first. Before you continue: The dashboard shows Rule mode, the relevant proxy group has a clear selection, and you're ready to route app traffic through the client.

STEP 03 / CONNECTION

Connect and route system traffic through the client

Once the configuration and endpoint are selected, return to the dashboard and tap Connect or Start. Check that the status changes to Running, and look for port conflicts, permission errors, or configuration load failures. A running core means the client is ready to handle requests; your browser and other apps still need to send traffic through it. Desktop and Android use different methods, so follow the instructions for your platform below. Don't change several network settings at once just to turn everything on.

Desktop: start with the system proxy and test your browser

On Windows, macOS, or Linux, first enable System Proxy in FlClash, then open a website in a browser that follows the system proxy settings. System proxy affects apps that read those settings; it does not route all network traffic. Some Linux desktop environments and apps don't use the same proxy settings, and apps such as Firefox may have their own configuration. If the proxy doesn't work in your browser, first check whether the browser is set to use the system proxy instead of immediately changing your subscription.

For your first setup, keep the default mixed port. A common default is 7890, but use the value shown in your client. If another proxy tool is using the same port, quit that program and restart FlClash. Don't guess at a port number, and don't force-quit the client right after enabling the system proxy. If the system still points to a local proxy after the client has stopped, webpages may be temporarily unreachable.

If your browser works but an app that doesn't follow the system proxy still can't connect as expected, consider enabling TUN. TUN routes traffic through a virtual network interface and may require administrator approval, a service component, or system network permissions, depending on the operating system and client version. Save your current settings first, then enable it as prompted and check that it starts successfully. Leave routing, DNS, and conflicts with other VPNs for a step-by-step check in Troubleshooting; don't change these advanced settings during this setup.

Android: approve the system VPN request

On Android, tapping Start may bring up a system VPN connection request the first time. Make sure the request comes from FlClash, which you just installed and opened yourself, then read the prompt and approve it. The VPN should appear as active in the status bar or network settings, and FlClash should show that it has started. If you deny the request, an imported configuration alone doesn't mean app traffic is being routed through the proxy. Since status bar icons vary by device, check both FlClash and the system VPN settings.

If another VPN is running on your phone, turn it off before connecting FlClash to prevent both tools from competing for the same network connection. If per-app routing is enabled, check that your test browser is allowed; excluded apps won't use the proxy just because the client is connected. Keep the default app scope until you've completed verification, then narrow it to fit your needs. This avoids extra variables during initial setup.

After connecting, keep the client running and move on to the next step. If Android disconnects only when the screen is locked, first confirm that the connection works, then check battery optimization and background activity permissions instead of changing every power-saving setting upfront. Before you continue: The client is running, the desktop system proxy or Android VPN is enabled as appropriate, and no other proxy app is interfering.

STEP 04 / VERIFICATION

Verify website access and actual routing

Once the connection button shows that the client is running, don't rely on its status color alone. In the browser you've confirmed is using the client, visit one site expected to connect directly, then one expected to use the proxy. Check that both load. Test both types of traffic: testing only a proxied site may miss a direct-connection DNS or rule issue, while testing only a site that's already accessible doesn't confirm that the proxy endpoint is being used.

Reload each page during testing, and try one you haven't visited before if needed. Existing connections, browser cache, and background tabs can make things look the same before and after you connect. Don't run multiple proxy extensions or another client at the same time; even if a page loads, you won't know which setup handled the request. If your browser has its own proxy settings, note the current settings first, then temporarily switch it to use the system proxy for comparison.

Check the destination and endpoint in the connection log

Open the Connections page in FlClash, then revisit a webpage and look for its destination domain. Depending on your version, check the matched rule, proxy group, and final endpoint. Short-lived connections may disappear quickly; if you miss one, reload the page or use the logs. A low log level may hide details, so raise it temporarily if needed. Restore your usual level after checking to avoid generating excessive logs.

If the page loads but the connection record shows Direct as the endpoint, first check whether that's what the configuration expects. In Rule mode, it's normal for direct sites and proxied sites to use different endpoints. To verify with an exit IP lookup, first make sure the lookup request itself matches a proxy policy, then compare the results. An unchanged IP alone doesn't prove the client has failed. Different destinations can match different rules, so check each request individually rather than assuming one test covers every app.

If something fails, check back to the last step that worked

If webpages worked before connecting but none load afterward, stop the connection and restore the system proxy settings. Check whether your basic internet connection still works, then review your endpoint selection and traffic routing settings. If only some sites fail, leave the configuration and mode unchanged. Note the failing domains, error messages, and matched rules, then check service reachability or DNS. Change one thing at a time and retest the same destination so you can tell what made a difference.

If the browser works but other apps behave the same as before, check whether they follow the system proxy, or whether Android per-app routing excludes them. If every proxy endpoint times out, check your subscription service, system clock, and local firewall. For a complete troubleshooting sequence, see Troubleshooting; for common concepts and configuration differences, see the FAQ. Start by verifying a reproducible case; there's no need to rewrite DNS settings or rebuild the entire configuration yet.

Before you finish, stop the connection in FlClash. On desktop, make sure the system proxy is disabled or restored before quitting the app. On Android, confirm that the VPN is no longer active. The next time you open the client, check that the correct configuration, Rule mode, and endpoint are still selected. If your subscription changes, update it from the Configurations page and test again; don't add the same URL repeatedly. Your initial setup is complete. From here, adjust settings gradually to meet the needs of specific apps.