How to Install Clash on Windows: Firewall, UAC & Proxy Troubleshooting

Before You Install: Check Your System Architecture and Client

Clash clients for Windows typically consist of a graphical interface and a proxy core. The interface handles subscriptions, proxy groups, the system proxy, and service management; the core listens on local ports, matches rules, and establishes connections. Clash Meta later evolved under the name mihomo, but clients built on mihomo do not necessarily share the same menus. When troubleshooting, note the client name and version as well as the core version—not just “Clash.”

This guide uses the Windows 11 Settings paths. Some entry names differ in Windows 10, but the steps for checking local listeners, the system proxy, and permissions are the same. Get a standard system proxy connection working first, then enable TUN if your apps need it. This avoids changing several network paths at once.

Choose an Installer

1. Open Settings → System → About, then check System type under Device specifications. Choose the x64 installer for most x64-based processors. On ARM devices, use the client’s ARM64 package if one is available.
2. Check the platform and architecture on the client download page. An installer and the standalone mihomo core are different downloads; a core archive usually does not include an interface for managing subscriptions.
3. Check the client’s release notes for the minimum supported Windows version, runtime dependencies, and maintenance status. Don’t assume an old Clash for Windows interface guide applies to every newer client.
4. Quit other proxy clients before installing, and note your current proxy and VPN settings. Extract portable clients to a permanent folder; once a service is registered, avoid moving its core files.

First Connection: Import a Config and Establish a Working Route

After installation, import a valid subscription or local YAML config. Subscription URLs may contain credentials, so don’t share them in public groups or screenshots. Once imported, make sure the config is active and proxy groups contain selectable nodes. A “Subscription updated” message alone does not confirm that the core loaded successfully.

1. Import the config from the client’s subscription or configuration page and activate it. Check the logs for YAML parsing errors, unknown fields, or failed downloads of rule providers.
2. Select rule mode on the proxy page, then choose a node in the proxy group actually referenced by your rules. Changing a group that no rule uses won’t affect the route for that request.
3. Make sure the core is running and note the actual HTTP or mixed-proxy port. The examples below use 127.0.0.1:7890; this is not the default for every client.
4. Enable the system proxy in the client, visit the site you want to test in a browser, then check the connection list for the matched rule, proxy group, and exit node.

If the client generates the config, change listener settings in the client or through a supported override feature. Direct edits to cached subscription files may be overwritten during the next update. The following mihomo local-listener example does not include nodes or routing rules, so it is not a complete configuration for internet access:

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

A mixed port accepts both HTTP and SOCKS proxy traffic. For local use, keep the listener bound to loopback and disable LAN access. Don’t bind to all interfaces to fix a browser connection, and never expose the proxy port to the public internet.

Isolate the Problem with an Explicit Proxy

Run the following command in PowerShell. It specifies curl.exe to avoid differences caused by the same-name alias in Windows PowerShell. The example URL is for connectivity testing only and says nothing about access quality for other sites.

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

• TcpTestSucceeded : True only confirms that a local TCP connection can be established; it does not prove the remote node is working.
• If the explicit proxy returns an HTTP response but the browser fails, check the system proxy, browser extensions, and app-specific settings first.
• If the connection to 127.0.0.1:7890 fails, check the port and core status first. There’s no need to switch remote nodes straight away.
• If the local port connects but the request later fails with a TLS error or remote timeout, check the node, rules, system time, and client logs. Don’t make certificate verification bypasses your go-to fix.

UAC and Service Mode: Grant Only the Permissions You Need

A standard local proxy listener usually doesn’t require administrator privileges. UAC may appear when installing to a protected directory, registering a system service, setting up a virtual network adapter, or changing routes. UAC confirms a request for elevated permissions; it does not grant network access. Clicking Yes won’t configure the firewall or select a node for you.

Install the Service and Verify Its Status

