协议与线路技术参考

分清连接中的协议与路径

先建立分层视角

打开网页看似只是发出请求，实际要经过本地应用、系统网络接口、客户端规则、服务入口以及目标站点。客户端决定哪些请求需要代理，协议规定客户端与服务端如何交换数据，线路则描述这些数据经过什么路径。三者有关联，却不能互相替代。把连接失败直接归因于某个协议，容易忽略域名解析、路由规则或本地网络权限。排查前先说清故障发生在哪个环节，才有可验证的下一步。

还要区分代理协议与底层传输。Shadowsocks、VMess、Trojan、VLESS 等名称描述各自的代理机制，但具体连接可能配合不同传输与安全层使用。TCP 提供有序可靠的字节流，UDP 提供数据报传递；建立在 UDP 上的 QUIC 又实现自己的可靠传输、拥塞控制与安全握手。因此，不能把“用了 UDP”直接理解为“不重传”，也不能把协议名称当作完整配置说明。

域名解析是另一条容易混淆的链路。应用可能使用系统解析，也可能自行解析；客户端可以接管部分解析过程，但行为取决于工作模式与规则。解析得到的地址还可能影响目标站点的内容分发位置。出现网页入口正常、图片加载困难的情况，未必是主连接中断，也可能是静态资源域名走了不同规则。观察时应分别记录域名、规则命中和实际出口，而不是只看首页能否打开。

把入口、出口与目标站点分开

入口是设备接入服务网络的位置，出口是目标网站看到的网络来源。中转线路的入口和出口可以位于不同地区，标签中的地区通常更接近出口含义，但仍需以面板说明为准。连接到某个地区，不代表数据沿地理直线到达那里。运营商互联、路由策略和链路调度都会改变实际路径。地图距离适合帮助理解方向，不能代替真实连接中的路径与质量判断。

客户端显示“已连接”，一般说明某个连接状态或系统接口已建立，不等于所有应用都已按预期转发。浏览器可能正常，而命令行工具没有读取系统代理；系统网络接口可能已启用，但应用被分流规则指定为直连。反过来，客户端中的探测失败也不必然代表所有业务失效，因为探测地址和真实业务目标不同。有效判断应回到具体应用，检查它实际访问的服务是否完成了预期操作。

加密也需要按边界理解。客户端与代理服务端之间的保护，并不自动替代应用自己的 HTTPS；目标站点的证书验证仍然重要。使用代理不会赋予服务账户权限或内容授权，也不能消除所有隐私风险。VPN86 的无日志策略属于服务隐私承诺，具体边界应阅读隐私政策。讨论协议时，把传输保护、账户安全与隐私政策分别看待，比只比较一个“加密”标签更准确。

建立自己的连接记录时，写下设备平台、客户端工作模式、线路名称、协议和出错应用即可。不要把订阅地址、账户密码或完整认证字段放入截图。这样既能保留复现条件，也能避免排查资料包含敏感信息。后续章节的比较都建立在这个分层视角上：先定位，再调整；先确认应用走向，再讨论协议是否适合当前链路。

理解常见协议的设计取舍

从封装与安全边界看差别

Shadowsocks 以轻量代理为设计重点，通过相应加密方法保护客户端与服务端之间的数据。它的实现生态较广，适合需要简洁代理能力的环境，但“简洁”不代表任意实现都具有相同资源占用。加密算法、硬件指令支持、连接数量和客户端内核都会影响表现。遇到导入错误，应先确认加密方法与客户端支持范围是否匹配；只看到名称相同，不能证明参数与实现能够互通。

VMess 自带认证与数据保护机制，具体使用时还会涉及传输承载及相关参数。它的选型价值通常来自既有配置兼容与客户端生态，而不是一个固定的速度结论。部分认证与校验过程对系统时间有要求，因此设备时间明显异常时，应先恢复自动校时，再检查网络。不要为了修复握手问题随意关闭校验，也不要把旧配置中的字段机械复制到不同协议中。

