這篇 VPN 名詞解釋 從訂閱、節點、協定與分流四個最常見的概念開始，說明用戶端介面中的各項名稱分別控制什麼。先記住一個判斷原則：訂閱負責將設定交給用戶端，節點決定流量從哪裡通過，協定規定用戶端如何與服務端通訊，分流規則則決定哪些要求需要使用線路。它們彼此相關，但不是同一項設定。
不少連線問題都源自概念混用。例如，訂閱匯入成功，不代表節點當下必定能連線；節點名稱標示某個地區，也不等於整段網路都是專線；切換協定也不會自動修正錯誤的 DNS 設定。了解每一層的職責後，排查就能從反覆點按鈕，改為依照連線路徑逐段確認。
訂閱、設定檔與訂閱連結是什麼
訂閱可以理解為由服務端維護的設定清單。清單可能包含節點位址、連接埠、驗證資訊、協定參數、傳輸方式，以及用於顯示的節點名稱。將訂閱連結匯入相容的用戶端後，用戶端會讀取清單並產生可選擇的節點，而不只是開啟一個普通網頁。
訂閱連結與單一節點設定的差異，在於維護方式不同。單一設定只描述一個連線入口，線路調整後通常需要重新匯入；訂閱則能在同一個入口更新一組設定。用戶端執行「更新訂閱」時，會重新取得服務端提供的清單，但本機分組、測速結果與自訂規則是否保留，仍取決於具體用戶端的合併邏輯。
訂閱連結通常包含可識別帳戶或套餐權限的資訊，因此應視為存取憑證，不要發布在公開頁面、共用文件或截圖中。只從用戶端刪除訂閱，不會改變服務端已簽發的存取憑證；若連結意外公開，應透過服務面板重設，而不是只在本機重新匯入。
- ✅ 匯入前確認用戶端支援訂閱所使用的協定與設定格式。
- ✅ 更新前留意本機自訂分組與規則是否會被遠端設定覆蓋。
- ✅ 將訂閱連結按照帳戶憑證管理，不要在公開環境轉發。
- ❌ 不要把「訂閱匯入成功」直接理解為所有節點都已完成連線測試。
匯入後用戶端實際做了什麼
匯入流程通常包括取得訂閱內容、解析設定、建立代理分組與載入規則。完成這些步驟後，用戶端才會在介面中列出節點。若匯入階段發生錯誤，問題多半出在連結有效性、網路存取、設定格式或用戶端相容性；若節點已出現但無法連線，則應繼續檢查協定參數、系統時間、網路環境與服務端狀態。
掃描匯入與貼上連結本質上沒有差別，QR Code 只是將文字編碼成方便傳遞的圖形。匯入後仍應核對訂閱名稱、節點清單與更新時間，避免將過期設定誤認為用戶端故障。
節點、伺服器與線路有何差異
節點是用戶端中可選擇的連線設定。它通常指向一個服務端入口，並附帶協定與驗證參數。節點名稱可能包含國家、地區、城市、入口類型或用途標籤，但名稱主要用於辨識，無法完整描述底層網路路徑。
伺服器偏向基礎設施概念，可能是實體設備、虛擬執行個體，或承載代理服務的執行環境。一台伺服器可以承載多個節點設定，一個節點也可能透過調度系統指向不同後端。因此，不能只憑節點數量推測實體伺服器規模，也不能把介面中的每一列都視為完全獨立的硬體。
線路描述資料從使用者網路到入口、再到出口與目標服務所經過的路徑。它涉及本地接入、電信商互聯、跨境傳輸、中轉入口與最終出口。節點是使用者可以點選的設定入口，線路則是流量實際經過的網路鏈路。
| 術語 | 主要含義 | 常見誤解 | 判斷重點 |
|---|---|---|---|
| 節點 | 用戶端中的一項可連線設定 | 每個節點都對應一台獨立實體設備 | 地區、協定、入口與目前連線表現 |
| 伺服器 | 承載代理服務的運算與網路資源 | 伺服器所在地必然等於最終出口位置 | 實際出口、路由與服務端部署方式 |
| 線路 | 流量從本地到目標服務所經過的路徑 | 節點名稱能說明整段鏈路品質 | 入口方式、中轉路徑、出口與目標網路 |
| 出口 | 造訪目標網站時對方看到的網路來源 | 入口地區與出口地區永遠相同 | 出口位址、DNS 解析位置與目標服務策略 |
直連、中轉與 IEPL 專線
直連線路通常表示用戶端直接與境外服務端建立連線，中間不經過服務商設定的額外入口。結構較簡單，但使用體驗會明顯受到本地電信商、跨網互聯與國際公網路由變化影響。距離較近不一定更穩定，因為網路路徑不是地圖上的直線。
中轉線路會先連接較近或互聯條件更合適的入口，再由入口將流量轉送至目標出口。中轉可以避開部分不理想的公網路徑，也方便服務端調整出口，但會增加鏈路環節。入口、轉發段或出口任何一段發生壅塞，都可能影響最終體驗。
IEPL 專線通常指國際乙太網路專線能力，用於連接特定網路端點。它在路由組織與資源保障方式上有別於一般國際公網，但「專線」不應理解為從使用者設備到目標網站的每一段都完全獨占。使用者到入口的接入網路、出口到目標服務的網路，以及本地無線環境，仍會參與最終連線。
代理協定名稱分別代表什麼
協定規定用戶端與服務端如何建立工作階段、驗證權限、封裝資料並處理傳輸。協定名稱不等於線路品質：同一種協定可以部署在不同網路上，不同協定也可能共用同一出口。實際體驗同時受到網路路徑、服務端負載、用戶端實作、傳輸層與目標應用程式影響。
| 協定 | 核心特色 | 設定時應注意什麼 |
|---|---|---|
| Shadowsocks | 輕量的加密代理協定，用戶端生態較完整 | 加密方式、驗證資訊與用戶端支援情況 |
| VMess | 常見於 V2Ray 生態，包含身分驗證與多種傳輸組合 | 使用者識別碼、傳輸方式、TLS 與路徑參數是否一致 |
| Trojan | 常與 TLS 搭配，讓連線形態接近一般加密流量 | 網域、憑證驗證、密碼與傳輸設定 |
| VLESS | 驗證與傳輸層相對分離，常與 TLS 等安全層組合 | 使用者識別碼、流量控制、傳輸方式與安全層設定 |
| Hysteria2 | 基於 QUIC 與 UDP，著重在複雜網路中利用壅塞控制維持傳輸 | UDP 可用性、驗證、TLS 與服務端參數 |
| TUIC | 基於 QUIC 的代理協定，支援多路複用與 UDP 轉發 | 用戶端版本相容性、壅塞控制與憑證驗證 |
為什麼協定參數必須完整匹配
代理連線不只是核對一個伺服器位址。用戶端與服務端還需要在連接埠、驗證資訊、傳輸方式、TLS 設定、網域與路徑等參數上保持一致。只要關鍵欄位不匹配，就可能出現逾時、交握失敗、憑證錯誤，或建立連線後沒有資料。
Trojan 與使用 TLS 的 VLESS、VMess 設定，通常需要正確處理網域與憑證驗證。略過驗證可能暫時避開憑證設定問題，卻會削弱用戶端確認服務端身分的能力，不應作為一般排障方案。較合適的做法是檢查系統時間、網域、憑證鏈與訂閱內容是否一致。
Hysteria2 與 TUIC 依賴 QUIC 和 UDP。某些辦公室網路、公共網路或路由設備會限制 UDP，此時即使設定正確，也可能無法穩定通訊。切換至基於 TCP 的相容設定可用於定位問題，但不代表某個協定在所有網路中天生更好。
選擇協定的重點不是追求最新。先確認用戶端是否完整支援，再確認目前網路能否承載相應傳輸，最後透過實際應用驗證持續連線。協定名稱只能說明通訊方式，無法單獨保證速度與穩定性。
系統代理、TUN 與 VPN 介面如何運作
桌面用戶端中的「系統代理」通常會修改作業系統的代理設定，讓遵循該設定的應用程式將 HTTP 或 SOCKS 要求交給用戶端。這種方式部署簡單，但不是所有程式都會讀取系統代理。有些遊戲、命令列工具、獨立更新程式或自行實作網路堆疊的應用程式，可能仍會直接連線。
TUN 模式會建立虛擬網路介面，在更接近 IP 層的位置接收流量，再依規則轉送至代理或直連路徑。它能涵蓋更多不支援系統代理的程式，也更適合處理 UDP，但通常需要額外的系統權限，並可能與安全軟體、其他網路工具或企業網路政策衝突。
Android 與 iOS 上的代理用戶端通常使用系統提供的 VPN 介面接管流量。這裡的「VPN」更多是指作業系統開放的網路通道能力，介面中的資料仍可能由 Shadowsocks、Trojan 或其他代理協定承載。macOS 通常透過網路延伸功能實現類似能力，Windows 用戶端則可能同時提供系統代理與 TUN，兩種模式的涵蓋範圍與權限要求不同。
- ✅ 瀏覽器可以存取、但獨立應用程式無法連線時，檢查該應用程式是否遵循系統代理。
- ✅ 需要涵蓋 UDP，或程式不讀取代理設定時，再評估 TUN 模式。
- ✅ 啟用 TUN 後出現網路異常，檢查路由衝突、權限與其他網路工具。
- ❌ 不要同時啟用多個接管網路的用戶端，期待它們自動協調路由。
「允許區域網路連線」是什麼意思
這個選項通常允許同一區域網路內的其他裝置連接目前用戶端開放的代理連接埠。它不會自動讓其他裝置取得設定，也不會自動完成存取控制。啟用後應確認監聽位址、防火牆與驗證設定，避免將本機代理連接埠暴露在不受信任的網路環境中。若沒有共用代理的需求，維持僅限本機存取會更容易管理。
全域模式、規則模式與直連模式怎麼選
全域模式通常會讓用戶端接管範圍內的流量統一經過目前的代理節點。它適合用來判斷某個應用程式是否因分流規則而未使用代理，也適合短時間驗證出口。但全域不代表作業系統中的所有資料都必然被接管；如果用戶端只啟用了系統代理，不遵循系統代理的程式仍可能直連。
規則模式會依據網域、IP、應用程式、連接埠或規則集，決定使用代理、直連或拒絕。它能減少不必要的繞行，也是日常使用中較常見的選擇。規則需要持續維護：網域變更、內容傳遞網路調整或應用程式新增介面，都可能使舊規則判斷不完整。
直連模式通常會讓流量略過代理。它適合排查本地網路本身是否正常，也可用於存取只允許本地網路的資源。直連不完全等同於「關閉用戶端」，因為用戶端仍可能處理 DNS、虛擬介面或規則流程，具體行為取決於實作方式。
| 模式 | 流量處理方式 | 適用情境 | 需要留意 |
|---|---|---|---|
| 全域 | 接管範圍內的要求統一使用代理 | 驗證節點與排查分流遺漏 | 本地服務可能繞遠，未被接管的應用程式仍可能直連 |
| 規則 | 依網域、位址或應用程式條件選擇路徑 | 日常存取與本地、國際流量並用 | 規則集需要更新，也要留意錯誤匹配 |
| 直連 | 要求不經過代理節點 | 存取本地資源與排查基礎網路 | 用戶端的 DNS 或虛擬介面可能仍在運作 |
分流規則依什麼順序匹配
多數規則引擎會由上而下檢查，命中後停止繼續匹配，最後由兜底規則處理未命中的要求。因此，較具體的應用程式或網域規則，通常應放在較寬泛的地區規則之前。若寬泛規則先命中，後面的精確規則就不會生效。
目標應用程式專用網域 → 指定代理分組
本地服務網域 → 直連
區域網路位址 → 直連
其餘未命中要求 → 預設分組這段示意強調的是優先順序，不是可以直接複製的設定語法。不同用戶端使用 YAML、JSON、圖形化規則或自有格式，欄位名稱並不一致。修改前應先確認設定是由本機維護，還是由遠端訂閱產生，避免更新訂閱後遺失自訂內容。
DNS 洩漏、解析與出口位置
存取網域前，裝置通常要先透過 DNS 將網域解析為 IP 位址。若網頁流量經過代理，但 DNS 查詢仍由本地網路直接送出，解析要求就沒有沿用預期路徑，這種情況通常稱為 DNS 洩漏。它可能暴露正在查詢的網域，也可能因本地解析結果與代理出口地區不一致而導致存取異常。
用戶端常見的 DNS 處理方式包括使用系統解析器、將查詢轉交遠端、透過加密 DNS 取得結果，或由規則引擎針對不同網域選擇解析路徑。加密 DNS 能保護查詢傳輸過程，但如果要求仍從本地網路直接送出，就不會自動等於「跟隨代理出口解析」。判斷時要同時確認查詢從哪裡送出、由誰回覆，以及回傳結果交給哪條路由。
有些用戶端會使用虛擬位址機制，先將網域映射至保留位址，再於內部還原網域並套用分流。這有助於處理只向系統要求 IP 的程式，但部分區域網路服務、企業軟體或依賴真實位址判斷的應用程式，可能需要例外規則。看到 Fake IP、遠端 DNS、DNS 劫持等選項時，不應只憑名稱切換，應配合用戶端文件與目前模式確認。
- ✅ 目標網站無法開啟，但直接輸入已知位址可以存取時，優先檢查 DNS 解析。
- ✅ 出口地區正確，但內容地區判斷異常時，同時核對 DNS 與應用程式快取。
- ✅ 切換節點後清除 DNS 快取並重新連線應用程式，避免繼續使用舊工作階段。
- ❌ 不要把更換 DNS 當成修復所有連線問題的通用方法。
用戶端選項的通用排查順序
不同平台的用戶端介面差異很大，但排查順序可以保持一致。先確認訂閱是否正常更新，再確認節點參數能否建立連線，接著檢查系統接管方式，最後處理規則與 DNS。依照這個順序，可以避免基礎連線尚未建立時，就過早修改複雜的分流設定。
- 檢查訂閱狀態：確認訂閱仍然有效，最近更新沒有解析錯誤，所需節點已出現在清單中。
- 選擇相容節點：使用用戶端明確支援的協定，核對系統時間與 TLS 相關資訊。
- 驗證基礎連線：暫時使用全域模式存取目標服務，區分節點故障與規則遺漏。
- 確認接管範圍：瀏覽器可用、其他應用程式不可用時，判斷是否需要 TUN 或系統 VPN 介面。
- 檢查 DNS：確認解析路徑與分流目標一致，切換線路後清除仍在重複使用的舊連線。
- 恢復日常規則：基礎連線穩定後再啟用規則模式，並查看目標要求實際命中了哪個分組。
日誌也是重要線索。訂閱解析錯誤、連線逾時、TLS 交握失敗、DNS 查詢失敗與規則命中，通常會留下不同紀錄。閱讀日誌時先找最早出現的關鍵錯誤，不要被後續大量重複的重試資訊干擾。提交客服工單時，可以提供錯誤類型、用戶端名稱、平台、使用模式與發生問題的節點類別，但應遮蓋訂閱連結、驗證資訊與完整設定。
如果只是日常使用，通常不需要頻繁修改底層參數。保持訂閱更新，選擇與目前網路相容的節點，在規則模式下使用，並在特定應用程式未被接管時檢查 TUN 與 DNS，已能涵蓋多數常見情境。真正需要手動編輯設定時，再針對單一問題逐項調整，每次只變更一個變數，結果會更容易判斷。