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並登入後，客戶端不應立即把所有生產節點地址、憑證和協議參數永久保存在本地。

更合理的處理流程是：

  1. 客戶端提交帳戶登入憑證；

  2. 帳戶系統驗證用戶；

  3. 系統確認套餐及節點權限；

  4. 返回用戶可用的節點列表；

  5. 返回短期有效的連線憑證；

  6. 返回當前協議版本及必要配置；

  7. 客戶端驗證配置完整性；

  8. 將敏感配置保存於系統安全儲存區。

這一層主要判斷：

  • 用戶是否為有效會員；

  • 可以使用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；

  • 請求能力；

  • 完整性驗證資料。

一個通俗化的驗證包可以理解為：

我是誰
我要使用哪個節點
我要使用甚麼協議
這次連線的隨機編號
我的授權何時到期
資料是否被人修改

服務端需要檢查：

  1. Token是否由官方簽發；

  2. Token是否過期；

  3. Token是否已撤銷；

  4. 用戶是否有節點權限；

  5. 隨機數是否曾使用；

  6. 請求是否被重放；

  7. 客戶端版本是否允許連線。

防重放

攻擊者可能記錄一次合法驗證資料，再原樣發送。

所以驗證資料需要包含：

  • 一次性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
        ↓
發送目標域名和端口
        ↓
節點連接目標網站
        ↓
節點回報成功或失敗
        ↓
開始雙向轉發

正常關閉

當應用結束連線：

  1. 客戶端發送FIN；

  2. 節點停止接收該方向資料；

  3. 等待另一方向完成；

  4. 完整關閉Stream；

  5. 釋放記憶體和連線狀態。

異常關閉

如目標網站拒絕連線：

  1. 節點返回錯誤；

  2. 客戶端向應用返回連線失敗；

  3. Stream立即清理；

  4. 不影響其他Stream。

第十三階段：UDP流量處理

UDP沒有傳統TCP連線概念，每個資料包都需要保留：

  • 來源關係；

  • 目標地址；

  • 目標端口；

  • 資料長度；

  • 資料包邊界；

  • 會話超時。

例如：

UDP Association ID
目標地址
目標端口
資料長度
UDP Payload

SingLink需要明確選擇：

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需要：

  1. 確定TUN MTU；

  2. 扣除協議頭；

  3. 扣除加密開銷；

  4. 根據IPv4、IPv6調整；

  5. 必要時拆分資料；

  6. 避免不必要IP分片。

這也是為甚麼同一套固定封包大小，不一定適合所有網絡。

正式2.0應具有更完整的跨平台MTU兼容處理；Beta若使用更積極的大幀策略，可能在部分網絡得到高速度，但在特殊網絡中穩定性較低。

第十七階段：延遲、丟包和擁塞處理

客戶端需要持續觀察：

  • RTT延遲；

  • 延遲波動；

  • 丟包；

  • 發送速度；

  • 接收速度；

  • 未確認資料；

  • 節點響應。

不能只依靠一次Ping。

例如：

正常：60ms
短暫升高：120ms
持續升高：500ms
完全無回應：超時

不同情況需要不同處理：

情況

處理方式

短暫延遲

繼續等待，不立即重連

輕微丟包

調整窗口或傳輸節奏

持續高延遲

降低並發或考慮切換節點

無資料但有心跳

保留會話

心跳及資料都失敗

判定連線中斷

節點完全失效

重新連線或切換節點

如果遇到一次丟包就重新連線，反而會讓協議更不穩定。

第十八階段：心跳與健康檢測

長時間沒有應用資料時，系統仍需要知道通道是否存活。

可以使用：

PING
↓
PONG

但心跳不能太頻繁。

過於頻繁會：

  • 浪費電量；

  • 消耗流量；

  • 增加伺服器負載；

  • 形成固定時間特徵。

過於疏鬆則會：

  • 節點失效後很久才發現；

  • 應用等待時間過長；

  • 網絡切換恢復慢。

因此心跳可以根據狀態調整：

  • 有正常流量時，不額外發心跳；

  • 空閒一段時間後開始低頻心跳；

  • 網絡剛切換時暫時提高檢測頻率；

  • 多次失敗後判定連線中斷。

第十九階段：網絡切換與會話恢復

手機由Wi-Fi切換到5G時，原有連線通常會失效。

完整處理應是：

