症狀與根因：為什麼 Clash 會「弄壞」企業 VPN

Cisco AnyConnect 這類 企業 VPN 會在連線期間寫入路由表、指定 DNS 搜尋後綴，有時還會下發分割隧道（split tunnel）或全隧道策略。當你同時開啟 Clash 的 TUN 或「設定系統代理」時，等於在作業系統上再疊一層會改寫預設路由或攔截 DNS 的元件。兩邊若同時爭奪預設閘道、或把 VPN 閘道應走的封包導向代理出口，就會出現握手逾時、隧道建立後秒斷、或 VPN 已連上但內網網段（RFC1918、公司自配位址）不可達。這與「代理節點品質」往往是不同維度的問題；可先讀 Clash 與傳統 VPN 深度對照，理解透明代理與企業 VPN 在堆疊中的角色差異，再回到本文明確「誰該主導路由」。

實務上最常見的三類根因是：（1）Clash TUN 的 auto-route 與 VPN 虛擬介面爭奪預設路由；（2）企業 VPN 依賴的驗證網域／OCSP／CRL被規則誤送到海外節點而逾時；（3）Clash 的 DNS（含 fake-ip、redir-host）讓 VPN 客戶端或瀏覽器解析到錯誤位址。接下來依序處理，比一次改十個開關更容易收斂。

第零步：建立可重現的對照基線

請先固定「誰先啟動」與「誰主導路由」兩個變因。建議在僅連企業 VPN、完全關閉 Clash時，記錄：能否穩定連線、內網目標（例如檔案伺服器、內部入口網）是否可 ping 或開啟。接著僅開 Clash、不連 VPN，確認一般網路與你關心的規則命中正常。最後才做「兩者同開」的實驗；每次只改一個選項（例如先關 TUN 只留系統代理），並在客戶端保留連線日誌截圖，避免事後無法對照。

若你在調整過程中遇到「關掉 Clash 仍斷網」，多半是系統代理或 TUN 殘留，可依 Clash 退出後清理系統代理與 TUN 殘留 還原乾淨狀態再重測，否則會把「殘留設定」誤判成「VPN 與 Clash 不相容」。

第一步：釐清 TUN、系統代理與 VPN 的優先級

TUN 模式會在 IP 層接管符合條件的流量，對企業 VPN 影響通常最大；若你的目標是「VPN 負責公司網、Clash 只負責少數網域」，可優先嘗試關閉 TUN、改以系統代理或瀏覽器擴充指向 Clash，讓 VPN 虛擬介面繼續主導預設路由。Windows 上圖形客戶端與 TUN 開關的對照，可參考 Clash Verge Rev 於 Windows 11 的 TUN 設定；macOS 則常牽涉系統擴展與 Network Extension，請一併讀 Clash macOS TUN 與系統擴展、代理衝突排查，確認不是權限問題偽裝成 VPN 故障。

若你必須使用 TUN（例如要讓不支援代理的程式也分流），請在客戶端檢視是否開啟過於激進的 strict-route 或等同選項，並理解它可能讓本機或 VPN 介面的細分流被收斂到單一路徑。此時更應依賴下文DIRECT 白名單把公司網段與 VPN 控制面明確排除在代理之外，而不是只靠「感覺上規則有寫到」。

第二步：內網與 VPN 控制面走 DIRECT（分流白名單）

企業 VPN 連線前後，客戶端常需連到公司公開的閘道主機名、憑證驗證端點、或內部 SSO；若這些流量被 MATCH 到 PROXY 或某個策略組，就會出現握手失敗。請向 IT 取得閘道網域與內網 CIDR（若政策不允許完整清單，至少取得你部門常用的 RFC1918 段），並在 Clash 規則前段加入對應的 DIRECT 條目。規則由上而下匹配，寫法與排序原則請對照 規則分流最佳實踐，避免一條過寬的 GEOIP 或 MATCH 蓋掉企業白名單。

若 VPN 客戶端為獨立執行檔，且你的核心支援進程規則，亦可考慮讓 vpnagent、vpnui（名稱依版本與平台而異）相關連線強制 DIRECT，降低被規則誤送的機率；細節可延伸閱讀 Windows 上 Clash Meta 按進程分流。下列為示意 YAML，實際鍵名與策略組名請替換為你的設定檔內容。

rules — enterprise VPN bypass (illustrative placeholders)

rules:
  - IP-CIDR,10.0.0.0/8,DIRECT
  - IP-CIDR,172.16.0.0/12,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT
  - DOMAIN-SUFFIX,vpn.example.com,DIRECT
  - DOMAIN-SUFFIX,ocsp.example.com,DIRECT
  - PROCESS-NAME,vpnagent.exe,DIRECT
  - MATCH,PROXY

第三步：用路由表驗證預設路由與介面指標

