SpaVPN 协议与
线路技术参考

连接模型：先分清协议与路径

访问网页之前，连接已经开始工作

一次访问通常涉及域名解析、连接到服务端、完成安全握手、提交请求和接收内容。客户端还可能先判断这次请求是否需要代理，再把它交给对应出口。页面迟迟没有出现，并不表示传输带宽不足：解析等待、握手失败、出口连接目标缓慢，都可能发生在正文开始下载之前。因此，讨论“快不快”时，应先说明是在比较打开页面、持续下载，还是连接中断后的恢复。

协议描述客户端与服务端之间怎样识别请求、保护内容、封装数据和处理连接。线路则描述数据经过的网络路径。相同协议放到不同线路上，体验可以明显不同；相同地区也可能因为入口、运营网络和出口机房不同而表现各异。只看协议名称，无法推导某条线路在当地网络中的实际效果。地区标签适合做初筛，不应被当作完整的路径说明。

传输层与代理层不是同一个选择

TCP 提供可靠、有序的字节流，丢失的数据需要恢复，后续内容也可能因此等待。UDP 提供数据报传送，本身不承诺可靠和顺序；建立在其上的 QUIC 则可以实现可靠流、拥塞控制与安全连接。把 UDP 简化成“更快”，或者把 TCP 简化成“更稳”，都会遗漏上层实现与路径条件。应用需要什么传输语义，和代理隧道采用什么传输方式，也应分别判断。

例如，浏览器可能通过代理隧道访问采用 TCP 的网站，也可能发出需要数据报转发的请求。客户端是否支持转发、服务器是否接受、路由规则是否把请求送进隧道，缺少任何环节都可能造成部分应用异常。连接测试成功只说明测试所覆盖的那条流程成立，并不自动证明域名解析、数据报、后台运行与所有应用都已正常。

用现象限定问题，不用标签代替证据

先判断问题范围：是所有应用都无法访问，还是仅某个网页；是刚连接就失败，还是运行一段时间后停顿；是更换本地网络后恢复，还是更换出口后恢复。范围越清楚，后续比较越有效。若普通网站正常而单个服务拒绝访问，应检查该服务的地区、账户和访问规则，而不是直接把全部客户端配置重置。

选型时也要保留这种分层习惯。协议兼容性、路径稳定性、目标服务规则属于不同问题，各自需要证据。SpaVPN 的覆盖为 100+ 国家 / 240+ 线路，具体地区与线路类型可从线路页查阅；覆盖数量本身不代表任意本地网络到任意目标都走相同路径。下文所有比较均是机制说明，不是对某个地区速度的固定排名。

流式协议：设计取舍与兼容边界

Shadowsocks：关注加密方式与实现兼容

Shadowsocks 是代理协议家族，常见部署使用认证加密保护客户端与服务端之间的数据。它的配置概念相对集中，但不能只凭名称判断兼容性：客户端支持的加密方式、密钥形式、数据报能力与服务端设置必须对应。旧配置能被导入，不等于当前客户端能够完整执行。选用订阅中已经匹配的条目，通常比手动拼接参数更容易保留正确语义。

资源占用与所选加密算法、设备指令支持、实现方式以及并发活动有关。所谓协议“轻”，不意味着任何设备上都会更省电，也不意味着缺少身份校验或错误配置就可以忽略。若只有某类请求失败，应先看客户端记录中是解析、认证还是数据报转发错误，再判断是否需要换协议，避免把局部兼容问题误判为线路整体不可用。

VMess 与 VLESS：把协议和外层传输分开看

VMess 包含身份验证与数据保护机制，实际条目还会搭配不同传输方式。客户端与服务端对认证细节、传输封装的支持需要一致，设备时间明显偏离时也可能影响认证。遇到认证错误，先检查系统自动时间、订阅是否更新、条目是否被手动修改。反复点击连接不会纠正不匹配的身份信息，也不能修复不受支持的封装。

VLESS 更侧重精简代理层的身份验证与请求表达，它本身不提供传统意义上的内容加密，因此不能脱离外层安全传输单独评价。看到 VLESS 名称时，还要看是否搭配合适的 TLS 等安全机制，以及客户端是否支持对应组合。“字段更少”不是忽略安全层的理由；真实开销也要把外层传输、连接复用和握手过程一起计算。

