网络加⁠速新手名词速查：订⁠阅、节点与分流一次讲清

刚接触网络加速时，最容易混淆的往往不是操作按钮，而是订阅、节点、线路、协议和分流这些名词。它们分别位于连接流程的不同环节：订阅负责交付配置，节点提供连接入口，线路决定数据经过的网络路径，协议规定客户端与服务端如何通信，分流规则则决定哪些请求需要经过这条路径。只要先建立这条完整链路，客户端里的大多数选项就不再显得零散。

本文从一次实际连接出发，解释这些概念之间的关系，并说明直连、中转、IEPL 专线、全局模式、规则模式、系统代理、TUN 模式和 DNS 泄漏分别意味着什么。重点不是记住缩写，而是知道某个环节出现问题时应该检查哪里。

先看完整连接流程

用户打开客户端并导入订阅后，客户端会读取服务器地址、端口、协议参数和节点名称等配置。选择节点并建立连接后，应用产生的请求先交给客户端；客户端依据当前分流模式判断请求是直接发送，还是封装后交给远端节点。远端节点再访问目标服务，并把响应沿连接返回。

应用请求
→ 系统代理或 TUN 接管
→ 分流规则判断
→ 直连，或交给所选节点
→ 节点对应的网络线路
→ 目标服务
→ 响应按原路径返回

这段流程中，“节点”和“线路”并不是同义词。节点通常是客户端可以选择的连接配置，包含主机、端口和协议等信息；线路则描述节点背后的网络路径。同一地区可能提供不同线路，同一条线路也可能对应多个入口配置。仅看节点名称无法完整判断实际路径，应同时阅读服务商对线路类型和适用场景的说明。

订阅、配置与节点是什么

订阅是可更新的配置入口

订阅通常表现为一个链接，也可能通过客户端内的登录状态获取。客户端访问订阅后，会得到一组节点配置和相关参数。服务端调整节点地址、线路名称或可用配置后，用户可以在客户端执行“更新订阅”，而不必逐项重新填写。

订阅链接并不是普通的公开网页地址。它可能包含用于识别订阅的凭据，应当像密码一样妥善保存，不要发布到公开页面、截图或共享文档。怀疑链接已经外泄时，应通过服务面板重新生成或联系支持渠道处理。

客户端中的“本地配置”和“订阅配置”也要区分。用户手动新建的节点通常只保存在本机；从订阅获得的节点由订阅源维护。部分客户端更新订阅时会覆盖对订阅节点所做的本地修改，因此不宜直接在订阅节点上长期保存自定义参数。确需调整时，可以使用客户端提供的覆写、规则集或独立配置功能。

节点是一组可连接参数

一个节点至少需要让客户端知道连接目标和通信方式。不同协议所需字段不同，常见内容包括服务器地址、服务端口、认证信息、传输方式、TLS 设置和服务器名称。客户端把这些字段组合成可选择的项目，并用地区或线路名称帮助用户识别。

节点显示的地区通常用于描述出口或线路定位，但应用最终如何判断地区，还会受到出口 IP 数据库、DNS 解析结果、浏览器存储、账号资料和系统时区等因素影响。因此，节点名称不能单独作为地区判定的证据。需要确认出口时，应在连接后使用 IP 检测查看公网地址和 DNS 结果。

订阅更新不等于客户端升级

“更新订阅”只会重新获取节点与规则等配置，“升级客户端”则是安装新版程序。遇到订阅里出现客户端无法识别的协议时，仅刷新订阅没有作用，需要确认当前客户端是否支持该协议及相应传输参数。反过来，客户端能够启动，也不代表订阅内容仍是最新状态。

直连、中转与 IEPL 专线的区别

线路类型描述数据从本地网络到出口节点所经过的路径。它会影响连接受公网拥塞、跨网互联和路由变化的程度，但不能只根据名称推断所有时段的实际表现。判断线路时，应结合所在地网络、目标地区和具体使用时间进行测试。

直连不是“本地应用绕过代理”的意思。在节点线路语境中，直连通常表示用户直接连接远端服务器；在分流语境中，“DIRECT”却表示请求不经过代理节点。两个词的中文显示相同，但所处层级不同。阅读客户端日志时，要先判断它说的是节点路径还是规则动作。

中转线路会增加一个或多个受控转发环节。它的价值在于重新组织入口到出口之间的路径，而不是简单地让数据“多绕一站”。如果本地到中转入口的连接稳定，而入口到出口之间的网络质量较好，中转可能比公网直连更适合持续传输；如果入口本身不适合当前网络，结果也可能相反。

IEPL 是 International Ethernet Private Line 的缩写，通常指国际以太网专线。它属于网络承载与线路组织概念，不是一种代理协议，也不是客户端必须支持的特殊按钮。客户端仍可能使用 Shadowsocks、Trojan、VLESS 等协议连接入口，之后的数据再由服务端网络承载。看到“IEPL 节点”时，应理解为节点背后采用了相应线路，而不是出现了一种名为 IEPL 的加密协议。

常见协议分别解决什么问题