Trojan 将代理认证放在 TLS 保护的连接内，证书、服务名称与 TLS 配置因此是连接成立的重要条件。它适合已经具有良好 TLS 兼容性的客户端环境，但不能仅凭名称判断证书部署是否正确。证书链不完整、系统信任库异常、设备时间错误，都可能让连接在传输业务前就失败。正确方向是修复验证条件，而不是开启跳过证书验证来掩盖原因。

VLESS 本身不承担与 VMess 相同的数据加密职责，实际安全性依赖所组合的安全层与传输方案。它的协议层设计较精简，但客户端展示的 VLESS 标签往往没有呈现完整组合。比较时应同时查看安全层、传输方式与服务端要求。把 VLESS 理解成“天然更安全”或“天然更快”都不准确；只有在路径、实现和工作负载近似时，讨论封装开销才有实际意义。

看清基于 QUIC 的方案

Hysteria2 基于 QUIC，并采用适合其设计目标的拥塞控制策略，在某些高延迟或存在丢包的链路上值得比较。它并不能凭空增加物理带宽，参数设置过于激进时，还可能加重排队或与其他业务争用资源。若当前网络对 UDP 的处理不理想，连接可能直接失败或表现波动。选用之前先确认网络可达性，再观察真实业务，不应只依据协议宣传词做判断。

TUIC 同样采用 QUIC 相关机制，提供面向代理场景的连接组织方式。它在多路流与数据报处理方面有自己的实现取舍，但不能与 Hysteria2 直接画等号。客户端内核是否支持所需功能、服务端参数是否对应、网络是否稳定承载 UDP，都会改变结果。不同项目对连接复用、恢复和拥塞控制的处理也可能不同，不能用共同的底层传输推导完全相同的体验。

这些描述用于理解技术类别，不是声明当前每条 VPN86 线路都开放全部协议。订阅提供什么组合，就在兼容客户端中比较什么组合；不要自行改写认证字段或安全选项来“转换协议”。如果需要了解真实可选地区与线路，请先查看线路页面，再以面板清单确认。协议选择应缩小到可用候选，而不是把所有名称都试一遍。

比较连接建立与会话复用

把首次打开与持续传输分开测

连接建立包含多个阶段：解析地址、接触入口、完成传输握手、认证，再建立面向目标服务的连接。某些阶段能够复用已有状态，某些需要重新进行。因此，第一次打开应用和持续使用中的响应感受可能不同。刚切换线路时页面稍慢，随后访问正常，不一定说明线路拥塞；可能只是缓存与连接尚未建立。比较协议时应分别观察首次访问和持续使用，避免混成一个印象分数。

基于 TCP 与 TLS 的连接会受到往返路径影响，但不能仅凭协议名称推算具体建立时间。会话恢复、证书处理、解析缓存以及客户端是否保留底层连接，都会改变实际过程。QUIC 将安全握手与传输设计结合，具有不同的建立与恢复机制，但能否利用这些机制取决于双方实现和已有状态。不要把理论上可减少的交互直接写成对每次访问都成立的速度承诺。

早期数据也是需要理解边界的机制。部分恢复连接能够更早发送数据，但存在重放风险和业务适用条件，客户端或目标服务未必启用。用户通常不需要为了追求建立速度手动打开相关高级选项。对于提交表单、支付或其他不可重复操作，更应尊重应用和协议实现的安全策略。一个看起来更短的握手过程，只有在兼容性与安全边界正确时才真正有价值。

复用减少开销，也改变故障形态

连接复用允许多个应用请求共享底层连接，可以减少重复建立带来的开销，尤其适合大量短请求。但如果复用发生在有序可靠的字节流之上，底层数据等待补齐时，其他逻辑请求也可能受到影响。基于 QUIC 的独立流能够缓解跨流的有序交付阻塞，不过共享拥塞窗口、路径带宽和连接状态仍然存在。它改善的是特定阻塞机制，而不是消除所有形式的相互影响。

长连接应用关心的则是会话是否能持续。AI 对话输出、代码补全、远程终端和实时消息，都可能在连接空闲后再次交换数据。客户端保活、系统后台策略、入口超时以及本地网络切换，都可能影响会话。只验证网页首页加载成功，无法代表这些任务可靠。应让应用完成实际工作流，再观察空闲后恢复、持续输出和网络变化时的行为。