Trojan：TLS 设置是连接的一部分

Trojan 通常依托 TLS 传输代理请求，证书验证、服务名称与身份凭据共同参与连接。若客户端提示证书不匹配，应检查条目的服务器地址、服务名称、系统时间与订阅来源，不要把关闭验证作为常规修复。验证失败可能来自错误配置，也可能来自本地网络中的干预页面，需要根据错误内容逐项排除，而不是掩盖提示继续使用。

对于这些协议，首次连接可能包含传输握手、安全握手与代理认证；已有连接的后续请求则可能复用已建立的通道。比较时应区分冷启动和连续使用，避免拿某个协议的首次连接去对比另一个协议的复用请求。连接复用可以减少重复建立，但也可能让多个请求共同依赖底层连接，具体效果取决于实现和业务负载。

配置边界：本文解释协议机制，不代表每个地区都提供全部组合。以面板订阅实际列出的条目和客户端支持情况为准。

实际选择可以从已有且兼容的条目开始。普通网页和办公应用若已稳定，无需为了名称更新而持续更换；遇到明确问题，再依据错误阶段尝试另一种传输。一次只改变协议或线路中的一个条件，才能知道改善来自哪里。协议之间不存在脱离设备、路径与目标服务的统一优先级，也没有仅凭名字就成立的资源占用排行榜。

QUIC 协议：恢复能力与路径条件

Hysteria2 与 TUIC 的共同基础

Hysteria2 与 TUIC 都采用基于 UDP 的 QUIC 技术路线，但它们不是可以互换配置的同一种协议。QUIC 将安全连接、可靠传输与多流管理结合起来，不同流可以分别处理交付状态，降低某条流的数据缺失对其他流的直接阻塞。底层路径拥塞仍会影响共享带宽，因此“流之间更独立”不等于每个应用都拥有互不影响的网络资源。

QUIC 连接建立可以结合传输与安全协商，具备减少重复交互的设计空间。是否能发挥这一点，取决于连接是否首次建立、实现是否支持会话恢复、网络是否允许相关数据包，以及服务端是否接受对应流程。不能把协议设计中的可能性直接写成每次连接都会更快的保证，尤其不能忽略域名解析和出口连接目标所需的时间。

拥塞控制与带宽设置需要放回网络环境

Hysteria2 的常见配置会涉及带宽与拥塞控制相关设置。填写过高的带宽预期，并不能让本地接入或远端线路增加容量，反而可能使发送行为不适合当前路径，引起排队、丢失或与其他应用争用。填写偏保守也可能限制能够利用的容量。订阅提供的参数应优先保留，确需调整时要查客户端说明，而不是照搬其他网络的截图。

TUIC 同样需要客户端、服务端以及证书验证等设置互相匹配。它可以利用 QUIC 的连接和流管理能力，但实际体验仍受实现调度、拥塞控制和数据报处理方式影响。不同客户端展示的字段名称不一定相同，某个选项在界面中缺失，也不意味着可以用另一个协议的同名参数替代。导入失败时，先确认客户端明确支持对应条目。

UDP 通路不理想时，保留可用的替代路径

有些接入网络对 UDP 的转发策略、空闲映射或传输质量不适合长时间使用，表现可能是握手迟迟没有结果、刚连接后又中断，或者切换网络后难以恢复。此时尝试基于 TCP 的条目，是判断问题范围的有效方法。如果替代条目稳定，而同一接入上的 QUIC 条目反复失败，应优先调查通路条件，不宜直接认定设备性能不足。

还需要注意封装后的数据包大小。隧道会增加额外头部，路径可接受的数据包大小又可能随链路而变化。若小请求可以完成，大响应或数据报应用却卡住，路径大小探测、分片处理和中间设备行为都值得检查。不要毫无依据地不断减小相关参数；先保存原值，查明客户端是否自动处理，再通过可复现的现象决定是否需要进一步排查。