當 AnyConnect 顯示已連線但內網仍打不開，請在作業系統上檢視路由表：預設路由（0.0.0.0/0）是否仍指向 VPN 介面，或已被 Clash 建立的 utun／Meta 介面覆寫。Windows 可用 route print 或 Get-NetRoute；macOS／Linux 可用 netstat -rn 或 ip route。若你看到兩條預設路由，請比對metric／priority數字較小者為何；metric 較小通常優先。調整 Clash 客戶端中與 auto-route、auto-detect-interface 相關的選項時，建議每次變更後都重新匯出路由表對照，而不是只看 UI 開關狀態。

部分企業採分割隧道：只有內網段走 VPN，其餘網際網路仍走本機 ISP。此時若 Clash 把預設路由整包改寫，可能破壞 IT 預期的「公網直連、內網走隧道」分割；解法仍是把公司內網前綴與 VPN 必要端點放在 DIRECT，並讓 Clash 的預設路由策略與 IT 文件一致，必要時在工單中附上你觀察到的路由表差異以利對方調整伺服器端策略。

第四步：DNS 是否被 Clash 劫持而與公司解析不一致

企業 VPN 常下發內部 DNS 伺服器與搜尋網域；若 Clash 啟用 DNS 覆寫或 fake-ip，可能讓 intranet.corp.local 這類名稱解析到錯誤位址，表現為「網頁打不開但 ping IP 卻通」。請檢視 Clash 的 dns 區塊：nameserver、fallback、fake-ip-filter 是否涵蓋公司網域與內部後綴；完整語意可對照 Clash Meta DNS、nameserver、fallback 與 fake-ip-filter。實務上常見修法包括：為公司網域指定 DIRECT 的 DNS 或跟隨系統解析、把內部後綴加入 fake-ip 過濾、或在連 VPN 期間暫時關閉 Clash 的 DNS 劫持做對照測試。

若你使用瀏覽器內建 DoH，也可能繞過作業系統與 VPN 下發的解析器，造成「只有瀏覽器壞、其他 App 正常」的分叉；此時應先關閉瀏覽器 DoH 做 A／B 測試，再回頭調 Clash。挑選客戶端時，選擇能把 DNS 與規則放在同一視窗檢視的產品會省很多時間，可參考 如何選擇適合自己的 Clash 客戶端。

GlobalProtect 與其他 SSL VPN 的類推

GlobalProtect、FortiClient、Juniper Pulse 等 SSL VPN 與 AnyConnect 在「會改路由與 DNS」這點上高度相似：只要 Clash TUN 與其爭奪預設路由，或 DNS 被 Clash 與瀏覽器 DoH 雙重改寫，症狀就會類似。差異多在閘道網域與客戶端進程名稱；排查順序仍可沿用本文：模式優先級 → DIRECT 白名單 → 路由表 → DNS。若組織使用 Zero Trust 代理與傳統 VPN 並存，請特別注意是否被要求只能使用公司核准的網路堆疊，在該情境下個人代理可能本就不被允許，應以公司政策為準。

⚠ 合規與授權：請勿利用本文步驟規避雇主或學校的資安政策。若公司明令禁止同時使用個人代理與企業 VPN，請依規定停用其一。調整路由與 DNS 可能影響稽核與存取紀錄，請在取得授權的環境中操作。

可列印檢查清單

  1. 僅 VPN、僅 Clash、兩者同開三種狀態是否各能重現問題？
  2. 目前主路徑是 TUN 還是系統代理？能否暫時關 TUN 驗證 VPN？
  3. 閘道網域、OCSP／CRL、內網 CIDR 是否已置於規則前段並命中 DIRECT？
  4. 路由表中預設路由指向哪張介面？metric 是否與 VPN 預期一致？
  5. Clash DNS 是否劫持內部網域？fake-ip-filter 是否涵蓋公司後綴？
  6. 瀏覽器 DoH 是否關閉後問題消失？
  7. 異常排除後是否已依清理專文確認無代理殘留？

結語

Clash 與 Cisco AnyConnect 並非要二選一，而是要在路由表與 DNS 上講清楚「誰先誰後」。把企業流量用 DIRECT 與分流白名單留在公司隧道內，其餘再以策略組處理，通常就能同時保留遠端辦公與個人分流需求。相較盲目更換節點，願意對照路由與解析路徑的人，較少被「握手失敗」這類表象帶偏。

若你常在不同筆電與系統間切換，建議把本文檢查清單存成備忘，並在每次系統或客戶端大版本升級後重跑一次基線測試；相比一次性魔改，可重現流程更能長期維護。

→ 立即免費下載 Clash，開啟流暢上網新體驗，在完成企業 VPN 白名單與 DNS 對齊後，把時間留給真正需要分流的服務。