Clash First-Time Setup Checklist for Windows, macOS & Android

1. Before Installing: Check the Client, Core, and System Architecture

Clash setup comes down to four things: the client launches, the configuration loads, the local proxy port is listening, and app traffic reaches the proxy. Successfully opening the installer only confirms the first step. Verify each one in order, then enable extras like TUN or launch at startup. This makes troubleshooting much more straightforward.

The GUI client handles subscriptions, proxy group selection, and system settings. The core parses the configuration, matches rules, and establishes outbound connections. Clash, Clash.Meta, and mihomo are not interchangeable version labels. If your subscription uses mihomo-specific fields or newer protocols, you need a compatible core—don't rely on the client name alone to determine compatibility.

• Windows: Go to Settings → System → About and check “System type.” Choose an x64 or ARM64 installer to match your device architecture; “Windows 11” alone doesn't tell you which one you need.
• macOS: Open the Apple menu → About This Mac. Choose ARM64 for a Mac with Apple silicon, or x64 for one with an Intel processor.
• Android: Most recent devices use ARM64, but older devices and some system configurations may differ. Check the client's release notes for the minimum Android version and supported architectures. If you can't confirm, consider using the universal package if one is available.

2. Importing a Subscription: A Successful Download Doesn't Mean It's Working

Subscription URLs often contain access tokens, so treat them like passwords. Get them only from a trusted provider, and never share the full URL in public screenshots, online conversion tools, or support requests. A subscription may return a full Clash YAML configuration or just a list of nodes; each may require a different import option.

First-import checklist

1. In the client's configuration or subscription section, add a remote configuration and paste the full URL. The menu name varies by client. Don't paste it into a proxy server address field.
2. Run an update and check for configuration parsing errors. If you get redirected to a login page, see an expiration notice, or receive ordinary HTML, the download may have succeeded—but the response isn't usable as YAML.
3. Select the configuration you just imported and make it the active one. Seeing a subscription card in the list doesn't mean the core has switched to that configuration.
4. Open the proxy groups page and confirm that at least one node is available. Select a node or the intended policy manually. If the import succeeded but DIRECT is still selected, traffic may still go direct.
5. Set the outbound mode to rule mode, then check that the rules list isn't empty and that the final rule uses the expected fallback policy.

If you see “unsupported proxy type” or “unknown field,” first check which core the configuration requires. For HTTP 401 or 403 errors, check the token and access permissions. For a 404, make sure the URL is complete and the resource hasn't moved. Reinstalling the client over and over is no substitute for identifying the error.

Keep subscription updates separate from local changes

Editing a file generated from a remote subscription can be undone the next time it updates. To add direct-connect domains, change DNS, or modify ports, use the client's override, merge, or local extension features where available, then check the resulting configuration. Keep track of what's in the original subscription and what's been changed locally so you can roll back easily.

3. Local Proxy Ports: Check the Listener and Port Conflicts

The system proxy must point to the address and port the client is actually listening on. A common example is 127.0.0.1:7890, but 7890 isn't the default for every client. Check the active configuration and logs. The controller port is for managing the core—don't enter it as your browser's HTTP proxy.

This mihomo snippet shows the local listener settings only; it isn't a complete configuration with nodes and rules. mixed-port accepts both HTTP and SOCKS proxy requests on the same port. Binding to the loopback address helps prevent accidentally exposing the listener to your local network during initial setup.

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

Windows: Find the process listening on a port

netstat -ano | findstr :7890

Look for a line with the port's local address and a status of LISTENING. The last column shows the PID. Match it to the process ID in Task Manager's Details tab. If another proxy client is using the port, exit that client normally before starting this one. Don't force-quit an unfamiliar system process.

macOS: Check TCP listeners

lsof -nP -iTCP:7890 -sTCP:LISTEN

If there's no result, the core may have failed to start, or it may be using a different port. If you change to an unused port, update the system or app proxy settings too. Changing the configuration without updating the listener settings will make browsers report a connection error.

4. Windows and macOS: Test the System Proxy First

The system proxy tells apps that honor system proxy settings to send requests through the local client. It doesn't route all traffic on the device. A browser is usually a good first test; games, command-line tools, and some apps may use their own network settings.

Use the client's system proxy toggle to apply the settings, then verify them in your system settings. If the client provides an HTTP proxy, use the corresponding HTTP or mixed port for macOS Web Proxy and Secure Web Proxy. For SOCKS Proxy, use the SOCKS or mixed port. Don't enter the same port for different protocols without checking which listener you're using.

Handle permission prompts based on the feature

