VPN 新手名詞速查：訂閱、節點、協定、分流一次搞懂

第一次接觸 VPN 時，最容易混淆的不是操作按鈕，而是訂閱、節點、線路、協定和分流這些名詞。它們常出現在同一個用戶端裡，卻分別描述設定來源、接入入口、網路路徑、傳輸方式和流量處理規則。只要先分清各自負責的環節，後續匯入訂閱、切換節點和排查斷線就會清楚許多。

還有一點需要先說明：日常討論中，「VPN」常被用來泛稱各種加密通道和代理工具，但 Shadowsocks、VMess、Trojan、VLESS、Hysteria2 與 TUIC 更精確地說是代理協定或傳輸方案。用戶端可以透過系統提供的 VPN 或 TUN 介面接管裝置流量，但不代表這些協定本身都屬於傳統企業 VPN。理解這項差異，就能避免把「用戶端工作模式」和「節點協定」混為一談。

先分清服務、用戶端與訂閱

服務不是用戶端

服務指的是節點設定、線路資源、流量規則和帳戶管理等交付內容；用戶端則是安裝在電腦、平板或其他裝置上的軟體。用戶端本身通常不會自動附帶可用線路，就像郵件軟體不會自動提供信箱一樣。你需要將服務提供的設定匯入相容用戶端，用戶端才能取得伺服器位址、連接埠、協定和驗證資訊。

同一份服務設定可能相容於多個用戶端，但相容不代表功能完全相同。一個用戶端可能支援規則分流和 TUN，另一個只提供系統代理；一個可以自動更新訂閱，另一個則需要手動重新整理。遇到教學介面與自己不同時，應先核對用戶端名稱、平台和版本，不要只根據按鈕顏色判斷操作位置。

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

訂閱連結通常是專屬於帳戶的網路位址。用戶端存取這個位址後，會取得節點名稱、伺服器入口、協定參數和分組規則等內容。它不是一般網頁，也不是一定要用瀏覽器開啟的下載頁面。直接在瀏覽器中存取時，看到編碼文字、下載檔案或空白頁面，都不一定代表連結失效；正確做法通常是將完整連結貼到用戶端的「訂閱」、「設定檔」或「遠端設定」入口。

訂閱連結通常包含可識別帳戶的權杖，因此應將它視為敏感設定保存。公開截圖時不要露出完整連結，也不要把連結貼到不明的轉換網站。其他人取得有效訂閱後，可能讀取其中的節點資訊；服務端日後調整節點時，對方也可能同步收到更新。

「匯入訂閱」和「更新訂閱」是兩個不同動作。匯入是讓用戶端第一次記住這個設定來源；更新則是用戶端再次存取原始位址，將服務端的最新內容同步到本機。節點改名、入口遷移或規則變更後，只切換舊節點未必能解決問題，應先更新訂閱。部分用戶端更新時會覆蓋訂閱內設定的本機修改，因此需要長期保留的自訂規則，適合放在用戶端提供的覆寫或本機規則區域。

• ✅ 確認複製的是完整訂閱位址，沒有遺漏開頭、結尾或中間字元。
• ✅ 從用戶端的訂閱或遠端設定入口匯入，不要把編碼內容當成錯誤頁面。
• ✅ 匯入後主動執行更新，再檢查節點清單是否出現。
• ✅ 儲存自訂規則前，確認更新訂閱是否會覆蓋本機修改。
• ❌ 不公開訂閱連結，也不要將它提交給來源不明的線上轉換工具。

節點、伺服器與線路有什麼不同

節點是使用者在用戶端中可以選擇的一組接入設定。它通常包含伺服器位址、接入連接埠、協定、驗證資訊和傳輸參數。清單中的「東京」、「洛杉磯」或「新加坡」多半只是方便辨識的顯示名稱，不一定代表伺服器機房、出口位址和整段網路路徑都位於同一地點。

伺服器是實際處理連線的軟體與運算資源。一部伺服器可以承載多個節點設定，一個節點也可能先接入中轉伺服器，再透過另一處出口存取目標網站。因此，「節點」更接近用戶端看到的設定入口，「伺服器」則更接近後台實際運作的資源。

線路描述的是資料從本機到出口的大致路徑和調度方式。線路品質不只取決於地理距離，也會受到電信商互連、路由繞行、晚間壅塞、入口負載以及目標網站網路狀況影響。距離較近的節點通常值得優先嘗試，但不能只看國家或地區名稱下結論。

直連、中轉與 IEPL 專線

直連通常表示裝置直接連接境外入口，中間沒有服務商額外部署的接力節點。結構較簡單，路徑主要受本地電信商與國際網際網路路由影響。互連順暢時可以有不錯的表現，但遇到網路壅塞或路由繞行時，波動也可能更明顯。

