VPN 新手完整指南：訂閱、節點與分流一次搞懂

這篇 VPN 新手指南從最容易混淆的訂閱、節點與分流開始。剛接觸國際線路時，介面裡往往同時出現伺服器名稱、協定、代理模式、規則更新和 DNS 設定；如果把這些詞當成互不相關的開關，連線失敗時很容易反覆切換，卻不知道問題究竟出在哪一層。

更實用的理解方式，是把整個連線過程看成一條路徑：訂閱負責將線路資料交給用戶端，節點描述可連線的入口，協定規定用戶端如何與入口通訊，線路決定資料如何跨網路傳輸，分流規則則判斷哪些請求應進入這條路徑。理解這條鏈路後，選線與排錯都會清楚許多。

訂閱、用戶端和節點分別是什麼

訂閱連結是一份會持續更新的設定清單

訂閱連結通常由服務後台產生，用戶端存取後會取得節點名稱、伺服器位址、連接埠、協定參數與分組資訊。它更像設定入口，而不是需要在瀏覽器中長期開啟的普通網頁。用戶端中的「更新訂閱」操作，就是重新讀取這份清單，讓線路增刪、名稱調整或參數變更同步到本機。

訂閱連結通常包含存取設定所需的識別資訊，因此不適合公開轉發，也不應貼到來源不明的轉換頁面。若連結意外外洩，穩妥的做法是前往服務後台重設訂閱，而不是只在用戶端刪除舊設定。刪除本機內容不會讓已洩漏的連結失效。

用戶端負責讀取設定並接管網路請求

用戶端是安裝在 Windows、macOS、iOS、Android 或 Linux 上的軟體。它會解析訂閱內容、建立加密連線，並透過系統代理或虛擬網路介面接收應用程式流量。不同用戶端支援的協定、規則格式與系統權限不完全相同；同一份訂閱在不同平台上顯示的可用節點數量不同，不一定代表訂閱損壞，也可能是某個用戶端不支援其中的傳輸方式。

節點是可選擇的連線入口

節點通常以地區、城市或用途命名，背後對應伺服器位址、協定與線路參數。選擇「日本」節點，不代表資料在整個過程中只經過日本；它通常描述的是出口位置或服務定義的地區。用戶端先從目前網路連線到入口，伺服器端再將請求送往目標網站，目標網站通常看到的是出口端的網路位址。

直連、中轉與 IEPL 專線有什麼差別

「節點地區」回答出口在哪裡，「線路類型」回答資料如何抵達該處。這兩個維度經常被混為一談。同一地區的節點可以採用不同路徑，使用感受也可能不同。判斷線路時，不應只看名稱中的城市，還要結合目前的接入網路、目標網站所在地與應用程式類型。

直連不等於沒有加密，也不等於裝置會直接暴露給目標網站；這裡的「直」主要描述用戶端到服務入口之間沒有額外中轉。中轉則是在路徑中加入接入層，再由接入層將資料送往出口。它可能改善某些網路環境下的路由，但也增加了路徑結構，因此不能脫離實際網路，簡單判斷哪一種一定更快。

IEPL 通常用來描述國際乙太網路專線類資源。它與一般公網中轉的關鍵差異，在於關鍵傳輸區段的承載與調度方式，而不是節點名稱看起來更高級。使用者端仍可能受到本地 Wi-Fi、接入電信業者、裝置效能、出口壅塞與目標網站限制影響，因此「專線」不應被理解為任何情境下都固定低延遲。

Shadowsocks、VMess、Trojan、VLESS、Hysteria2 與 TUIC

這些名稱經常統稱為「協定」，但設計重點並不相同。有些較接近加密代理協定，有些依賴特定生態的傳輸層與安全層組合，也有些建立在 QUIC 與 UDP 之上。新手通常不需要手動修改協定參數，但應知道相容性與網路條件會影響連線結果。

Shadowsocks

