SingLink 2.0是星连VPN自行研发的正式网络传输协议。「2.0」代表协议名称与协议世代，并不是星连VPN客户端的软件版本号。
SingLink协议不只负责把流量传送到VPN节点，还涵盖账户与节点权限验证、DNS处理、智能分流、加密会话、TCP与UDP封装、连接健康检测、网络切换及异常恢复。
SingLink目前分为正式的SingLink 2.0 协议，以及速度优先的SingLink Beta预览协议。内部A/B测试中，SingLink 2.0稳定率达99.5%，Beta最高约97%；Beta在合适网络及设备条件下，峰值速度可达1 Gbps以上。
核心数据对比： 正式的SingLink 2.0在指定测试环境下录得99.5%稳定率；Beta最高约为97%，但在合适网络及设备条件下，峰值速度可达1 Gbps以上。这些结果分别反映稳定性与速度取向，不应直接视为所有设备及网络的保证值。
证据与技术边界：已确认的产品定位、内部测试口径及公开功能可直接引用；本文涉及具体加密算法、数据包格式、能力协商、Session、Stream、多路复用及会话恢复的内容，属于参考处理模型，不能视为目前已部署规格，应以SingLink后续正式技术文件及公开源码为准。
SingLink协议完整处理原理
整个系统可以分为两条线：
控制面
负责：
登录账户；
验证会员；
获取节点；
判断节点权限；
下发协议配置；
更新规则；
选择Beta或2.0。
数据面
负责：
接收应用流量；
DNS解析；
建立安全连接；
封装和传输TCP、UDP；
维持连接；
处理断线；
将数据交回应用程序。
简化流程是：
用户登录星连VPN
↓
获取经授权的节点和协议配置
↓
客户端建立TUN／系统代理
↓
接收应用程序流量
↓
DNS及分流规则判断
↓
选择SingLink 2.0或Beta节点
↓
协商协议能力
↓
验证账户及设备权限
↓
建立加密会话及会话密钥
↓
为每个应用连接建立独立逻辑流
↓
封装TCP／UDP数据
↓
传送至星连节点
↓
节点解封装并访问目标网站
↓
返回数据并分配给原应用
↓
持续检测延迟、丢包和连接状态
↓
异常时重连、恢复或切换节点第一阶段：登录、获取节点与协议配置
用户打开星连VPN并登录后，客户端不应立即把所有生产节点地址、凭证和协议参数永久保存在本地。
更合理的处理流程是：
客户端提交账户登录凭证；
账户系统验证用户；
系统确认套餐及节点权限；
返回用户可用的节点列表；
返回短期有效的连接凭证；
返回当前协议版本及必要配置；
客户端验证配置完整性；
将敏感配置保存于系统安全存储区。
这一层主要判断：
用户是否为有效会员；
可以使用Beta还是2.0；
是否拥有Pro、Max或Rich权限；
哪些国家和节点可以使用；
配置是否已过期；
客户端版本是否需要更新。
通俗理解
就像乘坐高铁前，系统先检查：
你是谁；
买了什么等级的票；
可以乘坐哪一班车；
车票是否仍然有效。
建议安全规则
SingLink不应长期依赖一个永久不变的静态密码。
更合理的是使用：
短期连接Token；
一次性Challenge；
设备随机数Nonce；
有效期限制；
服务器签名的节点配置；
撤销机制。
这样即使某次连接配置被获取，也不代表可以永久使用。
第二阶段：建立系统网络入口
当用户点击连接后，星连VPN需要先在操作系统中建立网络入口。
不同平台的处理方式不同：
平台 | 常见网络入口 |
|---|---|
iOS／iPadOS | Network Extension／Packet Tunnel |
Android | VPN Service |
macOS | Network Extension或TUN |
Windows | TUN虚拟网卡及系统路由 |
Linux | TUN、路由表及DNS管理 |
建立后，原本由应用程序直接送往网络的数据，会先进入星连VPN客户端。
例如：
ChatGPT App
↓
操作系统网络栈
↓
SingLink TUN接口
↓
星连VPN客户端客户端在这个阶段需要：
建立虚拟IP；
设置路由表；
设置DNS；
排除本地局域网；
防止代理连接再次被送回TUN。
最后一点很重要。
如果没有「路由排除」，星连VPN连接节点的流量也可能再次进入VPN，形成循环：
VPN流量
↓
再次进入VPN
↓
再次封装
↓
无限循环所以客户端必须明确排除：
节点本身的IP；
必要控制接口；
本地网关；
系统需要直接访问的服务。
第三阶段：DNS解析与域名判断
当用户打开 chatgpt.com 时，设备通常需要先把域名解析成IP地址。
如果DNS处理不正确，可能出现：
DNS请求直接走本地网络；
本地DNS返回错误地址；
规则无法判断域名；
IPv6绕过VPN；
已连接VPN但DNS仍泄漏。
SingLink客户端可以按以下流程处理：
应用发出DNS请求
↓
客户端拦截DNS
↓
判断域名规则
↓
选择本地DNS或远端安全DNS
↓
获取IPv4／IPv6结果
↓
将域名与IP关联
↓
决定直连、代理或阻挡本地域名
例如本地银行、局域网设备或特定地区服务，可以使用本地DNS并直接连接。
代理域名
需要通过VPN访问的域名，可以经由代理节点或受保护DNS解析。
通俗理解
DNS就像查地址簿。
如果查地址簿的过程仍然走本地道路，即使后续数据走了VPN，也可能暴露「正在查哪一个网站」。
因此，SingLink协议体系应明确定义：
DNS是否由客户端拦截；
哪些DNS请求直连；
哪些DNS请求通过VPN；
IPv4和IPv6如何处理；
DNS缓存多久；
网络切换后是否清除旧DNS结果。
第四阶段：智能分流与路由判断
DNS和应用流量进入客户端后，系统需要决定流量如何处理。
通常有三种结果：
直连
代理
阻挡直连
流量直接使用本地网络，不进入SingLink通道。
适用于：
局域网设备；
本地网站；
不需要代理的应用；
用户自订白名单。
代理
流量进入SingLink协议，由节点转发。
适用于：
海外网站；
AI工具；
国际社交平台；
用户指定的App。
阻挡
拒绝连接。
适用于：
广告域名；
追踪域名；
恶意地址；
用户设置的黑名单。
判断依据可能包括：
域名；
IP地址；
端口；
应用程序；
地理位置；
协议类型；
用户规则；
全局或规则模式。
通俗理解
这一步相当于交通分流：
本地车走普通道路；
海外车进入加密高速公路；
危险车辆直接禁止通行。
第五阶段：节点选择与协议选择
确定流量需要代理后，客户端需要选择节点。
选择节点不能只看国家名称，还需要考虑：
用户套餐；
节点是2.0还是Beta；
节点是否在线；
延迟；
丢包；
负载；
节点距离；
本地运营商；
目标网站位置；
节点是否支持UDP；
客户端是否兼容。
手动选择
用户自己选择日本、美国、新加坡等节点。
智能选择
客户端根据测试结果选择合适节点。
智能选择不应只选延迟最低的节点。
例如：
节点 | 延迟 | 丢包 | 负载 |
|---|---|---|---|
A | 50ms | 8% | 90% |
B | 70ms | 0% | 30% |
A虽然延迟更低，但丢包和负载很高；实际使用中，B可能更稳定。
所以智能选择应综合考虑：
延迟＋丢包＋连接成功率＋负载＋历史表现第六阶段：协议能力协商
客户端连接节点后，不应立即假设双方支持完全相同的功能。
需要先进行能力协商。
协商内容可以包括：
SingLink版本；
Beta或2.0；
TCP支持；
UDP支持；
IPv4／IPv6；
是否支持会话恢复；
是否支持多路复用；
最大数据帧；
Padding策略；
心跳间隔；
压缩是否启用；
MTU大小；
重新协商能力。
例如：
客户端：
我支持SingLink 2.0
支持TCP、UDP、IPv6
支持Session Resume
最大帧64KB
服务器：
确认使用SingLink 2.0
TCP、UDP可用
Session Resume可用
实际最大帧32KB双方最后使用共同支持的能力。
为什么需要协商？
因为客户端与节点可能不是同一天更新。
如果新客户端直接发送旧节点不认识的格式，连接就会失败。
正式2.0应比Beta更重视：
向后兼容；
版本回退；
不支持功能时安全降级；
明确拒绝不兼容版本。
第七阶段：身份验证
完成基本连接后，节点需要确认用户是否有权使用。
建议验证数据包括：
短期Token；
账户或授权ID；
客户端随机数；
协议版本；
节点ID；
请求能力；
完整性验证数据。
一个通俗化的验证包可以理解为：
我是谁
我要使用哪个节点
我要使用什么协议
这次连接的随机编号
我的授权何时到期
数据是否被人修改服务端需要检查：
Token是否由官方签发；
Token是否过期；
Token是否已撤销；
用户是否有节点权限；
随机数是否曾使用；
请求是否被重放；
客户端版本是否允许连接。
防重放
攻击者可能记录一次合法验证数据，再原样发送。
所以验证数据需要包含：
一次性Nonce；
服务器Challenge；
短有效期；
已使用凭证记录；
会话绑定。
通俗来说：
同一张已经验过的车票，不能被复制后无限使用。
第八阶段：密钥交换与加密会话
身份验证通过后，客户端与节点需要建立本次连接专用的会话密钥。
推荐逻辑是：
客户端产生临时密钥
↓
服务器产生临时密钥
↓
双方交换公开数据
↓
各自在本地计算相同共享密钥
↓
由共享密钥派生多组会话密钥需要分开派生：
客户端到服务器的加密密钥；
服务器到客户端的加密密钥；
数据完整性密钥；
会话恢复密钥；
Header保护密钥。
不应让所有方向和所有用途共用同一把密钥。
前向安全
更合理的做法是每次会话使用临时密钥。
这样即使日后某一个长期服务端密钥泄漏，也不应直接解密以前所有已记录流量。
密钥轮换
长时间连接不应永久使用同一组会话密钥。
可以按照：
传输数据量；
连接时间；
帧数；
服务器要求；
重新派生密钥。
例如：
每传输若干GB
或
每隔一段时间
重新产生方向密钥具体阈值通过性能及安全测试确定。
第九阶段：建立Session
身份和密钥完成后，双方建立SingLink Session。
Session可以包含：
Session ID；
协议版本；
加密参数；
最大帧大小；
心跳间隔；
UDP模式；
Stream上限；
空闲超时；
会话恢复能力；
Beta或2.0策略。
服务端返回确认：
身份验证成功
会话建立成功
使用SingLink 2.0
TCP可用
UDP可用
多路复用可用
心跳已启用只有收到服务端确认后，客户端才应正式发送应用数据。
第十阶段：建立Stream或独立代理连接
这一阶段常见的架构有两种：
方案一：一个Session承载多个Stream
类似AnyTLS的思路：
SingLink Session
├─ Stream 1：ChatGPT
├─ Stream 2：YouTube
├─ Stream 3：Telegram
└─ Stream 4：浏览器每个Stream需要有：
Stream ID；
目标地址；
目标端口；
TCP或UDP；
当前状态；
发送窗口；
接收窗口。
优点：
减少重复握手；
降低连接延迟；
减少底层连接数；
适合大量短连接。
风险：
一条Session出问题，可能影响多个Stream；
单一TCP底层可能出现队头阻塞；
需要完善流量控制。
方案二：每个应用请求建立独立连接
ChatGPT → 独立连接
YouTube → 独立连接
Telegram → 独立连接优点：
不同流量相互隔离；
一条连接失败不影响其他连接；
逻辑较简单。
缺点：
握手较多；
连接开销较大；
大量短连接效率较低。
建议
SingLink可以采用混合模式：
短连接和普通网页使用Session多路复用；
大流量下载和影片建立独立通道；
低延迟UDP采用独立处理；
避免一个高速下载占满所有Stream。
第十一阶段：数据帧封装
应用数据不能直接原样扔进传输通道，需要封装成协议帧。
概念上的SingLink帧可以包含：
版本
帧类型
Session ID
Stream ID
序号
Flags
数据长度
加密数据
完整性标记不同帧类型可能包括：
帧类型 | 作用 |
|---|---|
OPEN | 建立新Stream |
DATA | 传输数据 |
ACK | 确认状态 |
FIN | 正常关闭 |
RESET | 异常终止 |
PING | 健康检测 |
PONG | 响应健康检测 |
UDP | 传输UDP数据包 |
SETTINGS | 更新会话参数 |
KEY_UPDATE | 更换会话密钥 |
RESUME | 恢复会话 |
这只是协议设计层面的建议，不代表目前SingLink已使用这些名称或位元格式。
第十二阶段：TCP流量处理
对TCP连接，例如网页、API和文件下载，SingLink需要保持：
数据顺序；
双向传输；
关闭状态；
流量控制；
错误状态。
完整流程可以是：
应用建立TCP连接
↓
客户端建立SingLink Stream
↓
发送目标域名和端口
↓
节点连接目标网站
↓
节点回报成功或失败
↓
开始双向转发正常关闭
当应用结束连接：
客户端发送FIN；
节点停止接收该方向数据；
等待另一方向完成；
完整关闭Stream；
释放内存和连接状态。
异常关闭
如目标网站拒绝连接：
节点返回错误；
客户端向应用返回连接失败；
Stream立即清理；
不影响其他Stream。
第十三阶段：UDP流量处理
UDP没有传统TCP连接概念，每个数据包都需要保留：
来源关系；
目标地址；
目标端口；
数据长度；
数据包边界；
会话超时。
例如：
UDP Association ID
目标地址
目标端口
数据长度
UDP PayloadSingLink需要明确选择：
UDP-over-TCP
把UDP数据包放入TCP或可靠Session中传输。
优点：
容易穿过只允许TCP的网络；
数据不容易丢失；
部署简单。
缺点：
TCP丢包时会阻塞后续UDP数据；
不适合部分游戏、语音和即时场景。
原生UDP
直接以UDP承载。
优点：
延迟低；
适合游戏、语音及QUIC；
不受TCP队头阻塞影响。
缺点：
某些网络限制UDP；
NAT和防火墙处理更复杂。
QUIC式传输
基于UDP，但在协议层提供：
加密；
重传；
多Stream；
拥塞控制；
网络迁移。
技术能力较完整，但实现复杂度更高。
较合理的SingLink方向是：
根据网络及流量类型，自动决定UDP使用原生传输、可靠封装或其他兼容模式。
第十四阶段：流量控制与反压
假设YouTube下载非常快，而ChatGPT只传少量文字。
若没有流量控制，影片Stream可能占满整条通道，导致：
ChatGPT响应变慢；
DNS延迟；
其他应用卡住；
内存持续增加。
因此需要两级流量控制：
Session级
限制整个Session可以同时传输多少未确认数据。
Stream级
限制每个Stream可以占用多少传输窗口。
通俗来说：
一条高速公路不能让一辆大货车占满全部车道，每个Stream都需要合理分配道路资源。
2.0正式协议可以比Beta采用更保守的流量调度，避免追求峰值速度时影响其他连接。
第十五阶段：分包、Padding与流量外观
数据完成加密后，仍可能从外部看到：
数据包长度；
发送间隔；
连接持续时间；
上下行比例；
重连行为。
因此协议可以进行流量外观处理，例如：
大数据拆成多个帧；
小数据合并；
加入可变Padding；
调整发送批次；
避免所有握手长度固定；
定期更新Padding策略。
但需要明确：
Padding不能代替加密，也不能保证流量永远无法识别。
过度Padding还会带来：
更多流量；
更高延迟；
更多CPU消耗；
免费额度浪费。
因此2.0可以使用自适应策略：
网络正常时使用低开销；
特殊网络环境增加外观处理；
高速下载时减少不必要Padding；
小型控制数据适当填充。
Beta则可能更偏向降低额外开销，以提高峰值速度。
第十六阶段：MTU与数据包大小处理
TUN流量加上协议头和加密数据后，数据包会变大。
如果超过网络MTU，可能发生：
IP分片；
数据包被丢弃；
某些网站打不开；
速度忽快忽慢；
VPN连上但无法传输。
SingLink需要：
确定TUN MTU；
扣除协议头；
扣除加密开销；
根据IPv4、IPv6调整；
必要时拆分数据；
避免不必要IP分片。
这也是为什么同一套固定数据包大小，不一定适合所有网络。
正式2.0应具有更完整的跨平台MTU兼容处理；Beta若使用更积极的大帧策略，可能在部分网络得到高速度，但在特殊网络中稳定性较低。
第十七阶段：延迟、丢包和拥塞处理
客户端需要持续观察：
RTT延迟；
延迟波动；
丢包；
发送速度；
接收速度；
未确认数据；
节点响应。
不能只依靠一次Ping。
例如：
正常：60ms
短暂升高：120ms
持续升高：500ms
完全无响应：超时不同情况需要不同处理：
情况 | 处理方式 |
|---|---|
短暂延迟 | 继续等待，不立即重连 |
轻微丢包 | 调整窗口或传输节奏 |
持续高延迟 | 降低并发或考虑切换节点 |
无数据但有心跳 | 保留会话 |
心跳及数据都失败 | 判定连接中断 |
节点完全失效 | 重新连接或切换节点 |
如果遇到一次丢包就重新连接，反而会让协议更不稳定。
第十八阶段：心跳与健康检测
长时间没有应用数据时，系统仍需要知道通道是否存活。
可以使用：
PING
↓
PONG但心跳不能太频繁。
过于频繁会：
浪费电量；
消耗流量；
增加服务器负载；
形成固定时间特征。
过于疏松则会：
节点失效后很久才发现；
应用等待时间过长；
网络切换恢复慢。
因此心跳可以根据状态调整：
有正常流量时，不额外发心跳；
空闲一段时间后开始低频心跳；
网络刚切换时暂时提高检测频率；
多次失败后判定连接中断。
第十九阶段：网络切换与会话恢复
手机由Wi-Fi切换到5G时，原有连接通常会失效。
完整处理应是：
检测到网络改变
↓
暂停向失效通道发送新数据
↓
获取新的本地IP和路由
↓
重新连接原节点
↓
提交会话恢复凭证
↓
服务端验证旧Session
↓
恢复可恢复的逻辑流
↓
无法恢复的TCP连接通知应用重建需要注意：
不是所有应用TCP连接都能无缝恢复。
协议可以恢复：
会话；
节点授权；
协议参数；
部分仍有状态的Stream。
但目标网站本身的TCP连接若已断开，仍可能需要应用重新连接。
所以我们不会宣称：
网络切换时所有应用永远完全无感。
更准确的说法是：
SingLink 2.0会缩短重新连接时间，恢复协议与路由状态，并尽量降低对应用的影响。
第二十阶段：节点失效与自动切换
节点异常可分为：
软故障
延迟升高；
偶尔丢包；
短暂无响应；
部分目标不可用。
处理方式：
暂时等待；
降低传输压力；
重新测量；
尝试同节点重连。
硬故障
节点完全无法连接；
认证接口不可用；
持续超时；
节点被下线。
处理方式：
停止使用原节点；
从可用列表选择替代节点；
建立新安全会话；
恢复DNS和路由；
通知应用重新建立必要连接。
正式2.0可以采取更保守的切换策略，避免因短暂抖动频繁跳节点。
Beta则可以使用更积极的重新连接或高速节点选择策略，但可能因此产生较高波动。
第二十一阶段：返回数据与解封装
目标网站的返回流程是：
目标网站返回数据
↓
星连节点接收
↓
找到对应Session和Stream
↓
封装成SingLink数据帧
↓
加密并发送给客户端
↓
客户端验证完整性
↓
解密
↓
按照Stream ID分流
↓
写入TUN或系统代理
↓
交回原本应用程序客户端需要检查：
数据是否被修改；
序号是否正确；
是否为重复帧；
Stream是否仍存在；
长度是否符合限制；
是否超过接收窗口。
错误数据不能直接交给应用。
第二十二阶段：正常断线与安全清理
用户点击断线后，客户端应该：
停止接收新的代理流量；
正常关闭活动Stream；
向节点发送会话结束；
清除会话密钥；
撤销或丢弃短期Token；
关闭TUN；
恢复系统路由；
恢复DNS；
清除不必要的临时配置。
如果客户端直接崩溃，也需要操作系统或下次启动时进行修复，避免留下：
无效系统代理；
错误DNS；
残留路由；
无法上网。
SingLink Beta与2.0的细节策略差异
下表总结了SingLink Beta与SingLink 2.0的技术定位。
处理环节 | SingLink Beta | SingLink 2.0 |
|---|---|---|
核心方向 | 峰值速度 | 速度、稳定、兼容 |
连接参数 | 较积极 | 自适应及较保守 |
并发策略 | 可使用较高并发 | 避免单流量占满通道 |
传输窗口 | 偏向高速吞吐 | 按延迟及丢包动态调整 |
节点切换 | 更快尝试高速节点 | 先确认故障再切换 |
多路复用 | 偏向提高复用效率 | 平衡复用与故障隔离 |
Padding | 优先降低开销 | 按环境自适应 |
网络切换 | 基本恢复 | 更完整的恢复与兼容 |
平台回归测试 | 预览范围 | 正式完整测试 |
内部稳定率 | 约97% | 99.5% |
速度 | 合适环境可达1 Gbps以上 | 保持高速但不只追求峰值 |
一句话说完整个处理原理
SingLink首先由客户端接管设备流量，完成DNS、智能分流及节点选择；再验证账户和节点权限，与节点协商协议能力及建立临时加密密钥。连接建立后，不同应用的TCP和UDP流量会被封装为独立代理连接或逻辑Stream，经受保护通道传送到节点，再由节点访问目标网站。传输过程中，系统会持续管理流量窗口、数据完整性、延迟、丢包、心跳和节点状态；遇到网络切换或节点失效时，则重新建立会话、恢复路由或切换可用节点。
而Beta与2.0的本质区别是：
SingLink Beta更积极地追求峰值速度；SingLink 2.0则在高速传输之外，加入更完整的兼容、健康检测、异常判断、会话恢复及跨平台处理，因此稳定率更高。
常见问题
SingLink 2.0是什么？
SingLink 2.0是星连VPN自行研发的正式网络传输协议，负责身份验证、加密会话、流量封装、TCP与UDP传输、健康检测及异常恢复。
SingLink 2.0是软件版本吗？
不是。SingLink 2.0是协议正式名称，与Windows、macOS、Android及iOS客户端版本属于两套不同版本体系。
SingLink Beta和2.0有什么分别？
Beta是速度优先的预览协议，合适条件下峰值速度可达1 Gbps以上；2.0则是正式协议，重视速度、稳定性、跨平台兼容及断线恢复。
SingLink 2.0的稳定率是多少？
在星连VPN指定测试环境下的内部A/B测试中，SingLink 2.0稳定率达99.5%，Beta最高约97%。
SingLink如何处理网络流量？
客户端先接管系统流量，完成DNS及智能分流，再验证账户与节点权限，建立加密会话，封装TCP或UDP数据并传送至节点。
SingLink如何处理断线？
系统会持续检测延迟、丢包、心跳及节点状态；出现异常时，可重新建立会话、恢复路由或切换可用节点。
SingLink与VLESS有什么分别？
VLESS核心主要是身份、指令及目标转发；SingLink则将身份、路由、节点权限、传输策略、健康检测及异常恢复整合为协议体系。
SingLink与AnyTLS有什么分别？
AnyTLS主要以TLS连接承载Session及多个Stream；SingLink的定位则更广，还包括智能路由、会员权限、节点调度及连接恢复。具体Session及Stream实现仍以正式技术文件为准。
哪些用户可以使用SingLink 2.0？
SingLink 2.0正式协议节点向Pro、Max及Rich会员开放；Beta协议适用于所有套餐，包括免费计划。实际权限以最新客户端显示为准。
SingLink 2.0是否已经完整开源？
目前尚未完整公开核心协议源码，但技术文件、测试方法、数据格式、验证工具及漏洞披露机制已纳入持续开源计划。
相关资料与延伸阅读
本文的产品定位与公开范围同时参考星连VPN官方技术中心、SingLinkLabs公开研究仓库及其性能测试方法。
其他相关内容可阅读星连VPN免费计划完整指南、星连VPN开源计划及2026年星连VPN安全审计报告。
技术说明：本文中的99.5%、97%及1 Gbps以上，分别属于指定环境下的内部A/B测试及峰值测试结果，不代表所有地区、设备、网络运营商及时间均能获取相同结果。涉及具体加密算法、数据包格式、Session及Stream机制的内容，应以SingLink后续正式技术文件及公开源码为准。