协议与线路
技术参考

连接分层：先区分协议与线路

一次访问经过哪些环节

浏览器打开国际网站时，应用先根据目标域名建立请求，系统或客户端再决定请求走本地网络还是所选线路。需要经过本服务的流量，会由客户端按照订阅里的协议与服务器通信，再从出口访问目标网站。目标网站返回的数据沿着相应连接回到应用。这里同时存在应用请求、域名解析、代理传输和网络路径，任何环节出问题都可能表现为“页面打不开”，但处理方法并不相同。

协议描述的是客户端和服务器怎样交换必要信息、验证身份、封装数据以及传递目标地址。线路描述的是数据经过的入口、骨干路径和出口安排。同样的协议可以部署在不同线路上，同样的出口地区也可能对应不同入口。因此，看到 Trojan 不能直接推出“专线”，看到香港也不能推出“低延迟”。客户端列表里的协议、地区和线路类型是不同维度，应分别读取，而不是拼成一个笼统的质量等级。

解析、连接与应用响应各自计时

域名解析负责把网站名称映射到可连接的地址，解析走向还会影响网站选择哪一处内容分发节点。随后是连接建立、必要的安全握手和应用请求。网页迟迟没有内容，可能是解析等待，也可能是握手重试，还可能是网站已经收到请求但仍在处理。已经打开的页面图片加载慢，则可能与持续传输或网站资源所在位置有关。只有把“开始得慢”和“传得慢”分开，才能判断该换协议、换线路，还是检查目标服务。

TCP 提供有序、可靠的字节流；UDP 提供数据报传递，本身不保证按序送达。使用 UDP 并不意味着应用只能接受丢失，也不意味着一定更快：上层协议可以自行实现确认、重传和拥塞控制。QUIC 就在 UDP 之上实现安全连接与可靠流。反过来，TCP 的可靠传输也不是“不会卡顿”，它需要等待缺失数据补齐。比较协议时，应看可靠性在哪一层完成，以及这层机制是否适合当前网络。

把“可连接”与“可使用”分开记录

客户端显示连接成功，通常只说明某个连接环节已经完成，不等于全部网站和业务都已验证。目标应用仍可能要求重新登录、验证账户地区，或对特定出口应用自己的访问规则。测试时先确认普通网页能返回，再检查目标应用的具体操作，不要只看一个绿色图标就结束。反过来，某个网站提示账户限制，也不应立刻解释为协议损坏；应保留原始提示，沿着应用层继续判断。

经典协议：认证、加密与兼容性

Shadowsocks 与 VMess 的关注点

Shadowsocks 的基本思路是让客户端与服务器通过约定的加密方式交换代理数据，常见用途是以相对直接的封装完成转发。实际安全属性取决于具体加密套件、凭据管理与实现，不能只看名字。不同套件的密钥处理和数据格式可能不同，客户端也未必全部支持。导入后若提示加密方式不受支持，应更新兼容的客户端或使用订阅提供的其他可用项，而不是自行猜测一个相似名称替换。

VMess 把身份认证和数据传输安排在自己的协议结构内，生态中常与不同传输封装组合使用。它的表现不只由 VMess 本身决定，还受底层传输、加密设置和实现影响。一些认证模式涉及时间有效性，设备时间明显偏离时可能出现难以直观理解的认证失败。遇到这种情况，校准系统时间、重新更新订阅、确认客户端支持情况，比随意修改服务器参数更合适。较多可组合选项意味着部署弹性，也意味着手工填写时更容易遗漏字段。

Trojan 与 VLESS 的安全边界

Trojan 通常依靠 TLS 建立受保护的传输，再在其中完成代理认证和转发。TLS 负责的服务器身份校验不能省略：证书有效性、服务器名称和系统信任状态都可能影响连接。某个节点无法握手时，不应把关闭证书验证当作通用修复。应先检查系统时间是否正确、订阅是否完整，以及该线路是否确实可用。认证信息正确而服务器身份不可信，仍然不构成一个应当继续使用的正常连接。

