Clash for Windows: Installation and Setup Guide, from Download to Startup

Before you install: understand the client, core, and subscription

Using Clash on Windows involves three parts: the client provides the interface, configuration management, and system integration; the core handles proxy protocols, rule matching, and connections; and the subscription supplies nodes and may also include proxy groups and rules. A successful installation only means the client can launch. It does not mean you have working nodes or that system traffic is being routed through the proxy.

Clash Meta continued development under the name mihomo. Clients using mihomo may support different configuration fields than older Clash clients. If a protocol is unsupported or a field fails to parse, first check which core is running and its version instead of repeatedly toggling the system proxy. The legacy Clash for Windows client is no longer maintained. For a new installation, check that the client project is actively maintained and supports your version of Windows.

• Client: Note the app name, app version, and installation path so you can find settings and upgrade instructions later.
• Core: Find the core name and version in the client's core information or at the start of its logs. The app version and core version are not the same.
• Configuration: Make sure the subscription provides a Clash- or mihomo-compatible format. A list containing only node URIs may not load as a complete YAML configuration.

Choose an installer: check your system architecture and installation type

Check for x64 or ARM64 before downloading

On Windows 11, open Settings → System → About and check System type. On Windows 10, look under Settings → System → About. Most desktop PCs with Intel or AMD processors use x64; for ARM-based devices, choose the ARM64 package if the project provides one. Don't assume x64 and ARM64 are interchangeable just because both are 64-bit.

Install and launch for the first time

1. Choose a Windows client from the download page, then check the relevant project's release notes, publisher information, and system requirements.
2. Exit any other proxy clients that are running. For initial troubleshooting, run only one core to reduce port and routing conflicts.
3. Install the program in a stable location. Don't keep a portable package in a temporary extraction folder, and avoid renaming or moving the entire directory after setup.
4. After launching the client, check the logs for repeated core exits or restarts and configuration parsing errors. If a runtime component is missing, install the required component as documented for that release.

If Windows displays a security warning, verify the download source, publisher, and file properties before deciding whether to proceed. Don't disable system protection long-term to work around installation problems. Organization policies may also restrict installation or network access on managed devices; check with your administrator.

Import a subscription: a successful download doesn't activate the configuration

The configuration menu has different names across clients, commonly “Subscription,” “Configuration,” or “Profiles.” These steps describe the tasks rather than assuming every client uses the same button labels. Before importing, make sure the link is from your subscription provider and returns a format the client can read.

1. Open configuration management, choose the option to import from a URL, and paste the subscription link into the address field.
2. Download or import the configuration and check the result. HTTP 401 or 403 errors usually mean you need to check authorization, expiration, or access restrictions. If the response is a web page, it isn't a YAML configuration you can use.
3. Select the imported configuration and make it the active one. Seeing a subscription in the list doesn't mean the core has switched to it.
4. Check that proxy groups are present and node names are complete. Then set the mode to Rule and choose a node for any proxy groups that require manual selection.
5. Run a latency test. If it fails, check the specific error in the logs; a single timeout doesn't mean the Windows installation failed.

Manage local edits separately from subscription updates

Direct edits to a downloaded configuration may be overwritten the next time the subscription updates. To keep custom rules or DNS changes, use the client's supported override, merge, or local configuration features, then check the effective configuration after an update. Don't assume all clients use the same override syntax.

Subscription links often contain credentials. Blur the full link, tokens, and management keys in troubleshooting screenshots. A third-party subscription converter may be able to access your subscription contents, so consider the trust implications. When possible, use a compatible configuration directly from your provider.

System proxy: verify 127.0.0.1 and the active listening port first

The Windows system proxy mainly affects apps that honor Windows proxy settings. It does not capture traffic from every process. Some command-line tools, games, and apps with their own networking code won't use this setting automatically, so a browser working while a terminal cannot connect isn't necessarily a fault.

This guide uses 7890 as an example mixed-proxy port. Some clients use 7897 or another value; check the active core configuration and listening ports. HTTP and SOCKS may use separate ports. Don't enter the controller API port as the system proxy.

# Example local connection settings; not a complete configuration to use in place of a subscription
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

1. Enable the client's system proxy feature.
2. Open Windows Settings → Network & internet → Proxy and check that the manual proxy address and port point to the current client. Some environments use a setup script; also check for script addresses added by other software.
3. In PowerShell, check whether a TCP connection to the local port can be established.

Test-NetConnection -ComputerName 127.0.0.1 -Port 7890
curl.exe --proxy http://127.0.0.1:7890 --head --connect-timeout 10 https://example.com/

TcpTestSucceeded : True only means the local port is reachable; it doesn't prove that a remote node works. The second command explicitly uses the local HTTP proxy, helping distinguish an app that ignores the system proxy from a failure in the proxy chain. Using curl.exe avoids parameter differences caused by the curl alias in some PowerShell environments. The test domain is only an example; replace it with the destination you're troubleshooting.

Service mode, TUN, and firewall: handle permissions and traffic routing separately

Service mode handles permissions; it doesn't verify your configuration

