「訂閱、節點、協定是什麼？」是許多新手匯入用戶端後遇到的第一個問題。簡單來說，訂閱負責將設定提供給用戶端，節點代表可選的連線入口，協定則規定用戶端與伺服器如何通訊；線路、分流與運作模式會進一步決定資料經過哪裡，以及哪些應用程式使用這條連線。它們屬於同一條連線流程，但並不是可以互換的名稱。
理解這些詞最好的方法不是背定義，而是按照實際使用順序觀察：先取得訂閱連結，將它匯入相容的用戶端；用戶端解析出節點；選定節點後，依照對應協定建立連線；連線建立後，再由全域模式或分流規則判斷哪些請求進入這條連線。最後，DNS 設定負責將網域名稱轉換為位址，也需要與分流策略保持一致。
訂閱連結究竟包含什麼
訂閱連結通常是由服務端產生、供用戶端讀取的網址。用戶端存取該網址後，會取得一組經過編碼或結構化處理的設定。設定可能包含伺服器位址、連接埠、協定類型、驗證參數、節點名稱與更新資訊。使用者看到的是一條連結，用戶端看到的則是一份可轉換為節點清單的資料。
因此，「購買訂閱」與「匯入訂閱」是兩個不同的動作。前者表示取得某項服務的使用權限，後者只是將既有設定加入用戶端。匯入成功也不代表線路已連線，只表示用戶端能夠讀取並解析設定。接下來還要選擇節點、啟動連線，並確認目標應用程式是否依預期使用代理或通道。
訂閱連結應視為敏感憑證處理。取得連結的人通常可以讀取其中的節點設定，因此不適合放在公開貼文、截圖或共用文件中。排查問題時，可以提供用戶端的錯誤訊息，但應遮住完整連結、驗證欄位與伺服器設定。若懷疑連結已外洩，應在服務面板中更新憑證，而不是只從本機用戶端刪除紀錄。
匯入、更新與本機設定的差異
「匯入」是首次讀取訂閱，「更新」是重新從原始網址取得最新設定，「本機設定」則只會儲存在目前裝置上。更新訂閱可能新增、刪除或調整節點，也可能覆寫同名項目的部分欄位。直接修改由訂閱產生的節點，往往會在下次更新時遺失。需要長期保留的自訂規則，建議放在用戶端支援的覆寫、規則集或獨立設定區域。
- 從服務面板複製完整的訂閱連結，不要手動刪除或修改連結中的字元。
- 在相容的用戶端中選擇「從 URL 匯入」或意思相近的入口。
- 完成匯入後先更新一次，確認用戶端能正常取得設定。
- 選擇一個節點並啟動連線，再用實際應用程式檢查存取結果。
- 之後若發現節點清單有變化，先執行訂閱更新，再判斷是否為連線故障。
節點、伺服器與線路有什麼差別
節點是用戶端中的可選設定項目，通常指向某個伺服器入口，並附帶協定、連接埠、驗證資訊與顯示名稱。同一台伺服器可以提供不同協定或入口，因此用戶端裡看到的多個節點，不一定代表相同數量的實體機器。反過來，同一地區的節點也可能由不同伺服器承載。
伺服器是執行網路服務的運算資源，節點是使用者可連線的設定入口，線路則描述資料從本機到目標網路所經過的路徑。節點名稱中出現某個地區，通常表示出口或主要入口與該地區有關，但不能只憑名稱推斷完整路由。實際路徑還會受到本地網路業者、入口位置、骨幹傳輸與目標網站網路策略影響。
| 名詞 | 主要含義 | 使用者能直接看到什麼 | 常見誤區 |
|---|---|---|---|
| 訂閱 | 向用戶端分發與更新設定 | 訂閱名稱、更新時間、節點清單 | 把匯入成功當成連線成功 |
| 節點 | 可選的伺服器入口設定 | 地區、協定、名稱與狀態 | 以為每個節點都對應獨立的實體伺服器 |
| 伺服器 | 實際執行連線服務的運算資源 | 通常不會顯示完整的底層資訊 | 只依伺服器所在的地區判斷整條路徑 |
| 線路 | 本機、入口、骨幹與出口之間的傳輸路徑 | 直連、中轉或專線等服務端標籤 | 把線路標籤直接等同於固定速度 |
直連、中轉與 IEPL 專線
直連通常表示本地網路直接連到境外伺服器入口，結構較簡單，但使用體驗更取決於本地網路業者與國際出口狀況。中轉則會先連到較近或更適合本地網路的入口，再轉送至目標出口。這能改善部分網路環境下的路徑選擇，但多一層轉發也代表服務端需要維護入口、轉發與出口之間的協調。
IEPL 專線通常指企業級國際乙太網路專線類型的承載方式。在面向個人使用者的服務中，這個標籤一般用來描述某段受控的傳輸路徑，不代表從使用者裝置到目標網站的每一段都屬於同一種專線。使用者本地到接入點、出口到目標網站仍可能經過一般網路，因此不應將「專線」理解為任何地點、任何時段都具備相同表現。
選線時，地區只是其中一項條件。目標所在位置、應用程式更依賴延遲還是持續吞吐量、本地網路是否限制 UDP，以及目前入口是否壅塞，都會影響結果。較穩定的選擇方式，是先依目標地區縮小範圍，再在相同使用情境下比較可用性，而不是只盯著節點名稱中的形容詞。
代理協定決定什麼
協定規定用戶端與伺服器如何建立工作階段、驗證身分、封裝資料並在網路上傳輸。節點設定必須與服務端支援的協定及參數相符，不能將 Trojan 節點手動改成 VLESS，還期待它繼續運作。協定也不是單獨決定速度的開關；線路品質、壅塞情況、裝置效能、傳輸層設定與目標網站都會共同影響使用體驗。
Shadowsocks、VMess、Trojan 與 VLESS
Shadowsocks 是常見的加密代理協定，設定通常圍繞伺服器、連接埠、密碼與加密方式展開。它的實作較成熟，用戶端支援也廣泛，但實際安全性與相容性取決於所選加密方式及用戶端實作。它主要負責代理傳輸，本身不會自動提供複雜的分流管理介面。
VMess 是 V2Ray 生態系中較早被廣泛使用的協定，驗證與傳輸設定涉及使用者識別碼、傳輸方式及時間同步等因素。裝置時間若明顯不準，部分設定可能出現驗證問題。VLESS 採用較輕量的驗證設計，本身不負責加密，通常需要搭配 TLS、REALITY 或其他安全傳輸機制使用。看到 VLESS 名稱時，還應檢查它搭配的傳輸層與安全層，而不是只看協定名稱。
Trojan 通常運作於 TLS 保護的連線之上，設定重點包括伺服器名稱、憑證驗證、密碼與傳輸設定。若用戶端關閉憑證驗證，雖然可能避開某些設定錯誤，卻會削弱對服務端身分的驗證，不應將此視為一般排障方法。正確方向是檢查系統時間、伺服器名稱、憑證狀態與設定是否相符。
Hysteria2 與 TUIC
Hysteria2 與 TUIC 都以 QUIC 及 UDP 傳輸為重要基礎，設計上會結合壅塞控制、多路複用與連線遷移等能力。在高丟包或波動較明顯的網路中，它們可能比部分以 TCP 為基礎的方案更具適應性，但前提是本地網路允許穩定使用 UDP。若辦公室網路、公共網路或路由設備對 UDP 限制嚴格，連線可能失敗或降級，此時應切換至服務端提供的其他協定，而不是反覆調整無關參數。
| 協定 | 傳輸特性 | 設定時應重點檢查 |
|---|---|---|
| Shadowsocks | 加密代理，用戶端支援廣泛 | 加密方式、密碼、連接埠是否一致 |
| VMess | 支援多種底層傳輸組合 | 使用者識別碼、傳輸參數與系統時間 |
| Trojan | 通常搭配 TLS 建立連線 | 伺服器名稱、憑證驗證與密碼 |
| VLESS | 輕量驗證，通常搭配安全傳輸層 | TLS 或 REALITY 等配套參數 |
| Hysteria2 | 以 QUIC 為基礎，重視對波動網路的適應性 | UDP 可用性、驗證與頻寬參數 |
| TUIC | 以 QUIC 為基礎，支援多路複用 | UDP 可用性、壅塞控制與驗證設定 |
全域模式、規則模式與分流
連線建立後，用戶端還要決定哪些流量進入節點。全域模式通常表示用戶端會讓能接管的請求盡量統一經過所選節點；規則模式則依照網域、IP、應用程式或規則集，分別選擇代理、直連或阻擋。分流就是這個判斷過程，目的不是讓所有流量都繞遠路，而是讓不同請求走更合適的出口。
在規則模式下，一個請求可能先符合區域網路直連規則，再符合特定網域規則，最後套用預設規則。規則順序非常重要：更具體的規則通常應放在較寬泛的規則之前。若寬泛的直連規則過早命中，後面的代理規則就不會執行；反過來，過於寬泛的代理規則也可能讓本地服務、列印裝置或內部系統走上不必要的遠端路徑。
系統代理、TUN 與應用程式內代理
系統代理是提供 HTTP 或 SOCKS 入口，讓遵循作業系統代理設定的應用程式使用。有些應用程式會讀取該設定，另一些則可能自行建立連線而忽略它。TUN 模式透過虛擬網路介面接管更廣泛的 IP 流量，通常能涵蓋不讀取系統代理的程式，但也更容易與防火牆、虛擬機器、企業網路軟體或其他通道工具發生路由衝突。
應用程式內代理只需在特定軟體中填入代理位址與連接埠，影響範圍最小，也方便排查。新手遇到「瀏覽器可以存取，其他軟體不行」時，常見原因不是節點失效，而是瀏覽器遵循系統代理，其他軟體沒有遵循。此時應檢查用戶端的運作模式，而不是立刻刪除訂閱。
- ✅ 只需要讓瀏覽器使用國際線路時，優先採用系統代理或瀏覽器支援的代理設定。
- ✅ 需要涵蓋不讀取系統代理的桌面程式時，再評估是否啟用 TUN 模式。
- ✅ 使用規則模式時，確認本地網路、常用中國大陸服務與目標國際服務是否分別命中預期規則。
- ✅ 切換模式後重新開啟目標應用程式，避免舊連線繼續沿用先前的路徑。
- ❌ 不要同時開啟多個接管系統流量的用戶端，否則路由與 DNS 設定可能互相覆寫。
- ❌ 不要把「已連線」圖示當成所有應用程式都已進入節點的證明。
DNS 洩漏與網域解析
應用程式存取網域之前，通常需要透過 DNS 查詢取得對應位址。所謂 DNS 洩漏，是指原本希望相關查詢由通道內或指定解析器處理，但查詢卻繞過預期路徑，交由本地網路的 DNS 處理。結果可能造成解析來源與存取出口不一致，也可能因本地解析結果不同而導致網站無法開啟、內容地區判斷異常或規則命中錯誤。
DNS 問題與分流密切相關。若用戶端依網域決定流向，就需要在連線早期取得網域資訊；如果應用程式預先將網域解析成 IP，用戶端可能只能依 IP 規則判斷。部分用戶端會使用 Fake IP、遠端解析或加密 DNS，維持網域與連線之間的對應關係，但不同平台與核心的實作方式並不完全相同。
檢查 DNS 時，不要只觀察「能不能開啟網頁」。還應確認用戶端是否接管 DNS、規則模式使用哪個解析器、系統是否保留舊的手動 DNS、瀏覽器是否啟用了獨立的安全 DNS，以及 TUN 模式與系統代理模式是否採用不同設定。瀏覽器獨立解析不一定代表錯誤，但可能繞過用戶端原本設計的網域分流流程。
不同平台的用戶端為什麼設定不一樣
Windows、macOS、Android、iOS 與 Linux 在系統代理、虛擬網路介面、背景執行及權限管理上的方式不同，因此同一份訂閱匯入不同用戶端後，介面與可用功能不會完全一致。訂閱負責提供伺服器設定，但用戶端如何實作規則、DNS、TUN 與自動更新，取決於本地核心與作業系統能力。
Windows 用戶端通常同時提供系統代理與 TUN。前者設定直接，後者涵蓋範圍更廣，但啟用 TUN 可能需要安裝虛擬網路元件並取得相應權限。macOS 同樣支援系統代理與通道方案，不過網路延伸功能權限、系統防火牆與其他網路延伸功能可能影響接管結果。
Android 用戶端通常透過系統 VPN 介面接管流量，也可能支援依應用程式分流。系統的電池管理若限制用戶端在背景執行，長時間待機後連線可能會被暫停。iOS 用戶端受到系統網路延伸機制限制，功能名稱可能與桌面版不同，訂閱更新與背景連線行為也更依賴系統調度。
Linux 的差異更多來自桌面環境、網路管理工具與執行方式。命令列核心可能只負責開放本機代理連接埠，系統是否自動使用該連接埠，則需要使用者另外設定環境變數、桌面代理或透明轉發。看到核心顯示「執行中」，只能表示程序已啟動，不能直接證明所有程式流量都經過它。
新手應先檢查哪些設定
- ✅ 用戶端是否支援訂閱中使用的協定與傳輸方式。
- ✅ 訂閱更新時間是否正常，節點清單是否完整顯示。
- ✅ 目前啟用的是系統代理、TUN，還是應用程式內代理。
- ✅ 規則模式的預設出口是否符合目前的使用目標。
- ✅ DNS 設定是否與分流模式配套，瀏覽器是否另有獨立解析設定。
- ✅ 系統時間是否準確，憑證驗證與需要時間同步的驗證都依賴它。
- ❌ 不要隨意複製來源不明的「最佳化參數」，參數必須與服務端及本地網路條件相符。
連線故障如何依名詞逐層定位
掌握名詞的實際價值，在於發生問題時知道該檢查哪一層。若訂閱無法更新，應檢查連結狀態、網路存取與用戶端解析能力；若訂閱可以更新但所有節點都無法連線，應檢查協定支援、驗證參數、系統時間與本地網路限制；若只有部分節點異常，則更可能與特定入口、線路或協定設定有關。
若用戶端顯示已連線，但某個應用程式仍使用本地網路，應檢查該應用程式是否由系統代理或 TUN 接管。若全域模式可用而規則模式不可用，應查看規則命中與 DNS。若網域無法開啟但直接存取已知位址可以連通，問題較可能出在解析流程；若網域能解析但連線逾時，則應繼續檢查路由、節點與目標服務回應。
排障時每次只變更一個變數。例如保留相同協定與模式，只切換節點；或保留相同節點，只從規則模式切換到全域模式。若同時更新訂閱、更換協定、啟用 TUN 並修改 DNS，即使問題消失，也很難知道是哪一項發揮作用，之後遇到同類問題仍無法重現。