协议规定客户端与服务端之间如何建立会话、认证、加密或承载数据。客户端和服务端必须支持相同协议及匹配参数，否则无法建立连接。协议名称本身也不能代替完整配置，因为传输层、TLS、服务器名称和其他扩展参数都可能影响兼容性。

Shadowsocks

Shadowsocks 是常见的加密代理协议，配置通常围绕服务器、端口、密码和加密方法展开。不同实现支持的加密方法可能不同，导入后出现“不支持的加密方式”时，应优先检查客户端版本与核心实现，而不是反复切换分流模式。

VMess 与 VLESS

VMess 是带有身份标识与协议结构的代理协议，常与不同传输方式组合使用。VLESS 的设计更轻量，本身不负责提供完整的传输加密，实际部署通常配合 TLS 或其他安全传输层。两者名称相近，但配置字段和服务端实现不能随意互换。

如果订阅导入后节点存在却无法连接，应检查客户端是否完整读取了传输方式、TLS、服务器名称和路径等参数。只复制服务器地址与端口，往往不足以还原原配置。

Trojan

Trojan 通常运行在 TLS 连接之上，认证信息、服务器名称和证书验证是关键配置。系统时间明显不准确、服务器名称填写错误或证书校验失败，都可能导致握手无法完成。为排查而长期关闭证书验证并不合适，应修正时间、域名或配置来源。

Hysteria2 与 TUIC

Hysteria2 和 TUIC 都侧重基于 UDP 的现代传输，常用于应对存在丢包或波动的网络环境。它们依赖本地网络、路由设备和服务端对 UDP 的正常支持。若同一订阅中的 TCP 类协议可以连接，而这两类协议持续失败，可以检查当前网络是否限制 UDP、客户端核心是否兼容，以及系统防火墙是否允许相关程序通信。

选择协议时不必追求缩写更新。客户端兼容、线路适配和当前网络条件比名称本身更重要。服务商已经通过订阅提供参数时，通常应先使用原始配置，不要在不了解含义的情况下随意修改传输层和安全选项。

系统代理、TUN 与应用内代理

节点连接成功只说明客户端与服务器之间的通道已经建立，还需要决定应用流量怎样进入客户端。常见接管方式包括系统代理、TUN 模式和应用自身的代理设置。

系统代理

系统代理会把代理地址写入操作系统的网络设置。遵循系统代理的浏览器和应用会把请求交给客户端，但某些程序会忽略系统设置，直接建立网络连接。于是可能出现浏览器出口已经改变，而命令行工具或特定应用仍走本地网络的情况。

TUN 模式

TUN 模式通过虚拟网络接口接管更多类型的 IP 流量，覆盖范围通常比系统代理更广，也更适合需要处理不读取系统代理设置的应用。启用时可能需要系统授权，并可能与其他网络过滤、企业安全软件或已有虚拟网络接口发生冲突。

TUN 并不表示所有请求必须经过远端节点。流量进入 TUN 后，仍然可以依据规则选择代理或直连。因此，“接管方式”和“分流策略”是两个独立维度：前者决定客户端能看到哪些流量，后者决定看到流量后如何处理。

应用内代理

部分浏览器、下载工具和开发工具允许单独填写 HTTP 或 SOCKS 代理。这种方式影响范围明确，适合测试特定应用，但需要确保填写的是客户端提供的本地监听地址，而不是直接把远端节点参数填入不兼容的代理输入框。应用退出后，这类设置也不会自动跟随客户端状态变化。

全局模式、规则模式与直连模式

分流模式决定已被客户端接管的请求下一步走向。不同客户端的命名略有差异，但核心通常可以归纳为全局、规则和直连。

• 全局模式：大多数被接管的请求交给所选节点，适合验证节点是否工作，也便于排除规则匹配问题。
• 规则模式：依据域名、IP、应用或规则集选择代理、直连或拒绝，是日常使用中更常见的方式。
• 直连模式：被接管的请求仍从本地网络直接发送，常用于临时停用代理路径或测试本地连接。

规则通常按客户端定义的顺序匹配。常见条件包括完整域名、域名后缀、IP 网段、进程名称和地理数据库分类。匹配成功后执行对应动作；没有命中时则使用最终规则。出现“某个网站没有经过所选节点”时，应查看连接日志中该请求命中了哪条规则，而不是只看主界面是否显示已连接。

域名规则与 IP 规则也可能产生不同结果。应用先请求域名，客户端可以直接按域名分流；如果应用自行解析并只提交 IP，域名信息可能不可见，只能依赖 IP 规则或嗅探能力。启用嗅探会改变客户端识别流量的方式，应根据客户端文档配置，而不是把它当成所有问题的通用开关。

排查分流最有效的方法，是暂时切换到全局模式进行对照。如果全局模式可用而规则模式不可用，问题通常位于规则匹配、DNS 解析或应用接管范围；如果两种模式都不可用，则应回到节点连接与本地网络环节。

DNS 解析与 DNS 泄漏

