剛接觸網路加速時，最容易混淆的往往不是操作按鈕，而是訂閱、節點、線路、協定和分流這些術語。它們分別位於連線流程的不同環節：訂閱負責提供設定，節點提供連線入口，線路決定資料經過的網路路徑，協定規定用戶端與伺服器如何通訊，分流規則則決定哪些請求需要經過這條路徑。只要先建立完整的連線概念，用戶端裡的大多數選項就不再顯得零散。
本文從一次實際連線出發，說明這些概念之間的關係，並解釋直連、中轉、IEPL 專線、全域模式、規則模式、系統代理、TUN 模式和 DNS 洩漏分別代表什麼。重點不是記住縮寫，而是知道某個環節出現問題時應該檢查哪裡。
先看完整連線流程
使用者開啟用戶端並匯入訂閱後，用戶端會讀取伺服器位址、連接埠、協定參數和節點名稱等設定。選擇節點並建立連線後，應用程式產生的請求會先交給用戶端；用戶端依據目前的分流模式判斷請求要直接傳送，還是封裝後交給遠端節點。遠端節點再存取目標服務，並沿著連線回傳回應。
應用程式請求
→ 系統代理或 TUN 接管
→ 分流規則判斷
→ 直連，或交給所選節點
→ 節點對應的網路線路
→ 目標服務
→ 回應沿原路徑返回在這段流程中，「節點」和「線路」並不是同義詞。節點通常是用戶端可以選擇的連線設定，包含主機、連接埠和協定等資訊；線路則描述節點背後的網路路徑。同一地區可能提供不同線路，同一條線路也可能對應多個入口設定。僅看節點名稱無法完整判斷實際路徑，還應閱讀服務商對線路類型和適用情境的說明。
訂閱、設定與節點是什麼
訂閱是可更新的設定入口
訂閱通常是一個連結，也可能透過用戶端內的登入狀態取得。用戶端存取訂閱後，會取得一組節點設定和相關參數。服務端調整節點位址、線路名稱或可用設定後，使用者可以在用戶端執行「更新訂閱」，不必逐項重新填寫。
訂閱連結並不是普通的公開網頁位址。它可能包含用於識別訂閱的憑證，應像密碼一樣妥善保存，不要發布在公開頁面、截圖或共用文件中。若懷疑連結已外洩，應透過服務面板重新產生，或聯絡支援管道處理。
用戶端中的「本機設定」和「訂閱設定」也要區分。使用者手動建立的節點通常只保存在本機；從訂閱取得的節點則由訂閱來源維護。部分用戶端更新訂閱時會覆蓋訂閱節點的本機修改，因此不宜直接在訂閱節點上長期保存自訂參數。確需調整時，可以使用用戶端提供的覆寫、規則集或獨立設定功能。
節點是一組可連線參數
一個節點至少要讓用戶端知道連線目標和通訊方式。不同協定所需欄位各異，常見內容包括伺服器位址、服務埠、驗證資訊、傳輸方式、TLS 設定和伺服器名稱。用戶端會把這些欄位組合成可選取的項目，並以地區或線路名稱協助使用者辨識。
節點顯示的地區通常用於描述出口或線路定位，但應用程式最終如何判斷地區，還會受到出口 IP 資料庫、DNS 解析結果、瀏覽器儲存資料、帳號資料和系統時區等因素影響。因此，節點名稱不能單獨作為地區判定的依據。需要確認出口時，應在連線後使用 IP 檢測查看公網位址和 DNS 結果。
更新訂閱不等於升級用戶端
「更新訂閱」只會重新取得節點與規則等設定；「升級用戶端」則是安裝新版程式。遇到訂閱中出現用戶端無法辨識的協定時，僅重新整理訂閱並沒有作用，需要確認目前用戶端是否支援該協定及相應的傳輸參數。反過來，用戶端能夠啟動，也不代表訂閱內容仍是最新狀態。
直連、中轉與 IEPL 專線的差異
線路類型描述資料從本地網路到出口節點所經過的路徑。它會影響連線受公網壅塞、跨網互聯和路由變化的程度，但不能只根據名稱推斷所有時段的實際表現。判斷線路時，應結合所在地網路、目標地區和實際使用時間進行測試。
| 線路類型 | 基本路徑 | 主要特點 | 適合關注的問題 |
|---|---|---|---|
| 直連 | 本地網路直接連線遠端節點 | 結構簡單，表現較依賴公網路由 | 本地電信商到目標地區的互聯品質 |
| 中轉 | 先到中轉入口，再轉往出口 | 可避開部分不理想的公網路段 | 入口品質、中轉鏈路與出口狀態 |
| IEPL 專線 | 透過國際乙太網路專線或相應承載路徑連線 | 與一般公網直連的路由組織方式不同 | 服務商標示的入口、出口及使用範圍 |
直連不是「本地應用程式繞過代理」的意思。在節點線路的語境中，直連通常表示使用者直接連線遠端伺服器；在分流語境中，「DIRECT」則表示請求不經過代理節點。兩個詞的中文顯示相同，但所處層級不同。閱讀用戶端日誌時，要先判斷它指的是節點路徑還是規則動作。
中轉線路會增加一個或多個受控轉送環節。它的價值在於重新組織入口到出口之間的路徑，而不是單純讓資料「多繞一站」。如果本地到中轉入口的連線穩定，而入口到出口之間的網路品質良好，中轉可能比公網直連更適合持續傳輸；如果入口本身不適合目前網路，結果也可能相反。
IEPL 是 International Ethernet Private Line 的縮寫，通常指國際乙太網路專線。它屬於網路承載與線路組織概念，不是一種代理協定，也不是用戶端必須支援的特殊按鈕。用戶端仍可能使用 Shadowsocks、Trojan、VLESS 等協定連線入口，之後的資料再由服務端網路承載。看到「IEPL 節點」時，應理解為節點背後採用了相應線路，而不是出現了一種名為 IEPL 的加密協定。
常見協定分別解決哪些問題
協定規定用戶端與服務端之間如何建立工作階段、驗證、加密或承載資料。用戶端和服務端必須支援相同協定及相符參數，否則無法建立連線。協定名稱本身也不能取代完整設定，因為傳輸層、TLS、伺服器名稱和其他擴充參數都可能影響相容性。
Shadowsocks
Shadowsocks 是常見的加密代理協定，設定通常圍繞伺服器、連接埠、密碼和加密方法展開。不同實作支援的加密方法可能不同，匯入後出現「不支援的加密方式」時，應優先檢查用戶端版本與核心實作，而不是反覆切換分流模式。
VMess 與 VLESS
VMess 是帶有身分識別與協定結構的代理協定，常與不同傳輸方式搭配使用。VLESS 的設計較輕量，本身不負責提供完整的傳輸加密，實際部署通常搭配 TLS 或其他安全傳輸層。兩者名稱相近，但設定欄位和服務端實作不能任意互換。
如果匯入訂閱後節點存在卻無法連線，應檢查用戶端是否完整讀取傳輸方式、TLS、伺服器名稱和路徑等參數。只複製伺服器位址與連接埠，往往不足以還原原始設定。
Trojan
Trojan 通常運作在 TLS 連線之上，驗證資訊、伺服器名稱和憑證驗證是關鍵設定。系統時間明顯不準確、伺服器名稱填寫錯誤或憑證驗證失敗，都可能導致交握無法完成。為了排查問題而長期關閉憑證驗證並不妥當，應修正時間、網域或設定來源。
Hysteria2 與 TUIC
Hysteria2 和 TUIC 都著重於基於 UDP 的現代傳輸，常用於應對存在封包遺失或波動的網路環境。它們依賴本地網路、路由設備和服務端對 UDP 的正常支援。若同一訂閱中的 TCP 類協定可以連線，而這兩類協定持續失敗，可以檢查目前網路是否限制 UDP、用戶端核心是否相容，以及系統防火牆是否允許相關程式通訊。
選擇協定時不必追求最新的縮寫。用戶端相容性、線路適配和目前網路條件比名稱本身更重要。服務商已透過訂閱提供參數時，通常應先使用原始設定，不要在不了解含義的情況下任意修改傳輸層和安全選項。
系統代理、TUN 與應用程式內代理
節點連線成功只代表用戶端與伺服器之間的通道已建立，還需要決定應用程式流量如何進入用戶端。常見接管方式包括系統代理、TUN 模式和應用程式自身的代理設定。
系統代理
系統代理會把代理位址寫入作業系統的網路設定。遵循系統代理的瀏覽器和應用程式會把請求交給用戶端，但部分程式會忽略系統設定，直接建立網路連線。因此可能出現瀏覽器出口已改變，而命令列工具或特定應用程式仍走本地網路的情況。
TUN 模式
TUN 模式透過虛擬網路介面接管更多類型的 IP 流量，涵蓋範圍通常比系統代理更廣，也更適合需要處理不讀取系統代理設定的應用程式。啟用時可能需要系統授權，並可能與其他網路過濾、企業安全軟體或既有虛擬網路介面發生衝突。
TUN 並不代表所有請求都必須經過遠端節點。流量進入 TUN 後，仍可依據規則選擇代理或直連。因此，「接管方式」和「分流策略」是兩個獨立維度：前者決定用戶端能看到哪些流量，後者決定看到流量後如何處理。
應用程式內代理
部分瀏覽器、下載工具和開發工具允許單獨填寫 HTTP 或 SOCKS 代理。這種方式影響範圍明確，適合測試特定應用程式，但需要確認填寫的是用戶端提供的本機監聽位址，而不是把遠端節點參數直接填入不相容的代理輸入欄位。應用程式關閉後，這類設定也不會自動隨用戶端狀態變化。
全域模式、規則模式與直連模式
分流模式決定已被用戶端接管的請求下一步如何處理。不同用戶端的命名略有差異，但核心通常可歸納為全域、規則和直連。
- 全域模式：大多數被接管的請求會交給所選節點，適合驗證節點是否正常，也便於排除規則比對問題。
- 規則模式：依據網域、IP、應用程式或規則集選擇代理、直連或拒絕，是日常使用中更常見的方式。
- 直連模式：被接管的請求仍從本地網路直接傳送，常用於暫時停用代理路徑或測試本地連線。
規則通常會依照用戶端定義的順序比對。常見條件包括完整網域、網域後綴、IP 網段、程序名稱和地理資料庫分類。比對成功後執行對應動作；未命中時則使用最終規則。出現「某個網站沒有經過所選節點」時，應查看連線日誌中該請求命中了哪條規則，而不是只看主介面是否顯示已連線。
網域規則與 IP 規則也可能產生不同結果。應用程式先請求網域時，用戶端可以直接按網域分流；如果應用程式自行解析後只提交 IP，網域資訊可能不可見，只能依賴 IP 規則或嗅探能力。啟用嗅探會改變用戶端識別流量的方式，應依照用戶端文件設定，不要把它當成解決所有問題的通用開關。
排查分流最有效的方法，是暫時切換到全域模式進行對照。如果全域模式可用而規則模式不可用，問題通常位於規則比對、DNS 解析或應用程式接管範圍；如果兩種模式都不可用，則應回到節點連線與本地網路環節。
DNS 解析與 DNS 洩漏
DNS 負責將網域轉換為可連線的 IP 位址。代理連線已建立，不代表 DNS 請求一定沿著相同路徑傳送。系統解析、用戶端內建 DNS、瀏覽器加密 DNS 和應用程式自有解析可能同時存在，因此 DNS 是分流排查中經常被忽略的一層。
所謂 DNS 洩漏，通常是指原本應由代理端或指定解析器處理的查詢，仍被傳送至本地網路的 DNS 服務。這可能暴露查詢的網域範圍，也可能造成地區判定不一致。檢查時不能只看公網出口 IP，還要觀察檢測頁列出的 DNS 解析位置是否符合目前設定的預期。
規則模式尤其依賴 DNS 設計。用戶端可能先根據網域比對規則，再決定使用本地解析或遠端解析；也可能透過虛擬 IP 機制保留網域與連線之間的對應。不同用戶端的實作各異，不應把其他軟體的 DNS 設定原樣照搬。若修改後出現網域無法開啟但 IP 可以存取，應檢查解析器是否可連線、規則是否讓解析請求走錯路徑，以及瀏覽器是否啟用了獨立的加密 DNS。
瀏覽器快取和系統 DNS 快取也會保留舊結果。切換線路後看到的內容沒有變化，不一定代表節點切換失敗。可以先開啟新的無痕視窗、關閉並重新開啟目標應用程式，必要時依照作業系統方式清理 DNS 快取，再重新檢測出口與解析結果。
不同平台的用戶端差異
訂閱內容可以跨平台使用，但用戶端功能不會完全一致。差異通常來自作業系統網路介面、背景執行限制、代理核心版本和用戶端本身的功能設計。
- Windows：常見用戶端通常同時支援系統代理與 TUN。啟用 TUN 時要留意管理員權限、防火牆和其他虛擬網卡。
- macOS：系統代理適合遵循系統設定的應用程式；需要更廣泛接管時會使用網路延伸功能或 TUN，並觸發系統授權。
- iOS：用戶端透過系統提供的網路延伸功能建立連線。背景行為、隨選連線和規則能力取決於用戶端實作與系統限制。
- Android：用戶端一般使用系統 VPN 介面接管流量，通常可按應用程式分流。省電策略可能影響用戶端在背景維持連線。
- Linux：不同發行版和桌面環境差異較大，可以使用圖形用戶端、系統代理、TUN 或命令列核心，需要自行確認權限與 DNS 整合。
從一個平台遷移到另一個平台時，應重新匯入訂閱，不要只複製介面截圖中的伺服器和連接埠。還要確認新用戶端支援訂閱中的協定、傳輸方式和規則格式。若服務提供官方用戶端，優先使用與訂閱設定相符的版本，通常更省去相容性判斷。
從匯入訂閱到驗證連線
新手可以依固定順序操作，每一步只驗證一個環節。即使連線失敗，也能迅速判斷問題位於設定、節點、接管、分流還是 DNS。
- 取得可信賴的訂閱。從服務面板複製訂閱，或在用戶端內登入取得，不使用來源不明的公開設定。
- 選擇相容的用戶端。確認用戶端支援訂閱包含的協定，並允許系統要求的網路權限。
- 匯入並更新訂閱。檢查是否出現節點名稱；如果清單為空，先處理訂閱讀取問題。
- 選擇節點並連線。查看用戶端日誌，確認協定交握成功，而不是只觀察按鈕顏色。
- 確認流量接管方式。依照應用程式範圍啟用系統代理或 TUN，避免同時疊加多個用途不明的代理設定。
- 先用全域模式驗證。確認目標請求能夠經過節點後，再切回規則模式。
- 檢查出口與 DNS。對照公網 IP、出口地區和 DNS 解析結果，判斷流量是否依預期傳送。
- 恢復日常分流。觀察目標網域命中的規則，必要時只調整相關規則，不要重設全部網路設定。
常見誤區與快速判斷
節點顯示已連線，但網頁無法開啟
「已連線」可能只代表用戶端完成了與節點的交握。接下來應檢查應用程式是否由系統代理或 TUN 接管、規則是否將請求設為直連、DNS 是否能夠解析，以及瀏覽器是否使用獨立的代理設定。可以透過全域模式和不同應用程式進行對照。
更換協定後速度仍沒有變化
效能不只由協定決定，還會受到本地接入、線路路徑、目標服務回應和目前網路壅塞影響。若多個協定實際使用相同入口和相同出口線路，單純切換協定未必能改變主要瓶頸。更有意義的做法是比較不同線路類型，並保持測試時間、目標和應用程式一致。
更新訂閱後自訂節點消失
這通常是因為修改發生在由訂閱管理的設定中，更新時被服務端版本覆蓋。應將自訂規則放入用戶端提供的覆寫區，或另存為本機設定。修改前先匯出備份，並確認匯出內容不會被公開分享。
出口地區正確，服務仍判定為其他地區
地區判定可能綜合出口 IP、DNS、帳號資料、瀏覽器快取、定位權限和系統環境。先清除舊工作階段並重新檢查 DNS，不要頻繁切換大量節點。若目標服務對帳號地區有獨立規則，應以其公開說明為準；網路出口變化不會自動修改帳號屬性。
規則模式只有部分應用程式生效
先判斷未生效的應用程式是否有進入用戶端。系統代理無法涵蓋所有程式，TUN 的應用程式排除設定也可能略過特定程序。如果日誌中完全沒有該應用程式的連線紀錄，問題更可能出在接管層；如果日誌存在但動作顯示直連，則應檢查規則層。