How to Install and Set Up Clash on Windows: Download, Startup, and Common Fixes

Recommended order: Choose the right installer → Start the core → Import and activate a subscription → Select a node → Enable the system proxy → Test a request → Set up startup. For your initial setup, use Rule mode with the system proxy, and leave TUN off. This makes it easier to distinguish installation, subscription, and traffic-routing issues instead of turning on several options at once and guessing what went wrong.

1. Check your Windows architecture and client support before downloading

On Windows 11, open Settings → System → About and check System type. On Windows 10, go to Settings → System → About. Most Intel and AMD PCs use x64 installers. If your system lists an ARM-based processor, choose the client’s ARM64 package if available. Don’t infer your architecture from your browser or the installer’s file size.

• x64 / amd64: Typically for 64-bit Intel and AMD Windows PCs. The name amd64 does not mean it only works with AMD processors.
• ARM64 / aarch64: For compatible Windows on ARM devices. Check that both the client and core support the platform.
• x86 / ia32: For 32-bit systems. If you’re running 32-bit Windows, you can’t install a client that only offers x64 builds.

Go to the client downloads page, select Windows, and check the supported versions and maintenance status. Clash for Windows is no longer maintained, so older guides may not match the current client. For clients based on mihomo, note the client version and core version separately when reporting an issue.

Installers usually come as .exe or .msi files; portable versions are usually archives. Extract a portable version fully to a permanent folder before launching it. Don’t run it from an archive preview. If you later delete the temporary download folder, a startup shortcut stored there may stop working.

2. Install the client and make sure the core starts

1. Close any older clients that are still running, including background processes in the system tray. For initial troubleshooting, keep only one proxy client running.
2. Run the installer and follow its prompts. For a portable version, launch it from the folder where you extracted it. Installing to a protected folder may require administrator permissions.
3. In the client’s Settings, note the active listening port, core type, and version. Check the startup result in Logs.
4. Make sure there are no configuration parsing errors, port binding failures, or repeated core exits before importing a subscription.

Menu labels vary between clients. This guide uses Configuration (Profiles), Proxies, Rules, and Logs to point you to the relevant features; it does not treat one client’s button labels as universal. The core’s running status matters more than whether the window is open: if the core has not started, enabling the system proxy sends app requests to a local port with no service listening.

If installation is blocked, don’t disable security protections first

If Windows warns about the source or publisher, verify where the installer came from, check the release information, and review its digital signature. If you can’t verify the source, stop the installation. If a required component is missing, install the runtime specified by the client project. Don’t download DLL files from random sites and drop them into the program folder.

If the window closes immediately, check the client logs, Event Viewer → Windows Logs → Application, and Windows Security → Virus & threat protection → Protection history. Save the exact error text; it’s more useful than repeatedly reinstalling.

3. Import a subscription and confirm which configuration is active

Go to Configuration (Profiles) and choose Import or Import from URL to paste your subscription link. To import an existing YAML file, use the local file option. Subscription links often contain account tokens, so treat them like passwords. Don’t post them in public support tickets or online converter sites.

1. After importing, run an update and make sure it reports success. A new configuration card appearing in the list is not enough.
2. Set the imported configuration as active and wait for the core to reload. Some clients do not activate an imported profile automatically.
3. Open Proxies and check that the expected groups and nodes appear.
4. Open Logs and look for unsupported fields, missing referenced nodes, or failed rule-set loads.

If a subscription update times out, distinguish between an unreachable subscription server and unusable nodes. Some clients let you choose whether to fetch subscriptions directly or through a proxy. If the initial connection is not working yet, choosing an unavailable proxy can create an update loop. Follow your provider’s instructions for fetching subscriptions; don’t enable LAN access just to import one.

4. Select a node and enable the system proxy in Rule mode

In Proxies, find the group actually referenced by your rules, select a node, and test its latency. Then enable the system proxy and set the mode to Rule. The system proxy is the traffic entry point; Rule mode determines how the core routes traffic it receives. They are separate settings.

• Rule: Routes, bypasses, or blocks traffic according to the rules in order. Best for everyday use.
• Global: Sends requests that reach the core through the selected global policy. Useful for temporary comparisons, but it won’t capture apps that ignore the system proxy.
• Direct: Sends requests that reach the core directly. Even with the system proxy enabled, traffic may still go out directly.

A latency test of 120 ms means the test address responded through that node at that moment. It doesn’t mean every site is reachable or indicate download speed. A timeout may also mean the test address is unreachable. Verify with an actual request to your target and check the connection logs.

Check the system proxy in Windows Settings

Open Settings → Network & Internet → Proxy and check that the manual proxy or setup script matches the client’s current mode. A common manual proxy address is 127.0.0.1; use the port shown by the client. PAC mode uses a script to decide which requests go through the proxy. The PAC script URL is not the local HTTP proxy port.

For initial troubleshooting, use the client’s standard system proxy option and temporarily disable browser extensions that manage proxy settings. Apps like Firefox may have their own proxy settings; other browsers can also be affected by extensions or organization policies. An enabled system proxy setting does not mean every app will use it.

5. Test with an explicit request instead of relying on a web page

The examples below use local HTTP or mixed port 7890. These are test commands, not a promise that every client uses this default port. If your port is 7897, substitute that instead. A mixed port accepts both HTTP and SOCKS requests; a SOCKS-only port cannot be used as an HTTP port.

