1. Project status: CFW is discontinued

Clash for Windows is a graphical client for the Clash proxy core. It does not provide proxy servers and is not an anonymity network or a complete VPN service. The original project was discontinued in November 2023. Its final public release was 0.20.39, and the original GitHub repository is no longer available.

Packages advertised as a “2026 CFW release,” “0.20.39.x,” or an “Opt build” must not be treated as official Fndroid releases. The legacy client no longer receives upstream maintenance, and the original distribution channel cannot verify random mirrors. New deployments should prefer a maintained mihomo-based client. This guide primarily serves people who already use CFW or maintain an existing configuration.

Legacy CFW’s Clash/Premium core, Clash.Meta, mihomo, and third-party forks do not share identical configuration fields. Do not paste newer options such as respect-rules, strict-route, or newer stacks into an old CFW profile without checking compatibility.

2. Four concepts that must not be confused

A useful configuration separates four layers: how an application reaches the core, which outbound the core chooses, how DNS is resolved, and what happens after a failure. Enabling one switch proves nothing about the other layers.

  • System Proxy configures supported applications to use a local endpoint. Some terminals, games, UDP applications and packaged apps may ignore it.
  • TUN captures more traffic, but routing and rules still decide whether that traffic uses a proxy. It is not a guarantee by itself.
  • Global only handles traffic that has already entered the core. It cannot capture an application bypassing Clash, and GLOBAL must select a real node rather than DIRECT.
  • Web traffic can use a proxy while DNS still goes to an ISP, router, another interface or browser-managed DoH.
Application
   │
   │  1. System Proxy: the app sends traffic to a local proxy
   │  2. TUN: a virtual interface captures network-layer traffic
   ▼
Clash core
   │
   │  3. Rule / Global / Direct: selects the outbound
   │  4. DNS: determines where and how names are resolved
   ▼
DIRECT / Proxy node / REJECT
   │
   ▼
Destination

3. Privacy boundaries: what CFW can and cannot hide

In this guide, “leak prevention” means reducing unintended network and address exposure, not achieving absolute anonymity. If precise location must be protected, also review operating-system location settings, browser permissions and account information rather than merely changing nodes.

  • Destination websites normally see the proxy exit IP when the entire request uses the proxy, not the original residential or office public IP.
  • The proxy provider can normally see the original public IP because it receives the connection. CFW cannot hide that address from the provider.
  • A local network or ISP may still see the proxy endpoint, timing and traffic metadata. Visibility of content depends on the protocol and encryption.
  • DoH and DoT encrypt DNS transport, but a directly contacted resolver may still see the source IP and queried names. Encryption is not anonymity.
  • Accounts, cookies, language, time zone, browser fingerprints, location permission and Wi-Fi-based location can still reveal identity or location.

4. Beginner quick start

A remote profile can define nodes, DIRECT rules, DNS, the final MATCH, TUN and Fake IP. An untrusted profile may intentionally route some traffic directly, so its source matters as much as the node provider. Back up personal changes before updating a remote profile.

  • Import a trusted HTTPS subscription or local YAML file in Profiles. A subscription URL often contains an account token and must not appear in screenshots or public logs.
  • Select the profile, then choose Rule mode and a real proxy node in Proxies.
  • Enable General → System Proxy and verify connectivity and the exit IP in a browser.
  • Install Service Mode and enable TUN only when broader desktop, terminal or UDP coverage is needed.
  • Keep Allow LAN off. Local applications using 127.0.0.1 do not need LAN access.
  • Start with Windows only launches CFW; it does not validate the profile, node, DNS or leak-prevention state.

5. Choosing between System Proxy and TUN

