VPN 新手名词速查:订阅、节点、线路类型、协议、分流、全局与规则模式

第一次接触 VPN 或代理客户端时，订阅、节点、线路类型、协议、分流、全局模式和规则模式常被混在一起。它们其实位于不同层级：订阅负责分发配置，节点是一组可连接的服务器参数，线路描述数据如何到达节点，协议规定客户端与服务端怎样通信，而分流模式决定哪些请求进入代理通道。

理解这些名词，不需要先背完整的网络原理。更实用的方法是沿着一次连接的顺序来看：客户端读取订阅，得到节点列表；用户选择节点后，客户端按对应协议建立连接；系统流量再由全局或规则模式决定走代理还是直连。只要先把层级分开，多数设置页面就不再难懂。

先分清订阅、节点与服务器

订阅链接是一份可更新的配置入口

订阅链接通常由服务端生成，客户端访问该链接后，会取得节点名称、服务器地址、端口、协议参数及必要的认证信息。它更像一份远程配置清单，而不是某个具体节点。服务端调整线路后，用户可以在客户端执行“更新订阅”或“刷新配置”，不必逐项重新填写。

订阅链接可能返回经过编码的文本，也可能返回 Clash、sing-box 等客户端能够识别的配置格式。浏览器直接打开时，即使看到一长串字符，也不代表链接损坏。正确操作通常是复制完整链接，再粘贴到客户端的订阅导入位置。

节点是客户端里可选择的一条连接配置

节点通常包含目标服务器、端口、协议、认证参数和传输设置。客户端列表里的“东京”“新加坡”或“美国”等名称，多数只是便于识别的标签。节点名称相同，不代表底层服务器、入口或网络路径完全相同；名称不同，也可能共享部分基础设施。

“服务器”偏向物理或虚拟计算资源，“节点”偏向用户能够连接的配置项。一个服务器可以承载不同协议或端口，从而形成多个节点配置。反过来，一个对外显示的节点也可能经过负载调度，实际连接到不同后端。因此，选节点时应以实际连接表现和用途为准，不要只看名称。

• ✅ 订阅更新后，先确认原有节点是否被替换或重命名。
• ✅ 导入多个订阅时，为不同来源添加清晰的分组名称。
• ✅ 节点失效时先刷新订阅，再检查客户端时间与网络权限。
• ❌ 不要把订阅链接当成单个节点地址手动拆分。
• ❌ 不要仅凭地区名称推断线路质量或具体路径。

IEPL 专线、中转与直连分别是什么

线路类型描述的是本地网络如何到达远端节点。它和 Shadowsocks、Trojan 等协议不是一回事。协议相同的两个节点，可以采用不同线路；同一类线路也可以承载不同协议。把“线路”和“协议”混为一谈，是新手选线时最常见的误区。

直连并不等于一定更快

直连少了中转环节，但网络路由不一定最短。跨运营商、跨地区或国际出口拥塞时，数据可能绕行。相反，位置合理的中转入口可以把本地到入口这一段控制在较稳定的路径上，再由后端完成跨境传输。因此，不能仅按“经过的服务器更少”判断速度。

中转也不等于节点位置

某个节点显示为日本，通常表示出口位于日本或以日本出口为主要用途；中转入口却可能位于其他地区。网站看到的出口 IP 与客户端首先连接的入口并不总是同一位置。排查问题时，要区分“入口连接失败”和“出口服务异常”。

IEPL 是线路资源，不是加密协议

IEPL 常用于描述国际以太网专线连接。它解决的是部分网络承载路径问题，不负责定义客户端认证、加密或流量封装方式。客户端仍需要使用具体协议连接服务端。看到“IEPL 节点”时，可以理解为该节点的部分传输链路使用了相应专线资源，而不是出现了一种名为 IEPL 的客户端协议。

常见协议名各代表什么

协议决定客户端和服务端如何认证、封装并传输数据。客户端必须支持节点所使用的协议及相关传输参数，否则即使服务器地址和端口正确，也无法建立连接。下面这些名称经常出现在订阅配置中，但它们的设计重点并不相同。

Shadowsocks 配置相对紧凑，兼容客户端较多，但加密方式必须与服务端一致。VMess 和 VLESS 常与 WebSocket、gRPC、TCP、TLS 或 REALITY 等传输与安全层组合使用。订阅导入的价值就在这里：它可以把彼此关联的参数作为完整配置交给客户端，减少手工漏填。

Trojan 常结合 TLS 与域名证书校验。若设备时间明显错误、域名填写不一致或证书验证失败，连接可能无法建立。遇到证书错误时，应检查系统时间和订阅配置，而不是直接关闭证书验证。