切换 Wi-Fi 与移动数据时，设备地址和路径可能变化。QUIC 具备连接迁移相关能力，但客户端是否支持、服务端是否允许、当前 NAT 行为是否合适，都影响恢复结果。传统连接也可能通过应用重试获得不错体验。因此，不能把“支持迁移”当作会话必然不中断的保证。需要持续工作的任务，仍应关注应用是否保存草稿、支持断点或能够安全重试。

一个实用比较过程是先关闭明显占用网络的后台任务，确认目标服务本身正常，再依次观察候选线路。不要反复清理所有缓存来制造不符合日常使用的条件，也不要同时运行多个测速任务。若连接建立正常而后续内容持续停顿，应转向吞吐、拥塞或目标服务响应；若总在认证前失败，则优先检查参数、时间、证书和可达性。

对 Cursor、Copilot 或命令行工具而言，还需确认应用是否读取系统代理、是否支持当前代理类型，以及扩展进程是否继承环境设置。主界面能访问网络，不代表后台组件采用相同路径。相关选择思路可结合AI 编程 VPN 选型文章阅读。把应用路径与底层会话分开验证，通常比不断更换协议更快找到原因。

判断设备资源与移动端电量

耗电来自整条处理链

移动端耗电不是协议名称的固定属性。无线链路信号、屏幕使用、后台同步、加密处理、数据包频率和客户端工作模式都会参与。弱信号环境中，设备维持无线连接的成本可能比代理运算更明显；频繁的小请求也可能反复唤醒网络组件。比较前先确认设备没有同时更新系统、同步相册或持续上传文件，否则很容易把其他任务的消耗归到客户端头上。

加密与封装需要计算资源，但实际成本取决于算法实现、硬件加速与数据处理路径。精简协议在某些实现中开销较低，不代表所有设备都能观察到明显电量差异。反复复制缓冲区、过多规则匹配、详细调试日志以及大量并发连接，也可能增加负担。判断时应同时查看系统电量页面、客户端活动状态与使用场景，而不是只看客户端占用比例的单次截图。

系统级虚拟网络接口可以覆盖更多应用，但通常需要处理更广范围的数据包和域名规则；仅使用应用代理时，覆盖范围较小，部分程序可能不会经过代理。这是工作模式的取舍，不是简单的好坏。需要全设备一致路由时，额外处理有其价值；只需某个应用访问服务时，则应理解范围并减少不必要的接管。切换模式后要重新验证应用路径，不能默认两种模式等效。

保活与省电之间需要平衡

保活可以帮助维持连接或网络映射，但过于频繁的保活也会带来唤醒和流量开销。把保活关闭到极端，可能在空闲后遇到连接恢复迟缓；把频率调得过高，也不一定能改善应用体验。普通用户适合先保留客户端默认值，在明确存在空闲断线问题时再查阅对应文档。不要同时修改保活、超时、复用和工作模式，否则无法判断哪项变化真正有用。

Android 的后台限制与电池优化可能暂停客户端，表现为锁屏后消息延迟、重新点亮屏幕后恢复。处理时应按系统提供的应用管理入口核对后台运行权限，并理解不同设备厂商的设置名称可能不同。只授予维持连接所需的权限，不要为了排查一口气放开所有权限。具体上手流程可参考安卓客户端设置指南，再按设备实际界面操作。

iOS 与 macOS 的网络扩展由系统管理，连接状态还会受到系统权限、其他网络过滤工具及睡眠恢复影响。Windows 与 Linux 同样可能受到休眠、虚拟网卡和其他安全软件影响。多个工具同时改写路由或解析时，异常很难只归因于协议。排查应先减少重复接管，保留明确的一套网络路径；不要通过删除系统组件或关闭全部安全防护来换取短暂连通。

做电量比较时，应选相近的信号环境与任务类型，保持屏幕使用习惯接近，并让设备从异常发热中恢复。下载大文件、待机和持续对话属于不同负载，不应直接混比。若某条线路反复重连，即使加密运算很轻，也可能因为连接恢复与无线唤醒消耗更多电量。优先选择能稳定完成任务、后台行为可控的组合，再考虑细微资源差别。

看懂直连、中转与专线拓扑

先画出数据经过的路径