# Check whether a TCP connection to the local port succeeds in PowerShell
Test-NetConnection 127.0.0.1 -Port 7890

# Send an explicit request through the local HTTP proxy to rule out inherited system proxy settings
curl.exe --noproxy "" --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://www.example.com/

Use curl.exe to avoid differences in how Windows PowerShell handles the curl alias. --noproxy "" clears the effect of the request’s proxy bypass list. The destination is only an example for testing connectivity; repeat the test with a site you actually need to reach.

1. TcpTestSucceeded is True: The port accepts TCP connections, but this alone does not prove the remote proxy works.
2. Connection refused: First check for a typo in the port or a stopped core.
3. The explicit proxy request succeeds but the browser fails: Check browser proxy overrides, PAC, cache, and rule differences.
4. The request appears in the connection log but times out remotely: Check the matched rule, active policy group, node, and DNS errors.

When an HTTP proxy accesses HTTPS, 200 Connection established only means the CONNECT tunnel was established. Check the subsequent TLS handshake and the target site’s response as well. Even with an explicit local proxy, the configuration may route the domain through DIRECT. Check the full policy chain in Connections or Logs; a request reaching the core does not prove it used a remote node.

6. Troubleshoot port conflicts, firewall blocks, and permissions separately

Port conflicts: Identify the process before ending anything

If the logs show address already in use or a binding failure, run this in PowerShell:

Get-NetTCPConnection -State Listen -LocalPort 7890 |
  Select-Object LocalAddress, LocalPort, OwningProcess

# You can also use the traditional command to find the listening process ID
netstat -ano | findstr :7890

Compare the process ID in the results with the PID shown in Task Manager → Details. A common cause is another client or an old core still running in the background. Exit the program normally first. If you need to change the port, do so in the client settings, reapply the system proxy, and update any browser extensions or terminal commands that still use the old port.

Firewall: Distinguish local connections from LAN access

If you only use the proxy locally through 127.0.0.1, you generally don’t need to enable Allow LAN. A Windows Firewall prompt does not mean you must allow inbound connections on public networks. Only check the listening address, private network settings, and inbound rules if you actually need to share the proxy with devices such as a phone on your LAN.

If you suspect security software is blocking outbound connections from the core, review its block log and verify the program’s full path. Check the relevant rules in Windows Security → Firewall & network protection. Use a narrowly scoped allow rule; don’t disable the entire firewall as a permanent fix. If your organization manages the device, ask an administrator to review its policies.

Permissions: The system proxy and TUN are different

Setting the system proxy for the current user usually does not require running the client as an administrator at all times. TUN involves a virtual network adapter, routing, and related services, so it may require elevated permissions or a service installed by the client. Use the client’s service installation process instead of assuming that running as administrator every time will fix every issue.

7. Set up startup and test again after signing out or restarting

For desktop clients, “start on startup” usually means launching after you sign in, not setting up a proxy before sign-in. In the client’s Settings, enable Start with Windows or Launch at login, and turn on Start minimized if you want. Check separately whether the system proxy, TUN, and active configuration are restored. Don’t assume startup restores every setting.

1. Open Task Manager → Startup apps. In Windows 10, this page is usually called Startup. Make sure the client is enabled.
2. Keep the single startup entry created by the client. Don’t also add a shortcut to the Startup folder or create a scheduled task.
3. Exit the client normally, reopen it, and confirm that the active subscription, Rule mode, and policy group selection are restored.
4. Sign out and back in, or restart. Wait for the network connection, then check the system tray, core logs, system proxy port, and an actual web request.

If you move a portable version, its startup entry may still point to the old path. Restore it to a permanent location, then turn startup off and back on in the client. If the client only works when run as administrator but fails at login, check the service installation and permission setup. Don’t disable Windows User Account Control for convenience.

If all nodes time out after startup, Wi-Fi may not be connected yet, the system clock may not have synced, or rule sets may update before the network is available. Wait for the connection to stabilize and check the order of events in the logs. Seeing the desktop does not mean the subscription server or nodes are already reachable.

8. Fix connectivity after exit and run a final checklist

If your browser loses internet access as soon as you close the client, open Settings → Network & Internet → Proxy and check for a manual proxy pointing to a local port or a leftover PAC script. The client may have exited unexpectedly before restoring the settings. Remove only the settings it added; don’t delete proxies managed by your organization.

If commands still fail in the terminal, check whether you manually set HTTP_PROXY, HTTPS_PROXY, or ALL_PROXY. These environment variables are separate from the Windows system proxy setting. After changing persistent environment variables, you usually need to reopen the terminal. Don’t overlook an old address still set in the terminal just because your browser works again.

• Installation check: The client and core both start, with no recurring startup errors in the logs.
• Configuration check: The subscription updates successfully, the intended configuration is active, and the nodes referenced by policy groups are present.
• Proxy check: The explicit port test and real app requests both work. Verify the matched rule and policy chain.
• Startup check: After signing in again, only one client instance is running and the port, configuration, and proxy state are as expected.
• Exit check: After a normal exit, connections that should go direct still work, and no stale local proxy settings remain.

For further troubleshooting, note your Windows version, CPU architecture, client and core versions, listening port, whether TUN is enabled, and the logs for one failed request. Before sharing screenshots, hide subscription URLs, tokens, node passwords, and management API keys. This information is usually more useful for reproducing the issue than reinstalling the client.