Shadowsocks 是一種加密代理方案，設定通常包含伺服器、連接埠、密碼與加密方法。它的結構相對直接，用戶端生態也很廣，但能否正常匯入取決於用戶端是否支援訂閱中的加密方法與擴充參數。它本身不是會自動接管所有系統流量的完整方案；哪些應用程式進入代理，還取決於用戶端採用系統代理、虛擬網路介面或應用程式內設定。

VMess 與 VLESS

VMess 常見於 V2Ray 生態，包含身分識別、傳輸方式等參數，並且對裝置時間準確性較為敏感。若系統時間明顯偏差，可能導致驗證失敗。VLESS 更強調精簡驗證，本身不負責提供完整的傳輸安全，通常需要搭配 TLS、REALITY 或其他傳輸設定。只複製伺服器位址而遺漏安全層與傳輸層參數，通常無法建立正確連線。

Trojan

Trojan 通常透過 TLS 建立連線，設定涉及伺服器名稱、憑證驗證與傳輸參數。遇到憑證錯誤時，不應把關閉驗證當成一般修復方式。較合理的處理方式是檢查系統時間、伺服器名稱、設定是否完整，以及訂閱是否已更新。憑證驗證是確認連線身分的一環，隨意略過會削弱這項機制。

Hysteria2 與 TUIC

Hysteria2 和 TUIC 都常見於基於 QUIC、使用 UDP 的連線方案，重點之一是應對高延遲或有丟包的網路環境。它們並非在所有網路中都更快：若公網限制 UDP、路由器處理 UDP 工作階段不佳，或用戶端版本缺少相應支援，連線可能直接失敗。此時切換到基於 TCP 與 TLS 的相容線路，往往比反覆調整未知參數更有效。

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

代理模式決定用戶端收到請求後如何處理。常見的全域、直連與規則模式，不是不同的線路方案，而是本機流量調度策略。節點不變時，切換模式也會改變哪些網站經過國際線路，因此排查「某個應用程式能用、另一個不能用」時，必須查看目前模式。

全域模式

全域模式通常會讓用戶端接管的大部分請求都通過目前節點。它適合暫時驗證節點能否存取目標服務，也方便判斷問題是否來自規則匹配。但長期使用全域模式可能讓本地網站、區域網路裝置或不需要國際存取的服務繞行，造成不必要的路徑變化。全域模式也不一定涵蓋所有流量，覆蓋範圍仍取決於用戶端採用的接管方式。

直連模式

直連模式會讓請求不經過所選節點，常用於暫停代理或測試原始網路。用戶端顯示「已連線」時，如果模式仍是直連，外部位址不會隨節點變更。這是新手常見的誤判：通道可能已經建立，但規則明確要求流量直接傳送，因此目標網站仍會使用原本的網路。

規則模式

規則模式會依網域、網路位址、應用程式程序或規則集合決定流量去向。它適合日常使用，因為本地服務可以直連，需要國際線路的請求再進入代理。難點在於規則可能過期、匹配順序可能衝突，新網域也可能尚未納入既有分類。

請求進入用戶端
├─ 區域網路與本地服務 → 直連
├─ 命中代理規則 → 選擇節點
├─ 命中攔截規則 → 阻止請求
└─ 未命中規則 → 依預設策略處理

規則通常由上至下，或依引擎定義的優先順序進行匹配，具體行為取決於用戶端實作。網域規則與網路位址規則也可能得出不同結果：應用程式先解析網域，再連線至解析結果；如果 DNS 解析路徑與代理規則不一致，就可能出現網域看似命中代理，實際連線卻走另一條路徑的情況。

DNS 洩漏、解析失敗與分流為什麼有關

