剛開始使用網路代理客戶端時，最難理解的通常不是安裝過程，而是介面裡同時出現的訂閱、節點、線路、協定、系統代理、TUN、分流、全域模式與規則模式。它們分別描述設定來源、連線入口、傳輸方式和流量處理策略，彼此不能互相取代。釐清這些層次後，選擇節點、匯入訂閱和排查連線問題都會簡單許多。
核心名詞速查：它們分別控制什麼
下面這張表可以當作客戶端介面的翻譯器。遇到不熟悉的設定時，先判斷它屬於設定、入口、傳輸、路由還是系統接管層，再決定是否需要調整。
| 名詞 | 實際含義 | 常見誤解 | 新手應該注意什麼 |
|---|---|---|---|
| 訂閱 | 由服務端維護的一組節點與參數，客戶端透過訂閱連結取得並更新 | 把訂閱當成某一個固定節點 | 是否更新成功、是否來自可信來源 |
| 節點 | 客戶端可選擇的連線入口，通常包含伺服器位址、連接埠、協定和驗證資訊 | 以為節點名稱就是完整的網路路徑 | 地區、協定、線路說明與目前可連線狀態 |
| 線路 | 資料從本地到出口之間經過的網路路徑與承載方式 | 把線路和協定視為同一個概念 | 直連、中轉或 IEPL 專線是否適合目前的網路 |
| 協定 | 客戶端與服務端交換資料時使用的封裝、驗證及傳輸規則 | 只看協定名稱判斷速度 | 客戶端相容性、傳輸層與本地網路限制 |
| 分流 | 依網域、IP、應用程式或規則集，決定請求走代理還是直接連線 | 以為分流會自動辨識所有使用情境 | 規則是否命中、DNS 是否與規則保持一致 |
| 全域模式 | 客戶端接管範圍內的流量優先交由所選節點處理 | 以為全域模式能接管裝置上的所有流量 | 系統代理與 TUN 的接管範圍仍有所不同 |
| 規則模式 | 依據規則決定不同請求的出口 | 以為規則越多就一定越精準 | 規則順序、匹配結果和最終兜底策略 |
| 直連 | 請求不經過所選代理節點，直接使用目前的本地網路存取目標 | 把直連理解成伺服器直連線路 | 分清客戶端動作與服務端線路標籤 |
表格中的「直連」特別容易產生歧義。客戶端規則中的直連，表示某個請求繞過代理；節點詳情中的直連線路，則通常表示本地網路直接連線境外伺服器，中間沒有服務商部署的接入中轉。判斷含義時，需要看它出現在哪個介面以及哪一層設定中。
訂閱、節點與線路為什麼不是一回事
訂閱是設定入口，不是持續傳輸通道
訂閱連結通常會回傳一份客戶端能夠解析的設定集合。集合中可以包含多個節點，也可能包含分組、規則和更新資訊。客戶端讀取訂閱後，會將解析結果儲存在本地；日常存取流量通常不會經過「訂閱連結」，而是直接連線至所選節點。
因此，訂閱更新失敗與節點連線失敗是兩類不同問題。前者可能與連結失效、網路無法取得設定或客戶端解析格式有關；後者則更可能與節點狀態、協定相容性、系統時間、本地 UDP 環境或路由路徑有關。不要因為訂閱暫時無法重新整理，就立刻刪除仍可使用的本地設定。
節點是設定物件，線路是底層路徑
一個節點通常會記錄伺服器位址、連線埠、協定類型、驗證參數、傳輸層與加密相關設定。客戶端選取節點後，會依照這些參數建立連線。節點名稱中的地區、用途或線路標籤只是方便辨識的說明，實際欄位才會決定客戶端如何連線。
線路描述的是更底層的路徑。直連線路從本地電信業者網路直接通往遠端入口，結構簡單，但表現較依賴公網路由。中轉線路會先連線至較近的接入點，再由服務商網路送往遠端出口，常用於避開波動較大的公網區段。IEPL 是國際乙太網路專線的常見稱呼，著重承載路徑與網路隔離方式，並不是一種代理協定。
匯入訂閱時依照這個順序操作
- 從服務面板複製完整的訂閱連結，避免手動刪改連結中的驗證參數。
- 在客戶端中選擇「從 URL 匯入」「新增訂閱」或意義相近的入口，而不是把連結貼到單一節點的位址欄。
- 執行更新並確認節點清單出現，接著選擇與目標服務所在地區接近的出口進行連線。
- 開啟客戶端日誌或連線詳細資料，確認交握完成，再用瀏覽器檢查出口位址和 DNS 解析結果。
- 之後需要同步節點變更時使用「更新訂閱」，不要反覆建立內容相同的訂閱項目。
- ✅ 訂閱名稱、節點清單和更新時間均能正常顯示
- ✅ 節點協定受到目前客戶端支援，沒有出現未知欄位
- ✅ 連線後出口位址如預期變更，目標網站能正常載入
- ❌ 將訂閱連結公開貼到論壇、截圖或線上轉換頁面
- ❌ 更新失敗時連續匯入同一個連結，留下多份重複設定
該如何看懂協定名稱
協定規定客戶端與伺服器如何驗證、封裝和傳輸資料，但協定名稱本身不是速度排名。相同協定在不同線路、本地電信業者和客戶端實作上的表現可能明顯不同。新手選擇時，優先使用服務端提供且客戶端完整支援的設定，不要只憑名稱手動替換欄位。
Shadowsocks
Shadowsocks 是輕量的加密代理協定，常見實作會使用預先共享金鑰和指定的加密方法，保護客戶端與伺服器之間的資料。它的設定相對直接，支援的客戶端也較多。需要注意的是，Shadowsocks 解決的是代理傳輸，不等同於傳統意義上接管整個系統網路的 VPN；是否涵蓋所有應用程式，仍取決於客戶端啟用系統代理、VPN 介面或 TUN 模式。
VMess 與 VLESS
VMess 是 V2Ray 生態系中較早使用的驗證與傳輸協定，可以搭配不同的傳輸層。VLESS 將驗證與資料傳輸設計得更精簡，本身不負責提供完整的傳輸加密，部署時通常需要搭配 TLS、REALITY 或其他安全傳輸方式。看到 VLESS 節點時，不能只填寫伺服器位址和身分資訊，還要讓傳輸類型、伺服器名稱、公鑰或路徑等欄位與服務端設定一致。
Trojan
Trojan 通常運作在 TLS 之上，透過密碼完成驗證，其連線外觀接近一般 TLS 流量。客戶端需要正確驗證憑證和伺服器名稱。若裝置時間明顯錯誤、網域解析異常或伺服器名稱填寫不符，TLS 交握可能會失敗。關閉憑證驗證不應作為常規修復方式，因為這會削弱連線驗證。
Hysteria2 與 TUIC
Hysteria2 和 TUIC 都建立在 QUIC 與 UDP 傳輸基礎上，主要處理高延遲、封包遺失或頻寬變動環境中的傳輸效率。在允許 UDP 正常通訊的網路中，它們可能更具優勢，但企業網路、校園網路、公共網路或部分路由設備可能限制 UDP。遇到連線逾時或交握反覆失敗時，可以改用基於 TCP 與 TLS 的可用節點進行對照，以判斷問題來自協定設定還是本地網路策略。
| 協定 | 主要傳輸特性 | 設定注意事項 | 常見排查方向 |
|---|---|---|---|
| Shadowsocks | 輕量加密代理 | 加密方法、密碼、外掛參數 | 客戶端是否支援對應的加密方法 |
| VMess | 驗證協定，可組合多種傳輸層 | 身分、傳輸類型、路徑與伺服器名稱 | 參數是否完整、系統時間是否正常 |
| VLESS | 精簡驗證，通常搭配安全傳輸層 | TLS 或 REALITY 相關欄位 | 伺服器名稱、公鑰和傳輸參數 |
| Trojan | 基於 TLS 的驗證與傳輸 | 密碼、憑證網域、伺服器名稱 | 憑證驗證、DNS 與裝置時間 |
| Hysteria2 | 基於 QUIC 與 UDP | 驗證、TLS 與頻寬相關設定 | 本地網路是否限制 UDP |
| TUIC | 基於 QUIC 與 UDP | 身分、密碼、TLS 與壅塞控制 | UDP 可達性與客戶端版本相容性 |
如何選擇分流、全域與規則模式
客戶端最終要解決的問題不是「是否開啟代理」，而是「哪些流量由哪個出口處理」。全域模式和規則模式都建立在客戶端已成功連線節點的前提上；它們改變的是流量決策，不會修復節點交握失敗或訂閱解析錯誤。
全域模式適合暫時診斷
全域模式通常會將客戶端能接管的請求交給目前節點。它的優點是邏輯直接，適合確認某個網站在不經過複雜規則時能否存取，也適合排查規則誤判。缺點是本地網站、下載更新和不需要國際出口的應用程式也可能經過遠端線路，增加繞路和流量消耗。
「全域」不一定等於裝置上的所有資料。若客戶端只設定了系統 HTTP 代理，不讀取系統代理的應用程式仍可能直連；若啟用了 TUN 或系統 VPN 介面，接管範圍通常更廣，但仍可能受到排除路由、本地網路流量和應用程式自身網路實作影響。
規則模式適合日常使用
規則模式會依序比對網域、IP 位址、應用程式程序或規則集，並將請求交給代理、直連、攔截或特定節點群組。規則通常有先後順序：請求命中較前面的規則後，後面的規則可能不再處理。因此，新增一條寬泛規則時，應檢查它是否提前覆蓋更具體的項目。
網域規則與 IP 規則解決的問題不同。網域規則需要在網域資訊仍可見時參與判斷；IP 規則則依賴解析結果。若 DNS 在客戶端外部完成，或應用程式使用自己的加密 DNS，客戶端可能只能看到目標 IP，導致預期的網域規則未命中。
直連模式適合恢復本地網路基線
直連模式會讓請求繞過代理節點，常用於確認問題是否由客戶端設定引起。若直連也無法存取本地服務，重點應轉向本地 DNS、路由器、系統防火牆或電信業者網路；若直連正常而規則模式異常，檢查規則匹配、節點連線和 DNS 處理會更有效。
- ✅ 日常瀏覽優先使用維護正常的規則模式，減少不必要的遠端繞路
- ✅ 某個目標無法存取時，短暫切換全域模式進行對照
- ✅ 本地服務異常時切回直連，確認基礎網路是否正常
- ❌ 把全域模式當成提高節點頻寬或修復交握失敗的開關
- ❌ 未查看命中日誌就反覆修改多條規則
系統代理、TUN 與 DNS 洩漏
系統代理只涵蓋願意讀取代理設定的應用程式
系統代理是在作業系統中寫入 HTTP、HTTPS 或 SOCKS 代理位址。瀏覽器和許多桌面應用程式會讀取這些設定，但某些遊戲、命令列程式、內建網路堆疊的應用程式或直接發起 UDP 請求的軟體可能忽略系統代理。此時客戶端顯示「已連線」，並不代表這些應用程式的流量已經進入節點。
TUN 模式透過虛擬網路介面接管流量
TUN 模式會建立虛擬網路介面，並透過系統路由將更多 IP 流量交由客戶端處理。它比單純的系統代理涵蓋範圍更廣，適合不支援代理設定的應用程式。相對地，它需要系統網路權限，也可能與其他 VPN 軟體、虛擬機器網路、容器網路或安全軟體產生路由衝突。
啟用 TUN 後若出現本地裝置無法存取、區域網路服務中斷或特定應用程式斷線，應先檢查是否啟用了區域網路繞過、私有位址直連和正確的預設路由。不要同時啟動多個會建立虛擬介面並修改預設路由的客戶端。
DNS 洩漏指解析請求走錯出口
DNS 洩漏通常是指業務流量已經透過代理，但網域解析仍由本地網路的 DNS 伺服器直接完成。這會造成解析位置與出口位置不一致，也可能讓本地網路看到查詢的網域。它不一定會表現為完全斷線，更常見的現象是目標回傳錯誤地區內容、規則無法命中或部分網域解析到不合適的位址。
排查時應確認客戶端是否接管 DNS、規則模式採用哪種解析策略、瀏覽器是否啟用了獨立的安全 DNS，以及系統是否保留其他網路介面的 DNS。連線後可以開啟本站的網路檢測頁面，比對出口位址與 DNS 解析位置；如果兩者明顯不一致，再回到客戶端調整 DNS 接管方式。
各平台客戶端的差異從何而來
同一份訂閱在不同平台上顯示的選項可能不同，這通常不是訂閱內容發生變化，而是作業系統提供的網路介面、背景限制和客戶端核心能力不同。轉移裝置時，應重新檢查模式與權限，不要假設匯入後所有開關都會自動保持一致。
Windows
Windows 客戶端通常同時提供系統代理和 TUN。系統代理適合瀏覽器與一般桌面應用程式，TUN 更適合需要接管命令列、遊戲或不讀取代理設定的軟體。出現無法連網時，可以檢查系統代理是否殘留、虛擬網卡是否正常載入，以及防火牆是否允許客戶端通訊。
macOS
macOS 客戶端可能透過系統代理、網路延伸功能或系統 VPN 介面運作。首次啟用相關模式時，系統會要求核准網路權限。若客戶端已連線但應用程式沒有經過節點，應檢查網路延伸功能是否啟用，以及系統設定中是否同時存在其他網路過濾器。退出客戶端前恢復系統代理，也能避免後續應用程式繼續指向已關閉的本地連接埠。
Android
Android 通常利用系統 VPN 介面接管流量，並可按應用程式決定是否進入通道。省電策略可能限制客戶端在背景維持連線，切換網路後也可能需要重新建立工作階段。若只有某個應用程式異常，應先查看按應用程式分流，而不是直接更換整份訂閱。
iOS 與 iPadOS
iOS 與 iPadOS 客戶端依賴系統提供的 VPN 與網路延伸功能，背景行為由系統統一管理。匯入訂閱後，系統仍會要求建立 VPN 設定。若切換節點沒有立即反映，可以先中斷連線再重新連線，並檢查目前啟用的設定是否確實屬於正在使用的客戶端。
| 平台 | 常見接管方式 | 重點檢查項目 |
|---|---|---|
| Windows | 系統代理、TUN | 代理殘留、虛擬網卡、防火牆 |
| macOS | 系統代理、網路延伸功能 | 網路權限、過濾器衝突、系統代理狀態 |
| Android | 系統 VPN 介面、按應用程式分流 | 背景限制、應用程式繞過、網路切換 |
| iOS 與 iPadOS | 系統 VPN、網路延伸功能 | 設定授權、目前啟用的設定、重新連線狀態 |
從連線失敗到規則異常的排查順序
新手常見的問題是一次修改節點、協定、DNS、TUN 和規則，最後無法確認哪項設定真正有效。更可靠的方法是沿著資料流逐層檢查，從訂閱輸入開始，一直檢查到目標應用程式的出口。
- 確認訂閱可以更新，節點設定沒有缺少協定或驗證欄位。
- 固定一個節點，查看客戶端日誌是否完成連線與交握。
- 使用規則較少的模式測試基本存取，排除複雜分流的影響。
- 確認目標應用程式是否讀取系統代理；如果不讀取，再測試 TUN 或系統 VPN 介面。
- 核對出口位址與 DNS 解析位置，判斷解析是否進入預期路徑。
- 恢復日常規則模式，透過命中日誌確認目標網域或 IP 使用了正確策略。
- 最後再比較不同節點與線路，避免把本地權限問題誤判為線路問題。
客戶端顯示「已連線」只代表某個連線流程已建立，不代表訂閱更新、應用程式接管、DNS 解析、分流命中和目標服務存取全部正常。排查時要分別驗證這些環節。
理解這些名詞後，客戶端介面可以拆解成清晰的鏈路：訂閱提供設定，節點給出入口，協定負責通訊，線路承載資料，系統代理或 TUN 接管應用程式流量，分流規則決定出口，DNS 則為網域解析提供位址。任何異常都能歸到其中一層，而不是靠反覆切換所有開關碰運氣。