DNS 负责把域名转换为可连接的 IP 地址。代理连接已经建立，不代表 DNS 请求一定沿相同路径发送。系统解析、客户端内置 DNS、浏览器加密 DNS 和应用自带解析可能同时存在，因此 DNS 是分流排查中经常被忽略的一层。

所谓 DNS 泄漏，通常指本应由代理侧或指定解析器处理的查询，仍被发送给本地网络的 DNS 服务。这可能暴露查询的域名范围，也可能造成地区判断不一致。检查时不能只看公网出口 IP，还要观察检测页列出的 DNS 解析位置是否符合当前配置预期。

规则模式尤其依赖 DNS 设计。客户端可能先根据域名匹配规则，再决定使用本地解析或远端解析；也可能通过虚拟 IP 机制保留域名与连接之间的映射。不同客户端实现不同，不应把其他软件的 DNS 配置原样照搬。若修改后出现域名打不开但 IP 可以访问，应检查解析器是否可达、规则是否让解析请求走错路径，以及浏览器是否启用了独立的加密 DNS。

浏览器缓存和系统 DNS 缓存也会保留旧结果。切换线路后看到的内容没有变化，不一定说明节点切换失败。可以先新建无痕窗口、关闭并重新打开目标应用，必要时按操作系统方式清理 DNS 缓存，再重新检测出口与解析结果。

不同平台的客户端差异

订阅内容可以跨平台使用，但客户端能力不会完全一致。差异通常来自操作系统网络接口、后台运行限制、代理核心版本和客户端自身的功能设计。

• Windows：常见客户端通常同时支持系统代理与 TUN。启用 TUN 时要留意管理员权限、防火墙和其他虚拟网卡。
• macOS：系统代理适合遵循系统设置的应用；需要更广泛接管时会使用网络扩展或 TUN，并触发系统授权。
• iOS：客户端通过系统提供的网络扩展建立连接。后台行为、按需连接和规则能力取决于客户端实现与系统限制。
• Android：客户端一般使用系统 VPN 接口接管流量，常可按应用分流。省电策略可能影响客户端在后台维持连接。
• Linux：发行版和桌面环境差异较大，可以使用图形客户端、系统代理、TUN 或命令行核心，需要自行确认权限与 DNS 集成。

从一个平台迁移到另一个平台时，应重新导入订阅，不要只复制界面截图中的服务器和端口。还要确认新客户端支持订阅中的协议、传输方式和规则格式。若服务提供官方客户端，优先使用与订阅配置匹配的版本通常更省去兼容性判断。

从导入订阅到验证连接

新手可以按固定顺序操作，每一步只验证一个环节。这样即使连接失败，也能迅速判断问题位于配置、节点、接管、分流还是 DNS。

1. 获取可信订阅。从服务面板复制订阅或在客户端内登录获取，不使用来源不明的公开配置。
2. 选择兼容客户端。确认客户端支持订阅包含的协议，并允许系统要求的网络权限。
3. 导入并更新订阅。检查是否出现节点名称；如果列表为空，先处理订阅读取问题。
4. 选择节点并连接。查看客户端日志，确认协议握手成功，而不是只观察按钮颜色。
5. 确认流量接管方式。根据应用范围启用系统代理或 TUN，避免同时叠加多个不清楚用途的代理设置。
6. 先用全局模式验证。确认目标请求能够经过节点后，再切回规则模式。
7. 检查出口与 DNS。对照公网 IP、出口地区和 DNS 解析结果，判断流量是否按预期发送。
8. 恢复日常分流。观察目标域名命中的规则，必要时只调整相关规则，不重置全部网络配置。

常见误区与快速判断

节点显示已连接，但网页打不开

“已连接”可能只代表客户端完成了到节点的握手。接下来应检查应用是否被系统代理或 TUN 接管、规则是否把请求设为直连、DNS 是否能够解析，以及浏览器是否使用了独立代理设置。可以通过全局模式和不同应用进行对照。

换协议后速度仍没有变化

性能不仅由协议决定，还受到本地接入、线路路径、目标服务响应和当前网络拥塞影响。若多个协议实际使用同一入口和同一出口线路，单纯切换协议未必改变主要瓶颈。更有意义的做法是对比不同线路类型，并保持测试时间、目标和应用一致。

更新订阅后自定义节点消失

这通常是因为修改发生在订阅托管的配置上，更新时被服务端版本覆盖。应把自定义规则放入客户端提供的覆写区，或者另存为本地配置。修改前先导出备份，并确认导出内容不会被公开分享。

出口地区正确，服务仍判断为其他地区

地区判定可能综合出口 IP、DNS、账号资料、浏览器缓存、定位权限和系统环境。先清理旧会话并重新检查 DNS，不要频繁切换大量节点。若目标服务对账号地区有单独规则，应以其公开说明为准，网络出口变化并不会自动修改账号属性。

规则模式只有部分应用生效

先判断未生效应用是否进入了客户端。系统代理无法覆盖所有程序，TUN 的应用排除设置也可能跳过特定进程。如果日志中完全没有该应用的连接记录，问题更可能在接管层；如果日志存在但动作显示直连，则应检查规则层。