VLESS 采用较精简的代理协议结构，自身不把完整的数据加密能力包办在协议名称里，安全传输需要看部署时搭配的保护机制。订阅中的传输方式、服务器名称和相关参数共同决定连接形式。把 VLESS 简化成“轻量所以一定快”容易忽略实际握手与底层网络成本；把某种外层保护方式当成所有 VLESS 连接的默认属性，也同样不准确。对普通用户来说，保留服务提供的完整参数比逐项追求看起来更高级的选项更重要。

连接成本不能只按名称排序

连接建立速度要把底层连接、安全握手、代理认证和目标网站响应一起看。已有连接可以复用时，用户感知与每次重新建立连接时不同；客户端进入后台后是否保留会话，也会改变结果。资源占用则受到加密实现、硬件加速、并发连接和规则规模影响。某台电脑上感觉轻快的组合，换到移动设备可能并不省电。因此本页不提供脱离设备与线路的固定排名，也不把协议年代等同于性能优劣。

选型时先以订阅能够正常导入、客户端能够持续维护为前提，再比较同一网络下的实际业务。网页访问正常但长连接不稳，可以继续检查空闲超时与网络切换；全部应用都无法完成握手，则优先检查入口可达性和参数。协议的意义是提供适合场景的传输工具，不是让用户收集名称。VPNCross 的具体支持情况应查看实际订阅；技术参考中介绍的协议，不构成全部线路的供给承诺。

QUIC 协议：Hysteria2 与 TUIC

为什么使用 UDP 承载可靠传输

Hysteria2 与 TUIC 都利用 QUIC 相关能力组织代理传输，但各自的认证、转发方式与拥塞处理细节并不相同。QUIC 运行在 UDP 之上，集成安全握手，并支持在同一连接内组织独立的数据流。当某个流的数据包需要恢复时，其他流不必因为同样的传输层按序交付要求而一起等待。不过，共享链路拥塞和共享拥塞控制仍会影响整体吞吐，这不是让丢包影响消失，也不是把网络容量变大的机制。

理解这类协议时，可以把“可靠传输由谁处理”作为入口。传统组合通常依靠 TCP 在系统内核中完成可靠传输；QUIC 的不少处理由用户态实现承担。这样做便于协议迭代和连接管理，但也会带来不同的处理成本。客户端实现、设备性能、系统调度和数据流量共同影响资源占用。不能由“使用 UDP”直接推出更低耗电，也不能由“用户态”直接推出更差性能，最终仍要看具体实现和工作负载。

Hysteria2 的带宽与拥塞理解

Hysteria2 面向网络质量不理想时的代理传输场景，其拥塞处理选择会影响发送行为。某些模式需要使用者或部署方提供带宽相关信息，这类值不是越大越好。把可用容量估计得过高，可能让发送压力超过接入链路的承受能力，带来排队、丢包和其他应用体验下降。普通订阅用户不应为了追求速度，擅自把参数改成与本地接入条件无关的数值；应优先使用订阅与客户端已经协调好的设置。

Hysteria2 在某种丢包环境下表现较好，不代表它能修复无线覆盖不足、出口拥塞或目标服务器繁忙。丢包发生在家庭无线接入段时，终端与路由器之间的竞争仍然存在；出口容量不足时，协议也无法凭空获得资源。判断其是否适合，应观察目标业务能否持续完成、其他设备是否受到明显影响，以及客户端是否出现异常发热。只看一次大文件传输的瞬时显示，容易把短时突发当成长期能力。

TUIC 的复用与连接持续性

TUIC 借助 QUIC 连接组织转发，并提供与代理业务相关的连接管理能力。复用可以减少重复建立底层连接的需要，但不意味着所有上层应用都会得到同样收益。短网页、持续视频和交互请求的等待模式不同，客户端还需要协调流管理与连接存活。QUIC 协议具备处理路径变化的相关机制，但具体客户端与代理部署是否完整支持，以及切网后是否真正保持业务，需要单独验证，不能只凭底层协议具备能力就宣布应用一定不断线。

