VPN 新手名詞速查：訂閱、節點、線路類型、協議、分流、全域與規則模式

第一次接觸 VPN 或代理用戶端時，訂閱、節點、線路類型、協議、分流、全域模式和規則模式常被混為一談。其實它們位於不同層級：訂閱負責分發設定，節點是一組可連線的伺服器參數，線路描述資料如何抵達節點，協議規定用戶端與伺服器如何通訊，而分流模式決定哪些請求進入代理通道。

理解這些名詞，不必先背熟完整的網路原理。更實用的方法，是沿著一次連線的順序來看：用戶端讀取訂閱，取得節點清單；使用者選擇節點後，用戶端依照對應協議建立連線；系統流量再由全域或規則模式決定要走代理還是直連。只要先分清層級，多數設定頁面就不再難懂。

先分清訂閱、節點與伺服器

訂閱連結是一個可更新的設定入口

訂閱連結通常由伺服器產生，用戶端存取該連結後，會取得節點名稱、伺服器位址、連接埠、協議參數及必要的驗證資訊。它更像一份遠端設定清單，而不是某個特定節點。伺服器調整線路後，使用者可以在用戶端執行「更新訂閱」或「重新整理設定」，不必逐項重新填寫。

訂閱連結可能回傳經過編碼的文字，也可能回傳 Clash、sing-box 等用戶端能辨識的設定格式。直接用瀏覽器開啟時，即使看到一長串字元，也不代表連結損壞。正確做法通常是複製完整連結，再貼到用戶端的訂閱匯入位置。

節點是用戶端中可選擇的一組連線設定

節點通常包含目標伺服器、連接埠、協議、驗證參數和傳輸設定。用戶端清單中的「東京」「新加坡」或「美國」等名稱，多半只是方便辨識的標籤。節點名稱相同，不代表底層伺服器、入口或網路路徑完全相同；名稱不同，也可能共用部分基礎設施。

「伺服器」偏向實體或虛擬運算資源，「節點」則偏向使用者可連線的設定項目。一台伺服器可以承載不同協議或連接埠，形成多個節點設定。反過來，一個對外顯示的節點也可能經過負載調度，實際連線至不同後端。因此，選擇節點時應以實際連線表現和用途為準，不要只看名稱。

• ✅ 訂閱更新後，先確認原有節點是否被替換或重新命名。
• ✅ 匯入多個訂閱時，為不同來源加上清楚的群組名稱。
• ✅ 節點失效時先重新整理訂閱，再檢查用戶端時間與網路權限。
• ❌ 不要把訂閱連結當成單一節點位址手動拆分。
• ❌ 不要只憑地區名稱推測線路品質或具體路徑。

IEPL 專線、中轉與直連分別是什麼

線路類型描述的是本地網路如何抵達遠端節點，和 Shadowsocks、Trojan 等協議不是同一回事。使用相同協議的兩個節點，可以採用不同線路；同一類線路也能承載不同協議。把「線路」和「協議」混為一談，是新手選擇線路時最常見的誤區。

直連不代表一定更快

直連少了中轉環節，但網路路由不一定最短。跨電信業者、跨地區或國際出口壅塞時，資料可能繞行。相反地，位置合理的中轉入口，可以將本地到入口的這一段控制在較穩定的路徑上，再由後端完成跨境傳輸。因此，不能只用「經過的伺服器比較少」來判斷速度。

中轉也不等於節點位置

某個節點顯示為日本，通常表示出口位於日本，或主要用途是使用日本出口；但中轉入口可能位於其他地區。網站看到的出口 IP，與用戶端首先連線的入口不一定在同一位置。排查問題時，要區分「入口連線失敗」和「出口服務異常」。

IEPL 是線路資源，不是加密協議

IEPL 常用來描述國際乙太網路專線連線。它解決的是部分網路承載路徑問題，不負責定義用戶端驗證、加密或流量封裝方式。用戶端仍需使用具體協議連線至伺服器。看到「IEPL 節點」時，可以理解為該節點的部分傳輸鏈路使用了相應專線資源，而不是出現一種名為 IEPL 的用戶端協議。

常見協議名稱各代表什麼

協議決定用戶端與伺服器如何驗證、封裝並傳輸資料。用戶端必須支援節點所使用的協議及相關傳輸參數，否則即使伺服器位址和連接埠正確，也無法建立連線。以下名稱經常出現在訂閱設定中，但各自的設計重點並不相同。

Shadowsocks 設定相對精簡，支援的用戶端較多，但加密方式必須與伺服器一致。VMess 和 VLESS 常與 WebSocket、gRPC、TCP、TLS 或 REALITY 等傳輸與安全層組合使用。訂閱匯入的價值就在這裡：它可以將彼此關聯的參數作為完整設定交給用戶端，減少手動漏填。

Trojan 常搭配 TLS 與網域憑證驗證。若裝置時間明顯錯誤、網域填寫不一致或憑證驗證失敗，可能無法建立連線。遇到憑證錯誤時，應檢查系統時間和訂閱設定，而不是直接關閉憑證驗證。

