What “AnyConnect Drops When Clash Starts” Usually Means

Cisco AnyConnect is not “just another app.” It installs kernel drivers, virtual interfaces, and often a split tunnel or full tunnel policy that expects to own default routes and sometimes DNS. Clash—especially in TUN mode—does the same class of work at a different layer: it steers flows through policy groups, may rewrite resolver behavior through DNS hijack, and can reorder which adapter wins when two stacks both think they are the smartest path to the internet. When both are active, the user-visible story compresses into a few rude phrases: handshake failures, reconnect storms, captive-portal loops, or intranet 10.0.0.0/8 prefixes that suddenly look “down” even though Wi-Fi is fine.

Before you touch knobs at random, separate three buckets. First, routing table conflicts—0.0.0.0/0 or more-specific corporate routes pointing at the wrong interface after Clash inserts its own metrics. Second, DNS inconsistency—AnyConnect pushes corporate resolvers while Clash’s fake-ip stack answers differently for the same name, so the VPN client validates one address family while your browser or helper resolves another. Third, policy mistakes inside Clash itself—your catch-all MATCH sends the VPN control plane through an overseas node, or a blocklist steals a hostname the enterprise client still needs. The fix order below is deliberate: prove DIRECT coverage for VPN infrastructure before you chase exotic kernel bugs. For the conceptual difference between a consumer “VPN app” and a local policy router like Clash, re-read Clash versus VPN: a deeper comparison—enterprise SSL VPN adds a fourth actor (security posture, always-on policies) that consumer marketing rarely mentions.

If symptoms appear only after you enable TUN, treat that as signal, not coincidence. TUN pulls more processes into the same routing story; it is powerful and conflict-prone. Skim the Clash TUN mode deep dive before you stack TUN on top of another virtual adapter. You are looking for coexistence, not “who wins forever.”

ℹ Evidence first: capture one failing window with AnyConnect logs, Clash connection logs, and a snapshot of routes (netstat -rn on macOS, route print on Windows). Guessing between “bad node” and “split tunnel got unpicked” wastes hours.

Two Tunnels, One Routing Table: Where Conflicts Hide

Think of your laptop as a switchboard, not a tube. Cisco AnyConnect may install routes to your concentrator, advertise corporate RFC1918 islands, and sometimes pin default egress through the tunnel depending on head-end policy. Clash adds policy routing via its core and—when configured—user-space or kernel forwarding rules that send “interesting” destinations toward proxy chains. The OS still maintains a single coherent routing table (often multiple tables on Linux, or interface metrics on Windows). When two stacks fight over the same prefix, the symptom is rarely a polite error string; it is silent packet hairpins, MTU black holes, or TLS alerts that look like “bad network day.”

System proxy mode is gentler with coexistence because fewer binaries inherit the redirection, but well-meaning “global” YAML still routes DNS through Clash. TUN mode is stricter about capture and therefore more likely to intersect with the VPN client’s control traffic. Neither mode is automatically “safe” for enterprise VPN; the decisive question is whether flows to the VPN gateway, OCSP/CRL endpoints, identity hosts, and internal name servers consistently hit DIRECT before any broad GEOIP shortcut or trailing MATCH line sends them elsewhere. The discipline is the same as other advanced topics we document in rule routing best practices: explicit allow-lists for infrastructure you depend on, then defaults.

IPv6 deserves an explicit mention. Dual-stack laptops happily use AAAA answers until a tunnel policy assumes IPv4-only split routes. If AnyConnect pushes IPv6 while Clash reshapes only IPv4 paths, you can see “connected” banners with unusable internal sites. Pair this walkthrough with IPv6 dual-stack DNS and DIRECT verification when your org actually runs v6 on the remote access network.

DIRECT Split Whitelist: VPN Gateways and Corporate Prefixes

Start YAML hygiene at the top of your rules: section with a small, well-commented split whitelist that pins enterprise VPN plumbing to DIRECT. You do not need perfection on day one—you need coverage for the concentrator hostname your client dials, certificate validation CDNs you observe in logs, and the RFC1918 or RFC6598 ranges your intranet uses. Many teams add IP-CIDR lines for those prefixes ahead of any geolocation shortcuts. If your employer publishes a list of VPN-related hostnames, prefer explicit DOMAIN or DOMAIN-SUFFIX entries for those names before you widen blindly.