如果当前网络对 UDP 的处理不稳定，这类协议可能在开始连接时就遇到困难，而基于 TCP 的可用项仍然正常。此时保留兼容线路比反复调整同一个选项更实际。比较时尽量保持地区、接入网络和应用一致，记录连接是否成功、业务能否完成，再讨论协议差异。不要把不同地区、不同时间和不同客户端的体验直接拼成结论，那样无法分清改善来自协议还是路径。

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

地区名称说明出口，不说明全程路径

客户端里的地区一般帮助用户识别出口位置，但数据进入服务网络的位置未必与出口相同。访问请求可能先到达某个入口，再沿转发路径送往出口，最后连接目标网站。出口靠近目标服务可能缩短后段路径，入口靠近用户则可能改善前段可达性，两者需要一起考虑。单凭地理距离猜测总延迟并不可靠，运营商互联、路由策略与拥塞状况会让实际路径绕行，地图上的近也不一定等于网络上的近。

直连通常指客户端直接连接对应的境外服务端入口，路径相对直观，也较依赖用户本地运营商的国际互联情况。它的优势可能是链路安排简单、额外转发环节较少，但这不构成稳定性保证。某个接入网络直连顺畅，换到另一个接入网络可能明显不同。选择时应查看实际业务是否流畅，而不是把“少一段中转”当成必然更快。直连更适合作为可比较的路径选择，而不是天然的高低档标签。

中转与 IEPL 专线怎样影响体验

中转在客户端与最终出口之间安排转发环节，目的是利用不同网络之间的路径组合。合理的入口与后段转发可以避开不理想的互联路径，使连接表现更均衡；但新增环节也需要处理容量、维护和故障切换。中转并非简单地把距离变长或变短，关键是换用了哪一段网络。遇到异常时，应观察同入口的其他出口是否也受影响，这有助于区分入口问题、转发问题与某个出口的个别问题。

IEPL 专线表示线路组织中使用相关的专用连接资源，通常用于降低某些共享路径带来的不确定性。但用户到入口仍要经过本地接入网络，出口到目标网站也可能继续使用公共网络，因此专线标签不能解释整条访问路径。专线同样受到容量安排、入口质量、维护状态和目标站点影响。把专线理解为线路中的一种资源安排，比理解为“任何时候任何网站都一样快”的承诺更准确。

延迟与稳定性应怎样一起取舍

交互应用关心往返等待是否平稳，大文件和视频则更关心持续传输是否有足够余量。某条线路的空载探测更低，但忙碌时排队明显，实际会议体验可能不如探测略高而波动较小的线路。选择时先排除连接失败与明显中断，再比较业务表现。地区需要匹配应用账户或内容规则时，也不能仅为更低探测值频繁换出口，否则网络问题尚未解决，应用侧又增加了新的变量。

VPNCross 提供 90+ 国家 / 190+ 线路，具体地区与线路类型请查看线路列表及登录后的可用项。列表用于识别选择范围，不代表每个地区都拥有完全相同的路径结构。比较同一地区时，先区分直连、中转和 IEPL 专线，再看协议与接入网络。若条件允许，保留平时使用的主线路和拓扑不同的备用线路；出现问题时切换路径，往往比只在相同入口下更换名称更有排查价值。

丢包与拥塞：为什么晚高峰会卡

延迟、抖动与吞吐不是同一个指标

延迟描述请求与响应之间的等待，抖动描述这种等待随时间的变化，吞吐描述一段时间内实际完成的数据传输。它们相关，但不能互相替代。空闲状态下响应迅速，不代表同时传输大量数据时仍然迅速；视频可以依靠缓冲容忍部分等待，语音会议则更容易被突发抖动打断。理解这些差别，有助于解释为什么某个测速结果看起来不错，日常交互却仍然不舒服。