1. Find the service mode or background service option in the client’s settings. Menu names vary by client; first make sure the install action comes from the client itself.
2. After clicking Install service, check the program path and publisher shown in the UAC prompt. Cancel if the path looks wrong or the source is unfamiliar.
3. Press Win + R, enter services.msc, and find the service registered by the client. Check its status and executable path. Service names vary between clients.
4. Return to the client and check the service status. If you plan to enable TUN, also check the virtual interface and core logs—don’t rely only on a message saying the service was installed successfully.

If you see “Access denied,” first confirm that the service installation was successfully elevated. If the service file is missing or the service stops immediately, check whether the portable folder was moved, whether security software quarantined a file, and whether the existing service still points to an old path. Prefer uninstalling the old service through the client’s service manager before reinstalling it. Don’t guess the service name and run a deletion command.

System Proxy: Check Windows, Browser, and Command-Line Settings Separately

In Windows 11, go to Settings → Network & internet → Proxy. Under Manual proxy setup, check that the address and port match the client. In this example, use 127.0.0.1 and port 7890. If the client uses PAC auto-configuration, check Use setup script and the script URL instead of layering a manual proxy on top.

Edge and Chrome usually follow the system proxy, but extensions, launch arguments, and organization policies can change their behavior. Firefox can also use a separate proxy under Settings → General → Network Settings. If only one browser fails, check that browser’s proxy settings first. Don’t change the core, DNS, and firewall all at once.

Check WinHTTP and Environment Variables Separately

netsh winhttp show proxy
Get-ChildItem Env: | Where-Object Name -Match '^(HTTP_PROXY|HTTPS_PROXY|ALL_PROXY|NO_PROXY)$'

netsh winhttp show proxy checks WinHTTP settings; it does not show the current-user system proxy used by browsers. A Direct access result does not mean the client’s system proxy switch is broken. Some developer tools read HTTP_PROXY, HTTPS_PROXY, or ALL_PROXY; others use their own configuration files.

Don’t import the current user’s proxy settings into WinHTTP until you know how the app gets its proxy settings. Background services may run under another account, and changing system-wide settings can affect other software. Identify the failing process first, then check its proxy documentation and account.

All Browsers Lose Internet Access After You Quit the Client

First check for a stale proxy setting: the core has stopped, but Windows still points to the local proxy port. Reopen the client and turn off the system proxy normally, or disable the manual proxy or script you configured in Windows. Don’t remove an organization-managed PAC script without approval. Once connectivity is restored, test a direct connection before starting the client again.

Port Conflicts: Find the Listening Process and Resolve Config Conflicts

The log message address already in use usually indicates a listener conflict, not high latency on the remote node. Check the local port and identify the process by PID before considering a reinstall.

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

netstat -ano | findstr ":7890"

The first command lists TCP listeners on the specified port only. The second may also show other connections, so check the local address column and connection state. Once you have the PID, find the process under Task Manager → Details. If PID isn’t shown, right-click a column heading and select it.

• If another proxy client is using the port, quit it from its system tray menu and stop any background service it starts automatically.
• If another instance of the current client’s core is using the port, check whether the portable and installed versions are both running, or whether service mode and a manually started core have started duplicate instances.
• If another essential program needs the port, change the local proxy port to an unused one, such as 7891, then update the system proxy and any in-app proxy settings to match.

Don’t change the port in YAML and leave the old value in Windows. If you see access denied but no process is listening, a security policy or system-reserved port may be involved; it isn’t necessarily a process conflict. Check the exact error and system policies instead of repeatedly terminating unknown processes.

Firewall and Security Software: Identify What Was Blocked

Windows Firewall prompts concern whether an app can communicate on different network profiles. The client interface, proxy core, and background service may be separate executables. Allowing only the interface does not ensure the core has the right rule. At the same time, a loopback proxy used only on your PC does not need an inbound port opened to public networks.

Investigate Blocks Based on Evidence

