When a corporate VPN and Clash fight over the routing table
Install your company's or university's network client and Clash either loses connectivity entirely or can no longer reach the intranet. There is usually one cause: both are rewriting the system routing table.
Confirm it is a routing conflict
Run route print and look for more than one 0.0.0.0/0 default route. Enterprise VPNs commonly run in full-tunnel mode and insert a default route with a better metric than the physical adapter; enabling TUN adds another, and the lower metric wins.
Three approaches
- Switch to system proxy mode: turn TUN off and use System Proxy only. It works at the application layer and never touches routes, which is the least painful way to coexist. The cost is that command-line tools, some games and UWP apps fall outside its reach;
- Send intranet ranges direct: put
IP-CIDR,10.0.0.0/8,DIRECT,no-resolveandIP-CIDR,172.16.0.0/12,DIRECT,no-resolveat the top of your rules so intranet traffic never enters a node. Ask IT which ranges actually apply — guessing wrong hands VPN traffic to the proxy; - Change the start order: connect the VPN first, then enable TUN. The other way round the VPN usually overwrites Clash's routes. This one is fragile — every VPN reconnect means doing it again.
When none of that works
Some enterprise clients actively detect and block third-party virtual adapters, or pin DNS so it cannot be overridden. Those are designed to own the network stack and no amount of configuration changes that — run one, quit the other. If you genuinely need both at once, putting Clash on a separate machine or VM acting as a gateway is the only clean answer.
One more thing: on company-managed hardware, make sure installing and running a proxy tool is compatible with your organisation's network and compliance policies.