丢包可能来自无线信号干扰、设备处理不过来、队列溢出、路径切换或某段链路异常。可靠传输通常通过确认与重传恢复缺失内容，但恢复需要额外等待，并可能触发发送速率调整。应用看到的结果可能是网页停顿、视频缓冲或请求超时。协议能改变恢复策略，却不能保证所有丢包都被用户无感地消化。尤其在持续拥塞时，单纯增加重试只会进一步占用本就紧张的链路资源。

晚高峰的瓶颈可能出现在不同位置

晚高峰访问变慢，首先说明某些共享资源在忙碌时出现压力，并不能直接锁定服务出口。家庭网络可能同时承担视频与备份，接入运营商可能在聚合段排队，线路入口和国际段也可能繁忙，目标网站还可能自行限速。判断方法是做范围比较：本地普通网站是否一起变慢，其他线路是否也变慢，同一线路上的不同目标是否同样异常。每个比较都对应一段不同的故障边界。

排队过长会让交互等待不断增加，这种现象有时比平均吞吐下降更明显。后台上传、云盘同步和系统更新都可能让家庭网络的发送队列持续繁忙，影响确认包和交互请求及时发出。先暂停非必要的大流量任务，再验证问题是否缓解，是成本很低的检查方式。若暂停后恢复，应该从本地流量竞争和路由器队列管理继续查，而不是立刻把全部责任归给某个协议。

探测结果怎样读才不误判

普通探测工具不一定与真实业务走同一类流量处理。中间设备可能降低探测报文的响应优先级，因此某个中间跳点不回复，并不等于最终业务丢失了相同比例的数据。路由跟踪中出现等待符号，也可能只是设备不回应探测。应将最终目标的可达性、应用请求结果与持续传输一起看，不要根据路径中间的一个空白就认定线路损坏，更不要把探测显示当成服务可用率承诺。

比较线路时尽量维持测试条件一致，避免一边后台下载、一边判断另一条线路的交互质量。先用相同目标完成相同操作，记录是首次连接慢、持续加载慢，还是运行中突然中断；再观察切换线路类型之后现象是否变化。如果只有某个应用异常，应保留其提示和发生场景。如果多种应用一起异常，再扩大到接入网络、入口和系统层面。这种按影响范围推进的方法，比不断刷新测速更能产生可用结论。

当问题具有明确时段规律时，可以记录接入网络、所选地区、线路类型、客户端状态与异常应用，通过面板工单提供这些信息。无需公开订阅地址或账户凭据。与“晚上很卡”相比，说明“相同网络下网页正常而持续视频会中断，切换不同入口后恢复”更便于定位，也能减少反复询问。描述可复现的条件，比自行推测某段网络一定故障更有帮助。

平台与电量：连接持续性的成本

耗电来自处理，也来自唤醒

移动端耗电不仅来自加密运算，还来自无线通信、后台唤醒、连接保活和应用自身的数据活动。某个协议在电脑上资源占用不明显，移动设备上却可能因为频繁重连或持续传输而发热。设备的硬件加速、系统网络接口和客户端实现也会影响结果。因此“协议越轻就越省电”只是过度简化，观察时应区分待机、普通浏览、视频与持续下载，不能把不同负载下的电量变化直接归为协议差异。

连接保活的目的是让路径上的会话状态不至于过早失效，但越频繁的保活不一定越好。它可能增加无线唤醒，而较少保活又可能让某些网络中的空闲连接被回收。合理选择需要兼顾当前接入网络与客户端设计。普通用户应先保持默认设置，只有在明确出现“空闲后首次请求失败”这类现象时，再按客户端说明调整；不应照搬与自己设备、网络都不同的参数清单。

系统后台策略会改变测试结果