1. Open Windows Security → Virus & threat protection → Protection history. Check the event time, affected file path, and detection name.
2. Confirm where the file came from and whether it belongs to the current client installation directory. If you’re still unsure, keep the record and ask the client maintainer or security software vendor to investigate.
3. Press Win + R, enter wf.msc, and check Windows Defender Firewall with Advanced Security for outbound rules targeting the current core path and any explicit block rules.
4. If you need to change a rule, limit it to the specific program, direction, and network profile. If a core update changes the file path, verify the rule target again.

Explicit block rules may take precedence over allow rules, so adding an allow rule alone may not work. Third-party security software may also have its own network filtering module; check its event log. Don’t default to disabling all protection, excluding the entire download folder, or opening every port.

UWP Loopback: Only Fix Apps That Are Actually Restricted

Some apps running in an AppContainer cannot connect to a local loopback proxy the way regular desktop apps can. You may see browsers work while a particular Store app fails. Not every app installed from Microsoft Store runs in this way, and not every app follows the system proxy. Confirm the app type and check its failure logs first.

Open PowerShell as an administrator and check existing loopback exemptions and locally installed package information. The example below checks a Microsoft Store package. If the query returns no results, don’t keep trying package names blindly.

CheckNetIsolation.exe LoopbackExempt -s
Get-AppxPackage -Name Microsoft.WindowsStore |
  Select-Object Name, PackageFamilyName

Once you’ve confirmed the package is the one you need to handle, use a variable to get its actual package family name for the current user. Don’t use the package full name or installation directory in its place:

$app = Get-AppxPackage -Name Microsoft.WindowsStore
if ($app) {
    CheckNetIsolation.exe LoopbackExempt -a "-n=$($app.PackageFamilyName)"
}

When done, close and reopen the target app, then check whether its requests appear in the client. To undo the change, remove the exemption for the same package family name:

$app = Get-AppxPackage -Name Microsoft.WindowsStore
if ($app) {
    CheckNetIsolation.exe LoopbackExempt -d "-n=$($app.PackageFamilyName)"
}

A loopback exemption only changes whether the target app can access local loopback; it does not configure a proxy, fix a subscription, or change routing rules. If the client includes a loopback management tool, select only the apps that need access—don’t exempt every package. TUN can sometimes change an app’s traffic path, but it is not a universal fix for Store apps.

TUN and DNS: Expand Traffic Capture Only After Basic Connectivity Works

Consider TUN only if explicit proxy tests and the browser’s system proxy both work, but games, command-line tools, or apps without proxy settings still connect directly. mihomo’s TUN coverage depends on the virtual interface, routes, exclusions, and DNS settings. Turning on a switch does not guarantee that all traffic will be captured.

• Make sure the service or permissions required by the client are ready before enabling TUN. Check the logs for virtual interface creation and routing errors.
• Check for a corporate VPN, other virtual network adapters, and proxy tools running at the same time. Multiple automatic routing setups may compete for the default route, so test one change at a time.
• Check the connection list for the target app and review its rule and exit node. If there’s no connection entry for the app, investigate the traffic capture path before changing proxy groups.
• If a domain fails but a known IP is reachable, check DNS next. Run Resolve-DnsName example.com to inspect system resolution, but this alone cannot confirm that the core’s internal DNS is working.

Don’t enter a public DNS address everywhere as a one-size-fits-all fix. System DNS, core DNS, proxy node hostname resolution, and browser Secure DNS may use different paths. Record the original values before making changes, change one setting at a time, and check whether the core reports DNS timeouts or an unreachable upstream. For TUN and routing settings, consult the cross-platform installation guide for the relevant platform.

Narrow Down the Troubleshooting Steps by Symptom

When reporting an issue, include your Windows version and architecture, client and core versions, when the problem started, the listening port, explicit proxy test results, and relevant logs from around that time. Remove subscription URLs, authentication tokens, node passwords, and personal domain names before sharing. Change one setting at a time to isolate permissions, listeners, rules, and network routing.