軟體VPN 原理：為什麼分流機制
二、分流機制的核心原理：路由決策是怎麼發生的？
分流機制的本質，是一連串「這個封包該不該進隧道」的判斷。判斷發生在封包離開應用程式、進入作業系統網路堆疊之後，VPN 客戶端會依據規則決定要讓它走虛擬網卡還是實體網卡。看似簡單，但魔鬼藏在層級與順序裡。
系統路由表與 VPN 虛擬網卡的博弈
最基礎的分流實作，是直接操作系統路由表（Routing Table）。路由表的每一條規則大致長這樣：目的網段、子網遮罩、閘道、介面、Metric（優先權）。當多條規則同時匹配時，系統會選擇 Metric 較低（優先權較高）的那一條。
VPN 客戶端常見的做法是：先插入一條 0.0.0.0/0 指向虛擬網卡的預設路由，再把特定網段（例如內網、本地 ISP 網段）用更低的 Metric 指向實體網卡，形成「例外清單」。這種做法效率高，但粒度很粗——它只能以「IP 網段」為單位，無法處理「同一個 IP 上不同網域」的情況，而現代 CDN 與共用主機恰恰讓一個 IP 承載數百個網域。
另一種做法是策略路由（Policy-Based Routing），在 Linux 上可透過多張路由表與 ip rule 實作，Windows 上則依賴 WFP（Windows Filtering Platform）或 NDIS 篩選器。這種方式可以做到「依來源程式、依目的地、依協定」決定走向，彈性遠高於單純改路由表，但開發複雜度也高，這也是為什麼多數免費 VPN 只做得到全局模式。
分流的三種層級：網域、IP、與應用程式
實務上的分流規則，通常落在三個層級：
netflix.com、taobao.com 這類域名。客戶端必須先「看到」DNS 查詢或 TLS SNI，才能判斷。優點是直覺、可讀性高，缺點是需要解析 DNS 或攔截 SNI，且對 ECH（Encrypted Client Hello）等新技術較難處理。203.0.113.0/24。判斷速度快、實作簡單，但 CDN 環境下容易誤判，而且 IP 清單需要持續維護，否則會出現「該繞的沒繞、不該繞的繞了」。一款成熟的軟體 VPN，通常會混合使用這三種層級：用 App 層級處理「本機程式分類」，用網域層級處理「網站分類」，再用 IP 層級做「兜底與效能優化」。
規則引擎的優先順序：誰先誰後決定一切
分流規則不是「有就好」，順序才是關鍵。假設你同時寫了「google.com 走代理」與「*.com 直連」，那麼前者必須排在後者之前，否則永遠不會被觸發。多數規則型 VPN 採用「由上而下、首條匹配即生效（First Match Wins）」的模型，少數採用「最長匹配優先（Longest Prefix Match）」。
這帶來兩個實務上的坑：第一，使用者自訂規則若順序錯置，會出現「明明加了規則卻沒生效」的靈異現象；第二，內建規則清單的排序邏輯若設計不良，可能導致熱門服務被較寬鬆的規則「吃掉」。所以在評測一款軟體 VPN 時，我會特別去看它是否允許使用者拖曳調整規則順序，以及是否提供「規則命中測試」這類除錯工具。
三、常見分流模式拆解：全局、智慧分流、規則分流
市面上的軟體 VPN 在分流設計上，大致可以歸納成三種模式。理解這三種模式的差異，你就能快速判斷一款產品適合什麼樣的使用者。
全局代理（Global Mode）的代價
全局模式把所有流量送進隧道，設定最簡單，隱私保護也最「無腦完整」。但如前面所述，它的代價是延遲、相容性與伺服器負載。對長期掛機、需要固定出口 IP 的商業場景，全局模式仍有其價值；但對一般使用者而言，全局模式幾乎等於「用便利換效能」。值得注意的是，有些產品雖然介面標示「全局」，實際上仍會對區域網段（192.168.x.x、10.x.x.x）做例外處理，否則連印表機或 NAS 都會斷線——這其實已經是分流的一種。
智慧分流（Smart Routing / GFW Mode）的判斷邏輯
智慧分流是近年最主流的設計，常見名稱包括「智慧模式」、「自動分流」、「規則模式」。它的核心邏輯是：預設直連，只有被判定為「需要代理」的流量才進隧道。判斷依據通常有幾種：
智慧分流的優點是「開箱即用」，缺點是判斷邏輯對使用者不透明。當它誤判時，你往往不知道為什麼某個網站走了代理，也不知道該去哪裡改。這也是為什麼評測時我特別重視「規則可視化」——能不能看到每一條連線實際走了哪條規則。
規則分流與自訂清單的實作
規則分流是給進階使用者的模式：使用者自行定義「哪些走代理、哪些直連、哪些封鎖」，常見格式包括 Clash 系的 YAML 規則、Surge 系的 CONF、以及各家自訂的圖形化規則編輯器。規則類型通常包含：
DOMAIN / DOMAIN-SUFFIX / DOMAIN-KEYWORD：以網域為判斷依據。IP-CIDR / GEOIP：以 IP 網段或地理歸屬為判斷依據。PROCESS-NAME：以應用程式為判斷依據（桌面端較常見）。
MATCH / FINAL：兜底規則，通常放在最後。規則分流的威力在於「可組合性」。你可以把「串流平台走美國節點、工作用 Git 走日本節點、本地網銀直連、其餘走預設節點」寫成一套規則，一勞永逸。但它的門檻也最高，一般使用者往往需要仰賴社群維護的規則集（Rule Provider），而規則集的品質與更新頻率，就成了產品體驗的隱形變數。
四、分流機制的技術實作：從 PAC 到 TUN 的分流
理解模式之後，我們再往下一層，看看分流在技術上是怎麼被「實現」的。這一段稍微硬核，但看懂之後，你對軟體 VPN 的評測判斷會完全不同。
最早的網路分流其實不是 VPN 發明的，而是代理自動設定（PAC，Proxy Auto-Config）。PAC 是一段 JavaScript，瀏覽器在每次連線前會呼叫 FindProxyForURL(url, host)，由腳本回傳「DIRECT」或「PROXY x.x.x.x:port」。PAC 的優點是標準化、瀏覽器原生支援，缺點是只涵蓋瀏覽器流量，且腳本效能與維護性都差，現代產品已逐漸淘汰。
第二種是系統代理（System Proxy），也就是設定作業系統的 HTTP/HTTPS/SOCKS 代理。它的優點是實作簡單、對瀏覽器友善；缺點是只對「遵循系統代理設定」的應用程式有效，很多遊戲、通訊軟體、命令列工具會直接繞過，形成「分流漏洞」。
第三種、也是現代軟體 VPN 的主流，是TUN 模式配合規則引擎。客戶端建立虛擬網卡並接管路由，所有 IP 封包都會經過使用者態的規則引擎。引擎會嘗試從封包中還原出「這是哪個網域」的資訊——做法包括解析 DNS 查詢、讀取 TLS ClientHello 的 SNI、或使用目的 IP 反查。判斷完成後，再決定要「原樣轉發到實體網卡」還是「送入代理隧道」。
這裡有一個關鍵細節：DNS 的處理方式會直接影響分流成敗。如果 DNS 查詢本身走了代理，你拿到的 IP 可能是代理端解析的結果，這時再用 IP 判斷地理歸屬就會失準；反之，如果 DNS 走本地但連線走代理，就可能發生 DNS 洩漏（DNS Leak），暴露你真實的查詢行為。成熟的做法是「DNS 與連線走同一條路徑」：需要代理的網域，DNS 也交由代理端解析（Fake-IP 或遠端解析）；直連的網域，DNS 則走本地。這種「一致性原則」是判斷一款 VPN 分流引擎是否專業的重要指標。
此外，還有行動裝置上的限制。iOS 的 Network Extension 框架要求所有 VPN 流量經過單一隧道，分流只能在隧道內部以「包含/排除清單」實作，粒度不如桌面端；Android 的 VpnService 則允許以 App 為單位設定 bypass。這也是為什麼同一款軟體 VPN，在桌機與手機上的分流表現可能天差地遠。
五、分流機制為什麼重要：效能、隱私與相容性的三角習題
談到這裡，我們可以回到標題的問題：為什麼分流機制會成為現代軟體 VPN 的核心競爭力？答案可以濃縮成三個維度。
第一是效能。分流讓不必要繞道的流量走直連，直接省下跨國 RTT。以台灣使用者連線本地服務為例，直連延遲可能只有 5 到 15 毫秒，繞到美西再回來則可能超過 150 毫秒。對於視訊會議、線上遊戲、遠端桌面這類對延遲敏感的應用，分流不是「優化」，而是「能不能用」的分界線。
第二是隱私。很多人誤以為「全部走 VPN 才安全」，但實際上，分流做得好反而能降低攻擊面。讓本地網銀、內網 NAS、印表機走直連，可以避免敏感流量離開本地網路；同時，把真正需要匿名的流量集中到代理，也讓出口 IP 的行為足跡更單純。當然，前提是分流規則本身不能造成 DNS 洩漏或 WebRTC 洩漏，這又回到上一節提到的「一致性原則」。
第三是相容性。金融 App、串流平台、政府網站、企業內網，各自有不同的網路政策。全局模式在這種環境下幾乎注定四處碰壁；而規則分流可以針對個別服務設定「直連」、「特定節點」或「封鎖」，讓 VPN 從「破壞者」變成「協調者」。這也是為什麼越來越多商業 VPN 把「App 分流」列為付費功能——它解決的是真實世界的相容性痛點，而不只是技術炫技。
值得注意的是，分流機制也帶來新的風險。規則寫錯可能導致「以為走了代理、其實直連」的隱私假象；規則集被惡意篡改可能把敏感流量導向不明節點；而過度依賴社群規則集，則可能讓使用者失去對自己網路行為的理解。因此，一款負責任的軟體 VPN，應該提供清楚的連線日誌、規則命中顯示，以及「一鍵阻擋未匹配流量」的嚴格模式（Strict Mode），讓使用者在便利與控制之間取得平衡。
六、實測觀察與選購建議：怎麼判斷一款 VPN 的分流做得好不好？
在實際評測軟體 VPN 時，我通常會用幾個簡單的檢查點來判斷分流引擎的成熟度，這些檢查不需要抓封包，一般使用者也能操作：
規則更新頻率：內建清單是否定期更新，是否透明列出資料來源。
從產品定位來看，如果你的需求是「偶爾跨區看串流、平日上網要順」，那麼智慧分流加上可自訂例外，大概就足夠；如果你是開發者、遠端工作者，或需要同時連線多個地區的服務，那麼規則分流、App 分流與嚴格模式會是必要條件。至於只提供全局模式的產品，並非不能用，但更适合「短時間、單一目的」的使用情境，而不是全天候掛機。
另外要提醒的是，分流機制的效能本身也會影響體驗。規則引擎若寫得不好，每一條連線都要比對上千條規則，在高併發情境下（例如同時開數十個分頁）可能造成 CPU 占用升高與連線延遲。這也是為什麼有些產品會採用「網域快取」與「連線複用」來降低規則比對成本。評測時若發現「開了規則模式之後整台電腦變慢」，那很可能是規則引擎的效率有問題，而非你的網路變差。
結語：分流機制，是 VPN 從「工具」走向「基礎設施」的關鍵
回顧整篇文章，我們從封包如何在作業系統中被攔截開始，拆解了路由表、虛擬網卡、規則引擎與 DNS 處理的互動，再看到全局、智慧分流、規則分流三種模式的取捨，最後回到效能、隱私與相容性的三角習題。你會發現，軟體 VPN 的價值早已不只是「加密隧道」，而是「如何在正確的時間，把正確的流量，送到正確的地方」。
分流機制之所以重要，是因為它讓 VPN 從一個「全有全無的開關」，變成一張可以精細繪製的路由地圖。它讓你能同時擁有本地服務的低延遲、海外服務的可用性，以及敏感流量的可控性。對使用者而言，理解分流原理不代表要自己寫規則，而是讓你在面對「為什麼這個網站變慢」、「為什麼銀行 App 擋我」這類問題時，能夠判斷是產品設計的限制，還是設定可以調整的空間。
下次你在雅寶社區 · 頂客論壇看到有人問「哪款 VPN 比較好」，不妨先反問一句：它的分流機制，能不能說清楚？因為在這個 CDN 遍地、區域限制常態化的時代，一款說不清自己怎麼分流的軟體 VPN，大概也很難真正照顾好你的網路體驗。