The fragment below is illustrative, not universal. Replace hostnames and CIDRs with values from your environment; remove lines you cannot justify. Keep the whitelist above aggressive blocklists and above GEOIP rules that might otherwise steal VPN control-plane traffic.

Illustrative rules fragment (VPN coexistence)

rules:
  # VPN control plane — replace with your real gateway / identity hosts
  - DOMAIN,vpn.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,DIRECT
  # Corporate internal IPv4 islands observed after connect
  - IP-CIDR,10.0.0.0/8,DIRECT
  - IP-CIDR,172.16.0.0/12,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT
  # Optional: certificate / OCSP CDNs you see in AnyConnect traces
  # - DOMAIN-SUFFIX,digicert.com,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

Notice the sequencing discipline: infrastructure first, geography shortcuts next, philosophy last. A common foot-gun is a remote rule provider that injects a broad IP-CIDR or DOMAIN-KEYWORD line above your VPN entries after an automatic refresh—suddenly Cisco AnyConnect reconnects “for no reason.” After every subscription refresh, diff the merged config the same way you would after any provider update described in subscription and node maintenance.

Step 1 — Pick a Coherent Capture Mode (TUN vs System Proxy)

If you only need browsers and a handful of CLI tools to respect Clash, system proxy mode plus careful application support is often the least invasive coexistence path with enterprise VPN clients. If stubborn binaries ignore OS proxy settings but must still share a machine with AnyConnect, TUN becomes attractive—and riskier. Before flipping TUN on for eight hours of meetings, validate that your whitelist truly covers the VPN client’s control flows; then watch metrics for interface binding order after sleep/wake.

When you toggle modes, stale OS proxy flags are a frequent confounder. Windows and macOS can retain PAC or manual proxy entries after a GUI crash. If “everything feels haunted” after quitting Clash, walk through no internet after exiting Clash to clear residues before you blame Cisco AnyConnect for a problem that is only orphaned proxy settings.

GUI cores differ in how clearly they expose per-flow decisions. If you routinely debug corporate stacks, invest time in choosing the right Clash client so live connections, DNS mode, and matched rules stay visible instead of buried.

Step 2 — DNS Hijack, Split DNS, and Fake-IP Alignment

Many SSL VPN deployments push split-DNS domains through the tunnel: internal corp.local names resolve only on the enterprise resolver. If Clash intercepts all UDP/53 or applies DNS hijack without forwarding those queries correctly, AnyConnect can look “connected” while hostname lookups for private services return NXDOMAIN or public parking pages. Under fake-ip, the mismatch can be even stranger: applications receive fast synthetic answers while policy and real destinations disagree.

Operationally, enumerate the suffixes your employer expects to resolve across the tunnel and give them a nameserver policy in Clash DNS that forwards to the VPN-provided resolver—or mark them direct if you intentionally want the OS stack to answer without fake-ip meddling. For Mihomo-class DNS stacks, the interplay of fallback, filters, and fake-ip is easy to misconfigure; read Clash Meta DNS: nameserver fallback and fake-ip filter before you assume “DNS leak” is the whole story. Often it is policy disagreement, not leakage.

Browser DNS over HTTPS is another parallel resolver. It can bypass split-DNS assumptions that the VPN client thought it enforced. For debugging, temporarily align to a single coherent resolver story, reproduce, then reintroduce privacy features deliberately.

Step 3 — Rule Order, Policy Groups, and the MATCH Line

Clash evaluates rules: sequentially. That means your split whitelist is not “anywhere in the file,” it is a race position. Geolocation shortcuts like GEOIP,CN,DIRECT can be correct for consumer sites yet disastrous if they sit above a line that should have caught the VPN gateway in another country. Likewise, aggressive MATCH,PROXY defaults are unforgiving: the moment a new OCSP host appears in traces, your default philosophy decides whether TLS succeeds or mysteriously stalls.

Policy groups still matter: even when a hostname hits DIRECT, upstream features such as url-test selectors affect unrelated traffic and can starve CPU on busy laptops. Keep enterprise-critical paths boring—DIRECT should mean direct, not “indirectly direct after three nested selectors,” unless you truly understand the latency budget. When you need a refresher on how selectors interact with rules, revisit policy groups, URL-Test, and fallback so maintenance windows do not turn into accidental routing churn during a VPN session.

Step 4 — Verify the OS Routing Table and Interface Metrics