Hysteria2 与 TUIC 都依赖 QUIC，并主要运行在 UDP 之上。它们在部分高延迟或存在丢包的网络中可能有较好的传输表现，但前提是本地网络允许相应 UDP 通信。如果公司、校园、酒店或公共网络限制 UDP，这类节点可能连接失败，此时可换用基于 TCP 的可用节点进行对照。

订阅链接如何导入客户端

不同客户端的按钮名称会有差别，但导入逻辑基本一致。先从可信的服务面板复制订阅链接，再在客户端中添加远程配置或订阅，等待解析完成后选择节点。不要把订阅内容逐行改写成手工配置，除非明确理解每个字段的用途。

1. 复制完整链接：确认没有遗漏开头、参数或末尾字符。某些聊天软件会截断长链接，复制后可先检查文本是否完整。
2. 打开订阅管理：在客户端中寻找“订阅”“配置”“远程配置”或“从 URL 导入”等入口。
3. 粘贴并保存：为订阅填写便于识别的名称，然后执行更新。若客户端要求选择配置格式，应以服务说明为准。
4. 选择节点：在代理组或节点列表中选择目标地区，不要停留在未指定出口的空配置上。
5. 选择运行模式：日常使用通常先采用规则模式，需要完整测试代理链路时再临时切换全局模式。
6. 验证连接：访问网络检测页面，确认出口 IP、DNS 与预期一致，再测试实际需要使用的网站或应用。

更新订阅通常会覆盖由该订阅生成的节点。如果直接修改订阅节点的内部参数，下次更新时可能恢复原值。需要长期保留的自定义规则，适合放在客户端支持的覆写、扩展配置或本地规则文件中，而不是直接改远程节点。

订阅链接
  → 客户端获取远程配置
  → 解析节点与代理组
  → 选择节点
  → 建立协议连接
  → 分流规则判断请求去向
  → 代理或直连

• ✅ 导入后检查节点列表是否正常显示，而不是只看“添加成功”提示。
• ✅ 定期使用客户端自带的订阅更新功能获取配置变更。
• ✅ 更换客户端前确认新客户端支持订阅中的协议和传输方式。
• ❌ 不要在来源不明的网站中转换包含凭据的订阅链接。
• ❌ 不要同时启用多个会接管系统网络的客户端进行排查。

全局、规则与直连模式怎么选

运行模式决定流量进入客户端后如何处理。它不会改变节点本身，也不会把直连线路变成中转线路。新手看到“全局”时容易理解成速度更快，其实它只表示更多请求被交给当前代理节点。

全局模式：多数流量统一走代理

全局模式适合临时排查规则遗漏，或确认某个网站在代理路径下是否能够访问。它的缺点是本地网站、局域网服务和不需要代理的应用也可能绕行，带来额外延迟，还可能影响打印机、路由器管理页或本地开发服务。

规则模式：按域名、IP 或应用分类

规则模式会按规则集判断请求。常见逻辑包括：局域网地址直连，本地常用网站直连，需要国际线路的域名交给代理，广告或恶意域名按规则拦截。规则可以基于域名后缀、完整域名、IP 网段、进程名称或规则集合，具体能力取决于客户端和系统平台。

规则匹配通常存在顺序。较具体的规则应放在较宽泛的规则之前，最终未匹配流量则由兜底规则处理。例如，一个域名已被更靠前的直连规则命中，后面的代理规则就不会再生效。遇到“某个网站没有走预期节点”时，应查看连接日志中的命中规则，而不是只反复切换节点。

直连模式：不经过代理节点

直连模式常用于暂停代理、对照本地网络表现或访问局域网设备。有些客户端的“关闭系统代理”只是不再接管遵循系统代理的应用，已经启用的 TUN 模式可能仍在处理流量。因此，暂停连接时要看客户端状态，而不是只看系统代理开关。

系统代理、TUN 与应用分流的区别

系统代理是操作系统提供给应用读取的代理设置。浏览器和部分桌面软件会遵循它，但某些游戏、命令行工具或自行建立网络连接的应用可能忽略系统代理。于是会出现浏览器已经生效，其他应用仍然直连的情况。

TUN 模式通过虚拟网络接口接管更广范围的 IP 流量，再交给客户端判断代理或直连。它对不读取系统代理设置的应用更有效，但通常需要额外系统权限，也更容易与其他网络工具、防火墙、虚拟机或企业安全软件发生路由冲突。

应用分流则按进程或应用决定去向。移动平台常见“仅代理所选应用”或“绕过所选应用”，桌面客户端可能提供进程规则。应用更新后若可执行文件路径改变，旧规则可能不再命中，因此排查时要核对实际进程名称。

