VPN 名詞解釋:訂閱、節點、線路類型、協定一次講明白

這篇 VPN 名詞解釋不按字母順序排列,而是按一次連線發生的先後順序來寫:先拿到節點清單,再決定連哪台伺服器,再決定資料走哪條路徑,最後才談怎麼加密。按這個順序理解,六個詞就不會再混在一起。

為什麼這六個名詞總被混著用

打開任一個用戶端,「訂閱」和「節點」並排出現,「線路類型」寫在方案頁,「協定」藏在節點詳情裡,「分流」是一整頁開關。詞都認識,但排障時說不清問題出在哪一層,就只能反覆「換節點試試」——換到第十個還是不行,人也累了。

把一次連線拆成四層會清楚很多:

帳號層:訂閱。決定用戶端能拿到哪些節點。
入口層:節點。決定連到哪台伺服器、用什麼參數。
路徑層:線路類型。決定資料從本地到落地怎麼走。
握手層:協定。決定怎麼加密、走 TCP 還是 UDP。

分流與全域/規則模式不屬於這四層,它們是路由層的兩個開關:前者決定「哪條流量走代理」,後者決定「這套規則到底生不生效」。

六個名詞速查:一句話定義與出問題時的第一檢查點
名詞	一句話定義	出問題先看什麼
訂閱	用戶端拉取節點清單的那條連結	連結是否完整、是否被轉發給別人
節點	一台伺服器的接入參數集合	位址、連接埠、協定、密碼是否與設定一致
線路類型	資料從本地到落地怎麼走	晚高峰是否抖動、中間段是否走公網
協定	用戶端與節點之間的握手與加密方式	系統時間、TLS、UDP 是否被限制
分流	哪些流量走代理、哪些直連	規則順序與最後的保底規則
全域與規則模式	用戶端整體的路由開關	是否誤開全域,導致規則全部失效

下面按這個順序逐一展開。

訂閱:一條連結,本質是帳號憑證

訂閱(subscription)是一條 URL。用戶端每隔一段時間向它發一次請求,拿回一份節點清單:可能是 base64 編碼的一串 ss://、vmess://、trojan://、vless://、hysteria2:// 連結,也可能是 Clash / mihomo 直接能讀的 YAML 設定。所謂「匯入訂閱」,就是把這條 URL 交給用戶端,剩下的事它自己完成。

三個容易忽略的重點:

更新訂閱等於整體替換。用戶端重新請求這條連結,伺服器回傳什麼就覆蓋什麼。手動改過的節點名稱、排序、備註,更新一次就沒了。
訂閱裡可能帶帳號狀態。部分伺服器會在回應標頭裡附上到期時間與已用流量(subscription-userinfo),用戶端把它顯示在首頁。不同用戶端對這個標頭的支援程度不一樣,看不到不代表沒有。
拉取失敗和連不上是兩件事。訂閱拉取失敗,通常是連結被聊天軟體截斷、裝置時間偏差過大導致 TLS 握手失敗,或者目前網路連不到面板網域;節點連不上屬於另一層的問題。

訂閱連結等同於帳號憑證這條 URL 裡的權杖一般不需要二次驗證就能取得全部節點。轉發給他人,等於把帳號一起給出去;換裝置時用同一份訂閱即可,不必複製單一節點。

節點:一組接入參數,不是一個名字

節點(node)是用戶端連線落地伺服器所需的全部參數:位址、連接埠、協定、加密方式、密碼或 UUID、傳輸層(TCP / WebSocket / gRPC)、TLS 開關與 SNI、路徑。少任何一項都握不上手。

所以「節點名稱」和「節點」是兩件事。名字只是標籤,改成什麼都能連;真正決定通不通的是上面那串參數。同一個落地伺服器可以派生出多個節點——不同連接埠、不同傳輸層——這也是「節點數」和「線路數」經常對不上的原因。

判斷一個節點是否可用,別只看一次測速:連續握手幾次是否都成功、晚高峰是否明顯掉速、長連線(視訊會議、SSH 工作階段)會不會中途斷開。這三項比單次峰值更能說明問題。

線路類型:直連、中轉與專線的差別

線路類型描述的是路徑:資料從本地出發,到落地伺服器,中間怎麼走。

