VPN 新手術語速查：訂閱、節點、協定、分流、全域與規則模式一次搞懂

第一次開啟 VPN 用戶端時，最難的通常不是按下連線，而是弄懂訂閱、節點、協定、分流、全域與規則模式各自控制什麼。它們並不是同一層級的選項：訂閱負責提供設定，節點代表連線入口，協定規定用戶端與伺服器如何通訊，線路類型描述資料實際經過的網路路徑，分流模式則決定哪些請求使用這條路徑。

可以把整個過程想成一次物流配送。訂閱像持續更新的地址簿，節點是可選的轉運站，協定是雙方約定的封裝方式，線路是貨物實際行走的道路，分流規則則是調度表。把這些概念放回連線流程後，用戶端裡看似密集的按鈕就會變成一條清楚的資料鏈。

核心術語速查：先分清每個選項控制什麼

這裡最重要的區別是「設定」和「流量」。訂閱、節點、協定屬於連線設定；分流、全域和規則模式屬於流量調度。連線成功只代表用戶端與遠端入口之間已建立通道，不表示所有應用程式都在使用通道，也不表示 DNS 請求一定經過預期路徑。

訂閱與節點：地址簿和連線入口不是一回事

訂閱連結提供什麼

訂閱連結通常指向一份可由用戶端讀取的設定內容。用戶端存取該連結後，會將回傳內容解析為節點清單或設定檔。不同用戶端支援的訂閱格式可能不同：有些可直接辨識通用分享連結，有些需要特定設定結構，有些還會同時下發規則組、代理群組和 DNS 參數。

訂閱連結不是普通的網頁書籤，也不只是下載按鈕。它可能包含伺服器位址、連接埠、協定驗證資訊、傳輸方式和節點名稱，因此應像保密憑證一樣妥善保存。將連結公開貼在截圖、日誌或問題回報中，可能同時洩露整組連線設定。

「更新訂閱」表示用戶端重新讀取遠端設定。更新後，伺服器端新增、刪除或調整的節點會反映到本地端。部分用戶端會覆蓋訂閱內節點的手動修改，因此需要長期保留的本地規則，最好放在用戶端支援的覆寫、設定片段或獨立規則區域，而不是直接編輯由訂閱產生的節點。

1. 複製訂閱連結：從服務面板取得與用戶端格式相符的連結，不要從聊天截圖中手動抄錄。
2. 選擇匯入方式：在用戶端中使用「從 URL 匯入」、「新增訂閱」或意思相近的入口。
3. 執行更新：等待用戶端完成解析，確認節點清單已經出現，而不是只看到尚未載入的訂閱名稱。
4. 選擇節點：先依目標地區和用途選擇出口，再根據線路類型與目前網路表現調整。
5. 啟用接管：依平台選擇系統代理或 TUN，並以實際請求驗證出口與 DNS。

節點名稱能提供多少資訊

節點是一份可以建立連線的遠端設定。名稱通常會標示地區、城市、線路或用途，但名稱本身不參與網路傳輸。它更像維運標籤，協助使用者選擇設定。節點顯示「日本」通常表示預期出口位於日本，但不能僅憑名稱判斷入口位置、傳輸路徑、電信商路由或目前壅塞情況。

「節點」和「伺服器」也不完全等同。多個節點設定可能由同一套基礎設施承載，也可能分別對應不同入口、出口或傳輸參數。反過來，一個節點背後也可能包含入口轉發和出口服務。對使用者來說，節點是用戶端可選的邏輯連線項目；伺服器則是實現該連線的基礎設施概念。

• ✅ 先確認出口地區是否符合目標服務的地區要求。
• ✅ 再確認線路類型是否適合目前的網路環境與使用時段。
• ✅ 切換節點後重新開啟目標連線，避免舊工作階段繼續沿用原本的出口。
• ❌ 不要只根據節點名稱中的「高速」、「專用」等描述判斷實際路徑。
• ❌ 不要把訂閱更新失敗誤判為所有節點同時故障。

協定：Shadowsocks、VMess、Trojan、VLESS、Hysteria2 與 TUIC

協定規定用戶端如何封裝請求、完成驗證並與伺服器交換資料。協定名稱經常和傳輸層、TLS、WebSocket、QUIC 等參數同時出現，因此同一種協定也可能有不同部署方式。只看協定名稱無法直接推論速度、穩定性或適用地區；更可靠的判斷方式，是將協定、傳輸、線路與本地網路一併考量。

Shadowsocks 嚴格來說屬於加密代理，而不是建立傳統網路介面的完整 VPN 協定。在日常使用中，許多用戶端會將不同代理協定統一放進「VPN」或「代理」產品介面，這是產品層面的分類，不會改變協定本身的運作方式。

VMess 與 VLESS 都常見於 V2Ray 相容生態系，但兩者不是單純的新舊名稱替換。它們在驗證方式和協定結構上有所不同；伺服器提供哪一種設定，用戶端就必須依對應格式匯入。Trojan 通常依賴正確的 TLS 參數；如果用戶端略過關鍵欄位，連線可能在驗證前就因握手問題中止。