移动网络切换时，QUIC 的连接标识机制为迁移提供基础，但协议具备基础能力不等于具体客户端一定保持应用会话。应用超时、系统后台限制或服务端策略仍可能结束请求。正确的比较应包含切换后的实际任务是否继续，而不只是客户端图标有没有改变；对无法恢复的任务，还要观察重新建立连接是否清晰、可控。

选择原则：当 UDP 通路稳定且客户端支持完整时，可以把 Hysteria2 或 TUIC 纳入对照；若通路受限，兼容的流式条目应作为备选，而不是被协议名称排除。

线路拓扑：直连、中转与专线

直连描述路径，不描述固定质量

直连通常指客户端直接连接境外入口，中间不额外安排服务方的中转节点。逻辑结构较简单，但数据仍会经过本地接入、运营网络、互联出口和目标地区网络。路径短不代表物理距离短，也不代表互联容量充足。如果跨网络互联拥塞，直连可能受到影响；如果本地到该入口的路由良好，直连也可能提供合适的日常体验。

地区相同的入口，路由可能并不相同。某条线路在家庭宽带上流畅，换到办公网络后却需要重新评估，因为起点、接入策略和上游网络都已改变。选线记录应包含使用的本地网络，而不是只写城市名称。地理位置适合帮助理解距离，却不能替代对实际互联关系的观察，更不能作为线路质量的唯一排序依据。

中转增加了一段，也可能改善关键一段

中转通过额外入口承接连接，再把数据转送到后续出口。它增加了处理与路径环节，但如果客户端到中转入口、以及中转到出口的连接更合适，整体体验仍可能改善。反之，中转入口排队、转发资源不足或后续路径拥塞，也可能成为新的瓶颈。因此，判断中转是否有效，要看它改变了哪段路径，而不是只数经过了多少个标签。

中转还会影响故障定位。客户端到入口连接成功，不能证明入口之后的链路正常。若多个出口都共用同一入口，故障可能同时出现；若只有某个出口异常，则可能集中在中转后的路径或出口本身。保留入口和出口都不同的备选，通常比只收藏多个相似名称更有诊断价值，但具体是否共用入口应以线路信息为依据。

专线需要结合完整端到端路径理解

IEPL 专线描述特定网络承载方式，不能被理解为从用户设备到所有目标网站的每一段都独享。用户到入口仍经过本地接入，出口到目标服务也有后续路径；本地无线干扰、设备负载与目标站点响应不会因专线标签自动消失。专线能够改善哪部分，应结合实际入口、承载与出口结构理解，不宜将它扩展为任意时段都固定表现的承诺。

延迟由传播、转发处理和排队共同构成。专线可能减少不确定的互联环节，却无法消除物理距离。访问远距离地区的账户服务时，选择符合服务规则的出口，可能比追求最低延迟更重要；而实时互动应用则应同时留意路径长度与波动。没有一种线路类型能在所有目标与所有接入网络中同时取得最佳结果。

查阅线路信息时，可以先按目标服务需要确定地区，再查看该地区实际提供的线路类型，最后在常用接入网络上验证。不要把线路名称中的城市、协议与承载方式混成同一种属性：城市说明位置，协议说明通信方式，拓扑说明路径组织，它们分别影响不同环节。

备用线路也应服务于明确问题。若经常遇到当地晚高峰拥塞，应比较不同承载与入口；若问题只发生于目标服务，应比较合适地区的出口；若设备不支持某协议，应先换兼容条目。这样建立的候选集合更小、更容易维护，出现故障时也能用清楚的替换顺序判断原因，而不是在全部地区之间无目的轮换。

丢包与拥塞：从现象找到瓶颈

丢包可能发生在本地，也可能发生在远端

数据包丢失不一定来自跨境段。本地无线干扰、接入设备负载、运营网络拥塞、中转队列和出口路径都可能参与。先在同一设备上观察普通网络访问，再比较代理访问，有助于区分本地与远端问题。若两者同时变差，应先检查本地网络与后台任务；若只有特定线路异常，再缩小到该线路涉及的入口、传输与出口。

丢包会触发恢复行为，可靠流可能重传并调整发送节奏，实时应用则可能表现为声音缺口或画面停顿。平均传输速度看似正常，短暂连续丢失仍会破坏互动体验。因此，流畅与否不能只看最终下载完成得多快，还要看等待是否集中出现、任务是否被中断、应用是否需要反复重新连接。不同任务对同一种网络波动的容忍程度并不相同。