After YAML looks sane, confirm what the OS actually does. On macOS, netstat -rn plus scutil --dns tells you which interface owns default and which resolver lists apply to which search domain. On Windows, route print and ipconfig /all expose interface metrics and DNS suffix search lists—AnyConnect frequently adds those explicitly. On Linux NetworkManager or systemd-networkd setups, split routes may live in policy tables you will not see if you only glance at ip route without table qualifiers.

What you are hunting is subtle: two defaults with different metrics, overlapping 0.0.0.0/0 routes, or a more-specific corporate route that disappeared when Clash adjusted adapter up/down events. If Wi-Fi reconnects while both tools run, race conditions are common—reproduce with a scripted toggle rather than anecdote.

When logs show TLS timeouts rather than immediate “no route,” also consider path MTU issues across double encapsulation. Sometimes lowering MTU on the Clash tunnel interface or adjusting MSS clamping is the difference between stable enterprise VPN sessions and mysterious mid-call drops—especially on Wi-Fi with aggressive aggregation. Pair route inspection with timeout and TLS patterns in connection logs so you do not mis-label a blackhole route as “bad node quality.”

GlobalProtect and Other Enterprise VPN Clients

Palo Alto GlobalProtect is not identical to Cisco AnyConnect, but the troubleshooting rhyme is similar: HIP checks, portal hostnames, internal gateways, and HIP report uploads all want predictable DNS answers and stable egress interfaces. The same DIRECT whitelist discipline applies—identify the vendor’s control hostnames from logs, pin them early in rules:, and avoid sending them through arbitrary third-party exits. Some GlobalProtect modes lean harder on always-on enforcement; if the client intentionally blocks split scenarios, no amount of consumer YAML overrides corporate policy—escalate with traces.

Zero-trust agents (WARP-class clients, Zscaler, Netskope) add yet another layer that may rewrite DNS or install their own certificates. In those environments, coexistence with Clash may be explicitly unsupported. This article documents technical interactions, not policy evasion—when IT says “no parallel tunnels,” that is a governance decision, not a puzzle to brute force.

Copy-Paste Checklist Before You Escalate to IT

Work top to bottom; send your networking team a filled copy if you eventually need help.

  1. Confirm running Clash alongside the company SSL VPN is permitted; export logs you are allowed to share.
  2. Record exact client versions (Cisco AnyConnect / Secure Client, GlobalProtect) and whether the tunnel is full or split.
  3. Baseline test: disconnect Clash entirely—does the VPN stabilize? If not, stop here; the root cause is not Clash.
  4. Re-enable Clash in system proxy mode only—does the regression disappear? If yes, focus on TUN overlap and routing metrics.
  5. Merge-view your final config: verify VPN gateway hostnames and internal IP-CIDR prefixes appear before broad geolocation or MATCH lines.
  6. Inspect DNS: split suffixes, fake-ip filters, DoH in browsers, and AnyConnect’s assigned resolvers must tell a coherent story.
  7. Dump the OS routing table while connected—confirm corporate routes exist and point at the VPN interface.
  8. Check IPv6 paths if your org publishes AAAA records for internal names.
  9. Clear stale OS proxy settings after mode experiments using the residue guide linked above.
  10. Only after local variables are exhausted, involve IT with packet notes—not vague “VPN bad.”
⚠ Compliance reminder: Respect workplace acceptable-use policies, contractual obligations, and local law. This article explains coexistence mechanics for legitimate remote access—not bypassing security controls, exfiltrating data, or tunneling where prohibited.

Wrap-Up: Observable Coexistence

Cisco AnyConnect and Clash can share a laptop when you treat coexistence as a routing project, not a luck-based toggle. Put enterprise VPN infrastructure on DIRECT with explicit ordering, align DNS hijack and fake-ip behavior with split-DNS reality, choose TUN versus system proxy with eyes open, and verify the routing table the OS actually installs. The same pattern transfers to Palo Alto GlobalProtect and other SSL VPN stacks with different hostnames but the same physics.

Compared with opaque “just use bridge mode” forum advice, an observable checklist fails faster and annoys IT less: you bring routes, resolver lists, and matched Clash rules instead of vibes. If you want a consumer-level mental model for why these tools overlap at all, keep Clash versus VPN: a deeper comparison bookmarked next to this guide.

→ Download Clash for free and experience the difference—keep your split whitelist boring, your defaults explicit, and your VPN sessions on the corporate network where they belong.