VPN 新手完整指南：订阅、节点、协议与分流

这份 VPN 新手完整指南从客户端里最常见的“订阅、节点、协议、分流”开始，不要求预先掌握网络知识。核心思路是先分清配置从哪里来、流量经过哪里，再决定哪些请求需要走跨境线路。理解这些概念后，导入失败、节点能连但网页打不开、国内网站变慢等问题通常都能按顺序排查，而不必反复切换所有选项。

订阅链接、配置文件与节点是什么

订阅链接是一段供客户端读取配置的地址。客户端访问该地址后，会取得服务端发布的节点名称、服务器地址、端口、协议参数以及分组信息。服务方调整入口或参数时，用户通常只需在客户端中更新订阅，不必逐项重新填写。

订阅链接并不是用于日常浏览的普通网页。它可能包含与账户配置关联的访问凭据，因此不应公开粘贴到论坛、测速页面或截图中，也不宜交给来源不明的在线转换工具。需要跨客户端转换格式时，应优先使用服务方提供的兼容格式或在可信环境中完成转换。

配置文件与订阅链接的作用相近，但更新方式不同。静态配置文件保存的是导出当时的内容；订阅链接则允许客户端重新拉取服务端当前配置。若节点名称已经更新而客户端仍显示旧列表，应先执行“更新订阅”，再检查本地缓存，而不是直接判断线路不可用。

节点通常表示客户端可以选择的一个连接入口。名称可能包含地区、城市、线路类型或用途标签，但名称本身不等于完整路径。两个名称都写着同一地区的节点，可能分别使用直连、中转或专线；同一个入口也可能因本地运营商、接入网络和目标网站不同而表现不同。

导入订阅的通用步骤

1. 从服务面板复制与当前客户端兼容的订阅链接，不要手动删改其中字符。
2. 在客户端中找到“订阅”“配置来源”或“远程配置”，新增链接并保存。
3. 执行一次更新，确认列表中出现节点或策略组，而不是只看到订阅名称。
4. 选择一个与目标内容所在地区接近的节点，再启用系统代理或隧道模式。
5. 打开目标网站进行验证；若失败，依次检查订阅更新时间、协议兼容性、系统代理状态和 DNS 设置。

直连、中转与 IEPL 专线有什么区别

节点是用户看到的入口，线路则描述数据从本地到入口或从入口到目标网络时采用的路径。线路标签有助于初筛，但实际质量仍受到本地网络、出口拥塞、目标站点互联和客户端协议影响。选择时应把“节点地区”和“线路类型”分开看。

直连并不等于一定更快。若本地到境外入口的公共网络路径稳定，直连可以减少转发环节；若跨网互联质量不理想，中转可能通过更合适的入口改善路径。IEPL 是国际以太网专线的行业术语，但不同服务对专线入口、出口和后续路径的设计并不相同，不能只凭名称推断所有流量都处于同一种承载方式。

新手选择线路时，可以先按目标内容所在地区筛选，再比较线路类型。例如访问面向日本地区提供的内容，应优先查看日本落地入口，而不是单纯选择地理上离自己最近的节点。用于日常文档、代码仓库或网页浏览时，则应优先观察连接稳定性和域名解析是否正常。

Shadowsocks、VMess、Trojan、VLESS、Hysteria2 与 TUIC

协议规定客户端与服务器如何建立连接、验证身份、封装数据和选择传输方式。协议名称不直接代表节点地区，也不能单独保证速度。服务端必须支持相同协议，客户端还要正确实现对应传输与安全参数，配置才能建立连接。

Shadowsocks

Shadowsocks 是加密代理协议，配置通常包含服务器、端口、加密方法和密码。它本身更接近代理而非传统系统级 VPN；是否能接管所有应用，取决于客户端是否提供系统代理、虚拟网卡或透明代理能力。浏览器能访问而其他应用不能访问时，应检查客户端接管模式，不要只检查节点。

VMess 与 VLESS

VMess 是 V2Ray 生态中常见的协议，包含身份验证和协议层处理，对系统时间明显错误等情况较为敏感。VLESS 采用更精简的认证与数据结构，本身不负责提供完整的传输加密，通常需要结合 TLS、REALITY 或其他受支持的安全传输方式。导入时不能只复制服务器地址，还要保留传输类型、主机名、路径、安全层和认证标识等参数。

Trojan

Trojan 通常建立在 TLS 连接之上，配置会涉及服务器名称、证书校验和密码。若客户端时间、服务器名称或证书校验参数不匹配，连接可能在 TLS 握手阶段失败。关闭证书校验并不是通用修复方法；更合理的做法是检查订阅是否完整、系统时间是否正确，以及客户端是否支持配置中使用的传输方式。

Hysteria2 与 TUIC