中轉通常表示裝置先連接較近或互連較好的入口，再由服務商控制的鏈路轉發到出口。中轉的價值在於重新選擇跨網路徑，並不等同於速度一定更快。入口選擇、轉發容量和出口負載只要有一項不合適，都可能抵消中轉帶來的改善。

IEPL 原本指電信商提供的國際乙太網路專線類連線，重點是相對獨立且可管理的跨境承載路徑。在實際產品標籤中，「IEPL」有時只描述線路的一部分，使用者端仍可能先經過共享入口或公網接入。比較時應了解服務商如何定義入口、中轉和出口，不要只憑節點名稱判斷整段路徑。

常見代理協定各自負責什麼

協定規定用戶端與伺服器如何驗證、加密、封裝和傳輸資料。訂閱只是將協定參數交給用戶端，不會自動把一種協定轉換成另一種。用戶端不支援節點使用的協定時，常見情況是節點無法匯入、匯入後缺少欄位，或按下連線後立即失敗。

協定名稱無法單獨決定最終速度。線路壅塞時，改換封裝方式未必能解決容量問題；本地網路限制 UDP 時，依賴 QUIC 的方案可能無法連線，而基於 TCP 或 TLS 的設定仍可能正常運作。反過來，在延遲與封包遺失明顯的鏈路上，設計完善的 QUIC 方案可能具備更順暢的恢復能力。正確做法是先確認網路條件，再比較同一時段、相近出口的不同協定。

TLS 也不代表「已經連線成功」。在 Trojan 或採用 TLS 的 VLESS 設定中，用戶端需要驗證憑證和伺服器名稱。裝置時間明顯錯誤、網域填寫不一致、憑證失效或用戶端關閉必要驗證，都可能導致交握異常。遇到憑證錯誤時，應修正設定或更新訂閱，不要把關閉驗證當作長期處理方式。

全域模式、規則模式與直連模式怎麼選

用戶端中的「模式」決定流量去向，不是切換協定的按鈕。全域模式通常會將由用戶端接管的流量統一交給代理節點；規則模式會先檢查網域、位址、應用程式或網路類型，再決定代理、直連或阻擋；直連模式則讓流量繞過代理，適合暫時排查或暫停代理。

全域模式適合驗證，不一定適合長期使用

全域模式的規則鏈最簡單，適合剛匯入設定後驗證節點是否可用。如果目標網站在全域模式下正常、規則模式下失敗，問題大多不在節點本身，而在規則比對、DNS 結果或用戶端的流量接管範圍。長期維持全域模式，可能讓本地網站、區域網路裝置和不需要代理的下載流量也經過遠端出口，增加繞路並影響使用體驗。

規則模式取決於「比對順序」

規則通常會從較具體的條件開始比對，例如應用程式、網域後綴或位址範圍，最後再由兜底規則處理未命中的請求。同一個網域若同時符合多條條件，用戶端通常會採用第一個命中的結果。將寬泛規則放在前面，可能導致後面的精確規則永遠無法生效。

規則中的「代理」也不一定直接指向某個固定節點，它可能指向一個策略群組。策略群組再根據手動選擇、連通性檢查或服務端下發邏輯決定節點。因此，看到規則寫著代理，不能證明流量已從預期地區出口送出；仍應檢查策略群組目前的選項和實際出口位址。

系統代理與 TUN 的接管範圍不同

系統代理是將代理位址寫入作業系統設定，願意遵循該設定的應用程式會透過用戶端轉發。部分遊戲、命令列程式、獨立網路元件和自行實作連線的應用可能忽略系統代理。TUN 模式則會建立虛擬網路介面，在更底層接管 IP 流量，涵蓋範圍通常更廣，但也更容易與安全軟體、其他 VPN、虛擬機網路或企業網路政策發生衝突。

• ✅ 初次驗證節點時先使用全域模式，確認基本連線與出口是否正常。
• ✅ 全域正常但規則模式異常時，檢查網域規則、策略群組和 DNS 設定。
• ✅ 瀏覽器正常但命令列或獨立應用程式失敗時，檢查該程式是否遵循系統代理。
• ✅ 需要涵蓋更多應用程式時再考慮 TUN，並留意其他網路工具是否同時接管流量。
• ❌ 不要同時啟用多個具備流量接管能力的用戶端，以免路由和 DNS 互相覆蓋。

DNS 洩漏、出口位址與 WebRTC 各代表什麼

DNS 的工作是將網域名稱解析成網路位址。連線代理後，如果網域查詢仍由本地網路提供的解析器直接處理，而使用者原本預期查詢應經由加密通道或指定的遠端解析器，這種不符合預期的旁路查詢通常稱為 DNS 洩漏。它不一定會讓網頁立即無法開啟，但可能暴露曾存取哪些網域，也可能回傳與代理出口不相符的位址，進而造成規則判斷或地區存取異常。