直連:用戶端直接連落地伺服器,全程走公共網際網路。成本最低,晚高峰受公網壅塞影響最明顯。
中轉:先連到中轉入口,再由中轉機轉發給落地。入口位址可以更換,落地保持不變,穩定性比直連好一些,但中間段仍然是公網。
IEPL 專線:電信業者等級的國際乙太網路專線,中間段不走公共網際網路,頻寬相對獨享。延遲與抖動更可控,成本也最高。

三種線路類型的走法與適用情境
類型	走法	特點	適合
直連	本地 → 落地,全程公網	成本低;晚高峰波動明顯	臨時查資料、輕量瀏覽
中轉	本地 → 中轉 → 落地	入口可換,比直連穩一些;中間段仍是公網	日常網頁、社群、一般下載
IEPL 專線	本地 → 專線入口 → 落地,中間段不過公網	延遲與抖動更可控,晚高峰相對穩定	視訊會議、長連線、串流影音

先看線路,再看協定。晚高峰卡不卡,主要由路徑決定;協定解決的是「怎麼加密、怎麼握手」,不解決中間那段公網塞不塞。反過來,一條好線路配錯協定,一樣連不上。

站內目前的線路與方案資訊可以直接對照:90+ 國家、190+ 線路,同時在線裝置不限台數,首次付費 7 天內可申請無理由退款。

90+覆蓋國家

190+線路

不限同時在線裝置

7 天無理由退款

協定:六種常見握手方式怎麼選

協定決定用戶端與節點之間怎麼握手、怎麼加密、走 TCP 還是 UDP。它和「加密強度」不是同一回事:主流協定的外層加密都夠用,真正影響體驗的是傳輸特徵與你所在網路的環境是否相符。

六種常見協定:傳輸基礎、特點與注意事項
協定	傳輸基礎	特點	需要注意
Shadowsocks	TCP / UDP,AEAD 加密	輕量、開銷小,用戶端支援面廣	流量特徵較明顯,容易被針對性識別
VMess	TCP / WebSocket / gRPC,可套 TLS	V2Ray 體系裡的老牌協定,支援多工	校驗依賴時間,兩端時間偏差過大會握手失敗
VLESS	通常套 TLS(含 Reality)	本身不加密,靠外層 TLS,少一層開銷	設定項目多,SNI 與偽裝目標要配對
Trojan	TLS	偽裝成一般 HTTPS 流量,密碼驗證	需要網域與憑證,密碼錯直接連不上
Hysteria2	QUIC(UDP)	弱網、高丟包環境下仍能運作	依賴 UDP,部分網路會限制或劣化 UDP
TUIC	QUIC(UDP)	多工,握手快,延遲低	同樣受 UDP 品質影響

三類取捨

網路對 UDP 友善:Hysteria2、TUIC 在丟包時更穩,適合行動網路與長距離跨境鏈路。
網路限制 UDP:優先 TLS 系,VMess + TLS、VLESS + Reality、Trojan 都能走 443 連接埠。
舊裝置、舊用戶端:Shadowsocks 的相容性最好,幾乎每個用戶端都支援。

時間同步不是小事 VMess 的握手會校驗時間戳,用戶端與伺服器相差過大時會直接失敗,表現是「節點顯示可用,但一直連不上」。遇到這種情況,先把裝置時間設為自動同步,再回頭排查設定。

分流:哪些流量走代理,哪些直連

分流(routing)是一組有序規則。用戶端從上往下比對,命中一條就停止,所以順序比數量重要。

常見規則類型:

DOMAIN / DOMAIN-SUFFIX / DOMAIN-KEYWORD:按網域比對。
IP-CIDR / GEOIP:按 IP 網段或地理歸屬比對。
PROCESS-NAME:按處理程序名稱比對,只有桌面端支援。
RULE-SET:引用外部規則集,便於批次維護。
MATCH(部分用戶端寫作 FINAL):保底規則,必須放在最後。

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - DOMAIN-KEYWORD,github,PROXY
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

這段規則的意思是:example.com 及其子網域直連;網域中含 github 的走代理;解析到中國大陸 IP 的走直連;剩下的全部走代理。如果把 MATCH 移到第一行,後面所有規則都不會被執行,現象就是「規則寫了卻完全沒效果」。

DNS 洩漏:分流之外的另一半