檢測到網絡改變
        ↓
暫停向失效通道發送新資料
        ↓
取得新的本地IP和路由
        ↓
重新連接原節點
        ↓
提交會話恢復憑證
        ↓
服務端驗證舊Session
        ↓
恢復可恢復的邏輯流
        ↓
無法恢復的TCP連線通知應用重建

需要注意：

不是所有應用TCP連線都能無縫恢復。

協議可以恢復：

  • 會話；

  • 節點授權；

  • 協議參數；

  • 部分仍有狀態的Stream。

但目標網站本身的TCP連線若已斷開，仍可能需要應用重新連接。

所以我們不會宣稱：

網絡切換時所有應用永遠完全無感。

更準確的說法是：

SingLink 2.0會縮短重新連線時間，恢復協議與路由狀態，並盡量降低對應用的影響。

第二十階段：節點失效與自動切換

節點異常可分為：

軟故障

  • 延遲升高；

  • 偶爾丟包；

  • 短暫無回應；

  • 部分目標不可用。

處理方式：

  • 暫時等待；

  • 降低傳輸壓力；

  • 重新測量；

  • 嘗試同節點重連。

硬故障

  • 節點完全無法連接；

  • 認證接口不可用；

  • 持續超時；

  • 節點被下線。

處理方式：

  1. 停止使用原節點；

  2. 從可用列表選擇替代節點；

  3. 建立新安全會話；

  4. 恢復DNS和路由；

  5. 通知應用重新建立必要連線。

正式2.0可以採取更保守的切換策略，避免因短暫抖動頻繁跳節點。

Beta則可以使用更積極的重新連線或高速節點選擇策略，但可能因此產生較高波動。

第二十一階段：返回資料與解封裝

目標網站的返回流程是：

目標網站返回資料
        ↓
星連節點接收
        ↓
找到對應Session和Stream
        ↓
封裝成SingLink資料幀
        ↓
加密並發送給客戶端
        ↓
客戶端驗證完整性
        ↓
解密
        ↓
按照Stream ID分流
        ↓
寫入TUN或系統代理
        ↓
交回原本應用程式

客戶端需要檢查：

  • 資料是否被修改；

  • 序號是否正確；

  • 是否為重複幀；

  • Stream是否仍存在；

  • 長度是否符合限制；

  • 是否超過接收窗口。

錯誤資料不能直接交給應用。

第二十二階段：正常斷線與安全清理

用戶點擊斷線後，客戶端應該：

  1. 停止接收新的代理流量；

  2. 正常關閉活動Stream；

  3. 向節點發送會話結束；

  4. 清除會話密鑰；

  5. 撤銷或丟棄短期Token；

  6. 關閉TUN；

  7. 恢復系統路由；

  8. 恢復DNS；

  9. 清除不必要的臨時配置。

如果客戶端直接崩潰，也需要作業系統或下次啟動時進行修復，避免留下：

  • 無效系統代理；

  • 錯誤DNS；

  • 殘留路由；

  • 無法上網。

下表總結了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是星連VPN自行研發的正式網絡傳輸協議，負責身份驗證、加密會話、流量封裝、TCP與UDP傳輸、健康檢測及異常恢復。

不是。SingLink 2.0是協議正式名稱，與Windows、macOS、Android及iOS客戶端版本屬於兩套不同版本體系。

Beta是速度優先的預覽協議，合適條件下峰值速度可達1 Gbps以上；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正式協議節點向Pro、Max及Rich會員開放；Beta協議適用於所有套餐，包括免費方案。實際權限以最新客戶端顯示為準。

目前尚未完整公開核心協議源碼，但技術文件、測試方法、數據格式、驗證工具及漏洞披露機制已納入持續開源計劃。

相關資料與延伸閱讀

本文的產品定位與公開範圍同時參考星連VPN官方技術中心、SingLinkLabs公開研究倉庫及其性能測試方法。

其他相關內容可閱讀星連VPN免費計劃完整指南、星連VPN開源計劃及2026年星連VPN安全審計報告。

技術說明：本文中的99.5%、97%及1 Gbps以上，分別屬於指定環境下的內部A/B測試及峰值測試結果，不代表所有地區、設備、網絡營運商及時間均能取得相同結果。涉及具體加密算法、封包格式、Session及Stream機制的內容，應以SingLink後續正式技術文件及公開源碼為準。