For ordinary browsing with good compatibility, System Proxy plus Rule mode is usually sufficient. Use TUN when terminals, games, chat applications or programs that ignore system proxy settings must reach Clash. Enabling both does not create “double encryption” and can make troubleshooting harder.

  • Install the service under General → Service Mode → Manage and approve the Windows prompt.
  • Verify Service Mode before enabling TUN Mode. The legacy documentation commonly used gVisor for compatibility.
  • Do not experiment with legacy TAP and TUN at the same time. Restore a known-good configuration instead of disabling the entire Windows firewall.
  • In Rule mode, check for DIRECT matches, the final MATCH and public destinations in the system-proxy bypass list.
  • For a controlled single-exit test, temporarily select Global with a real node, then decide whether to return to Rule mode.

6. A legacy CFW DNS/TUN example and its limits

This example illustrates legacy CFW Mixin syntax. Back up and merge it into a copy of the existing configuration rather than replacing a working profile or pasting it into current mihomo. CFW’s override priority is Mixin > TUN Mode settings > Profile, so do not maintain the same fields in three places.

  • Fake IP returns reserved addresses to applications while the core maintains domain mappings. It is not encryption or anonymity.
  • Merge fake-ip-filter with the existing list for LAN and system services that require real addresses.
  • dns.ipv6: false suppresses AAAA answers; it does not disable IPv6 in Windows.
  • The dns-hijack value shown here is legacy CFW syntax and is not universal across clients.
  • DoH/DoT encrypts upstream transport but does not prove that legacy CFW sends upstream DNS through a node. If the resolver must not see the original IP, legacy CFW is not a reliable single-tool solution.
mixin:
  dns:
    enable: true
    enhanced-mode: fake-ip
    fake-ip-range: 198.18.0.1/16
    fake-ip-filter:
      - "*.lan"
      - "localhost"
      - "dns.msftncsi.com"
      - "www.msftncsi.com"
      - "www.msftconnecttest.com"
    nameserver:
      - "https://1.1.1.1/dns-query"
      - "tls://1.0.0.1:853"
    ipv6: false
  tun:
    enable: true
    stack: gvisor
    dns-hijack:
      - "198.18.0.2:53"
    auto-route: true
    auto-detect-interface: true

7. Browser DoH, IPv6, WebRTC, QUIC and kill switches

  • Browser secure DNS: only consider disabling it after TUN and DNS hijacking are verified, so Clash can resolve names consistently. Do not disable DoH before DNS capture works.
  • IPv6: the CFW switch is not an operating-system kill switch. With public IPv6 on the physical network and an IPv4-only tunnel, IPv6 destinations may still see the original address. Capture it fully or deliberately restrict and retest it.
  • WebRTC: STUN may bypass a conventional application proxy and expose additional addresses. Chromium’s disable_non_proxied_udp can help in strict scenarios, but may degrade or break voice and video calls.
  • QUIC and HTTP/3 use UDP. Do not assume failure always produces a safe TCP fallback. Verify the path or temporarily disable QUIC through a supported browser policy.
  • Kill switch: CFW’s TUN toggle is not a verified fail-closed mechanism. Crashes, sleep, network changes, profile updates and other VPNs can create unintended paths.
  • A .local mDNS candidate in a modern browser does not automatically prove a public-IP leak. Focus on original public IPv4 or IPv6 candidates.

8. General and Proxies settings explained

  • Port: the local mixed proxy endpoint. Use the value actually displayed rather than assuming 7890.
  • Allow LAN: lets other LAN devices use the local proxy. Keep it off in the privacy baseline.
  • Log Level: Info is suitable for normal use and Debug for troubleshooting. Redact domains, IPs, process paths and subscription data before sharing logs.
  • IPv6: controls core behavior, not the operating system’s entire IPv6 stack.
  • Home Directory: contains configuration, logs and caches. Review it before sharing.
  • GeoIP Database: supports GEOIP rules; updating it does not update nodes or the core.
  • UWP Loopback: removes loopback restrictions for specific packaged apps. Apply it only to apps that need it.
  • Service Mode: provides privileged support for TUN; it is not a proxy service.
  • Mixin: injects shared fields into profiles and is useful for preserving personal DNS settings.
  • Group types include select for manual choice, url-test for measured selection, fallback for failover and load-balance for distributing connections. Low latency is not high bandwidth.