DNS 的任務是將網域名稱解析為網路位址。在瀏覽器輸入網站名稱後，裝置通常會先發出 DNS 查詢，再連線到解析出的位址。如果網頁流量經過節點，而 DNS 查詢仍交由本地網路處理，外部觀察到的解析路徑就可能與代理路徑不一致，這通常稱為 DNS 洩漏。它也可能導致地區判斷錯誤、解析結果不適合目前出口，或規則無法依預期匹配。

用戶端常見的 DNS 處理方式包括使用系統解析、在代理通道內查詢、依網域類別選擇解析器，以及透過虛擬位址搭配規則引擎。不同用戶端對這些功能的命名各異，不應只憑「增強模式」之類的標籤判斷效果。更可靠的檢查方式，是確認 DNS 請求由誰發出、透過哪條路徑傳送，以及解析後的連線是否仍受同一套規則控制。

• 已連線但網域無法開啟時，可嘗試直接存取已知可達的服務，以區分解析問題與連線問題。
• 全域模式正常、規則模式異常時，檢查網域規則是否命中，以及規則檔案是否已完成更新。
• 瀏覽器啟用獨立的安全 DNS 後，解析可能繞過用戶端的預期設定，應核對瀏覽器與系統設定是否衝突。
• 區域網路裝置無法存取時，確認本地網段是否被錯誤送入代理；通常應為本地資源保留直連規則。
• 切換節點後仍保留舊的解析結果時，可以重新啟動相關應用程式，必要時清除系統或用戶端的 DNS 快取。

DNS 洩漏不是「能否開啟網頁」的唯一判斷標準，也不能只憑外部檢測頁的單一結果推斷所有流量路徑。現代瀏覽器、系統與應用程式可能各自使用不同的解析機制。排查時，應將應用程式 DNS、系統 DNS、用戶端 DNS 與出口連線放在同一條鏈路中觀察。

各平台用戶端的差異

同一份訂閱在不同平台上的表現可能有所差異，原因通常來自系統網路介面、背景執行限制與用戶端協定支援，而不是節點對某種裝置有特殊偏好。選擇用戶端時，應先確認訂閱支援的協定，再考慮規則編輯、記錄檢視與自動更新能力。

Windows 與 macOS

桌面系統通常同時提供系統代理與虛擬網路介面兩種接管方式。系統代理主要影響遵循代理設定的應用程式，部分遊戲、終端程式或自行實作網路堆疊的軟體可能會繞過它。虛擬網路介面能涵蓋更廣泛的流量，但可能與防火牆、虛擬機器、企業網路軟體或其他網路工具發生路由衝突。

macOS 應用程式也可能使用系統網路延伸功能建立通道。首次啟用時需要授予相應權限。若用戶端介面顯示連線成功，但終端請求沒有經過節點，應檢查終端工具是否讀取代理環境變數，以及目前使用的是系統代理還是虛擬網路介面。

iOS 與 Android

行動作業系統通常透過系統提供的 VPN 介面接管流量。背景省電、網路在 Wi-Fi 與行動網路之間切換、系統重新啟動或設定權限變更，都可能觸發通道重新連線。行動用戶端對訂閱格式與協定支援也有差異，成功匯入不代表其中每種節點類型都能使用。

Android 裝置的系統客製化差異很大，電量管理可能限制用戶端在背景執行。iOS 上的用戶端則受到系統網路延伸機制約束。遇到鎖定螢幕後斷線時，應先查看系統是否允許用戶端維持網路活動，再考慮節點故障。

Linux

Linux 常見的使用方式包括圖形用戶端、命令列核心與服務程序。桌面環境的系統代理不一定會影響命令列工具；命令列程式可能需要代理環境變數，也可能需要透過虛擬網路介面統一接管。使用服務程序時，還要確認設定檔權限、監聽位址、DNS 設定與路由規則是否由正確的使用者載入。

從匯入訂閱到驗證連線的操作順序

新手最容易在多個設定之間反覆切換。更有效率的做法是依照相依關係操作，每完成一步就驗證相應結果。即使連線失敗，也能藉此確定問題停在哪個環節。