Hysteria2 和 TUIC 都利用基于 UDP 的 QUIC 技术思路，侧重在有丢包或波动的网络中改善传输体验，并支持并发数据流。它们不是在所有网络中都更快：某些办公网络、公共网络或路由设备会限制 UDP，此时可能出现握手失败、连接很快中断或只能传输少量数据。遇到这种情况，应切换到基于 TCP 与 TLS 的兼容节点进行对照，而不是持续修改无关的分流规则。

对新手而言，最稳妥的选择原则不是追逐协议名称，而是先用服务方原生提供、客户端完整支持的配置。若多个协议都可用，再结合当前网络是否允许 UDP、是否需要系统级接管以及目标应用的稳定性进行比较。

系统代理、TUN 模式与 VPN 模式的区别

桌面客户端常见的“系统代理”会修改操作系统代理设置，让遵循该设置的应用把 HTTP 或 SOCKS 请求发送给本地客户端。浏览器通常能够使用系统代理，但部分游戏、命令行程序和自行实现网络栈的应用可能忽略它。因此，“浏览器正常，其他软件直连”往往是接管范围问题。

TUN 模式会创建虚拟网络接口，通过系统路由把更多类型的 IP 流量送入客户端，再由客户端按规则处理。它覆盖面更广，也更容易受到路由冲突、权限、防火墙和其他网络工具影响。启用后若本地打印、局域网设备或企业内网无法访问，需要检查局域网绕过规则，而不是把所有私有地址都转发到远端。

移动平台通常通过系统提供的 VPN 接口接管流量。状态栏显示 VPN 标记，只表示系统隧道接口已启用，并不说明每个域名都经过远端节点。客户端仍可能按照规则让部分流量直连，这正是规则模式的正常行为。

• 只有浏览器可用：检查系统代理与应用自身代理设置。
• 所有应用都无法访问：检查节点连接、隧道权限、默认路由和 DNS。
• 局域网设备无法访问：检查私有网络绕过与路由冲突。
• 切换其他网络后恢复：检查原网络对 UDP、代理端口或特定传输的限制。

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

全局模式通常表示客户端接管的流量统一交给当前代理节点。它适合临时验证“问题是否与分流规则有关”：如果规则模式无法访问，而全局模式可以访问，重点应转向域名匹配、规则优先级或 DNS 解析，而不是协议本身。

全局模式不适合作为所有场景的默认答案。国内网站、局域网服务和对来源地区敏感的应用也可能被送往远端，导致路径绕行、登录环境变化或本地资源不可达。所谓“全局”也只针对客户端成功接管的流量；不受系统代理或隧道控制的程序仍可能直连。

规则模式会根据域名、IP、应用进程或规则集决定流量走代理、直连还是拒绝。常见逻辑是让本地服务和局域网直连，让需要跨境访问的域名使用代理。规则通常按顺序匹配，较宽泛的规则放在前面，可能遮盖后续更具体的规则。

直连模式表示流量不经过远端代理。它常用于暂停代理、访问局域网资源或排查本地网络是否正常。如果直连也无法打开某个本地可访问的网站，问题可能出在基础网络、浏览器缓存或本地 DNS，而不是节点。

实用的选择顺序

1. 初次导入后使用规则模式，选择与目标内容地区匹配的节点。
2. 访问失败时短暂切换全局模式，判断是否为规则遗漏。
3. 全局模式仍失败时，检查节点连接、协议兼容、系统时间和 DNS。
4. 本地服务异常时切换直连进行对照，并检查局域网绕过规则。
5. 确认原因后回到规则模式，只修正必要的域名或应用规则。

DNS 泄漏是什么，为什么会出现“能连接但打不开”

用户输入域名后，系统需要先通过 DNS 查询对应地址。若网页流量进入代理，而 DNS 查询仍发送给本地网络指定的解析器，本地解析方仍可能看到所查询的域名，这通常被称为 DNS 泄漏。它也可能造成解析结果与代理出口地区不一致，使目标网站返回错误地址、地区页面或连接失败。

DNS 泄漏不应只靠一个测试页面下结论。浏览器可能启用自己的加密 DNS，操作系统可能保留缓存，客户端也可能对不同域名使用不同解析器。正确排查方式是先明确当前接管模式，再查看客户端 DNS 选项和分流逻辑。

DNS 排查步骤

1. 确认客户端是否启用了远程 DNS、代理 DNS 或由隧道接管的解析功能。
2. 检查规则模式是否先解析域名再匹配 IP；不同客户端的处理顺序可能不同。
3. 清理系统与浏览器 DNS 缓存，再重新连接节点，避免旧结果干扰。
4. 暂时关闭浏览器独立的加密 DNS进行对照，判断解析请求由谁发送。
5. 若启用 TUN 后完全无法解析，检查虚拟接口 DNS、系统防火墙和其他网络工具是否冲突。

