How to Install Clash on Windows: System Proxy, Subscription Setup, and Loopback Troubleshooting

A Clash desktop client on Windows usually consists of the interface, a Clash or Mihomo core, configuration management, and system proxy controls. Installation only confirms that the program can launch. Reliable connectivity also depends on a valid configuration, the selected proxy group, local listening ports, the Windows system proxy, and DNS. Following a consistent order makes problems easier to isolate than repeatedly toggling settings.

Check your system, architecture, and configuration source before installing

First, open “Settings → System → About” and check the system type. Most Intel and AMD PCs should use an x64 build; Windows devices with ARM processors should generally use an ARM64 build. With the wrong architecture, the installer may fail to run, or system translation may cause the core to start incorrectly.

Start from this site's client downloads page, open the relevant project, and choose a Windows client that is still maintained. Menu names vary between clients, but the basics of configuration files, proxy ports, rule modes, and TUN are similar. If another Clash client is already installed on an older PC, note the subscription URL, active policy, and custom rules before migrating. Do not run two programs that both control the system proxy at the same time.

Make sure Windows 10 or Windows 11 has all currently available system updates installed.
Confirm that the target folder is writable, and avoid keeping a portable build in a temporary download directory.
Prepare a valid subscription URL or local YAML configuration file, and verify that its source is trustworthy.
Close proxies, debugging tools, or older clients that are listening on the same ports.
Note the existing system proxy settings, especially any manual proxy address used on a work network.

Install the client and complete the first launch

An installed build usually creates a Start menu entry and places runtime components in the user or application directory; a portable build must be fully extracted first. Do not run it from an archive preview window, because the core, database, and resource files may not load correctly. Keep the installation path stable. If you later enable service mode or startup at login, moving the directory can leave the service pointing to the old location.

Close other Clash clients, then run the installer or extract the portable package.
After the first launch, check that the main interface shows the core status, proxy ports, and configuration pages.
If Windows Firewall asks for network access, allow only the network types required for your actual use. When the proxy is used only on this PC, there is no need to open it to every network just to “make it connect.”
Open the client settings and confirm that the core starts successfully. Check the logs for port conflicts, configuration parse failures, or database read errors.
Keep the system proxy and TUN disabled until the configuration has been imported, then enable features one at a time.

Some clients offer “Service Mode,” an “Administrator Helper,” or “Service Mode.” These components mainly handle network operations that require elevated privileges, especially TUN, routing, and DNS changes. Standard local HTTP, SOCKS, or mixed ports usually do not require the client to run as administrator all the time. If you only need to import a subscription and enable the system proxy, do not treat “always run as administrator” as the default fix.

What to check first when the program will not start

Open Task Manager first and check whether a process with the same name is still running in the background; end the old process and try again. Then inspect the client log directory and Windows Security protection history. If the interface opens but the core repeatedly exits, focus on configuration syntax, port conflicts, the core file path, and runtime-library messages. Reinstalling only the interface usually will not fix a configuration that cannot be parsed.

Import a subscription, update the configuration, and choose a policy

Find the subscription field on the client's Configuration or Profiles page, paste the complete URL, and start the download or import. After a successful import, you should see a configuration name, update time, and available proxy policy groups. Seeing a configuration card does not mean it is active; click it to select it or set it as the current configuration.

Import the subscription and wait for the client to finish parsing it.
Select the newly imported configuration and check the logs for a successful load message.
Open the Proxy or Proxies page and locate the policy groups defined by the configuration.
Choose an available node in groups that require manual selection, or use latency testing as a guide.
Return to the configuration page and run one update to confirm that the subscription can be downloaded again.

Clash policy group names are defined by the configuration provider. Common types include manual selection, automatic latency testing, failover, and load balancing. A latency value reflects one probe between the test address and a node; it does not represent the actual speed of every website. If every test fails, do not immediately assume that the nodes are dead. An inactive subscription, DNS resolution failure, unreachable test address, or incorrect system time can also affect the result.

Rule mode, Global mode, and Direct mode

Rule mode matches traffic from top to bottom against the configured rules and is suitable for everyday use; Global mode typically sends traffic to the selected global policy group and is useful for temporarily testing the proxy path; Direct mode connects directly and can help determine whether the proxy route is causing the problem. You can switch modes briefly while troubleshooting, but restore the mode intended by the configuration after testing.

