Setting up a Clash client for the first time:cross-platform essentials and common beginner pitfalls
Choose the right installer, import your subscription, and configure the system proxy. Follow these cross-platform setup steps and avoid common port, certificate, and permission issues.
When you launch a Clash client for the first time, don't enable the system proxy, TUN, and startup-on-boot all at once. Follow this order: installer → configuration → proxy groups → route traffic → verify the connection. Check the result at each step. If your connection drops, you'll be able to tell whether the subscription failed to download or your traffic never reached the core.
1. Installer and system architecture
Clash clients typically consist of a graphical interface and a proxy core. The interface imports configurations, manages policies, and changes system settings; the core listens on ports, matches rules, and establishes connections. Installing the interface doesn't mean you have usable nodes or that every app will automatically use the proxy.
| Platform | Where to check | Choosing an installer |
|---|---|---|
| Windows | Settings → System → About → System type | Most Intel and AMD desktop PCs use x64. For ARM devices, first check whether the client offers native support. |
| macOS | Apple menu → About This Mac | Choose arm64 for Apple silicon or x64 for Intel, and check the minimum macOS version requirement. |
| Linux | Run uname -m in Terminal | x86_64 corresponds to x64; aarch64 corresponds to arm64. Choose the right package for Debian-based or RPM-based distributions. |
| Android | OS version, device processor, and installer requirements | Most recent devices use arm64-v8a. Older devices may require a different architecture, so don't choose based on brand alone. |
| iOS / iPadOS | Compatibility notes on the app store listing | Choose a client compatible with your device. Windows EXE files and Android APKs can't be installed directly on other platforms. |
If installation fails, check the system message first
- Incompatible version: Check your OS version and processor architecture. Don't keep trying similarly named packages one after another.
- Missing runtime: Install the runtime specified in the client's release notes. Don't download a DLL with the same name from an untrusted site.
- Untrusted source or signature: Check the download source, publisher, and project documentation first. Security prompts don't all have a generic “Continue” button, and device management policies shouldn't be bypassed by disabling protection.
For an initial system proxy test on Windows, you usually don't need to run the entire client as administrator. Grant the relevant permissions only when installing a service or creating a virtual network adapter. On a managed work computer, check whether installing network services is permitted.
2. Import a subscription and activate the configuration
Most clients have a Configuration, Profiles, or Subscription section. Copy the Clash- or mihomo-compatible subscription URL from your provider, then use that page's Import, Add Remote Profile, or Download option. In older CFW versions, go to Profiles → enter the URL in the field at the top → Download. After it finishes, select the profile card to make that configuration active.
- Check the format: A regular webpage URL, a node share link, or a subscription intended for another client may not load as a Clash YAML configuration.
- Check the download: A new entry should appear in the profile list with a successful update status. Saving the URL without successfully downloading the configuration doesn't count as importing it.
- Check that it's active: Open the Proxy or Proxies page and look for the policy groups defined in the configuration. If the page is still empty, check which profile is selected.
- Check core compatibility: If an error mentions an unknown protocol, unknown field, or unsupported proxy type, check which core the subscription requires instead of repeatedly clicking Update.
A failed subscription download is different from an unavailable node
Downloading a subscription contacts the configuration server; testing a node sends a request to a destination through the selected proxy. If the subscription returns HTTP 401 or 403, first check the URL, authorization, or provider restrictions. An HTML response may be a login or error page. If the parser reports a YAML error, verify that the response is actually a configuration before trying random indentation changes.
Some clients keep a local copy of remote configurations. Manual edits to that copy may be overwritten the next time the subscription updates. Start by testing the original configuration; if you need custom rules, learn how your client handles overrides, merges, or extensions.
3. Rule mode and policy selection
After loading the configuration, select Rule mode and choose a node in a policy group. Global mode generally sends connections that reach the core through the global policy; Direct mode connects directly. “Global” describes how the core handles traffic it receives—it doesn't mean apps that never send traffic to the core will be captured.
- Manual selection: The common type is
select; choose a node or a nested policy group manually. - Automatic testing: The common type is
url-test. The test URL, interval, tolerance, and other configuration settings affect the selection. - Rule targets: A rule can point to a policy group,
DIRECT, orREJECT. Changing one group won't necessarily change the route used by every website.
A latency test that returns a value in milliseconds only confirms that the test request received a result. It doesn't guarantee video quality or download speed. For an initial check, open a real webpage and the client's Connections page, then confirm which rule matched and which policy handled the request.
4. System proxy and VPN permissions on mobile
Windows: Check the listening address and port first
In older CFW versions, check the port and enable System Proxy on the General page. Other clients usually put this setting on the home or settings page. The snippet below illustrates how the fields relate; it isn't a complete subscription with nodes and rules, and it isn't a default configuration for every client:
mixed-port: 7890
allow-lan: false
mode: rule
mixed-port: 7890 means the same listening port accepts both HTTP and SOCKS proxy connections. If the client actually listens on port 7897, use 7897—not the 7890 shown here. For local use, apps generally connect to 127.0.0.1. allow-lan: false restricts access from your local network; you don't need to enable LAN sharing just to browse the web.
After enabling the system proxy, check Settings → Network & Internet → Proxy in Windows 11. Common setups configure a local address and port under manual proxy settings; some clients use a proxy script instead. Make sure the system settings match how the client handles traffic—there's no need to turn on every option.
macOS, Linux, and mobile differences
- macOS: Check System Settings → Network → your current network service → Details → Proxies. Some clients ask to install a helper to change system network settings.
- Linux: Desktop environment proxy settings may not apply to terminal programs or every app. Browsers, package managers, and command-line tools may each use different proxy settings.
- Android: A common approach is to start a local VPN service and approve the system permission, rather than looking for a Windows-style System Proxy switch. Per-app proxy settings and bypass lists also affect which traffic is captured.
- iOS / iPadOS: Clients usually create a VPN configuration and ask for system approval. Supported protocols, background behavior, and configuration compatibility depend on the app.
The system proxy mainly serves apps that honor system settings. If a game or command-line tool doesn't appear in the connection list, the node may be fine—the app may not use the system proxy at all. Check the app's own proxy settings before considering TUN.
5. Port conflicts and connection checks
For your first connection, run only one proxy client. Older clients, developer tools, and background services may already be using a port. If the log shows address already in use or a bind failure, check the listening port first instead of downloading the subscription again.
Check whether port 7890 is in use on Windows
netstat -ano | findstr :7890
Look for a row with local port 7890 and status LISTENING; the last column shows the PID. In Task Manager → Details, find the process associated with that PID. If it's an old proxy client you no longer need, close it normally. Don't end an unfamiliar system process. You can also switch to an unused port, but update the system proxy and any manually configured apps to match.
Narrow it down with a request that explicitly uses the proxy
If the client listens on local HTTP or mixed port 7890, run this diagnostic command in Windows Terminal. On macOS or Linux, replace curl.exe with curl:
curl.exe --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com/
This command connects directly to the proxy port, regardless of whether your browser uses system settings. It still follows the core's rules, so a successful response doesn't necessarily mean traffic went through a remote node: a rule may have sent it direct. Check the Connections panel to see the route. The 10-second value is the connection timeout; 20 seconds is the total request time limit, not a measured result.
| What you see | Check first |
|---|---|
| Immediate error connecting to the local port | Check whether the core is running, whether the listening port matches, and whether the port binding failed. |
| The request appears in Connections, then times out | Check the selected policy, node connection logs, destination, and whether your local network allows the connection. |
| The command works, but the browser doesn't | Check the system proxy, the browser's own proxy settings, extensions, and cached browser connections. |
| The browser works, but one app doesn't | Check whether the app supports proxies, bypasses system settings, or needs another way to capture its traffic. |
6. Certificate warnings and TUN permissions
Don't bypass browser certificate errors
A regular HTTP CONNECT tunnel or SOCKS proxy doesn't require installing an unfamiliar root certificate to browse HTTPS websites. If your browser reports an expired certificate, a hostname mismatch, or an untrusted issuer, first check the system date, time zone, and time sync. Then check for corporate network inspection, antivirus HTTPS scanning, or a captive login page.
An app signature warning during installation, a TLS error while downloading a subscription, and a certificate error in your browser happen at different stages. Note the exact error and where it occurred; that's more useful than turning off every certificate check. Don't use skip-cert-verify as a general fix: it changes certificate validation for the relevant connection and may hide something other than a node problem.
Enable TUN only after basic connectivity works
TUN uses a virtual network interface and routing settings to capture eligible IP traffic. It's useful for apps that don't use the system proxy, but enabling it doesn't guarantee that all traffic will go through the proxy. Routing exclusions, per-app settings, IPv6, DNS handling, and system permissions all affect what gets captured.
- First make sure a browser works through the system proxy and the Connections panel shows the expected policy.
- Install or enable the service according to your client’s instructions, then turn on TUN. On Windows, this often requires a service or elevated permissions; on macOS and Linux, it may require a helper or network management permissions.
- Check the logs for virtual interface creation failures, routing errors, or DNS listener conflicts. Don't enable traffic capture in another VPN at the same time.
- Test with an app that normally ignores the system proxy. If enabling TUN disconnects the whole device, turn TUN off to restore connectivity, then check the logs.
DNS hijack rules direct specific DNS traffic to the core; they don't mean that a browser's built-in encrypted DNS, every interface, or every app will follow the same route. When setting things up, don't change DNS mode, IPv6 policy, and routing options all at once. Change one setting at a time so you can identify what caused the difference.
7. Restore settings and final checklist
Once setup is complete, decide whether to enable startup on boot, connect at startup, and scheduled subscription updates. First test a normal exit: turn off traffic capture, quit the client from the tray or menu, and confirm that your regular connection is restored. Force-quitting the process can leave the system proxy pointing to localhost after the listener has stopped.
If Windows can't connect after you quit, go to Settings → Network & Internet → Proxy and check for leftover manual proxy or script settings. Remove only settings you just added; don't delete existing proxy policies on a work computer without permission. On mobile, check the system VPN status and options such as Always-on VPN and Block connections without VPN.
- Installation: Confirm the architecture, minimum system requirements, and whether the client is maintained.
- Configuration: The subscription downloaded successfully, the active profile is selected, and policy groups are visible.
- Mode: Rule mode is enabled, and you know which rule and policy handled the test request.
- Ports: The system proxy or app settings match the actual listening port, and no other client is competing for it.
- Permissions: Grant permissions only when needed for a service, VPN, or TUN. Don't disable security checks as a substitute for troubleshooting.
- Recovery: Verify connectivity after turning off traffic capture and quitting normally, and know where to remove any leftover settings.
Once you've checked all six items, add custom rules, per-app routing, and TUN. For later troubleshooting, follow the same order: Is the configuration valid? Is the core listening? Is traffic reaching it? Which rule matches? Can the selected route reach its destination? This is more effective than repeatedly uninstalling and reinstalling.