Get the system proxy working first, then configure TUN
To set up Clash on Windows, follow this order: install a client → import a subscription → choose a policy → enable the system proxy → check the connection. Once your browser works, enable TUN if needed. Change one thing at a time to pinpoint whether the issue is a bad subscription, an unreachable node, or traffic routing on your PC.
This guide uses the Windows 11 menus as an example. The menu names in graphical clients such as Clash Verge Rev and FlClash may differ; use the toggles shown in your current client for the system proxy, service mode, and TUN. The graphical client manages your configuration, while a core such as mihomo parses it, matches rules, and establishes connections. Check their versions separately.
Choose an installer: architecture, installer, or portable
Check your Windows system architecture
Go to Settings → System → About and check System type. Most Intel and AMD PCs need the x64 build; for ARM devices, choose an ARM64 build if the project provides one. A 64-bit version of Windows does not mean x64 and ARM64 installers are interchangeable.
| Package type | Best for | Notes |
|---|---|---|
| EXE / MSI installer | Everyday desktop use | Follow the setup wizard. Whether a service component is installed depends on the client. |
| Portable ZIP | Manual extraction and launch | Extract all files to a permanent folder first; don't launch the app from inside the archive. |
| Core executable | Command-line use or service deployment | This is not a graphical client; you'll need to provide the configuration and runtime arguments yourself. |
Before launching, shut down older clients
- Turn off the system proxy from the old client's tray menu, then exit the client.
- Pause other VPNs or transparent proxy tools to avoid conflicting changes to routes and DNS.
- Install and launch the new client. Confirm the core starts successfully before importing a configuration.
- If the portable version needs to install a service, move it to a permanent folder first. Moving the folder later may require reinstalling the service.
Clash for Windows is no longer maintained and shouldn't be the default choice for a new installation. If you need to keep using an old configuration, read the client selection guide to check client and core compatibility before migrating your subscription and override settings. Don't copy the entire old client folder over the new installation.
Import a subscription: check its format, activate it, and verify updates
Subscription links are usually generated by your service provider. A client download link is not a subscription link, and neither a sign-in page nor a payment page can be imported as a configuration. Links may contain access credentials, so don't post a full URL, QR code, or configuration file in a public forum when troubleshooting.
- Open the client's Subscription or Profiles page and add a remote configuration.
- Paste a subscription link compatible with Clash or mihomo, download it, and check for parsing errors.
- Select the imported configuration to make it active; having it listed doesn't mean it's in use.
- Expand the policy groups on the Proxies page and select an available node or an auto-select group.
- Set the outbound mode to Rule, then check the logs and connections page.
“Download complete” doesn't mean “configuration active”
A successful download only means the server returned content. That content could also be a sign-in prompt or an error page. If you see a YAML parsing error, an unknown proxy type, or a reference to a missing policy group, fix the configuration first. Toggling the system proxy won't resolve these errors.
- Authentication failed: Check whether the subscription has expired or the link was reset, and make sure you didn't copy any extra spaces.
- Download timed out: Check that the subscription domain resolves. If a broken system proxy is enabled, turn it off and try again.
- Unsupported protocol: Check which core is running, not just the client name, and confirm the provider offers a compatible configuration format.
- Settings disappeared after an update: A remote configuration may have been downloaded over your changes. Save local edits using the override or merge feature supported by your client.
A successful node connectivity test only shows that the test target was reachable at that moment. Whether an app actually uses the proxy depends on the matched rule and connection details; test latency is not download speed.
System proxy: check the address, port, and app support
The system proxy mainly affects apps that follow Windows proxy settings. It doesn't route all device traffic or guarantee that UDP traffic uses the proxy. Leave TUN off, enable System Proxy in the client, then visit a site in your browser and check the client's connections page for the corresponding connection.
Check the proxy address in Windows
In Windows 11, go to Settings → Network & internet → Proxy → Manual proxy setup → Edit. If your client uses a local HTTP or mixed proxy port, the address is usually 127.0.0.1; enter the port shown in the client. Don't enter the external controller port here: for example, 9090 is often used for the control interface, not the proxy.
The following mihomo snippet illustrates what each field means. It isn't a complete subscription and can't replace your current configuration. A graphical client may override the port, so check the runtime configuration and actual listening port.
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
mixed-port accepts HTTP and SOCKS proxy requests on the same port; allow-lan: false restricts access from your local network. If you're using the proxy only on this PC, you don't need to enable LAN access just to browse the web.
Test the proxy endpoint from the command line
curl.exe --proxy http://127.0.0.1:7890 --head --connect-timeout 10 https://www.microsoft.com/
This command explicitly uses the local proxy, helping distinguish an unavailable proxy endpoint from an app that isn't reading the system proxy setting. An HTTP response means this request established basic communication with the target server, but it doesn't prove other nodes or sites are reachable. If the connection is refused, first check that the core is running and the port is correct.
TUN mode: service permissions, DNS, and virtual network adapters
TUN uses a virtual network interface and routing settings to capture traffic, making it useful for apps that don't read system proxy settings. It operates at a different layer from the system proxy: enabling TUN won't fix an unavailable node, and Rule mode still uses rules to decide whether traffic is direct, proxied, or blocked. Actual support depends on the core, client, and configuration.
Enable it step by step, with a way to roll back
- First confirm that the same configuration can reach the target site through the system proxy.
- Find Service Mode or the service installation option in the client settings. If the client uses a background service for elevated permissions, install it and confirm that it's running.
- To test TUN on its own, temporarily turn off the system proxy, then enable TUN Mode. Some clients coordinate these toggles automatically, so check their actual status.
- Check the logs to confirm the virtual interface was created successfully, with no permission errors, route failures, or DNS port conflicts.
- Launch the app you're testing, then check its process, destination address, matched rule, and final outbound in the connections page.
Installing a virtual interface or changing routes usually requires elevated permissions. Some clients handle this through a service; others require launching the client as an administrator. Running every client as an administrator is not a universal requirement. If it still fails after installing the service, check the service status and core logs instead of repeatedly reinstalling the driver.
If sites won't load, check DNS separately
If the logs show a DNS resolution failure, check whether DNS is enabled in the current configuration, whether the upstream resolver is reachable, and whether another VPN is competing to manage DNS. mihomo's Fake-IP and redir-host modes handle DNS differently. Switching modes changes behavior, so don't toggle between them without a reason in the logs.
Use ipconfig /all to view adapter and DNS details, and route print to inspect routes. These commands show system state; they don't prove that every request is going through TUN. A browser's secure DNS may use a separate encrypted resolution path, so check the client's connection logs as well.
If your whole PC loses internet after enabling TUN, turn TUN off first and check whether your normal connection recovers. If it does, check service permissions, DNS, and other virtual adapters one by one. On managed corporate devices, ask your administrator which connection methods are allowed.
Windows Firewall: distinguish outbound connections from inbound LAN access
A local proxy used by a browser on the same PC usually doesn't require an inbound port open to the entire LAN. Windows Firewall commonly allows outbound connections by default, but enterprise policies or security software may impose other restrictions. First identify what's being blocked: outbound traffic from the core, the service process, or access to your local proxy from another LAN device.
Allow access for the right program and network
- Local outbound traffic is blocked: Check your security software's logs and find the path of the core executable that actually initiates the connection. Allowing only the graphical client may not cover a separately run core.
- Stopped working after a client update: If the program folder or executable path changed, update any rules that were configured for the old path.
- Need to share on your LAN: Check the client's Allow LAN setting, listening address, and inbound rules. Opening a firewall port alone isn't enough.
- Using public Wi-Fi: Don't expose the proxy listener to an untrusted network, and be especially cautious about allowing access on the Public profile.
To review detailed rules, press Win + R, run wf.msc, and open Windows Defender Firewall with Advanced Security. Limit inbound rules for LAN sharing to the program or actual port, the Private profile, and trusted source addresses. If you don't need LAN sharing, keep allow-lan: false.
UWP apps and port conflicts: two separate issues
Local loopback restrictions in app containers
Some UWP and other app-container apps may be restricted from using a local loopback proxy, so your browser works while a particular app can't connect. However, not every Microsoft Store app uses an app container, and not every Store app connection problem is caused by loopback restrictions.
Run the following command in an administrator terminal to view existing loopback exemptions. It only displays their status and won't change any app settings:
CheckNetIsolation.exe LoopbackExempt -s
If you need to add an exemption, first confirm the target app's package family name and add it for that app only; don't exempt every package. If your client offers UWP loopback management, select only the apps that need the local proxy. TUN uses a different traffic path, so system-proxy troubleshooting advice may not apply directly.
Port 7890 is in use? Find the process listening on it
If the logs show address already in use or a bind failure, run these two commands in a terminal. The second command uses PID 4321 as an example; replace it with the PID shown by the first command.
netstat -ano -p tcp | findstr ":7890"
tasklist /FI "PID eq 4321"
Look for a record with local port 7890 and state LISTENING. The output may also contain remote ports or similar numbers, so don't assume the port is in use just because you see a matching number. Common causes include an old client still running in the tray, a background service that hasn't stopped, or a second instance of the new client.
Use the relevant app's exit option or stop its service to free the port; don't terminate an unidentified system process. You can also change the proxy port to an unused value, such as 7891, but update the system proxy and any apps configured to use it. Changing the YAML alone while leaving the app's port unchanged will cause connection refusals.
Verify the setup and configure startup
Loading one web page isn't enough to confirm that setup is complete. Follow these checks to catch the most common issues after a routine restart or unexpected exit.
- Check rule routing: Keep Rule mode enabled. Visit destinations that should go direct and through the proxy, then confirm the matched rule and final policy on the connections page.
- Check your apps: Launch the apps that need internet access, not just a browser, and test UDP or other connections where needed.
- Check shutdown: Turn off the system proxy and TUN, then exit the client. Confirm that your normal internet connection still works.
- Check restart: After enabling startup, restart your PC and confirm that the client, configuration, and background service run as expected.
- Check updates: After updating a subscription or core, recheck configuration parsing, ports, TUN status, and critical rules.
Client startup, automatic background service startup, and automatically enabling the system proxy are three separate settings. In Windows 11, Settings → Apps → Startup shows only some startup items; check background services in services.msc as well. Don't create multiple startup tasks, or you may end up with duplicate processes and port conflicts.
When troubleshooting, keep the time of the issue, client and core versions, error logs, and system proxy and TUN status. Remove subscription tokens, authentication details, and node credentials before sharing logs publicly. For basic instructions, see the setup guide. For common connection issues, see the FAQ.