移动系统会通过后台管理和省电机制限制应用活动，不同系统与设备的行为并不完全一致。屏幕关闭后连接状态改变，可能与系统调度有关，也可能是网络切换或空闲会话超时。排查时分别观察前台正常、切到后台、关闭屏幕和重新回到应用的过程，确认故障出现在哪一步。若只有后台场景异常，应优先查看系统允许的后台运行设置和客户端说明，而不是直接判定出口不可用。

从无线局域网切换到移动网络时，设备地址、路由和网络状态可能变化。底层协议即使具备连接迁移相关能力，上层应用也未必能保留原来的会话。正在进行的上传、会议或长响应可能仍需重建连接。需要连续业务时，尽量避免在关键操作中主动切网；必须切换时，先确认客户端已经恢复，再继续业务。界面显示重新连接，不等于应用里尚未完成的任务一定会自动续接。

分流、规则和日志也有运行成本

智能分流需要判断目标请求应走哪条路径，规则规模、匹配方式和域名解析安排都会影响处理过程。并不是规则越多越准确，也不是全部流量统一走同一路径就一定省心。某些桌面程序不读取系统代理，需要客户端提供适当的接管方式；多个工具同时修改系统代理或网络接口，又可能发生冲突。排查时应确认只有预期的客户端在接管流量，避免把叠加软件产生的问题误认为协议表现。

客户端本地诊断日志与 VPNCross 的“不记录日志”服务策略不是同一层面的概念。用户为排查问题开启本地日志时，应留意其中可能包含域名、订阅标识与连接信息，不要直接公开整份文件。诊断结束后恢复日常日志级别，既减少无关信息积累，也避免持续记录带来额外处理。VPNCross 支持 Windows / macOS / iOS / Android / Linux，客户端统一从面板下载入口获取，订阅需登录后获取。

场景选型：先看业务，再看协议

网页、开发与 AI 请求

普通网页访问由许多短请求组成，首次连接、域名解析和内容分发位置往往影响体感。选型时先看常用网站能否顺畅打开，再看同地区不同线路的等待是否稳定，不必为追求某个协议名称反复切换。开发工具则可能使用独立代理设置，浏览器正常并不代表终端、代码编辑器和依赖管理工具已经使用同一路径。应在真正工作的工具里验证，而不是只打开一个网页就判断开发环境已经接通。

AI 网页与 API 调用也要分开。网页端包含登录状态、浏览器会话与界面资源；API 调用关心认证、请求超时、流式输出和应用自身的重试逻辑。网络中断可能让响应未完整送达，而服务端仍可能已经处理请求，所以自动重试前要考虑业务是否允许重复执行。出口长期一致的需求还涉及线路与应用政策，不能由协议名称推断。更多开发场景可参阅AI API 加速选型文章。

流媒体、会议与大文件

流媒体更关心持续传输和内容可用性。播放开始快但随后频繁缓冲，可能是持续容量不足，也可能是内容分发路径变化。不同平台还会根据账户、版权地区和出口识别结果决定内容，连接成功不等于指定片库一定可用。比较时保持同一个账户、同一内容和相同播放设置，观察持续播放，而不是不断换片又换出口。若只有内容权限提示变化，应把它与网络传输故障分别处理。

语音会议与远程协作对等待波动更敏感，即使总流量不大，也可能被上传占用和排队影响。会前关闭非必要的大流量同步，选择表现平稳的线路，并避免在会议过程中频繁切换地区。大文件传输则适合观察长时间是否中断、能否续传以及本地存储是否成为瓶颈。协议能提供传输机制，但应用是否支持恢复仍由应用决定；不能把所有下载失败都归结为线路带宽不足。

流量预算与技术选择分别决定

技术上适合的线路，也需要配合实际流量需求。VPNCross 月订阅为 ¥9.9/月含 60GB、¥18/月含 250GB、¥28/月含 500GB，流量按开通日每月重置，中途升级差价折算成剩余天数。流量包为 ¥158/300GB、¥358/1000GB、¥658/3000GB，用完为止，永久不过期。具体对照请阅读套餐页。不要为了测试协议长时间反复传输大文件，测试用量也属于实际消耗，协议不同也不能据此承诺相同业务一定更省流量。