DNS 洩漏指的是網域名稱解析請求沒有跟著代理鏈路走,而是交給了本地網路。後果有兩個:存取了哪些網域暴露在本地 DNS 上;解析結果可能被污染,拿到一個錯誤的位址。

常見做法是讓代理解析 DNS。fake-ip 模式下,用戶端在本地直接合成一個假位址回傳給應用程式,真實解析在落地側完成;代價是部分依賴真實 IP 的軟體(區域網路裝置探索、個別連線遊戲)會異常,需要給這些網域加上直連規則,或放進 fake-ip-filter。

分流自查

✅ 開啟一個中國大陸網站,連線詳情裡顯示直連,說明規則正常命中。
✅ 開啟一個境外網站,連線詳情裡顯示走代理,說明保底規則生效。
❌ 所有流量都顯示走代理,通常是模式停在全域,規則沒參與比對。
❌ 境外網站走了直連,多半是規則順序寫反,或者保底規則缺失。
❌ 網域解析仍由本地電信業者完成,存在 DNS 洩漏,需要檢查 DNS 設定。

全域與規則模式:兩個開關別混用

用戶端通常提供三種模式:

全域:所有流量都走代理,分流規則完全不生效。
規則:按分流規則決定,日常使用選這個。
直連:所有流量都不走代理。

全域模式最大的用處是排查,不是日常。遇到「某個網站打不開」,先切全域:全域能打開,說明節點、線路、協定都沒問題,問題在規則;全域也打不開,問題在節點或網路本身。這個順序能省掉大量反覆換節點的時間。

各平台用戶端:同一個訂閱,行為並不一樣

訂閱是通用的,用戶端不是。同樣的節點清單,在不同系統上的表現可能完全不同。

Windows:Clash Verge Rev(mihomo 核心)、v2rayN 較常見,可選系統代理或 TUN 模式。
macOS:ClashX Meta、Surge 等,TUN 模式需要授權系統擴充功能。
iOS:Shadowrocket、Stash 等,透過系統 VPN 設定接管流量;背景保持運作受系統限制,長時間切到背景可能斷線。
Android:Clash Meta for Android、v2rayNG 等,首次連線需要授權 VPN 服務。
Linux:多以 mihomo、sing-box 核心配合 systemd 執行;TUN 模式需要 root 或相應的網路權限。

差異集中在四點:支援的協定子集、分流規則語法、DNS 處理方式、TUN 權限。換用戶端之前,先確認它支援你正在用的協定——部分用戶端對 QUIC 系協定的支援較晚,拿 Hysteria2 節點去試,連不上未必是節點的問題。

把六個詞串起來:一次連線的全過程

用戶端用訂閱連結拉取節點清單。
你選中一個節點,用戶端讀出位址、連接埠、協定、密碼。
流量先過分流規則,決定走代理還是直連;全域/規則模式決定這套規則是否生效。
走代理的流量按協定加密,經線路類型決定的路徑到達落地。
落地伺服器解密後存取目標網站,資料原路返回。

按這個順序排障基本不會繞圈:先確認訂閱能拉到節點,再確認節點參數沒錯,再看模式是否誤開全域,最後才懷疑線路與協定。

常見問題

更新訂閱後節點全變了,是出錯了嗎?

不是。訂閱更新是整體替換,伺服器調整了節點清單就會體現出來。手動改過的名稱和排序會被覆蓋,屬於正常現象。

同一個節點,電腦能連,行動裝置連不上?

先看兩端的協定與傳輸層設定是否一致,再看行動裝置所在網路是否限制了 UDP——QUIC 系協定依賴它。同一份訂閱在不同用戶端裡解析出的參數偶爾會有差異。

全域模式能打開,規則模式打不開?

說明節點本身沒問題,問題在分流規則:檢查規則順序、保底規則是否存在,以及目標網域是否被誤判進直連清單。

一定要開 TUN 模式嗎?

不一定。系統代理只能接管遵循系統代理設定的應用程式;TUN 模式在網路層接管,能涵蓋不認系統代理的程式,但需要更高權限,設定也更複雜。按使用情境選即可。

六個詞,四層加兩個開關。訂閱管帳號,節點管入口,線路類型管路徑,協定管握手;分流決定哪些流量走代理,全域與規則模式決定規則是否生效。排障時按層往下走,比反覆換節點有效得多。