If importing a subscription produces a YAML parse error, common causes include downloading something that is not a configuration file, copying an incomplete URL, or damaging the indentation while editing locally. YAML uses spaces for nesting and should not contain tabs. The client supports only configuration fields implemented by its core. A Mihomo-oriented configuration may include features that the classic Clash core does not recognize, so check compatibility between the configuration and the current core.

Enable the Windows system proxy and verify the local port

The system proxy works well for browsers and desktop applications that follow Windows proxy settings. After enabling it in the client, Windows usually points the proxy to a local loopback address such as 127.0.0.1, while the port comes from the configuration's HTTP or mixed port. Use the number shown by the current client; do not copy a port from another PC.

You can view the current status under “Settings → Network & Internet → Proxy.” The manual proxy address should match the client's listening details. If the client shows mixed port 7890 but Windows still points to a different port used by an old application, browser requests will not reach the current core. Stale proxy settings left behind after switching clients are a common reason that “the program has exited, but no website will open.”

Do not enable LAN access without a reason

Allow LAN makes the local proxy port listen on the LAN interface so other devices on the same network can use it. Keep it disabled when the proxy is used only on this PC. If sharing is necessary, check the bind address, Windows Firewall rules, and the current network environment to avoid exposing the proxy port on an untrusted public network.

Verify the connection in four layers

Verify connectivity from inside the client outward to the target application instead of relying only on the tray icon. A dependable sequence is configuration load, node route, local proxy, then the system application. Each step has a clear result, making the failure scope easier to narrow down.

Configuration layer: the current configuration is selected, the logs show no parse failure, and the proxy policy group has a definite selection.
Route layer: node latency tests return results, or an actual connection record appears in Global mode.
Local proxy layer: the client shows an HTTP, SOCKS, or mixed port listening, with no port-conflict error.
Application layer: after enabling the system proxy, open a test page and find the matching domain and policy in the connection list or logs.

In the logs, DIRECT means the connection went direct according to the rules, a policy group name means the request was handed to that group, and REJECT usually means the rules actively denied it. If a target domain has a connection record but still fails to load, check the selected node, DNS result, and remote response. If there is no record at all, the problem is more likely in the system proxy, the application's proxy settings, or the traffic covered by TUN.

Command-line tools do not necessarily read the Windows system proxy automatically. Support varies between tool versions and distribution methods. During testing, explicitly specify the proxy address shown by the client so that a direct command-line failure is not mistaken for a Clash problem:

curl.exe --proxy http://127.0.0.1:local-HTTP-port https://example.com/

Replace “local-HTTP-port” with the number currently shown by the client. If you are using a SOCKS port, use the SOCKS option supported by the tool; do not enter a SOCKS port as an HTTP port.

Troubleshoot loopback access for Microsoft Store and UWP apps

Some packaged applications are subject to Windows AppContainer network isolation and cannot directly access a proxy running on 127.0.0.1. A typical symptom is that a browser can connect through the system proxy while a Microsoft Store app, older UWP app, or other container-restricted component remains offline; the Clash logs also show no requests from that app.

Prefer the client's “UWP Loopback,” “Loopback Exemption,” or similar management tool. It usually lists installed applications. Select only the apps that genuinely need access to the local proxy and save the changes. Add only affected, clearly identified packages; do not select every package at once, because a loopback exemption changes the network-isolation boundary for the selected apps.

View loopback exemptions with system commands

From an elevated Command Prompt, first view the existing exemption list:

CheckNetIsolation LoopbackExempt -s

If the client has no graphical tool, first obtain the target app's exact Package Family Name from the system, then add it by name:

CheckNetIsolation LoopbackExempt -a -n=app-PackageFamilyName

After resolving the issue, remove the corresponding entry using the same package family name:

CheckNetIsolation LoopbackExempt -d -n=app-PackageFamilyName

Do not enter the app's display name or copy a package name arbitrarily from another PC. If the app does not read the Windows system proxy, adding a loopback exemption may still not make it use Clash automatically. Check the app's proxy behavior or use TUN to capture the traffic.

TUN mode, administrator privileges, and DNS

TUN mode uses a virtual network interface and routing rules to capture more traffic, making it useful for programs that ignore the system proxy. Modern Mihomo cores can use TUN on Windows together with the client's service component, but TUN is not a universal fix. First make sure the standard system-proxy path works so that TUN issues can be separated from subscription and node problems.

