SingLinkLabs · Protocol Paper 01
SingLink协议技术白皮书
SingLink 2.0是星连VPN自主研发的VPN传输协议（指协议代际，不是客户端版本号），向Pro套餐及Max、Rich流量包开放；本白皮书说明它的身份验证、DNS处理、智能分流、加密会话、TCP/UDP传输与断线恢复，以及与Beta、VLESS、AnyTLS的差异。
最后更新：
SingLink 2.0架构、完整连接生命周期与协议边界
SingLink 2.0是星连VPN自行研发的正式网络传输协议，不是客户端软件版本。本文以控制面、数据面和完整连接生命周期为主线，说明协议的公开能力、参考实现模型、测试数据边界及外部协议差异。
- Document
- SLP-WP-01
- Revision
- 1.0
- Published
- 2026-07-29
- Language
- 简体华文
协议代际与客户端版本独立管理。节点可用性以客户端实时状态为准。
订阅白皮书更新FeedScope and evidence
范围、结论与证据边界
这不是营销页，而是一份从配置取得到连接清理的系统说明。每项内容都区分已确认能力、公开设计说明与参考实现模型。
SingLink 2.0是星连VPN自行研发的正式网络传输协议代际。“2.0”代表协议名称与协议世代， 不是Windows、macOS、Android、iOS或其他客户端的软件版本号。
协议的产品边界不只是一段客户端到服务器的字节格式，还涉及账户与节点权限、DNS处理、 智能分流、节点选择、会话健康检测、网络切换和故障恢复。
来自产品页面、客户端能力及官方公开口径。
描述协议需要解决的问题和当前公开的系统边界。
用于解释可能的实现方式，不等同于已公开二进制规范。
Versioning
协议代际不是软件版本
Protocol
SingLink 2.0
表示传输协议代际、能力协商、会话模型和兼容策略的整体演进。
Client software
各平台独立编号
Windows、macOS、Android、iOS、Linux和TV客户端按各自发布节奏管理，不与协议2.0混用。
System architecture
控制面与数据面分离
权限、配置和节点调度由控制面负责；真正承载用户流量的通道由数据面负责。两者分离有助于限制敏感数据范围并隔离故障。
Control plane
控制面
- 01 账户与套餐权限
- 02 节点与协议能力列表
- 03 短期配置、策略与撤销
- 04 节点健康和调度信息
Data plane
数据面
- 01 流量接管与转发
- 02 TCP、UDP及逻辑流承载
- 03 会话状态与健康检测
- 04 返回数据解封装
Connection lifecycle
22个处理阶段
从账户权限、系统网络入口到返回数据解封装和安全清理，以下流程保留完整技术链路，并为每一步标注证据状态。
- 01
账户登录与权限确认
已确认能力客户端取得当前账户可用套餐、节点与协议权限。认证凭据应短期有效、可撤销，并与后续数据转发状态分离。
- 02
节点与协议配置下发
公开设计说明控制面返回节点地址、端口、可用协议和必要策略，不应把长期主密钥或不必要的敏感字段直接下发到客户端。
- 03
建立系统网络入口
已确认能力客户端通过TUN模式、系统代理或平台网络扩展接收需要处理的流量，具体入口取决于操作系统能力。
- 04
DNS解析与域名判断
已确认能力DNS请求与后续连接必须采用一致策略，避免域名走代理而DNS仍从本地网络泄漏或产生错误分流。
- 05
智能分流与路由判断
已确认能力根据规则、应用、目标域名、IP和网络状态，将连接判定为直连、代理或阻止。
- 06
节点选择
已确认能力手动模式采用用户指定节点；智能模式可综合延迟、可用性、负载、地区和套餐权限选择候选节点。
- 07
协议能力协商
公开设计说明客户端与服务端确认双方支持的协议代际和能力，旧端不应在无法识别新能力时静默启用不兼容行为。
- 08
身份验证与防重放
参考实现模型节点验证账户或会话是否有效，并应通过时效、随机值或等价机制阻止旧认证数据被重复使用。
- 09
密钥交换与会话密钥
参考实现模型协议需要为当前连接建立独立的加密上下文。具体密码套件、握手字段和轮换周期须以未来公开规范为准。
- 10
建立Session
参考实现模型Session表示客户端与节点之间的传输会话，可承载连接状态、能力信息、心跳和一个或多个逻辑流。
- 11
建立Stream或独立代理连接
参考实现模型每个应用请求可以映射为Session内的逻辑Stream，也可以建立独立连接；最终方式取决于公开实现。
- 12
数据帧封装
参考实现模型目标信息、流标识、负载长度、控制命令和数据需要形成可解析的帧；本页不虚构未公开的二进制字段。
- 13
TCP流量处理
公开设计说明TCP字节流需要保持顺序、处理半关闭与异常关闭，并把应用侧背压传递到传输侧。
- 14
UDP与QUIC流量处理
公开设计说明UDP数据报要保留消息边界并管理会话超时；QUIC等UDP型业务还需要避免不必要的队头阻塞。
- 15
流量控制与反压
参考实现模型当客户端、节点或目标服务消费速度下降时，应限制缓冲区增长，避免单个Stream拖垮整个Session。
- 16
分包、Padding与流量外观
参考实现模型分包和填充只能作为传输策略的一部分，不能被描述为绝对隐身；其启用条件和开销需要测试验证。
- 17
MTU与封包大小处理
公开设计说明隧道额外开销会降低可用MTU，需要通过分片避免、MSS调整或等价机制减少大包失败。
- 18
延迟、丢包与拥塞处理
参考实现模型协议应根据网络反馈控制发送节奏和重传，区分真实丢包、排队延迟与短暂网络抖动。
- 19
心跳与健康检测
已确认能力持续监测会话和节点状态，避免仅依赖操作系统的长超时来发现已经失效的连接。
- 20
网络切换与会话恢复
已确认能力Wi-Fi与移动网络切换后，客户端重新确认网络入口、DNS、路由与传输会话，并按能力恢复连接。
- 21
节点失效与自动切换
已确认能力软故障可先重建会话，硬故障则切换可用节点；切换过程中要恢复系统路由并避免流量意外直连。
- 22
返回数据、解封装与安全清理
公开设计说明客户端验证并解封装返回数据，连接结束后清除临时会话状态、缓存密钥、路由和DNS改动。
Traffic entry and routing
流量接管、DNS与智能分流
系统网络入口、域名解析与路由判断必须共享同一份上下文，避免DNS泄漏、错误出口和意外直连。
桌面系统可采用TUN模式或系统代理；移动与TV平台使用各自的网络扩展能力。 不同平台API不同，但策略目标一致：需要代理的流量进入隧道，不需要代理的流量按规则直连。
只代理应用流量而让DNS继续走本地网络，可能暴露域名或取得不适合当前出口的解析结果。 因此域名匹配、DNS查询、IP缓存和连接建立必须使用同一份路由上下文。
直连
本地服务或明确不需要代理的目标使用本地网络。
代理
经权限验证后，通过选定SingLink节点建立连接。
阻止
命中安全规则或无权限目标时拒绝连接。
Authentication
身份验证与加密会话
权限确认回答“这个账户能否使用该节点和协议”；传输认证回答“当前连接是否来自有效客户端”。 两者应使用短期、可撤销的会话状态，并防止旧认证信息被重放。
客户端与节点还需确认双方支持的协议代际和能力。无法识别新能力的一端必须安全降级或拒绝连接， 不能在未确认的情况下启用不兼容行为。
Disclosure boundary
未公开的密码学细节
现有资料不足以确认具体握手字段、密码套件、密钥派生函数、轮换周期和二进制数据包格式。 本文只描述安全目标，不把AES、TLS版本、某种曲线或固定字段长度写成既成事实。
Session model
Session、Stream与数据帧
用分层会话模型解释应用连接、逻辑流和节点传输上下文之间的关系，同时明确未公开的格式边界。
Session
客户端与节点之间的传输上下文，可承载认证结果、能力、心跳和连接级流控。
Stream
一个逻辑应用连接。多个Stream是否共享Session，取决于最终公开实现和平台策略。
数据帧至少需要表达控制命令、逻辑流、负载边界和错误状态；正式格式公开前，本页不会给出未经验证的字段表。
Transport
TCP、UDP与QUIC
TCP
有序字节流
保持字节顺序，处理半关闭、异常关闭、背压和目标连接错误，避免慢连接占满Session缓冲区。
UDP
数据报边界
保留数据报边界并维护目标和超时状态；若采用UDP-over-TCP，需要评估队头阻塞与丢包放大。
QUIC
UDP之上的可靠传输
尽量保留QUIC自身的拥塞和重传优势，避免额外可靠层造成重复恢复。
Reliability
流控、MTU、心跳与恢复
稳定连接不是一个自动重连按钮，而是缓冲、封包、健康检测、路由恢复和节点切换共同构成的状态机。
流量控制
按消费速度调整发送窗口，避免单流阻塞整条会话。
MTU处理
考虑隧道额外开销，降低分片和黑洞风险。
健康检测
结合心跳、延迟、丢包与真实转发状态判断连接。
网络恢复
切网后重建入口、DNS、路由和会话，防止流量意外直连。
Product comparison
SingLink 2.0与Beta
| 指标 | SingLink 2.0 | SingLink Beta |
|---|---|---|
| 定位 | 正式协议代际 | 速度优先的预览协议 |
| 内部A／B测试稳定率 | 99.5％ | 最高约97％ |
| 速度侧重点 | 速度、稳定和兼容平衡 | 合适条件下峰值超过1Gbps |
| 协议节点权限 | Pro、Max及Rich | 所有套餐 |
| 变更策略 | 重视长期兼容和恢复 | 用于新能力与性能验证 |
External protocols
与VLESS及AnyTLS的边界对比
比较依据采用各项目官方公开文档。这里比较定位、系统边界和公开能力，不把营销数字混入底层协议结论。
| 维度 | SingLink白皮书范围 | VLESS公开范围 | AnyTLS公开范围 |
|---|---|---|---|
| 公开定位 | 产品控制面与传输数据面的整体体系 | 无状态、轻量的客户端与服务端传输协议 | 基于TLS的代理协议与参考实现 |
| 身份与目标 | 账户、节点权限、会话与路由协同 | UUID、指令、端口和目标地址 | TLS后认证，再建立会话 |
| Session／Stream | 参考模型解释，精确格式尚未公开 | 支持Mux，具体由实现与配置决定 | 公开会话帧、Stream复用和命令 |
| 流量外观 | 待验证的传输策略，不宣称绝对隐身 | 官方文档描述可选Flow等机制 | 公开分包、Padding方案和更新机制 |
| 恢复能力 | 健康检测、切网、会话重建和节点切换 | 由Xray生态与具体传输组合承担 | 协议v2公开SYNACK、心跳和服务端协商 |
| 产品系统 | DNS、智能分流、套餐权限及节点调度 | 不等同于完整VPN产品控制面 | 不等同于完整VPN产品控制面 |
此表不代表代码兼容、性能排名或安全审计结论。
Platforms and openness
跨平台兼容与开源边界
平台一致性
SingLinkVPN覆盖iOS、Android、Windows、macOS、Linux和TV设备。跨平台一致性并不表示每个平台使用完全相同的系统API， 而是保持同一套权限、路由、节点和协议选择逻辑，并遵守各操作系统的网络扩展限制。
公开范围
SingLink 2.0核心协议源代码尚未完整公开。已公布方向包括技术文档、架构说明、研究数据、 可复现测试方法、数据格式、验证工具和负责任漏洞披露基础设施。
Frequently asked questions
常见问题
Q01SingLink 2.0是什么？
SingLink 2.0是星连VPN自行研发的正式网络传输协议代际，用于组织身份与权限验证、流量路由、传输会话、TCP与UDP处理、健康检测和异常恢复。
Q02SingLink 2.0是客户端软件版本吗？
不是。SingLink 2.0是协议名称与协议代际，Windows、macOS、Android、iOS及其他客户端使用独立的软件版本体系。
Q03SingLink Beta和SingLink 2.0有什么区别？
Beta是面向速度与新能力验证的预览协议；SingLink 2.0是正式协议代际，更重视稳定性、跨平台一致性、连接恢复和长期兼容。
Q04SingLink 2.0的稳定率是多少？
星连VPN指定测试环境中的内部A／B测试记录为99.5％，Beta最高约97％。这些不是对所有地区和时段的保证，实际结果会受到网络运营商、节点负载、设备和测试方法影响。
Q05SingLink如何处理网络流量？
客户端先建立系统网络入口，完成DNS与智能分流，再选择节点、验证权限、建立传输会话，并把TCP或UDP数据封装后发送到节点。
Q06SingLink如何处理断线和网络切换？
客户端持续检测会话与节点状态。出现异常时，会按能力重建会话、恢复DNS和路由，或切换到其他可用节点。
Q07SingLink与VLESS有什么区别？
VLESS官方定位是无状态、轻量的客户端与服务端传输协议。SingLink白皮书描述的范围更宽，还覆盖产品控制面、节点权限、智能路由、健康检测和恢复流程；二者不应只按单一帧格式比较。
Q08SingLink与AnyTLS有什么区别？
AnyTLS公开规范重点描述TLS之上的认证、Session、Stream复用、Padding和心跳。SingLink白皮书同时描述客户端流量入口、DNS、路由、套餐权限和节点调度，因此比较的是系统边界，而不是宣称底层实现相同。
Q09哪些用户可以使用SingLink 2.0？
当前SingLink 2.0协议节点主要向Pro、Max及Rich套餐开放；SingLink Beta协议节点向所有套餐开放。实际可用节点以客户端实时显示为准。
Q10SingLink 2.0是否已经完整开源？
目前核心协议源代码尚未完整公开。技术文档、研究数据、测试方法、数据格式、验证工具和漏洞披露机制已列入持续开源计划，公开范围以SingLinkLabs仓库和官方公告为准。
References and revision