• Windows service mode: Some clients use a background service for features that require elevated permissions, such as TUN. Install the service only if you need it, and check which program is requesting access in the system prompt.
• macOS helper components: The client may request permission to set the system proxy or create a virtual network interface. If authorization fails, check the component's status. Repeatedly launching the entire app as an administrator won't fix the underlying issue.
• System blocks the app: Check the download source and the specific reason shown in the system alert first. Don't disable system security protections globally just to run an installer.

5. Android: VPN Permission and Background Activity

Android clients typically route traffic through the system VPN interface rather than using the desktop-style system proxy toggle. The first time you tap Connect, Android asks for VPN permission; allow it to create the interface. A VPN icon in the status bar confirms only that the interface is up—not that the node, DNS, and rules are working correctly.

1. Disconnect other VPNs first. Another VPN, firewall, or filtering app in the same user or work profile may compete with the client for the VPN interface.
2. Check which apps are included. If per-app proxying is enabled, make sure your browser is covered and check whether the mode is “allow only selected apps” or “exclude selected apps.”
3. Check background restrictions. Start at Settings → Apps → the client → battery settings and allow the background activity it needs. Menu paths vary by device manufacturer. Also grant notification permission if the client requires it.
4. Test after locking the screen. Connect, lock your phone for a few minutes, then unlock it and visit a page. Check that notifications, connection status, and logs remain active. If it works only while the app is in the foreground, check battery optimization first.

During initial setup, don't enable both “Always-on VPN” and “Block connections without VPN.” The latter blocks other network paths when the VPN isn't connected, which can make subscription updates and troubleshooting harder. The setting is often under Settings → Network & internet → VPN → the connection's settings, though menu names vary by manufacturer.

If regular internet access works but domains fail to resolve after connecting, check Android Private DNS and the client's DNS settings. Compare results by changing one setting at a time—automatic, a specific provider, or off—and note what happens. Disabling Private DNS isn't a universal requirement.

6. Verify Traffic: Check Each Layer from Port to Rule

A successful node latency test doesn't prove that every app is using the proxy. The test may use a different destination, protocol, or site from the traffic you're trying to route. For a more reliable check, look at the local listener, the client's connection log, and the destination site together.

Test an explicit proxy on desktop

On Windows, use the command below to avoid any PowerShell aliases with the same name. On macOS, replace curl.exe with curl. Use the HTTP or mixed port that the client is actually listening on.

curl.exe --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com

The 10-second connection timeout and 20-second overall timeout are troubleshooting parameters, not speed-test results. Getting an HTTP response means the explicit proxy request completed; the rules may still have routed it direct. To confirm the selected node was used, check the connection details for the matched rule and final outbound.

• Connection refused: Check the local port, listening process, and core startup logs first.
• No connection entry: Check whether the app uses the system proxy, has its own proxy settings, or is excluded by per-app rules.
• Matched DIRECT: Check the current mode, domain rules, and rule order. Don't assume the node is down.
• Proxy handshake or authentication failed: Check the subscription status, node credentials, protocol support, and device clock.
• Domain lookup failed: Check DNS logs, upstream reachability, and the current network. Troubleshoot this separately from an unreachable TCP port.

Enable TUN only after basic testing

Consider TUN if the browser works through the system proxy but a particular app ignores proxy settings. TUN uses a virtual network adapter and routing rules to capture eligible traffic, and often also requires DNS routing and extra permissions. Its coverage still depends on routes, exclusions, and platform limits; enabling it doesn't necessarily send all traffic through a proxy node.

If enabling TUN makes local network devices unreachable, disconnects another VPN, or creates a network loop, turn TUN off to restore your baseline, then check the routing and exclusion settings. Don't change nodes, DNS, the core, and the TUN network stack all at once—you won't know which change made the difference.

7. Startup and Restart Checklist

Set the client to launch at startup only after the connection is stable. Opening the client window, running the core in the background, restoring the system proxy, and connecting the VPN automatically are separate things. One startup option may not do all four. On Android, app startup and automatic VPN connection may also be controlled separately.

On Windows, check startup apps under Settings → Apps → Startup. On macOS, check allowed login items and background items under System Settings → General → Login Items. If the client has its own startup setting, don't add a duplicate manually; two instances could compete for the same port.

1. Save your current settings: Note the configuration name, node policy, proxy port, and whether TUN is enabled.
2. Restart the device: Confirm that the client and core are running, and check for port conflicts, authorization issues, or configuration parsing errors.
3. Check traffic routing: On desktop, verify the system proxy. On Android, check the VPN connection and per-app scope.
4. Test and observe: Visit sites expected to go direct and through the proxy, then check the matched rule and final outbound for each. Don't rely on a single webpage.
5. Confirm settings are restored on exit: Turn off the proxy normally and make sure basic internet access works. Keep the system proxy and VPN settings easy to find in case the client exits unexpectedly.