Hysteria2 與 TUIC 都依賴 QUIC，主要運作於 UDP 之上。它們在部分高延遲或有封包遺失的網路中可能有較佳的傳輸表現，但前提是本地網路允許相應的 UDP 通訊。如果公司、校園、飯店或公共網路限制 UDP，這類節點可能連線失敗，此時可改用基於 TCP 的可用節點進行比較。

如何將訂閱連結匯入用戶端

不同用戶端的按鈕名稱可能不同，但匯入邏輯大致一致。先從可信賴的服務面板複製訂閱連結，再在用戶端新增遠端設定或訂閱，等待解析完成後選擇節點。除非明確理解每個欄位的用途，否則不要逐行改寫訂閱內容成手動設定。

1. 複製完整連結：確認開頭、參數或結尾字元沒有遺漏。某些聊天軟體會截斷長連結，複製後可先檢查文字是否完整。
2. 開啟訂閱管理：在用戶端尋找「訂閱」「設定」「遠端設定」或「從 URL 匯入」等入口。
3. 貼上並儲存：為訂閱填寫方便辨識的名稱，然後執行更新。若用戶端要求選擇設定格式，應以服務說明為準。
4. 選擇節點：在代理群組或節點清單中選擇目標地區，不要停留在未指定出口的空白設定上。
5. 選擇執行模式：日常使用通常先採用規則模式，需要完整測試代理鏈路時，再暫時切換至全域模式。
6. 驗證連線：開啟網路檢測頁面，確認出口 IP、DNS 與預期一致，再測試實際需要使用的網站或應用程式。

更新訂閱通常會覆蓋由該訂閱產生的節點。若直接修改訂閱節點的內部參數，下次更新時可能恢復原值。需要長期保留的自訂規則，適合放在用戶端支援的覆寫、擴充設定或本機規則檔案中，而不是直接修改遠端節點。

訂閱連結
  → 用戶端取得遠端設定
  → 解析節點與代理群組
  → 選擇節點
  → 建立協議連線
  → 由分流規則判斷請求去向
  → 代理或直連

• ✅ 匯入後檢查節點清單是否正常顯示，而不是只看「新增成功」提示。
• ✅ 定期使用用戶端內建的訂閱更新功能取得設定變更。
• ✅ 更換用戶端前，確認新用戶端支援訂閱中的協議和傳輸方式。
• ❌ 不要在來源不明的網站轉換包含憑證的訂閱連結。
• ❌ 不要同時啟用多個會接管系統網路的用戶端來進行排查。

如何選擇全域、規則與直連模式

執行模式決定流量進入用戶端後如何處理。它不會改變節點本身，也不會將直連線路變成中轉線路。新手看到「全域」時，容易以為速度會更快；其實它只表示更多請求會交給目前的代理節點。

全域模式：大多數流量統一經由代理

全域模式適合暫時排查規則遺漏，或確認某個網站在代理路徑下是否能夠存取。缺點是本地網站、區域網路服務和不需要代理的應用程式也可能繞行，增加額外延遲，還可能影響印表機、路由器管理頁面或本機開發服務。

規則模式：依網域、IP 或應用程式分類

規則模式會依規則集判斷請求。常見邏輯包括：區域網路位址直連、本地常用網站直連、需要國際線路的網域交給代理、廣告或惡意網域依規則攔截。規則可以依據網域後綴、完整網域、IP 網段、程序名稱或規則集合，具體能力取決於用戶端與作業系統平台。

規則匹配通常有先後順序。較具體的規則應放在較寬泛的規則之前，最後未匹配的流量則由兜底規則處理。例如，某個網域已被較前面的直連規則命中，後面的代理規則就不會再生效。遇到「某個網站沒有使用預期節點」時，應查看連線記錄中的命中規則，而不是只反覆切換節點。

直連模式：不經過代理節點

直連模式常用於暫停代理、比較本地網路表現或存取區域網路裝置。有些用戶端的「關閉系統代理」只是停止接管遵循系統代理的應用程式，已啟用的 TUN 模式可能仍在處理流量。因此，暫停連線時要查看用戶端狀態，而不是只看系統代理開關。

系統代理、TUN 與應用程式分流的差異

系統代理是作業系統提供給應用程式讀取的代理設定。瀏覽器和部分桌面軟體會遵循它，但某些遊戲、命令列工具或自行建立網路連線的應用程式可能忽略系統代理。因此可能出現瀏覽器已生效，其他應用程式仍直連的情況。

TUN 模式透過虛擬網路介面接管更廣泛的 IP 流量，再交由用戶端判斷要使用代理或直連。它對不讀取系統代理設定的應用程式更有效，但通常需要額外的系統權限，也更容易與其他網路工具、防火牆、虛擬機器或企業安全軟體發生路由衝突。

應用程式分流則依程序或應用程式決定去向。行動平台常見「僅代理所選應用程式」或「繞過所選應用程式」，桌面用戶端可能提供程序規則。應用程式更新後若可執行檔路徑改變，舊規則可能不再命中，因此排查時要核對實際程序名稱。