Hysteria2 和 TUIC 使用 QUIC 及 UDP。在存在封包遺失、抖動或頻寬變化的網路中，它們可能呈現不同於 TCP 方案的行為，但前提是目前網路允許 UDP 正常通訊。公司網路、公共網路或部分路由設備可能限制 UDP；這時切換到基於 TCP 的設定，通常比反覆修改 QUIC 參數更直接。

線路類型：直連、中轉與 IEPL 專線的實際差異

協定解決「如何傳輸」，線路解決「經過哪裡」。即使兩個節點使用相同協定、指向相同出口地區，也可能因路徑不同而呈現完全不同的延遲、抖動和封包遺失特徵。選擇節點時只看協定而忽略線路，就像只看車款、不看道路狀況。

直連線路

直連表示用戶端直接連接遠端節點入口，中間沒有服務方明確提供的轉發入口。結構較簡單、鏈路繞行較少，但國際段品質更依賴本地電信商與公網路由。某條直連線路在一個網路環境中順暢，不代表換到另一家電信商後仍有相同表現。

中轉線路

中轉會先連接較近或較容易到達的入口，再由入口將流量轉發至目標出口。中轉的意義不是憑空縮短實體距離，而是透過更可控的入口與後續路由避開品質較差的公網路段。中轉鏈路增加了轉發環節，因此入口容量、入口到出口的路徑和調度策略都會影響最終體驗。

IEPL 專線

IEPL 通常指國際乙太網路專線類連線，用於在不同地點之間提供更可控的專用傳輸路徑。對訂閱服務而言，常見結構是使用者先抵達本地或鄰近入口，再透過專線段前往遠端出口。這不表示使用者裝置直接接入整條專線，也不表示從裝置到入口之間的每一段都脫離公網。

IEPL 的工程價值主要在於路徑可控性與跨境路段穩定性。它和任何代理協定都沒有綁定關係：專線負責承載路徑，Shadowsocks、Trojan、VLESS 等負責用戶端與入口之間的通訊。將「IEPL」理解為協定名稱，會讓設定排錯方向完全偏離。

分流、全域與規則模式：決定每個請求要去哪裡

建立連線後，用戶端還要決定哪些流量交給節點，這個決策過程就是分流。常見動作包括代理、直連和攔截：代理表示將請求交給目前節點或代理群組；直連表示使用本地網路存取；攔截表示不傳送請求，常用於廣告網域、追蹤網域或明確不需要連線的位址。

全域模式不是字面上的「全部」

全域模式通常表示在用戶端已接管的流量範圍內，預設全部交給代理。關鍵限制是「已接管」。如果用戶端只開啟系統代理，遵循系統代理設定的應用程式會被接管；忽略系統代理、自行建立連線的應用程式可能不會進入用戶端。啟用 TUN 後，用戶端通常能從網路層接管更廣泛的流量，但仍可能受到平台權限、路由排除和區域網路設定影響。

因此，看到「全域」不能直接推論裝置上的所有資料都經過節點。正確的驗證方式是檢查目標應用程式的出口、DNS 路徑和用戶端連線日誌。如果瀏覽器出口已改變，但某個獨立應用程式仍使用本地網路，應檢查該應用程式是否繞過系統代理，以及 TUN 是否正確啟用。

規則模式如何比對請求

規則模式會依照網域、IP 位址、地理資料庫、應用程式程序或連接埠等條件選擇動作。用戶端通常會由上到下比對規則，命中後執行對應策略；未命中的請求則進入最終規則。因此規則順序非常重要：寬泛規則放在前面，可能使後面的精確規則永遠無法生效。

網域屬於目標服務 → 代理
網域屬於本地常用服務 → 直連
位址屬於區域網路範圍 → 直連
網域屬於攔截清單 → 拒絕
其餘請求 → 依最終規則處理

這段邏輯不是某個用戶端的固定語法，而是方便理解的決策模型。不同用戶端的規則格式並不通用。複製規則前，應確認目前核心支援的語法、策略群組名稱以及 DNS 模式，否則規則可能成功匯入卻沒有實際命中。

• ✅ 需要存取國際服務時，讓對應網域及其相依網域套用代理策略。
• ✅ 本地服務優先直連，減少不必要的繞行和地區辨識變化。
• ✅ 區域網路裝置通常保留直連，避免印表機、儲存裝置或路由器管理頁面失去連線。
• ✅ 修改規則後關閉舊連線並重新測試，避免連線重用影響判斷。
• ❌ 不要在不了解含義時，長期將所有請求固定到同一個策略。

系統代理與 TUN：為什麼連線成功，仍有應用程式沒有生效

系統代理是作業系統提供給應用程式讀取的代理設定。瀏覽器和多數遵循系統網路設定的桌面應用程式會使用它，但遊戲、命令列工具、虛擬機器以及自行實作網路堆疊的程式可能忽略它。系統代理設定簡單，適合網頁與一般應用程式，但涵蓋範圍取決於應用程式是否配合。

TUN 模式會建立虛擬網路介面，並透過路由將流量送入用戶端處理。它能涵蓋更多不支援系統代理的應用程式，也更適合需要 UDP 或依程序分流的情境。相對地，TUN 需要較高的系統權限，並可能與其他網路工具、防火牆、虛擬機器網卡或企業安全策略發生路由衝突。