• ✅ 浏览器生效而游戏无效时，检查游戏是否忽略系统代理。
• ✅ 开启 TUN 后无法访问局域网时，检查局域网绕过和路由规则。
• ✅ 应用分流失效时，核对进程名称与客户端运行权限。
• ❌ 不要同时让系统代理、TUN 和其他网络工具重复接管同一流量后再凭感觉判断故障。

DNS 泄漏与分流为什么互相关联

访问域名前，设备通常需要通过 DNS 把域名解析为 IP 地址。如果网页流量走代理，但 DNS 请求仍发往不符合预期的本地解析器，就可能暴露访问域名的解析行为，也可能获得与代理出口地区不匹配的地址。这通常被称为 DNS 泄漏或 DNS 路径不一致。

规则分流依赖域名时，客户端需要在合适的阶段获取域名信息。若应用提前解析并只把 IP 交给客户端，纯域名规则可能无法命中；若 DNS 返回受地区影响的地址，也可能导致内容分发网络选择不合适的入口。因此，现代客户端常把 DNS、规则匹配和代理连接放在同一套配置中处理。

常见排查顺序

1. 确认客户端的 DNS 模块是否启用，并查看当前使用的解析方式。
2. 确认浏览器自身的加密 DNS 设置是否绕过客户端配置。
3. 检查目标域名命中了直连、代理还是兜底规则。
4. 清理操作系统与浏览器 DNS 缓存后重新测试。
5. 在网络检测页比较出口 IP 与 DNS 解析器是否符合当前模式预期。

DNS 检测结果不应只看解析器名称。某些公共解析服务采用全球调度，显示的地区可能与实际网络路径不同。更重要的是确认请求是否按预期通过客户端处理、是否出现本地运营商解析器，以及切换模式后结果是否发生合理变化。

不同平台的客户端差异

相同订阅在不同平台上，显示方式和可用能力可能不同。原因通常不是订阅内容改变，而是操作系统权限、客户端核心与网络接管方式不同。

Windows

Windows 客户端通常同时提供系统代理和 TUN。系统代理适合浏览器及遵循系统设置的软件；游戏、商店应用或部分命令行程序可能需要 TUN。开启 TUN 时，客户端可能请求管理员权限以创建虚拟网卡和写入路由。

macOS

macOS 上的系统代理同样不能覆盖所有应用。使用网络扩展或虚拟接口时，系统会要求用户授权。若客户端更新后连接异常，可检查网络扩展权限是否仍然有效，以及系统中是否残留其他 VPN 配置。

Android

Android 客户端通常通过系统 VPN 接口接管流量，并可提供按应用分流。系统同一时刻通常只允许一个活动 VPN 通道，因此其他防火墙、广告过滤或企业网络应用可能与代理客户端互相替换。

iOS 与 iPadOS

iOS 和 iPadOS 客户端依赖系统提供的网络扩展能力。不同客户端支持的协议核心并不完全一致，导入成功但节点无法启动时，应先核对协议和传输方式是否受支持。系统的按应用控制也受应用能力与设备管理策略影响。

连接失败时按层级排查

有效的排查方法不是连续点击多个节点，而是判断故障发生在哪一层。先确认本地网络，再确认订阅和节点，之后检查协议连接，最后检查规则与 DNS。每次只改变一个变量，才能知道是哪项调整产生作用。

• ✅ 本地网络层：关闭代理后确认普通网站可以正常访问。
• ✅ 订阅层：更新订阅并检查是否返回节点，而不是登录页或错误文本。
• ✅ 节点层：选择同一订阅中的其他可用节点进行对照。
• ✅ 协议层：查看日志中的超时、证书、认证、UDP 或不支持参数提示。
• ✅ 接管层：确认系统代理或 TUN 已按预期启用，且没有其他工具冲突。
• ✅ 规则层：查看目标连接命中的规则与代理组。
• ✅ DNS 层：检查解析路径、缓存与浏览器独立设置。
• ❌ 不要同时更换节点、协议、DNS 和运行模式，否则无法定位原因。

日志里的“超时”只表示规定时间内没有完成连接，并不能单独说明服务器、线路或本地网络哪一方有问题；“认证失败”更偏向凭据或系统时间问题；“证书名称不匹配”通常需要检查域名、TLS 配置和系统时间；“不支持的协议或传输”则应检查客户端核心版本。

掌握这套层级后，设置页中的名词可以重新串起来：订阅负责提供配置，节点提供连接目标，线路影响到达目标的路径，协议规定通信方法，系统代理或 TUN 负责接管流量，规则模式决定请求去向，DNS 则参与域名解析与分流判断。选型时不必追逐最长的功能列表，能与当前平台和网络环境稳定配合，才是更实际的标准。