「DNS 走代理」和「網頁流量走代理」是兩項獨立設定。有些用戶端會先在本地解析，再根據結果分流；有些會依網域規則決定去向，並將查詢交給不同解析器；還有些會提供虛擬位址映射，讓網域規則在建立連線前保持可用。不同用戶端的實作不能直接照搬，尤其不要在不了解映射方式時任意複製整段 DNS 設定。

出口位址是網站看到的公開來源位址。連線成功後，如果出口仍顯示本地網路位址，可能是目前應用程式未被接管、規則判定為直連，或用戶端只設定了系統代理而應用程式忽略了它。若出口已經變更但 DNS 解析位置仍不符合預期，應單獨檢查 DNS 路由，而不是繼續更換節點。

WebRTC 是瀏覽器和即時通訊應用使用的一組技術。在某些環境下，它可能暴露與頁面一般請求不同的候選網路位址。現代瀏覽器、作業系統與網路結構對它的處理差異很大，不能只因檢測頁面出現一個區域網路位址，就判定代理失效。重點應放在公開候選位址是否繞過預期出口，以及瀏覽器是否遵循目前的代理或 TUN 路由。

不同平台的用戶端為什麼操作方式不同

Windows 與 macOS 用戶端通常可以同時提供系統代理和 TUN，但安裝虛擬網路元件、申請系統權限以及處理路由衝突的方式不同。桌面版瀏覽器大多會讀取系統代理，命令列工具則可能需要另外設定環境變數或自身的代理選項。在終端機中存取失敗，不能直接代表瀏覽器使用的節點失效。

Android 用戶端通常透過系統 VPNService 接管流量，較常見的功能包括分應用程式代理、繞過區域網路，以及依應用程式決定代理或直連。系統省電策略可能限制用戶端在背景執行，鎖定螢幕後頻繁斷線時，應檢查背景限制和電池最佳化，而不是只反覆更換協定。也要看清分應用程式清單的含義：有些清單表示「只有選取的應用程式經過代理」，有些則表示「選取的應用程式繞過代理」。

iOS 用戶端依賴系統提供的網路延伸功能。匯入訂閱後，首次連線通常需要允許新增 VPN 設定。不同用戶端對規則集、指令碼、協定和依應用程式控制的支援差異很大，桌面教學中的 TUN、系統代理或複雜覆寫選項，未必能在 iOS 中原樣找到。出現設定不相容時，應使用服務明確支援的設定格式，不要強行改寫未知欄位。

瀏覽器擴充功能只會處理該瀏覽器內可代理的請求，不會自動接管其他應用程式、系統更新或命令列程式。路由器用戶端可以涵蓋連入該網路的多部裝置，但規則、DNS 與硬體效能都由路由器負責，排查難度也更高。新手更適合先在單一裝置上驗證訂閱、節點和規則，再考慮移轉到路由器。

從匯入訂閱到驗證連線的完整流程

新手排查最常見的問題，是同時修改節點、協定、DNS、TUN 和規則，最後無法判斷哪項改動有效。更穩妥的做法是按照固定順序逐層確認，每一步只驗證一個環節。以下流程適用於大多數支援遠端訂閱的用戶端，具體按鈕名稱則以所使用的用戶端為準。

1. 確認用戶端相容性。先核對平台、用戶端名稱與服務支援的協定。訂閱可以匯入，不代表其中每個節點都能被目前的用戶端正確辨識。
2. 匯入完整訂閱連結。將連結貼入訂閱或遠端設定入口，為設定取一個容易辨識的名稱，然後執行更新。
3. 查看更新結果。確認用戶端沒有驗證、格式或網路錯誤，並檢查節點清單是否出現。若清單為空，先處理訂閱，不要進入後續測速。
4. 選擇推薦節點。優先選擇服務明確標示為常用，或與目前所在地網路互連較合適的節點，不要一開始就根據名稱猜測最快線路。
5. 使用全域模式驗證。建立連線後開啟網路檢測頁面，確認公開出口已經變更，再測試目標網站或應用程式。
6. 切回規則模式。若全域模式正常，再啟用規則模式並檢查常用網站。本地服務應直連、國際服務應使用代理，實際去向以規則與策略群組為準。
7. 最後調整 DNS 或 TUN。只有在出現解析位置異常、部分應用程式不遵循系統代理等明確現象時，才修改對應選項。

根據現象定位，不要憑感覺更換設定

• ✅ 訂閱無法更新：檢查連結完整性、用戶端時間、授權狀態與目前網路。
• ✅ 節點立即連線失敗：檢查協定支援、驗證參數、TLS 驗證與 UDP 條件。
• ✅ 瀏覽器正常但其他應用程式失敗：檢查系統代理涵蓋範圍、應用程式自身代理與 TUN。
• ✅ 全域模式正常但規則模式失敗：檢查規則順序、策略群組選擇和 DNS 解析結果。
• ✅ 連線一段時間後中斷：觀察本地網路切換、背景限制與連線維持情況。
• ❌ 不要同時修改所有開關，否則很難重現問題並確認真正原因。