有些用戶端還提供「增強模式」、「虛擬網卡模式」或類似名稱，本質上可能是不同的 TUN 實作。名稱由用戶端介面決定；判斷時應查看它是否建立虛擬介面、是否接管 DNS、是否修改預設路由，而不是只看按鈕文案。

DNS 洩漏與解析路徑：出口正確還不代表設定完成

存取網域前，裝置通常需要透過 DNS 將網域名稱解析為位址。所謂 DNS 洩漏，是指原本應透過指定解析器或通道處理的 DNS 請求，實際上離開了預期路徑。例如網頁連線透過代理節點發出，但網域查詢仍直接交給本地網路提供的解析器。這可能造成地區解析不一致、規則誤判或隱私界線偏離預期。

DNS 問題不只表現為「洩漏」。如果 DNS 回傳適合本地網路的位址，而連線實際從遠端出口發出，目標服務可能連線緩慢或進入錯誤區域；如果規則依賴網域，但用戶端只能看到解析後的位址，網域分流也可能失效。部分用戶端透過 Fake-IP、遠端解析或 DNS 劫持將解析過程納入規則引擎，但具體能力取決於用戶端核心與設定。

檢查時應將「使用哪個出口」和「使用哪個解析器」分開。出口檢測只說明網頁連線從哪裡發出，不能單獨證明 DNS 路徑正確。切換節點或 DNS 模式後，還要考慮作業系統、瀏覽器和應用程式本身的快取。瀏覽器啟用獨立的加密 DNS 時，也可能繞過用戶端設定的解析器。

1. 確認接管方式：檢查目前使用的是系統代理還是 TUN，以及 DNS 是否由用戶端處理。
2. 清除舊工作階段：關閉目標應用程式中的既有連線，必要時清除 DNS 快取。
3. 驗證出口：確認目標請求顯示為預期的節點地區。
4. 驗證解析：檢查解析器是否符合目前設定，而不是只查看出口位址。
5. 回看日誌：確認網域命中預期規則，且沒有被更前面的規則攔走。

各平台用戶端差異：為什麼同一份訂閱的介面不一樣

訂閱內容可以相同，但 Windows、macOS、Linux、Android 與 iOS 用戶端的權限模型、背景限制和網路介面各不相同。一個用戶端能匯入某種協定，不代表它支援該協定的所有傳輸組合；同名功能也可能由不同核心實作。

Windows 用戶端通常同時提供系統代理和 TUN。啟用 TUN 時，虛擬網卡、系統防火牆與其他網路軟體是主要排查對象。macOS 同樣可以使用系統代理或網路延伸功能，但系統權限授權、睡眠喚醒和網路切換可能影響連線狀態。Linux 的用戶端型態差異更大，既有圖形介面，也有以設定檔和服務程序執行的核心；桌面代理變數、系統路由和容器網路需要分別確認。

Android 用戶端通常透過系統 VPN 介面接管流量，並可能提供依應用程式分流。系統的省電與背景管理會影響長時間連線，網路在 Wi-Fi 與行動數據之間切換時也可能觸發重新連線。iOS 用戶端受系統網路延伸機制管理，不同應用程式對協定、規則集和腳本功能的支援範圍各異，匯入前應先確認格式相容性。

跨平台移轉時，最穩妥的方式是重新匯入與目標用戶端相符的訂閱，而不是將某個平台匯出的完整設定原樣複製過去。完整設定可能包含特定核心的規則語法、腳本、策略群組或 DNS 欄位；另一個用戶端即使接受該檔案，也可能忽略無法辨識的部分。

新手排錯清單：從訂閱到流量逐層確認

當用戶端顯示異常時，不要同時修改協定、節點、DNS 和分流。一次改變多個變數，即使問題暫時消失，也無法知道真正原因。更有效的方法，是依照設定交付、建立連線、流量接管、規則比對和網域解析的順序逐層確認。

• ✅ 訂閱可以更新：連結有效，用戶端能解析對應格式。
• ✅ 節點可以連線：驗證、協定、傳輸與 TLS 參數相符。
• ✅ 流量已被接管：系統代理或 TUN 已啟用，目標應用程式已進入用戶端。
• ✅ 規則有命中：目標網域套用預期策略，而不是被前置規則覆蓋。
• ✅ 出口符合預期：新連線從所選地區發出。
• ✅ DNS 路徑正確：解析器與目前模式一致，沒有被應用程式單獨繞過。
• ❌ 不要依靠連線按鈕的顏色判斷所有設定是否正常。
• ❌ 不要將單一網站的快取、帳號地區或服務限制直接歸因於節點故障。

如果訂閱無法更新，但先前匯入的節點仍可連線，問題較可能位於設定取得層；如果所有節點都能完成握手，卻沒有應用程式流量，問題較可能位於接管層；如果只有特定網域走錯路徑，應查看規則與 DNS；如果某個平台異常而其他平台正常，則應優先比較用戶端核心、權限和支援的設定欄位。