1 為何企業 VPN 與 Clash 會「打架」
Clash 類用戶端不論走系統代理或 TUN，本質都是在本機插入一層「把符合條件的流量轉交給代理程式」的邏輯。相對地，多數企業 VPN連上後會做兩件影響極大的事：第一，在作業系統層新增或覆寫預設路由，讓「未特別指定的目標」改走 VPN 介面與企業閘道；第二，可能一併推送名稱解析設定，讓內部網域只從公司 DNS 取得正確位址。當 VPN 採全隧道（full tunnel）策略時，幾乎所有對外流量都會先進入企業再出去，本機 Clash 即使監聽 127.0.0.1，應用程式實際選路仍可能以 VPN 下發的路由為準，於是您會感覺「規則寫了卻不生效」或「只有瀏覽器／部分程式異常」。
另一種常見現象是雙預設路由並存：VPN 與實體網卡各有一筆 0.0.0.0/0，此時 Windows 會依介面 metric、路由度量或綁定介面決定優先順序。若 VPN 的 metric 較「好」（數字較小），則多數流量會優先走隧道，Clash 只能在剩餘路徑或特定程式行為下介入。理解這點後，與其反覆重裝用戶端，不如先學會讀 route print -4 與「連線前／後」路由差異，再決定是要向 IT 申請拆分隧道，還是在允許範圍內新增例外路由。若您需要終端機、Docker 與 TUN 一併納管，可與站內Clash Verge Rev TUN 模式教學對照閱讀；本文則專注在企業 VPN 與本機路由的優先順序。
2 GlobalProtect、AnyConnect 等常見行為
Palo Alto GlobalProtect 與 Cisco AnyConnect 在企業環境極為常見，實際是否全隧道、是否允許分割 DNS、是否鎖定分割包含／排除清單，皆由閘道端政策決定，終端使用者無法只靠本機選項「猜」出來。實務上可先觀察：連線後是否出現新的虛擬介面、該介面是否帶有公司內部網段的路由、以及預設路由的下一跳是否指向隧道內位址。部分部署會同時下發受信任網域分流（僅內網走 VPN，其餘直連），這就是最典型的拆分隧道（split tunneling）；若政策要求所有網際網路流量經過公司 DLP／防火牆檢查，則多為全隧道，此時本機代理能介入的空間通常極小，除非 IT 明確放行特定前綴或埠。
不同廠牌用語略有差異，但 Windows 底層看的仍是路由表與介面索引。因此跨廠牌排查時，建議以「連線前後路由差異」為共同語言，與 IT 溝通時也較容易對齊：您需要的是某幾個子網仍走實體網卡、或某幾個目標不要進全隧道，而不是直接要求「一定要與 Clash 並存」這種不易審核的表述。
3 拆分隧道：最乾淨的「不打架」方案
若公司政策允許拆分隧道，通常代表：僅內部網段與必要管理流量走 VPN，一般網際網路流量仍由本機預設閘道出去。在此架構下，Clash 以系統代理或 TUN 接管「非內網」流量時，較不容易與 VPN 爭奪預設路由，因為兩者職責已經分區：VPN 負責到內部網路與零信任檢查點，Clash 負責您個人工作所需的出站策略（仍須符合公司規範）。申請拆分隧道時，建議準備具體網段或網域名稱、業務理由與資安風險自評，並接受可能必須改用公司提供的分開設定檔或Always-On VPN限制。
若 IT 僅願意做「部分排除」而非完整拆分，常見折衷是排除清單（exclude）：指定少數子網或主機不走隧道。此時您可把「必須直連或必須走本機代理」的目標整理成清單，請對方在閘道政策中實作，比在本機反覆 route add 更穩定，也不易在 VPN 重連時被沖掉。
4 Windows 路由表與例外子網（政策路由的簡化版）
當 VPN 強制全隧道、但您仍希望特定子網走實體網路（例如本機實驗環境、區網印表機、或測試用閘道），可在具授權且符合公司政策的前提下，於 Windows 新增較具體（較長前綴）的路由項目，讓系統優先匹配該筆路由，而非最寬鬆的 0.0.0.0/0。檢視目前 IPv4 路由可開啟具系統管理員權限的命令提示字元或 PowerShell，執行：
route print -4
輸出中的 Network Destination、Netmask、Gateway、Interface 與 Metric 欄位，即為排查核心。若要在連上 VPN「之後」仍強制某子網走本機閘道，典型作法是使用 route add 並指定介面與 metric（實際參數依您的閘道 IP 與介面索引而定，請勿直接複製網路範例上線）。持久化路由在傳統上可使用 -p 參數，但企業映像常鎖定變更權限，且 VPN 重連可能再次改寫表項，因此本機手動路由僅適合實驗或臨時驗證，長期仍應回到閘端拆分政策。
REM Example shape (do not run blindly):
REM route add <DEST_NET> mask <NETMASK> <LOCAL_GW> metric <M> if <IF_INDEX> -p
新增路由後請再以 tracert 或 Test-NetConnection 驗證封包是否依預期介面送出。若發現 VPN 用戶端每次連線都清空自訂表項，表示該路徑不可維護，應停止依賴本機 workaround。
5 連線順序與介面 metric：誰先連未必誰贏
許多使用者會問：「應該先開 Clash 還是先連 VPN？」在 Windows 上，關鍵通常不是開啟順序，而是連線完成當下誰寫入了預設路由與較佳 metric。若 VPN 連上後強制插入高優先序的 0.0.0.0/0，則後開的 Clash 可能只剩「對已願意走系統代理的應用」有效；若 Clash 使用 TUN 並設定較高優先序的虛擬介面，則可能與 VPN 虛擬介面競爭，出現內網中斷或分裂路由。實務排查建議：在兩種開啟順序下各擷取一次 route print -4 與 ipconfig /all 比對差異，用據決定是否調整 TUN 堆疊選項、或改以系統代理為主以降低與 VPN 驅動的摩擦。
進階環境可能會用到弱主機模型以外的路由原則或協力廠商補丁；若您遇到「僅 Microsoft Store 類型應用」異常，亦可交叉參考UWP 與 Loopback 排除，因為問題有時同時涉及路由與應用沙箱，而非單一路由表。
6 Clash 側：TUN、系統代理與「不要搶內網」
在企業 VPN 已連線的情境下，Clash 規則仍會執行，但進入 Clash 之前的選路可能已被 OS 決定走隧道。實務上常見兩種調整方向：其一，在規則中明確將公司內網網域與 RFC1918 私網位址 DIRECT，避免誤送到海外節點，並與 VPN 內網路由一致；其二，若 TUN 與 VPN 驅動衝突，可暫時改以系統代理搭配支援 PAC／系統代理的應用，換取較温和的共存。若您使用 Meta 系核心，亦可檢視是否需為特定進程或埠設定 DIRECT，並參考Windows 進程名分流讓遊戲或視訊會議走直連，其餘走代理，減少與會議伺服器或內部視訊邊界的摩擦。
無論採哪種模式，請避免在不了解公司 DLP 與日誌政策的情況下，把明確標示為內部機密的流量繞過 VPN；技術上可行與政策上允許是兩件事。若尚未完成 Clash 用戶端在 Windows 的基礎安裝，建議先依Clash Verge Rev Windows 安裝教學建立乾淨基線，再疊加 VPN 測試，避免埠號、服務模式與防火牆規則一開始就與企業映像衝突。
7 DNS 分叉：路由對了仍打不開
企業 VPN 常推送連線專用 DNS 尾碼或強制所有查詢走內部解析器，以避免資料外洩與釣魚網域。此時即使您在 Clash 內為某網域設了代理，若解析結果仍指向僅能從內網路由到的位址，而該路由又因全隧道被改寫，便會出現「時好時壞」的假象。排查順序建議：先用 nslookup 或 PowerShell 的 Resolve-DnsName 比對連 VPN 前後回傳的位址是否一致，再對照 Clash 日誌觀察實際連線目標。若您使用 FakeIP 或自訂 DoH，請一併閱讀Meta 核心 DNS 防洩漏，確認「誰在回答 DNS」與「誰在決定路由」兩條鏈路沒有互相矛盾。
在拆分隧道可行的環境，理想狀態是：內部網域只由公司 DNS 解析並只走 VPN；一般公網網域由本機或 Clash 上游解析並走您允許的路徑。若無法達成，請優先保全內網解析正確性，再處理外網加速或分流需求。
8 合規與資安：先取得授權再動手
繞過公司強制 VPN或流量檢查可能違反僱傭合約、資訊安全辦法或個資法下的委託管理義務。本文僅說明 Windows 路由與 Clash 並存的技術機制與故障排除思路，不作為規避公司監控的指引。若您的職務需要存取內網與外網兩類資源，正途仍是與 IT 協調官方支援的拆分隧道、零信任分層或核准的代理／跳板。自行新增持久路由或修改登錄檔若違反裝置管理政策，可能導致裝置被鎖定或稽核處分，請務必自行評估。
9 排查檢查清單（濃縮版）
- 比對路由：VPN 連線前後各存一份
route print -4，確認預設路由與內網靜態路由變化。 - 比對 DNS：對問題網域執行解析，確認是否被 VPN 改寫為內部位址。
- 分離變因：先關閉 Clash 僅留 VPN，確認內網必備服務可通；再僅開 Clash 關 VPN，確認用戶端本身無誤；最後才做並存測試。
- 檢查 metric：若存在多筆預設路由，觀察哪一筆 metric 較小、介面索引為何。
- 記錄重現步驟：若需 IT 支援，附上時間點、介面截圖與路由表較易一次到位。
10 總結
Windows 上同時使用企業 VPN（如 GlobalProtect、AnyConnect）與 Clash 時，真正的主戰場在作業系統路由表與 DNS，而不是單純規則 YAML 寫得是否漂亮。拆分隧道與閘端排除清單是最穩定、最不會在每次重連後「消失」的解法；本機 例外路由僅適合驗證與短期 workaround。並存時請優先確保內網流量與公司解析鏈路正確，再調整 Clash 的 TUN／系統代理與 DIRECT 規則，並全程留意資安與僱傭合約允許範圍。
相較在社群零散搜尋指令，先建立「連線前後路由差異」的習慣，長期維護成本更低。若您希望用與本站教學一致的圖形用戶端作為基線，可從本站下載頁取得 Clash Verge Rev，再依 Windows 安裝、TUN、DNS 與本文逐步銜接企業環境。