1. 選擇相容的用戶端。確認用戶端支援訂閱提供的協定與目前的作業系統，不要只依介面外觀選擇。
2. 複製訂閱連結。從服務後台取得連結，透過用戶端的訂閱匯入功能新增，避免在公開轉換工具中處理。
3. 執行訂閱更新。確認用戶端顯示節點名稱；若清單為空，查看更新提示與用戶端記錄，不要直接開始切換代理模式。
4. 選擇目標地區。依目標網站或服務所在的地區選擇出口，再比較同一地區的直連、中轉或專線線路。
5. 先以規則模式連線。若目標無法存取，可暫時切換全域模式作為對照，藉此判斷是否為規則匹配問題。
6. 驗證流量路徑。檢查外部位址是否與所選地區相符，同時測試本地網站與區域網路資源是否仍依預期直連。
7. 恢復日常設定。測試完成後，回到適合長期使用的規則模式，並保留可用節點作為切換選項。

如何分層排查常見故障

訂閱更新失敗

先確認原始網路能夠存取訂閱入口，再檢查連結是否完整、是否已被重設，以及用戶端是否將連結誤當成單一節點設定。若用戶端提供更新記錄，可留意網路逾時、格式解析與驗證失敗等資訊。不要不斷重複匯入而建立多個同名訂閱，這會讓後續更難判斷節點來源。

所有節點都無法連線

所有節點同時失敗時，優先檢查目前網路、用戶端核心、系統時間、防火牆與協定支援。若 Hysteria2、TUIC 等 UDP 方案失敗，而其他傳輸方案可用，可能與目前網路對 UDP 的限制有關。若 Trojan 或其他 TLS 連線提示憑證異常，應核對系統時間與訂閱參數，不要直接關閉驗證。

只有某個節點失敗

單一節點失敗而同地區其他節點正常時，通常可以先切換線路，稍後再更新訂閱。節點名稱相近不代表路徑完全相同。若特定線路長期異常，可將用戶端記錄與節點名稱提交給服務支援，以便定位入口、出口或傳輸參數問題。

已連線但應用程式仍走直連

檢查目前是否處於直連模式、應用程式是否遵循系統代理，以及虛擬網路介面是否成功建立。終端工具、遊戲與部分桌面應用程式可能不會讀取系統代理。此時應依用戶端能力使用虛擬網路介面，或為應用程式設定明確的代理環境，而不是只觀察用戶端的連線圖示。

網頁能開啟但影片或下載異常

網頁可用只能表示基本請求已建立，不代表持續傳輸一定穩定。影片、下載與即時通訊對吞吐量、抖動、丟包及長連線更為敏感。可以在同一出口地區比較不同線路類型，並暫時停用佔用頻寬的背景工作。若只有特定服務異常，還應檢查分流網域是否完整，以及出口地區是否符合服務本身的規則。

建立適合日常使用的設定習慣

穩定使用不需要頻繁修改進階參數。更重要的是保持訂閱可更新、用戶端版本與協定相容、規則來源明確，並為常用地區保留可替換線路。節點短暫波動時先切換同地區線路，整份訂閱都異常時再檢查本地網路與用戶端，不要把單點故障擴大成全面重裝。

分流規則也應保持可解釋。了解本地服務為何直連、國際網站為何進入代理、未命中請求採用什麼預設策略，比堆疊大量來源不明的規則更可靠。涉及工作系統、網路銀行或地區敏感服務時，應遵守服務條款與所在地規範，並在處理重要帳戶前確認出口地區與網路環境。

當「訂閱提供設定、用戶端執行連線、節點代表入口、線路負責傳輸、協定規定通訊、分流決定去向」這套關係建立起來後，介面中的術語就不再是零散的開關。選線時有明確依據，連線失敗時也能沿著鏈路逐層定位，而不是依賴盲目試錯。