晚高峰关注排队与共享容量

晚高峰常见的问题是共享链路承载增加，数据在队列中等待。队列过长时，下载仍有进展，网页响应和互动却明显变慢。此时继续启动更多测速任务会制造额外竞争，反而掩盖原来的问题。先停止大文件同步和后台下载，再观察轻量请求是否恢复，有助于判断瓶颈是否来自本地上行或同一接入中的争用。

若停止后台任务后问题仍在，可以在相近时段对比不同入口或线路类型。只换出口城市却保留相同的受限入口，可能看不到改善；同时切换协议、地区与本地网络，又无法知道哪个条件起作用。对照需要控制变量，同时保留普通网站作为参照。重复出现的趋势比偶然一次顺畅更有参考价值，但它仍只代表所观察的网络环境。

检测工具也有自己的解释边界

探测请求超时，不一定代表实际业务数据同样丢失。部分设备会降低探测报文的处理优先级，路径中间的节点也可能不回复。不能仅凭某一跳没有响应就认定那里发生故障；应看后续是否仍正常到达，并结合实际业务的连接记录。路径探测还可能只展示某个方向，回程路由与业务协议经过的处理方式未必完全相同。

对网页打开缓慢，应区分解析等待、建立连接等待和内容下载等待；对持续下载波动，应观察本地网络占用、连接是否重建以及目标服务器是否限速。测速站点本身也可能有负载和地区差异。若一个下载源变慢而其他任务正常，先更换合法可用的对照资源，再评价线路，避免把目标服务器的限制错误归到代理协议。

停止条件：如果某项调整让正常应用也出现异常，应恢复原值并记录变化。排查的目标是定位瓶颈，不是把所有高级选项都改过。

还有一种容易混淆的现象是应用超时。网络只是短暂波动，但应用自己的重试策略较保守，可能长时间停留在加载界面。此时先验证新的轻量请求是否能完成，再决定是否重启应用。若每次都通过重启整个客户端恢复，仍需要查明底层连接是否空闲失效、域名缓存是否陈旧，或者系统后台策略是否终止了隧道进程。

提交排查信息时，可以描述发生时段、本地网络类型、线路名称、目标服务、错误阶段与已经完成的对照，不必附上账户密码或完整订阅。有关工具与记录方法，可继续阅读VPN 测速自测方法。保留原始现象比给出“协议不好用”的总结更有帮助，因为后者无法区分解析、握手、排队和目标服务响应。

移动端与资源：耗电不是协议名

无线唤醒、加密与后台活动共同耗电

移动端的电量消耗来自多个环节：无线模块保持活跃、处理加密与转发、维护连接、解析域名，以及应用自身同步内容。代理协议只是其中一部分。持续视频、云端相册上传和频繁通知，与偶尔查看网页的负载不同，即使采用相同条目也不能直接比较耗电。先确认任务和网络条件相近，再讨论协议之间的设备负担。

无线信号较弱时，设备可能需要更积极地维持传输；网络反复切换时，又会产生连接恢复和应用重试。此类耗电常被误认为来自某个协议。比较前应记录是在无线局域网还是移动网络、屏幕是否常亮、应用是否在后台运行。系统电量页面可以提供线索，但其中归到客户端名下的流量，可能实际由其他应用通过隧道产生。

连接维护过密与过疏都有代价

保持连接需要平衡活跃性与系统资源。过于频繁的维护请求可能增加无线唤醒；过于稀疏则可能让中间设备回收空闲映射，下一次访问需要重新建立。合适策略取决于接入网络、客户端实现与系统调度，不能从其他设备截图抄一个固定间隔。优先使用客户端推荐值，只有出现明确的空闲后断开现象时，再查阅相关选项的实际含义。

后台运行同样受到系统限制。设备锁屏后不能连接、解锁后恢复，可能与节电策略或网络扩展生命周期有关，不一定是线路故障。应检查客户端是否具有系统要求的网络权限，是否被限制后台活动，以及是否同时开启其他接管网络的工具。调整权限时只授予连接所需范围，不要因为排查而关闭全部系统保护或安装来源不明的软件。