9. Profiles, Mixin and rule syntax

Profiles contain nodes, groups and rules. Remote updates can overwrite manual edits, so use Mixin, Diff or a local copy for long-term customization. Mixin JavaScript and parsers are active code and should only run from trusted sources.

  • Rules are evaluated in order and MATCH belongs at the end.
  • Proxy must be replaced with the exact name of an existing proxy group.
  • PROCESS-NAME normally requires the full Windows process name, including .exe.
  • no-resolve prevents additional DNS resolution for rule matching; it is not a privacy switch.
  • REJECT blocks a connection rather than hiding its address through a proxy.
rules:
  - DOMAIN-SUFFIX,example.com,Proxy
  - PROCESS-NAME,git.exe,Proxy
  - IP-CIDR,203.0.113.0/24,Proxy,no-resolve
  - MATCH,DIRECT

10. Using Logs, Connections and Settings for verification

  • Logs reveal profile-loading, DNS, node-handshake and TUN-startup errors.
  • Connections shows Process Path, the matching Rule and the outbound Chains. A chain ending in DIRECT bypasses the node.
  • Inbound types distinguish HTTP, SOCKS5 and TUN; Network distinguishes TCP and UDP.
  • Close old connections after changing nodes, modes or profiles so an old TCP connection does not keep using the previous exit.
  • Break When Proxy Change / Profile Change / Mode Change in Settings can reduce stale-connection confusion.
  • Core Secret and a random controller port protect the local control API. Do not expose an unauthenticated API on 0.0.0.0.

11. Making CFW work with different applications

Chrome and Edge normally follow the system proxy, but check proxy extensions, browser DoH, WebRTC and QUIC. Firefox can use system proxy settings or manually configured SOCKS v5 with remote DNS. The IDE, its plugins, language servers and integrated terminal may maintain separate proxy settings.

For packaged Windows apps, test TUN first and use UWP Loopback only for specific applications that need an exemption. Games, voice applications and emulators often require TUN with UDP support; a working launcher does not prove the game itself is proxied. WSL, Docker and virtual machines have separate network stacks, and 127.0.0.1 inside a container is not normally the CFW endpoint on Windows.

# Temporary settings for the current PowerShell session
$env:HTTP_PROXY = "http://127.0.0.1:7890"
$env:HTTPS_PROXY = "http://127.0.0.1:7890"

# curl with an explicit HTTP proxy
curl.exe --proxy http://127.0.0.1:7890 https://example.com/

# SOCKS with remote hostname resolution
curl.exe --proxy socks5h://127.0.0.1:7890 https://example.com/

# Configure and remove Git's HTTP(S) proxy
git config --global http.proxy http://127.0.0.1:7890
git config --global --unset http.proxy

# Remove proxy variables from this session
Remove-Item Env:HTTP_PROXY -ErrorAction SilentlyContinue
Remove-Item Env:HTTPS_PROXY -ErrorAction SilentlyContinue

12. Verification and troubleshooting checklist

  • Test IPv4 and IPv6 separately using two independent IP-echo services. An inaccurate geolocation city does not by itself prove a leak.
  • In Connections, verify the process, rule, chain and UDP entries. No entry usually means the application bypassed Clash.
  • Run standard and extended DNS tests, looking for ISP, router or unexpected local resolvers. A public resolver’s IP does not have to match the node IP.
  • Check WebRTC for original public addresses and do not treat .local mDNS names as automatic proof of a public leak.
  • Retest after node changes, profile updates, sleep, Wi-Fi changes, CFW restarts and unexpected TUN shutdowns.
  • If applications regain direct Internet access when CFW stops, the configuration is not fail-closed.
  • If TUN breaks connectivity, check Service Mode, firewall treatment, DNS, competing VPN/TUN clients and the stack. Restore a backup rather than disabling the whole firewall.