这里所说的直连线路，是设备经当前互联网路径接入相应服务节点，再由节点访问目标服务。它不是客户端分流规则中的“直连目标网站”。前者描述服务线路拓扑，后者描述某个请求不经过代理。两个词语相同，含义却不同。阅读面板时先确认所在语境，避免把“选择直连线路”理解成“应用不使用代理”，从而在验证出口时得出相反结论。

直连路径的优势是结构相对直接，额外转发环节较少；局限是跨网络互联与路由变化更直接影响体验。地理距离近不一定路径短，运营商互联方式可能让数据绕行。某条直连线路在当前网络中表现良好，也不能推导其他接入网络一定相同。家庭宽带、办公网络和移动数据应分别看待，尤其要注意它们可能采用完全不同的国际互联路径。

中转线路先将设备流量送到入口，再由入口转发至出口。它的价值在于调整路径，把设备到入口这一段与后续传输分开组织。若入口接入条件好、后续路由稳定，整体体验可能优于直连；若入口本身拥塞或转发资源不足，中转也可能增加等待。中转只是拓扑描述，不自动代表更高带宽、更低延迟或更好的流媒体兼容性。

专线标签要落到具体链路

IEPL 等专线概念通常强调特定区段的专用承载或可控互联，但最终体验仍包含设备到入口、服务端转发和出口到目标站点的公共网络部分。即使某个区段采用专线，也不能据此承诺整条业务路径没有拥塞。判断面板里的专线标签时，应理解其适用区段，并结合当前接入网络实际使用。标签说明路径组织方式，不替代端到端体验验证。

入口、出口和目标服务的相对位置会共同决定体验。访问某个地区的服务，不一定只需要选择同地区出口；还要考虑目标站点的内容分发、账户路由及入口质量。对于远程开发，出口到代码托管或云主机的互联可能比页面地理标签更重要。对于视频，持续吞吐与平台地区规则也会参与。选地区是起点，不是完成了所有路径优化。

在比较不同拓扑时，尽量固定出口地区与目标任务。如果同时从附近出口切换到远处出口，又从直连换成中转，就无法确定变化来自地理路径还是转发方式。面板未提供相同出口的不同类型时，可以记录限制，但不要强行做精确归因。实际选型允许以任务结果为主，只需要避免把有限观察扩大成对所有线路的普遍结论。

VPN86 的覆盖为 120+ 国家 / 230+ 线路，具体可选入口、出口与类型应查看线路清单与选线说明。覆盖范围表示候选空间，不代表每个地区都有相同拓扑，也不代表每个目标服务都接受相同出口。先确定业务需要的地区与稳定性，再在可用候选中比较，能减少盲目切换。保留适合当前网络的主要线路与替代线路，比收藏大量未经验证的标签更有用。

解释丢包与晚高峰拥塞

区分链路损伤与排队等待

丢包表示数据没有按预期到达接收方，但原因不只一种。无线干扰、链路错误、设备缓冲区溢出和路径策略都可能导致丢弃。拥塞则是某段资源承受的需求超过当前处理能力，常伴随排队增加或丢包。二者有关联，却不是同义词。链路可能延迟上升但尚未明显丢包，也可能因为无线问题在并不拥塞时丢包。只观察一个延迟数字，很难分清机制。

可靠传输需要检测缺失数据并补发，补发会增加等待和额外流量。TCP 与 QUIC 都有恢复机制，但检测方式、拥塞控制和流之间的交付关系不同。协议可以改变对丢包的反应，不能修复所有底层链路问题。若 Wi-Fi 信号本来就不稳定，更换协议可能暂时改变体感，却不如改善本地连接直接。排查应先确认设备到本地网关这一段是否正常。

排队过长会造成一种常见现象：下载看似仍在进行，但网页点击、语音或终端输入变得迟缓。原因可能是后台上传或下载占满瓶颈链路，让交互数据排在大量数据之后。此时更换远端地区不一定有效，先暂停后台同步、上传和更新更能区分问题。若停掉占用任务后恢复，说明至少存在本地共享带宽或队列竞争，不应全部归因到服务节点。

晚高峰是负载条件，不是协议属性