After enabling TUN, the client may require a service, virtual network adapter, or administrator privileges to complete initialization. If the logs report failure to create the interface, set routes, or obtain permission, install the service component according to the client's instructions and restart it. Do not run multiple VPNs, virtual adapter managers, or network-acceleration tools during comparison testing; they may change the default route, interface priority, and DNS.

Why DNS can make a connection look successful but still fail

Resolving the node's domain often happens before the proxy connection is established, and both rule matching and target access depend on DNS. If the node domain cannot be resolved, DNS requests are intercepted by another application, or the TUN DNS hijacking settings conflict with the system environment, policies and ports may look normal while pages time out.

Check the logs for DNS timeout, lookup failed, or nameserver errors.
Confirm that the Windows time, date, and time zone are correct to avoid simultaneous encrypted-DNS and HTTPS errors.
Temporarily exit other network software that rewrites DNS or routes, then restart the client.
If the configuration uses fake-ip, check whether fake-ip-filter covers the relevant domains when LAN devices or special applications behave unexpectedly.
Do not change DNS, TUN, rule mode, and nodes at the same time if you do not understand the configuration; otherwise you will not know which change took effect.

Some clients can enable the system proxy and TUN together, but during troubleshooting it is better to test one traffic-capture method at a time. If the system proxy works but TUN fails, focus on service permissions, the virtual interface, routes, and DNS. If both fail, return to configuration loading, node status, and local ports.

A fixed troubleshooting order for common Windows issues

No websites open after enabling the system proxy

Turn off the system proxy immediately and check whether direct access recovers. Then verify that the client is still running, the local proxy port is listening, and the address and port in Windows settings match. If the client exited unexpectedly but Windows retained a manual proxy, disable it on the system proxy page and restart the client. A port-conflict error usually means another process is using the same port; close the conflicting program or change the port if the configuration allows it.

A node has latency, but web pages time out

A successful latency test only means that a specific test request received a response. Check that the current policy group actually selected this node, then inspect the rule matched by the target domain. If the domain was assigned to a different policy group, changing the global node will not affect it. Also check fallback rules, direct rules, and the system time required by the node protocol.

Subscription updates fail, but the old configuration still works

This usually means the current configuration is cached locally while the update URL is temporarily unreachable. Check that the subscription URL is complete, the account is still valid, and the update request is not being routed incorrectly by the current rules. Retry with the system proxy disabled, or follow the provider's instructions to decide whether update requests should go direct or through the proxy. Do not delete a working old configuration; export necessary local changes first.

The proxy behaves unexpectedly after restarting the PC

Check the order of client startup, core startup, and automatic system-proxy setup. If the program starts slowly, Windows may temporarily retain the previous proxy address while the corresponding port is not yet listening. After reaching the desktop, check the tray process and core status. If automatic capture is unnecessary, disable automatic system-proxy setup and enable it manually after the client has fully started.

Only LAN addresses or printers are unreachable

First determine whether the problem occurs with the system proxy or TUN. In system-proxy mode, check the Windows proxy bypass list and the configuration's direct rules for LAN traffic. In TUN mode, also check private-address routing, interface priority, and strict-route settings. Common private ranges include 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16, but actual handling should follow the current LAN addresses and configuration rules.

Maintenance checklist after installation

Once the client is stable, there is no need to change every option frequently. Keep one reproducible setup so comparisons are possible when something goes wrong. After a subscription update, check whether policy groups were reset. Put custom rules in the override or extension area explicitly supported by the client, rather than editing a subscription file that will be replaced during the next update.

Update the client and the core you use regularly, and read the release notes for each project.
After updating the subscription, confirm that the current configuration, policy groups, and rule mode still match your expectations.
Keep necessary configuration backups, but remove subscription tokens and account details before sharing them.
Before switching clients, disable the old client's system proxy, TUN, and background services.
When troubleshooting, record the time, error text, matched rule, and port status—not just “it won't connect.”

For more on rules, DNS, policy groups, and configuration fields, read the site's Clash User Guide. For interface-based setup instructions on other platforms, visit the Installation and Configuration Guide. On Windows, the priority is not enabling every feature at once. First establish a verifiable path through the configuration, node, local port, and system proxy, then add loopback exemptions or TUN as needed.