使用教程 约 8 分钟

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。它和「加密强度」不是一回事:主流协议的外层加密都够用,真正影响体验的是传输特征与你所在网络的环境是否匹配。

六种常见协议:传输基础、特点与注意事项
协议传输基础特点需要注意
ShadowsocksTCP / UDP,AEAD 加密轻量、开销小,客户端支持面广流量特征较明显,容易被针对性识别
VMessTCP / WebSocket / gRPC,可套 TLSV2Ray 体系里的老牌协议,支持多路复用校验依赖时间,两端时间偏差过大会握手失败
VLESS通常套 TLS(含 Reality)本身不加密,靠外层 TLS,少一层开销配置项多,SNI 与伪装目标要配对
TrojanTLS伪装成普通 HTTPS 流量,密码认证需要域名与证书,密码错直接连不上
Hysteria2QUIC(UDP)弱网、高丢包环境下仍能跑依赖 UDP,部分网络会限制或劣化 UDP
TUICQUIC(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 节点去试,连不上未必是节点的问题。

把六个词串起来:一次连接的全过程

  1. 客户端用订阅链接拉取节点清单。
  2. 你选中一个节点,客户端读出地址、端口、协议、密码。
  3. 流量先过分流规则,决定走代理还是直连;全局/规则模式决定这套规则是否生效。
  4. 走代理的流量按协议加密,经线路类型决定的路径到达落地。
  5. 落地服务器解密后访问目标站点,数据原路返回。

按这个顺序排障基本不会绕圈:先确认订阅能拉到节点,再确认节点参数没错,再看模式是否误开全局,最后才怀疑线路与协议。

常见疑问

更新订阅后节点全变了,是出错了吗?

不是。订阅更新是整体替换,服务端调整了节点列表就会体现出来。手动改过的名字和排序会被覆盖,属于正常现象。

同一个节点,电脑能连,移动端连不上?

先看两端的协议与传输层配置是否一致,再看移动端所在网络是否限制了 UDP——QUIC 系协议依赖它。同一份订阅在不同客户端里解析出的参数偶尔会有差异。

全局模式能打开,规则模式打不开?

说明节点本身没问题,问题在分流规则:检查规则顺序、兜底规则是否存在,以及目标域名是否被误判进了直连列表。

一定要开 TUN 模式吗?

不一定。系统代理只能接管遵循系统代理设置的应用;TUN 模式在网络层接管,能覆盖不认系统代理的程序,但需要更高权限,配置也更复杂。按使用场景选即可。

六个词,四层加两个开关。订阅管账号,节点管入口,线路类型管路径,协议管握手;分流决定哪些流量走代理,全局与规则模式决定规则是否生效。排障时按层往下走,比反复换节点有效得多。
首月免费