晚高峰通常意味着某些接入、互联或服务资源承受更多同时需求。问题可能发生在家庭接入、运营商互联、服务入口、转发区段或出口，并不天然指向同一个位置。白天正常而晚间变慢，是有价值的时段线索，但仍需对照其他网络与线路。若同设备换用另一种接入后恢复，应重点关注原接入路径；若不同接入都只在同一入口异常，则更值得检查入口相关因素。

拥塞控制会根据路径反馈调整发送节奏。过于保守可能无法充分利用可用资源，过于激进可能增加排队，并影响共享网络中的其他业务。基于 QUIC 的方案在某些受损链路上表现不同，但不是越激进越合适。使用家庭共享网络时，还要考虑其他设备的视频通话与办公任务。选择能保持交互响应的组合，往往比追求单个下载任务占用全部链路更符合日常需求。

探测工具也有边界。部分网络设备会降低诊断报文的处理优先级，路由路径中的某个中间节点不回复，并不一定意味着转发业务同样丢包。路径探测显示异常时，需要结合最终目标响应和真实业务观察。不要把中间跳点的缺失直接写成故障证据，也不要把一次正常探测当作长期稳定的保证。持续输出中断、重复加载失败等可复现症状通常更有说明力。

处理疑似晚高峰问题时，先固定应用与出口地区，换入口或拓扑观察是否改善；再保持线路不变，换本地接入检查是否为接入路径问题。每次只改变明确的一项，并记录发生时段和症状。若所有候选都仅对某个目标服务异常，还需检查该服务状态与账户提示。这样的记录能把“晚上都很慢”变成可定位的问题，而不是不断堆叠互相矛盾的猜测。

订阅流量额度与瞬时传输表现也应分开理解。VPN86 月订阅流量按开通日每月重置，额度决定套餐内可使用的流量，不是对某条路径瞬时吞吐的描述。流量包用完为止，永久不过期，也不表示网络条件永远不变。理解这一点后，才能把套餐选择与线路诊断分工处理：前者匹配用量，后者解决路径与业务响应。

按使用场景选择连接组合

先确定任务对网络的要求

日常网页访问以大量短请求为主，关心解析是否正确、连接建立是否顺畅，以及页面资源是否采用一致规则。适合的组合通常不需要复杂手动参数，而是客户端兼容、入口稳定、规则清楚。遇到部分页面元素缺失，先看资源域名与规则，再考虑协议变化。只因为某个协议名称更新就替换已经稳定的组合，可能增加兼容成本，却没有解决实际问题。

AI 对话与编程辅助更依赖持续会话、稳定出口和应用完整路径。页面能打开，只验证了入口；模型输出、附件上传、扩展后台请求与账户认证可能走不同服务域名。应使用符合平台规则的账户和地区，避免在任务进行中频繁更换出口。若网页可用而编辑器失败，优先检查编辑器与扩展进程的代理设置。更深入的场景说明可阅读AI 工具专题。

流媒体播放关注持续吞吐、内容分发路径与平台自己的地区规则。出口地区与可见内容并非简单对应，还会受到账户所在地、授权安排及平台策略影响。协议只能承载连接，不能提供内容授权。测试时让实际影片进入稳定播放阶段，观察是否反复缓冲，而不是只看首页封面。切换线路后可能需要重新建立播放会话，旧连接继续存在时，出口变化未必立即反映到当前播放。

远程终端、桌面操作与实时协作更敏感于抖动和短时中断。平均传输能力很强的线路，也可能因为排队导致输入迟滞。此时应优先选择交互稳定、空闲恢复正常的候选，减少同时进行的大流量任务。涉及 UDP 的应用还要确认客户端与线路是否支持对应流量；应用协议未被支持时，单纯换出口地区通常无效。明确功能需求比泛泛追求“最快”更重要。

把设备兼容与用量放在正确位置

大文件传输更关注持续吞吐、重试与断点能力，适合在实际下载工具中验证，不必只依赖通用测速。长任务应优先使用应用自己的校验与恢复功能，避免线路切换让进度丢失。若设备已经持续发热，客户端处理性能也可能成为瓶颈。选择协议时应把本地资源、网络条件与工具能力共同考虑，而不是把某个协议与“大文件专用”永久绑定。