还有一种常见现象是 DNS 正常返回地址，但连接仍失败。此时应检查目标流量是否真的匹配到代理规则、节点是否支持对应的网络类型，以及 IPv6 流量是否绕过了仅处理 IPv4 的配置。客户端若未完整接管两类地址，可能出现同一网站时好时坏的现象。

分流规则如何匹配域名与应用

分流规则通常包含域名、域名后缀、IP 网段、地理规则、应用进程和最终兜底规则。域名后缀规则可以覆盖一个站点及其子域名，但大型服务往往还依赖内容分发、登录、图片和接口域名，只添加主页域名可能造成页面框架出现而内容加载失败。

规则顺序同样重要。客户端一般从上到下寻找首个匹配项：如果“所有域名直连”之类的宽泛规则位于前面，后面的具体代理规则就不会生效。最终规则用于处理没有命中前面条件的请求，配置为代理还是直连，会显著影响整体行为。

IP 规则存在一个前提：客户端需要先获得目标地址。如果 DNS 查询在本地完成，域名可能被解析到与代理出口不匹配的地址；如果客户端使用远程解析，得到的地址又可能不同。因此，对依赖地域调度的网站，优先采用域名规则通常更容易理解和维护。

局域网与本地服务 → 直连
明确需要跨境访问的域名 → 代理
已知应保持本地出口的应用 → 直连
未匹配流量 → 按当前用途选择兜底策略

上面的顺序是逻辑示意，不是可直接导入的配置。不同客户端使用 YAML、JSON、图形规则或专用语法，字段名称也不相同。复制规则前应核对客户端文档，尤其注意域名后缀、完整域名和关键字匹配的区别。

Windows、macOS、Android、iOS 与 Linux 的客户端差异

同一份订阅在不同平台上不一定呈现完全相同的选项。原因通常不是节点发生变化，而是操作系统提供的网络接口、后台限制和客户端实现不同。迁移平台时，应确认协议与传输是否受支持，不要只比较客户端名称。

Windows 客户端常同时提供系统代理与 TUN 模式。TUN 可能需要虚拟网卡驱动和相应权限，企业安全策略也可能限制驱动安装。若退出客户端后系统仍无法联网，应检查系统代理是否被正确恢复。

macOS 通常通过网络扩展建立隧道，首次启用时需要用户批准相关系统权限。系统代理与网络扩展可以由不同功能控制，菜单栏显示已连接时，也应确认当前启用的是哪一种接管模式。其他防火墙或网络过滤扩展可能影响路由与 DNS。

Android 客户端一般使用系统 VPNService 接口，并可能提供按应用分流。电池优化和后台限制会在锁屏后暂停客户端进程，表现为连接标记仍在但数据无法持续传输。需要长期保持连接时，应检查系统对该客户端的后台运行策略。

iOS 客户端通过系统网络扩展工作，可用协议取决于客户端实现与系统权限。订阅中的某种传输若未被客户端支持，可能被忽略或显示为不可用。导入前应核对客户端支持列表，而不是手动删掉无法识别的字段后继续连接。

Linux 的差异更多来自发行版、桌面环境、路由工具和 DNS 管理组件。命令行代理只会影响显式使用代理环境变量的程序；需要接管其他应用时，通常还要配置 TUN、策略路由或透明代理。排查时应分别检查接口、路由表、DNS 管理和防火墙规则。

连接异常时按什么顺序排查

同时修改协议、节点、DNS、分流和系统代理，会让问题更难定位。更有效的方法是每次只改变一个变量，并记录哪一步改变了结果。下面的顺序从配置来源开始，逐层检查到应用侧。

1. 检查订阅：确认链接未被截断，更新操作有明确成功提示，节点列表不是旧缓存。
2. 检查客户端兼容性：确认客户端支持当前协议、传输方式与安全参数。
3. 检查节点连接：查看错误发生在 DNS、TCP、UDP、TLS 还是认证阶段。
4. 检查接管方式：确认目标应用遵循系统代理，或已被 TUN、系统 VPN 接口接管。
5. 检查分流：临时使用全局模式对照，判断域名是否被错误分配到直连。
6. 检查 DNS：清理缓存，核对远程解析与浏览器独立解析设置。
7. 检查本地环境：排除防火墙、其他 VPN、网络过滤扩展和企业策略冲突。
8. 更换网络对照：若同一配置在另一网络可用，重点检查原网络的 UDP 与路由限制。

客户端日志比“连接不上”的描述更有价值，但分享日志前应移除订阅链接、认证信息、服务器凭据和本地文件路径。向技术支持说明平台、客户端版本、接管模式、节点协议、错误发生阶段以及已经做过的对照测试，通常比连续发送多张界面截图更容易定位问题。