资源比较需要观察处理器、内存与热状态

处理器负载可能随加密算法、并发连接、数据报封装和规则匹配而变化。设备发热后还可能主动降低处理能力，导致同一任务后段比前段慢。内存占用则受连接数量、缓存与规则规模影响，不能只把应用启动时的占用作为结论。比较时应让设备恢复接近的热状态，并确保后台没有同步更新或大型任务。

桌面端也不能忽略接管方式。系统代理通常只影响遵循系统设置的应用，虚拟网络接口模式则会涉及更广的路由和解析处理。看到浏览器成功、其他程序失败，应先核对程序是否使用对应代理设置，而不是直接更换地区。macOS 的安装与权限流程可参考Mac VPN 安装与订阅导入指南。

若需要评估省电效果，可以选定相同任务，保持屏幕亮度、网络和后台应用接近，观察系统记录与是否出现连接中断。不要将短暂的电量刻度变化当成精确实验，也不要承诺某协议必然节省多少电。更实用的目标是在任务完成、设备温度和连接可靠性之间取得可接受的平衡，而不是追求脱离使用方式的理论最低值。

SpaVPN 支持 Windows / macOS / iOS / Android / Linux，不限台数。设备可以分别使用兼容条目，但套餐流量需要共同管理；多设备同时运行后台任务，也会影响家庭接入的共享容量。设备数量规则与本地无线网络承载能力是两件事，不能因为服务不限台数，就忽略路由器负载和各设备之间的带宽竞争。

场景选型：先定任务，再选组合

网页与办公：优先关注建立连接和连续性

普通网页、文档协作与远程办公往往包含许多小请求，初次响应、域名解析和连接复用可能比持续下载能力更影响感受。先选择客户端完整支持、访问目标符合地区要求的条目，再观察打开页面、提交表单和保存文档是否连续。若长连接正常而新页面偶尔等待，应优先检查解析与新连接建立，不必先追求更高的下载结果。

办公环境还应考虑账户会话的稳定性。频繁在不同地区之间切换出口，可能触发目标服务的额外验证或让正在进行的任务中断。常用出口可以保持相对一致，备用线路用于排查和故障恢复，而不是每次打开应用都重新挑选。若目标服务有组织访问要求，应遵循其规定，代理协议不能替代账户权限和合法授权。

AI 工具与流媒体：地区和账户规则先于协议

AI 工具是否可用，既取决于网络连通，也取决于服务开放地区、账户状态与产品政策。请求能够到达服务器，不代表账户可以使用所有功能。若出现地区提示，应先核对服务规则和出口地区；若只是流式响应中断，则再调查长连接、空闲超时和网络切换。关于具体场景，可查阅AI 工具访问专题。

流媒体更依赖持续交付与缓冲。播放开始较慢，可能是解析、账户或内容授权；播放中反复停顿，则应检查持续吞吐、丢包和同一网络上的竞争任务。可观看内容依平台地区规则变化，不能把某个协议名称视为内容可用性的保证。有关地区与播放设置的分工，可继续查阅观影专题，并以平台实际提示为准。

互动任务与大文件：重视的指标不同

实时交流、远程操作等任务对波动和中断较敏感，未必需要很高的持续吞吐。应该观察操作反馈是否稳定、声音是否连续，以及网络切换后能否恢复。若应用需要数据报传输，要确认客户端和条目实际支持。大文件传输则更看重持续交付能力、断点续传与流量预算，单次很快建立连接不代表长时间下载也同样平稳。

可以为不同任务保留不同候选，但不宜让规则复杂到无法解释。开始时使用清楚的默认路径，只有某类应用出现明确需求时再增加分流。每条规则应能回答“哪些请求受影响”和“为什么走这个出口”。遇到应用异常时先回到简化规则做对照，比继续叠加例外更容易排除规则匹配、解析路径与出口选择之间的冲突。

协议选择也不应取代套餐选择。月订阅按开通日每月重置流量，流量包用完为止、永久不过期，两者适合的使用节奏不同。先估计任务是否长期持续，再到套餐页核对实际价格与流量规则。不限台数意味着可以安排多设备使用，不意味着流量没有边界，也不意味着本地接入不会被同时进行的任务占满。