VPN86 支持 Windows / macOS / iOS / Android / Linux，不限台数。但设备支持不代表所有平台提供完全相同的内核功能或代理模式。Android / Windows / macOS / Linux 登录即可获取客户端；iOS 的实际下载入口需要有效套餐，订阅需登录后获取。可通过用户面板客户端入口核对，营销页不提供安装包或订阅直链。

套餐按照用量选择，不必用价格推测协议性能。月订阅为 ¥9.9/月含 60GB、¥18/月含 250GB、¥28/月含 500GB；流量按开通日每月重置，中途升级差价折算成剩余天数。间歇使用可比较流量包：¥158/300GB、¥358/1000GB、¥658/3000GB，用完为止，永久不过期。完整计费说明请看套餐页面；30 天无理由退款与技术测试结果是不同维度，不应混为性能保证。

建立可复现的排查流程

从症状开始，不从猜测开始

先把症状写成能够复现的句子，例如“浏览器能打开正文，编辑器补全没有返回”，而不是“网络坏了”。补充设备平台、工作模式、线路标签、协议和发生条件，再确认订阅已经导入、所需权限已授予、系统时间正常。若尚未完成这些基础步骤，回到快速上手教程处理。系统参考用于缩小原因，不应替代最基本的安装与连接流程。

接着区分故障范围。只有单个应用异常时，先检查该应用是否采用代理、账户是否有效、目标服务是否报告问题。多个应用都异常时，再检查客户端连接状态、本地接入和线路可达性。只有特定域名异常时，检查解析与分流；只有锁屏后异常时，检查后台策略与会话恢复。按范围分类能够减少无关操作，也能避免把应用限制误认为整条线路中断。

建立基准后再换候选。保持设备、接入网络与目标任务不变，先更换同类线路观察；若问题仍在，再尝试不同入口或传输方案。需要换本地网络时，把这次变化单独记录，不与协议切换同时进行。若某次调整改善体验，重新确认原条件下问题是否仍可复现。这样可以避免把目标服务刚好恢复，误认为某个高级参数发挥了作用。

按错误阶段决定检查方向

认证失败应优先核对订阅是否更新、客户端支持是否匹配以及系统时间，不要先改 DNS。证书错误应核对设备时间、系统信任环境与服务名称，不要跳过验证。连接建立后才出现停顿，应检查目标服务、拥塞与应用会话；解析错误则先确认解析请求采用的路径。错误信息越明确，排查越应贴近对应阶段，避免把所有问题都用“重装客户端”处理。

必要时可以用系统提供的工具观察基础 HTTPS 请求。下面的命令只向示例域名读取响应头，不包含订阅或认证信息。它默认沿当前命令行进程的网络路径运行，并不自动证明请求经过了客户端。若系统采用虚拟网络接口，行为可能与仅启用系统代理不同；命令不存在时不必额外下载陌生工具，可以改用浏览器与客户端内置诊断完成观察。

curl --head https://example.com/

阅读输出时，先看解析、连接与证书是否出现明确错误，再区分正常的 HTTP 响应与网络中断。目标站点返回业务错误码，通常说明已经收到某种响应，不等于传输完全失败；但也要防止响应来自本地网关提示页或其他中间环节。不要为了得到“成功”字样删掉安全校验参数。诊断命令是观察工具，不是网络修复开关。

分享排查资料前，隐藏订阅地址、认证标识、账户密码和完整请求头。保留错误阶段、线路名称、设备平台和操作过程即可。需要协助时，通过登录后的工单入口提交清楚描述；一般问题也可先查常见问题。不要把私密配置贴到公开讨论中，也不要把完整日志视为越多越好，信息应围绕故障而不是暴露账户。

用任务结果收尾

问题解决后，按最初的真实任务复测：网页资源是否完整、对话是否能持续、文件是否完成、锁屏后是否正常恢复。记录最终可用的线路与模式，把临时调试日志恢复为日常级别，并撤销没有必要的实验改动。若原因尚不明确，就保留“当前可用、原因待确认”的结论。准确描述不确定性，比把偶然改善包装成协议定律更有助于下次排查。