Some Windows clients use service mode to start the core or perform tasks that require elevated permissions. A UAC prompt when installing a service is part of the elevation process; confirm that it comes from the client you installed. Implementations vary: installing a service doesn't enable TUN or guarantee that routing and DNS are configured correctly.

After installing the service, check its status in the client. To verify further, press Win + R, enter services.msc, and open Services. Use the project's documentation to confirm the actual service name and status. Don't copy a service name from instructions for another client or remove an unfamiliar Windows service.

Enable TUN only after verifying the basic connection

TUN uses a virtual network interface and routing to capture matching IP traffic, including traffic from some apps that ignore the system proxy. It often requires administrator privileges and involves routing and DNS. First verify that the regular local proxy works, then enable TUN and check the logs for virtual interface creation failures, route errors, or insufficient permissions.

• When using another VPN at the same time, check route priority, DNS settings, and virtual adapters. For initial troubleshooting, use only one traffic-capture solution at a time.
• If devices on your LAN, corporate network access, or Remote Desktop stop working, check whether internal network ranges are being sent through the proxy by mistake. Don't use Global mode long-term to hide rule problems.
• DNS hijacking in TUN mode only applies to requests that actually take the relevant route. Check browser-encrypted DNS and other VPN DNS policies separately.

Authorize firewall access by program and use case

When Windows Defender Firewall prompts you, verify the core's program path and choose network profiles based on how you use it. If you're only using a loopback proxy on this PC, you generally don't need to open an inbound proxy port to your LAN. To share the proxy with other devices, check the listening address, allow-lan, and the relevant inbound firewall rule.

Don't turn off the entire firewall for testing. Third-party security software or organization policies may also block outbound connections; check their logs. A core upgrade may change the executable path, making existing program rules obsolete. Update the authorized path rather than adding a broad rule that applies to every program.

Common issues: port conflicts, stale proxy settings, and configuration errors

Port in use: identify the process before closing it or changing ports

If the logs show address already in use or a bind error, check which process is listening on the port. The commands below identify the listening address and process ID; they won't terminate the process.

netstat -ano | findstr LISTENING | findstr :7890
Get-NetTCPConnection -LocalPort 7890 -State Listen |
  Select-Object LocalAddress, LocalPort, OwningProcess

Use the PID in the output to find the process in Task Manager's Details tab. If it's an old client or a duplicate core process, exit it normally from its interface first. If another program needs that port, change the client's mixed-proxy port to a value such as 7891, then update the system proxy, terminal proxy variables, and explicit proxy test commands to match.

Windows proxy not working: distinguish app settings from Windows settings

WinHTTP and the user-level system proxy come from different settings. netsh winhttp show proxy displays the WinHTTP configuration, but its output doesn't represent the proxy status of every browser and desktop app. Don't change the machine-wide proxy settings blindly to fix a single program.

No internet after exit: check whether the proxy still points to a closed port

If the client crashes while Windows still points to 127.0.0.1:7890, apps that honor the system proxy may fail to connect. Restart the client to restore the listener, or turn off the manual proxy in Windows settings if you enabled it. Don't delete a proxy script managed by your organization; record its current value and follow your administrator's instructions.

For configuration parsing errors, use the logs to identify the specific field. YAML indentation requires spaces, proxy group references must match existing names, and the current core must support each protocol type. Save the full error, line number, and core version; these details are more useful for troubleshooting than simply reporting that the connection fails.

Start on boot: verify login startup, service startup, and proxy restoration separately

A client's “start on boot” option usually launches its interface after you sign in to Windows. A background service may start before sign-in; these are not the same thing. After enabling startup, also verify that the current configuration loads automatically, the system proxy is restored as expected, and TUN has the required permissions.

1. Enable the startup option provided in the client settings. Don't add multiple startup shortcuts manually.
2. In Windows 11, check Settings → Apps → Startup or the Startup apps tab in Task Manager to make sure the client isn't disabled. If the client uses a service or scheduled task, check it separately using the client's documentation.
3. Exit the client normally and relaunch it. Confirm that the selected configuration, proxy group, and port are still set.
4. Restart Windows and sign in to test a real reboot, not just waking from sleep. Wait for the network connection to come up, then test the local port and destination connection.
5. Check that only one core instance is running and that the tray interface, background service, and active configuration are in sync.

If a subscription update fails after reboot but works manually, the issue may be that Wi-Fi wasn't connected at startup, the system clock hadn't synced, or the subscription wasn't reachable yet. Check the timing and error logs first, then consider a delayed-start or retry option provided by the client. Reinstalling should not be the first step.

Post-setup checklist

• The local listening port is reachable, with no bind errors or repeated core restarts.
• The active configuration matches the subscription, and the proxy group has a working node selected.
• The connection log shows which rule matched each destination and the final outbound.
• The network behaves as expected after a normal exit, and the system proxy doesn't point to a port with no listener.
• The configuration is restored after reboot and sign-in. If you need TUN, separately verify the virtual interface, routes, and DNS.

Following these steps makes it easier to identify later problems as belonging to app proxy settings, core listening, subscription configuration, the node connection, or system traffic routing. For more on rules and subscription maintenance, see the user guides. For additional help with permissions and network issues, see the FAQ.