VPNCross 同时在线不限台数，但设备越多，家庭接入网络与套餐流量仍然需要共同安排。无需邮箱地址，用户名加密码即可注册；支付方式为支付宝 / 微信 / USDT，并提供 60 天无理由退款。上述服务事实与协议优劣没有直接对应关系，不应把较大流量档理解成客户端会自动改用某个协议。先确认自己的业务、接入网络和客户端兼容性，再选择用量安排，能减少把计费问题和技术问题混在一起的困惑。

验证与排错：按失败位置收敛

先保存现场，再改变条件

排错开始时，先记录正在使用的客户端、接入网络、线路地区、协议与应用提示，确认问题是否能够重复出现。不要同时更新客户端、更换协议、修改解析模式又切换出口；即使最后恢复，也无法知道哪个变化有效。更稳妥的方式是保留其他条件，只改变当前怀疑的因素，然后重复同一个操作。每次观察都应回答具体问题，例如“是否能完成握手”或“长响应是否中断”，而不是只记一句“感觉快了”。

如果全部线路都无法使用，先确认设备本地网络能正常访问普通网站，再检查客户端是否启用、订阅是否成功载入、系统时间与权限是否正常。若只有某个节点异常，换到路径或入口不同的可用项进行比较。若只有某个应用异常，检查应用是否读取系统代理、是否使用自己的网络设置，以及错误是否属于账户或服务端提示。这样的分支可以把排查范围从整台设备收敛到线路或应用，避免无关修改越积越多。

订阅完整性与证书问题

订阅链接是客户端获取线路配置的入口，不能当作普通网页地址随意公开。导入失败时先区分下载订阅失败、解析格式失败和连接线路失败：前者关注网络与链接状态，中间环节关注客户端支持的格式，最后才涉及具体服务器连接。不要手动删改不认识的字段来强行导入，字段缺失可能把明显的导入错误变成更难定位的握手错误。基础概念可查阅订阅链接获取、导入与更新指南。

出现证书或身份校验错误，应保留错误原文，检查系统时间和订阅更新情况，并使用客户端支持的正常校验方式。不要把跳过验证作为长期设置，也不要把订阅发到公开讨论区请人代试。若需要提交材料，应只提供必要的错误片段，隐藏账户标识、订阅地址和认证信息。服务策略中的不记录日志，不意味着用户设备上的截图和诊断文件可以不经处理就共享；这些文件仍需由用户自己控制传播范围。

把诊断写成可以复现的记录

一份有用的记录应交代：问题发生在前台还是后台、是否刚刚切网、普通网站是否正常、同地区其他线路是否正常，以及目标应用返回了什么。若恢复后又复发，还可以说明恢复前改变了哪个条件。无需把原始配置完整贴出，也不必自行断言是哪个网络环节故障。通过面板工单提交这些经过整理的信息，通常比连续发送测速截图更便于判断；本页不提供公开订阅地址或安装包直链。

恢复连接后，再做一次与日常用途一致的验证：网页用户确认资源加载，开发用户在实际工具中发出请求，流媒体用户观察持续播放，会议用户留意声音与交互是否平稳。随后清理排错期间临时增加的规则、恢复日常日志级别，并保留确实有效的设置。不要在恢复后继续叠加所谓优化参数，否则稳定状态又会被新的变量打乱。可解释、可恢复的设置，比复杂但无法说明作用的设置更容易维护。

需要从头操作时返回使用教程；需要比较路径时查看线路列表；需要确认费用与流量重置规则时查看套餐页。协议、线路、客户端和应用分别承担不同职责，没有单个开关能替代全部环节。掌握这套分层方法后，遇到新的协议名称也可以用相同问题判断：依靠什么传输，怎样保护连接，当前平台是否支持，以及真实业务是否因此变得更稳定。