最终留下的组合应是能够解释、能够复查且容易恢复的组合。如果兼容的流式协议已经满足工作任务，就没有必要仅因新名称而替换；如果 QUIC 条目在当地接入中更合适，也应同时保留另一种可用路径。把协议视为工具而非等级，才能避免围绕名称反复试错，并将注意力放回实际任务是否完成。

验证与记录：让选型可以复查

建立基线，保留恢复入口

正式比较前，先保存当前可用条目与原始设置，确认普通网络访问正常，再选定常用应用作为观察对象。不要一边更新客户端、一边更换协议，又同时切换接入网络；这些变化叠在一起，结果即使改善也无法解释。基线的意义不是证明某种协议优越，而是提供一个随时可以回到的状态，防止排查本身扩大问题。

开始测试时，记录本地网络、设备平台、线路名称、协议和任务现象即可。先观察首次连接，再观察连续访问，最后检查锁屏或切换网络后的恢复。每种观察回答不同问题，不应只保留一个笼统的“正常”。如果需要使用测速工具，应注明测试目标与当时后台任务，让结果有上下文；没有可比条件的数字不适合用来给协议排序。

遇到失败，按错误阶段收敛

导入失败时，检查客户端是否支持订阅条目，而不是立刻修改服务器地址；认证失败时，检查订阅更新、系统时间与条目完整性；证书提示出现时，核对安全设置与网络环境；连接成功但应用失败时，再查看接管模式、解析路径和目标服务规则。按照发生顺序排查，可以避免把后面的应用问题误当作前面的握手问题。

若只有特定接入失败，可保留同一设备与任务，切换到另一个可信网络作对照；若同一接入下仅某个协议失败，可选择同地区的兼容条目作对照；若多个协议都只在某个出口异常，则优先调查出口与目标服务。对照不是为了穷尽全部组合，而是用尽量少的变化排除一类原因。每次得到结论后，再决定是否需要下一步。

记录格式：本地网络与设备 → 线路与协议 → 具体任务 → 错误发生阶段 → 已完成的单项对照 → 恢复方式。分享前删除凭据、订阅链接与个人内容。

订阅与日志需要分开保管

订阅链接通常包含访问授权信息，应像账户凭据一样保管。截图、公开提问或共享日志前，要检查是否包含完整链接、身份字段和个人访问内容。匿名无日志是 SpaVPN 的服务承诺，不代表设备本地的诊断记录不会包含敏感信息，也不代表其他目标网站不会保存自己的账户活动。服务策略、客户端记录与目标平台记录需要分别理解。

获取客户端与订阅应通过用户面板进行，订阅登录后获取；无需邮箱地址，使用用户名与密码即可创建账户。不要将订阅导入不明网页来判断协议是否正确，也不要把完整凭据交给陌生工具。有关账户与公共网络中的保管习惯，可阅读VPN 新手安全指南。

把观察结果落到长期使用安排

完成对照后，可以确定常用条目、备用条目与适用场景，并把不再需要的临时规则恢复。长期使用过程中，如果本地接入、目标服务或客户端实现发生变化，原来的结论也需要重新验证。一次成功只能说明当时任务完成，不构成对未来路径的固定保证。保留简短记录，比长期收藏大量不清楚用途的线路名称更容易维护。

套餐规则也应作为使用安排的一部分核对。月订阅有 ¥9.9/月含 60GB、¥18/月含 250GB、¥28/月含 500GB，流量按开通日每月重置，中途升级差价折算成剩余天数。流量包为 ¥158/300GB、¥358/1000GB、¥658/3000GB，用完为止、永久不过期。支付方式为支付宝 / 微信 / USDT，提供 60 天无理由退款，具体说明请查阅退款政策。

如果仍不能定位问题，可从帮助中心核对常见现象，再通过工单入口提交经过整理的信息。说明实际任务、错误阶段和已经验证的替代条件，通常比堆叠测速截图更有用。技术选型的终点不是找到抽象意义上的最强协议，而是在当前设备与网络中，得到可以持续使用、清楚解释并能在异常时恢复的连接方案。