• ✅ 瀏覽器有效但遊戲無效時，檢查遊戲是否忽略系統代理。
• ✅ 開啟 TUN 後無法存取區域網路時，檢查區域網路繞過設定和路由規則。
• ✅ 應用程式分流失效時，核對程序名稱與用戶端執行權限。
• ❌ 不要同時讓系統代理、TUN 和其他網路工具重複接管同一流量，再憑感覺判斷故障。

DNS 洩漏與分流為何互相關聯

存取網域前，裝置通常需要透過 DNS 將網域名稱解析為 IP 位址。如果網頁流量經由代理，但 DNS 請求仍傳送至不符合預期的本地解析器，就可能暴露存取網域的解析行為，也可能取得與代理出口地區不相符的位址。這通常稱為 DNS 洩漏或 DNS 路徑不一致。

規則分流依賴網域時，用戶端需要在適當階段取得網域資訊。若應用程式提前解析，只將 IP 交給用戶端，純網域規則可能無法命中；若 DNS 回傳受地區影響的位址，也可能使內容分發網路選擇不合適的入口。因此，現代用戶端通常會將 DNS、規則匹配和代理連線放在同一套設定中處理。

常見排查順序

1. 確認用戶端的 DNS 模組是否啟用，並查看目前使用的解析方式。
2. 確認瀏覽器本身的加密 DNS 設定是否繞過用戶端設定。
3. 檢查目標網域命中的是直連、代理還是兜底規則。
4. 清除作業系統與瀏覽器的 DNS 快取後重新測試。
5. 在網路檢測頁面比較出口 IP 與 DNS 解析器是否符合目前模式的預期。

DNS 檢測結果不應只看解析器名稱。某些公共解析服務採用全球調度，顯示的地區可能與實際網路路徑不同。更重要的是確認請求是否依預期經由用戶端處理、是否出現本地電信業者的解析器，以及切換模式後結果是否產生合理變化。

不同平台的用戶端差異

相同訂閱在不同平台上，顯示方式和可用功能可能不同。原因通常不是訂閱內容改變，而是作業系統權限、用戶端核心與網路接管方式不同。

Windows

Windows 用戶端通常同時提供系統代理和 TUN。系統代理適合瀏覽器及遵循系統設定的軟體；遊戲、商店應用程式或部分命令列程式可能需要 TUN。啟用 TUN 時，用戶端可能要求系統管理員權限，以建立虛擬網卡和寫入路由。

macOS

macOS 上的系統代理同樣無法涵蓋所有應用程式。使用網路延伸功能或虛擬介面時，系統會要求使用者授權。若用戶端更新後連線異常，可檢查網路延伸功能的權限是否仍然有效，以及系統中是否殘留其他 VPN 設定。

Android

Android 用戶端通常透過系統 VPN 介面接管流量，並可提供依應用程式分流。系統同一時間通常只允許一個啟用中的 VPN 通道，因此其他防火牆、廣告過濾或企業網路應用程式可能與代理用戶端互相取代。

iOS 與 iPadOS

iOS 和 iPadOS 用戶端依賴系統提供的網路延伸功能。不同用戶端支援的協議核心並不完全一致，匯入成功但節點無法啟動時，應先核對協議與傳輸方式是否受支援。系統的應用程式控制也會受應用程式能力與裝置管理策略影響。

連線失敗時依層級排查

有效的排查方法不是連續點擊多個節點，而是判斷故障發生在哪一層。先確認本地網路，再確認訂閱與節點，之後檢查協議連線，最後檢查規則與 DNS。每次只改變一個變數，才能知道是哪項調整產生作用。

• ✅ 本地網路層：關閉代理後，確認一般網站可以正常存取。
• ✅ 訂閱層：更新訂閱並檢查是否回傳節點，而不是登入頁面或錯誤文字。
• ✅ 節點層：選擇同一訂閱中的其他可用節點進行比較。
• ✅ 協議層：查看記錄中的逾時、憑證、驗證、UDP 或不支援參數提示。
• ✅ 接管層：確認系統代理或 TUN 已依預期啟用，且沒有其他工具衝突。
• ✅ 規則層：查看目標連線命中的規則與代理群組。
• ✅ DNS 層：檢查解析路徑、快取與瀏覽器獨立設定。
• ❌ 不要同時更換節點、協議、DNS 和執行模式，否則無法定位原因。

記錄中的「逾時」只表示在規定時間內沒有完成連線，無法單獨說明是伺服器、線路還是本地網路出了問題；「驗證失敗」較偏向憑證或系統時間問題；「憑證名稱不相符」通常需要檢查網域、TLS 設定和系統時間；「不支援的協議或傳輸」則應檢查用戶端核心版本。

掌握這套層級後，設定頁面中的名詞便能重新串聯起來：訂閱負責提供設定，節點提供連線目標，線路影響抵達目標的路徑，協議規定通訊方式，系統代理或 TUN 負責接管流量，規則模式決定請求去向，DNS 則參與網域解析與分流判斷。選擇時不必追逐最長的功能清單，能與目前的平台和網路環境穩定配合，才是更實際的標準。