SingLink 2.0 Protocol

SingLink 2.0 is the official network transport protocol developed in-house by SingLinkVPN. “2.0” identifies the protocol name and generation; it is not a SingLinkVPN client software version.

The SingLink protocol does more than carry traffic to a VPN node. It also covers account and node authorization, DNS handling, smart routing, encrypted sessions, TCP and UDP encapsulation, connection health checks, network changes, and exception recovery.

SingLink currently has the production SingLink 2.0 protocol and the speed-first SingLink Beta preview protocol. In internal A/B tests, SingLink 2.0 reached 99.5% stability and Beta reached up to about 97%; under suitable network and device conditions, Beta peak speed exceeded 1 Gbps.

Core-data comparison: Production SingLink 2.0 recorded 99.5% stability in the specified test environment. Beta reached up to about 97%, but exceeded 1 Gbps peak speed under suitable network and device conditions. These results represent different stability and speed priorities and are not guarantees for every device or network.

Evidence and technical boundary: Confirmed product positioning, internal-test definitions, and public functions may be cited directly. The specific encryption algorithms, packet format, capability negotiation, Session, Stream, multiplexing, and session-recovery details below are a reference processing model, not a statement of the currently deployed specification. Future official SingLink technical documents and published source code take precedence.

Complete SingLink Protocol Processing Principles

The complete system can be divided into two paths:

Control plane

Responsible for:

• signing in to an account;

• validating membership;

• obtaining nodes;

• determining node entitlements;

• delivering protocol configuration;

• updating rules;

• selecting Beta or 2.0.

Data plane

Responsible for:

• receiving application traffic;

• resolving DNS;

• establishing a secure connection;

• encapsulating and carrying TCP and UDP;

• keeping the connection alive;

• handling disconnections;

• returning data to the application.

The simplified flow is:

User signs in to SingLinkVPN
        ↓
Obtain authorized nodes and protocol configuration
        ↓
Client creates a TUN / system proxy
        ↓
Receive application traffic
        ↓
Evaluate DNS and routing rules
        ↓
Select a SingLink 2.0 or Beta node
        ↓
Negotiate protocol capabilities
        ↓
Verify account and device entitlements
        ↓
Create encrypted session and session keys
        ↓
Create an independent logical stream for each application connection
        ↓
Encapsulate TCP / UDP data
        ↓
Send data to the SingLink node
        ↓
Node decapsulates and accesses the destination website
        ↓
Return data and deliver it to the originating application
        ↓
Continuously measure latency, loss, and connection state
        ↓
Reconnect, recover, or switch nodes after an exception

Stage 1: Sign-in, Node Retrieval, and Protocol Configuration

After a user opens SingLinkVPN and signs in, the client should not immediately store every production-node address, credential, and protocol parameter permanently on the device.

A more appropriate flow is:

1. The client submits account credentials.

2. The account system verifies the user.

3. The system confirms plan and node entitlements.

4. It returns the nodes available to that user.

5. It returns short-lived connection credentials.

6. It returns the current protocol version and required configuration.

7. The client verifies configuration integrity.

8. Sensitive configuration is stored in protected system storage.

This layer primarily determines:

• whether the user has valid membership;

• whether Beta or 2.0 is available;

• whether the account has Pro, Max, or Rich entitlement;

• which countries and nodes are available;

• whether configuration has expired;

• whether the client must be updated.

Plain-language explanation

It is like checking before boarding a high-speed train:

• who you are;

• which ticket class you bought;

• which service you may board;

• whether the ticket remains valid.

Recommended security rules

SingLink should not rely indefinitely on one permanent static password.

A more appropriate design uses:

• a short-lived connection token;

• a one-time challenge;

• a device nonce;

• an expiry limit;

• server-signed node configuration;

• a revocation mechanism.

Obtaining one connection configuration would then not grant permanent access.

Stage 2: Establishing the System Network Entry Point

When a user selects Connect, SingLinkVPN first needs to create a network entry point in the operating system.

The method differs by platform:

After it is created, data that applications would normally send directly to the network first enters the SingLinkVPN client.

For example:

ChatGPT App
    ↓
Operating-system network stack
    ↓
SingLink TUN interface
    ↓
SingLinkVPN client

At this stage, the client needs to:

• create a virtual IP;

• configure the routing table;

• configure DNS;

• exclude the local-area network;

• prevent the proxy connection from being routed back into the TUN;

• create Kill Switch rules.

The last point is important.

Without a route exclusion, the traffic used by SingLinkVPN to reach its node could itself re-enter the VPN and create a loop:

VPN traffic
↓
Re-enters VPN
↓
Is encapsulated again
↓
Infinite loop

The client must therefore explicitly exclude:

• the node’s own IP;

• required control interfaces;

• the local gateway;

• services that the system must reach directly.

Stage 3: DNS Resolution and Domain Evaluation

When a user opens chatgpt.com, the device usually must first resolve the domain to an IP address.

Incorrect DNS handling can cause:

• DNS requests to travel directly over the local network;

• the local DNS resolver to return an incorrect address;

• rules to lose the original domain context;

• IPv6 traffic to bypass the VPN;

• DNS leakage even while the VPN appears connected.

The SingLink client can use this flow:

Application sends a DNS request
        ↓
Client intercepts DNS
        ↓
Evaluate domain rules
        ↓
Select local DNS or protected remote DNS
        ↓
Obtain IPv4 / IPv6 result
        ↓
Associate domain with IP
        ↓
Choose direct, proxy, or block

Local domains

Local banks, LAN devices, or region-specific services can use local DNS and connect directly.

Proxied domains

Domains that must be accessed through the VPN can be resolved through the proxy node or a protected DNS resolver.

Plain-language explanation

DNS is like looking up an address.

If that lookup still uses the local road, it may reveal which website is being requested even when subsequent data uses the VPN.

The SingLink protocol system should therefore define:

• whether the client intercepts DNS;

• which DNS requests go direct;

• which DNS requests use the VPN;

• how IPv4 and IPv6 are handled;

• how long DNS results are cached;

• whether stale DNS results are cleared after a network change.

Stage 4: Smart Routing and Route Decisions

After DNS and application traffic enter the client, the system must decide how to handle them.

There are normally three outcomes:

Direct
Proxy
Block

Direct

Traffic uses the local network and does not enter the SingLink tunnel.

Suitable for:

• LAN devices;

• local websites;

• applications that do not need a proxy;

• user-defined allowlists.

Proxy

Traffic enters the SingLink protocol and is forwarded by a node.

Suitable for:

• overseas websites;

• AI tools;

• international social platforms;

• user-selected apps.

Block

The connection is rejected.

Suitable for:

• advertising domains;

• tracking domains;

• malicious addresses;

• user-defined blocklists.

The decision can consider:

• domain;

• IP address;

• port;

• application;

• geographic location;

• protocol type;

• user rules;

• global or rule mode.

Plain-language explanation

This stage resembles traffic routing:

• local vehicles take ordinary roads;

• overseas vehicles enter an encrypted expressway;

• dangerous vehicles are denied entry.

Stage 5: Node and Protocol Selection

Once traffic is identified as proxied, the client must choose a node.

Selection cannot rely only on a country name. It must also consider:

• the user’s plan;

• whether the node uses 2.0 or Beta;

• whether the node is online;

• latency;

• packet loss;

• load;

• node distance;

• the local carrier;

• destination location;

• UDP support;

• client compatibility.

Manual selection

The user chooses a node in Japan, the United States, Singapore, or another location.

Smart selection

The client selects a suitable node from test results.

Smart selection should not simply choose the lowest-latency node.

For example:

Although A has lower latency, its loss and load are high; B may be more stable in real use.

Smart selection should therefore combine:

Latency + loss + connection success rate + load + historical performance

Stage 6: Protocol Capability Negotiation

After the client reaches a node, it should not immediately assume that both sides support identical functions.

Capabilities need to be negotiated first.

Negotiated items may include:

• SingLink version;

• Beta or 2.0;

• TCP support;

• UDP support;

• IPv4 / IPv6;

• session-resumption support;

• multiplexing support;

• maximum data-frame size;

• Padding strategy;

• heartbeat interval;

• whether compression is enabled;

• MTU size;

• renegotiation support.

For example:

Client:
I support SingLink 2.0
I support TCP, UDP, and IPv6
I support Session Resume
Maximum frame: 64 KB

Server:
Use SingLink 2.0 confirmed
TCP and UDP available
Session Resume available
Effective maximum frame: 32 KB

The two sides ultimately use only mutually supported capabilities.

Why is negotiation required?

Clients and nodes may not be updated on the same day.

If a new client sends a format that an old node cannot recognize, the connection fails.

Production 2.0 should place more emphasis than Beta on:

• backward compatibility;

• version fallback;

• safe degradation when a feature is unavailable;

• explicit rejection of incompatible versions.

Stage 7: Identity Verification

After the basic connection is established, the node needs to confirm that the user is authorized.

Recommended verification data includes:

• short-lived token;

• account or authorization ID;

• client nonce;

• protocol version;

• node ID;

• requested capabilities;

• integrity-verification data.

A simplified authentication packet says:

Who I am
Which node I want
Which protocol I want
The random identifier for this connection
When my authorization expires
Whether the data was modified

The server needs to check:

1. whether the token was officially issued;

2. whether the token expired;

3. whether the token was revoked;

4. whether the user has node access;

5. whether the nonce was used before;

6. whether the request is a replay;

7. whether this client version may connect.

Replay protection

An attacker could record valid authentication data and send it again unchanged.

Authentication data therefore needs:

• a one-time nonce;

• a server challenge;

• a short validity period;

• a used-credential record;

• session binding.

In plain language:

A ticket that has already been validated cannot be copied and reused without limit.

Stage 8: Key Exchange and Encrypted Session

After identity verification succeeds, the client and node need session keys dedicated to this connection.

The recommended logic is:

Client creates an ephemeral key
        ↓
Server creates an ephemeral key
        ↓
Both exchange public data
        ↓
Each independently computes the same shared secret
        ↓
Multiple session keys are derived from that shared secret

Separate keys should be derived for:

• client-to-server encryption;

• server-to-client encryption;

• data integrity;

• session recovery;

• header protection.

All directions and purposes should not share one key.

Forward secrecy

A more appropriate design uses ephemeral keys for each session.

If a long-term server key leaks later, it should not directly decrypt every previously recorded connection.

Key rotation

A long-running connection should not use one set of session keys forever.

Keys can be re-derived according to:

• transferred data volume;

• connection duration;

• frame count;

• server instruction.

to re-derive the keys.

For example:

After a defined number of GB
or
after a defined period
derive new directional keys

Exact values should be determined through engineering performance and security tests, not invented in a promotional article.

Stage 9: Creating a Session

After identity and keys are established, both sides create a SingLink Session.

A Session may contain:

• Session ID;

• protocol version;

• encryption parameters;

• maximum frame size;

• heartbeat interval;

• UDP mode;

• Stream limit;

• idle timeout;

• session-recovery capability;

• Beta or 2.0 policy.

The server returns confirmation:

Identity verified
Session established
Using SingLink 2.0
TCP available
UDP available
Multiplexing available
Heartbeat enabled

The client should send application data only after receiving server confirmation.

Stage 10: Creating a Stream or Independent Proxy Connection

Engineering confirmation is required to establish which architecture SingLink actually uses.

Option 1: One Session carries multiple Streams

This resembles the AnyTLS approach:

SingLink Session
├─ Stream 1: ChatGPT
├─ Stream 2: YouTube
├─ Stream 3: Telegram
└─ Stream 4: Browser

Each Stream needs:

• Stream ID;

• destination address;

• destination port;

• TCP or UDP;

• current state;

• send window;

• receive window.

Benefits:

• fewer repeated handshakes;

• lower connection latency;

• fewer underlying connections;

• efficient handling of many short connections.

Risks:

• one Session failure can affect multiple Streams;

• one underlying TCP connection may cause head-of-line blocking;

• complete flow control is required.

Option 2: Each application request creates an independent connection

ChatGPT → independent connection
YouTube → independent connection
Telegram → independent connection

Benefits:

• different traffic is isolated;

• failure of one connection does not affect the others;

• simpler logic.

Disadvantages:

• more handshakes;

• greater connection overhead;

• lower efficiency for many short connections.

Recommendation

SingLink can use a hybrid mode:

• multiplex short connections and ordinary web traffic over a Session;

• create independent channels for large downloads and video;

• handle low-latency UDP separately;

• prevent one high-speed download from consuming every Stream.

Stage 11: Data-Frame Encapsulation

Application data cannot be dropped unchanged into the transport channel. It needs to be encapsulated as protocol frames.

A conceptual SingLink frame may contain:

Version
Frame type
Session ID
Stream ID
Sequence number
Flags
Data length
Encrypted data
Integrity tag

Possible frame types include:

This is a protocol-design recommendation. It does not state that SingLink currently uses these names or bit formats.

Stage 12: TCP Traffic Processing

For TCP connections such as websites, APIs, and file downloads, SingLink needs to preserve:

• data order;

• bidirectional transfer;

• close state;

• flow control;

• error state.

A complete flow can be:

Application creates a TCP connection
        ↓
Client creates a SingLink Stream
        ↓
Send destination domain and port
        ↓
Node connects to destination website
        ↓
Node reports success or failure
        ↓
Begin bidirectional forwarding

Normal close

When the application ends the connection:

1. The client sends FIN.

2. The node stops receiving data in that direction.

3. It waits for the other direction to finish.

4. The Stream closes completely.

5. Memory and connection state are released.

Abnormal close

If the destination refuses the connection:

1. The node returns an error.

2. The client reports connection failure to the application.

3. The Stream is immediately cleaned up.

4. Other Streams are unaffected.

Stage 13: UDP Traffic Processing

UDP has no conventional TCP connection. Each datagram needs to retain:

• source association;

• destination address;

• destination port;

• data length;

• datagram boundary;

• association timeout.

For example:

UDP Association ID
Destination address
Destination port
Data length
UDP Payload

SingLink needs to choose explicitly among these approaches:

UDP over TCP

UDP datagrams are carried inside TCP or a reliable Session.

Benefits:

• easier traversal of networks that allow only TCP;

• less chance of data loss;

• simpler deployment.

Disadvantages:

• TCP loss blocks later UDP data;

• unsuitable for some games, voice, and real-time uses.

Native UDP

UDP carries the data directly.

Benefits:

• low latency;

• suitable for games, voice, and QUIC;

• unaffected by TCP head-of-line blocking.

Disadvantages:

• some networks restrict UDP;

• NAT and firewall handling is more complex.

QUIC-style transport

It is based on UDP but supplies at the protocol layer:

• encryption;

• retransmission;

• multiple Streams;

• congestion control;

• network migration.

It offers more complete technical capabilities but is harder to implement.

A reasonable SingLink direction is:

Automatically choose native UDP, reliable encapsulation, or another compatible mode according to network and traffic type.

Whether this is implemented needs to be confirmed.

Stage 14: Flow Control and Backpressure

Assume YouTube is downloading quickly while ChatGPT transfers only small amounts of text.

Without flow control, the video Stream can fill the channel and cause:

• slower ChatGPT responses;

• DNS delay;

• stalled applications;

• continuously increasing memory use.

Two levels of flow control are therefore required:

Session level

Limits how much unacknowledged data the whole Session can carry.

Stream level

Limits how much of the transport window each Stream can occupy.

In plain language:

One large truck cannot occupy every lane of an expressway. Each Stream needs a fair allocation of transport resources.

The production 2.0 protocol can use more conservative scheduling than Beta so that pursuit of peak speed does not disrupt other connections.

Stage 15: Segmentation, Padding, and Traffic Appearance

After data is encrypted, an observer may still see:

• packet length;

• sending interval;

• connection duration;

• upload/download ratio;

• reconnection behavior.

The protocol can therefore modify traffic appearance, for example by:

• splitting large data into multiple frames;

• combining small data;

• adding variable Padding;

• adjusting send batches;

• avoiding one fixed handshake length;

• periodically updating the Padding strategy.

But it must be clear that:

Padding cannot replace encryption and cannot guarantee that traffic will always be unidentifiable.

Excessive Padding also causes:

• more traffic;

• higher latency;

• more CPU use;

• wasted Free Plan allowance.

The 2.0 profile can therefore adapt:

• use low overhead on ordinary networks;

• increase appearance processing in special network environments;

• reduce unnecessary Padding during high-speed downloads;

• apply suitable padding to small control data.

Beta may instead reduce extra overhead to improve peak speed.

Stage 16: MTU and Packet-Size Handling

Adding protocol headers and encrypted data to TUN traffic increases packet size.

Exceeding the network MTU can cause:

• IP fragmentation;

• packet drops;

• websites that fail to open;

• unstable speed;

• a VPN that connects but carries no data.

SingLink needs to:

1. determine the TUN MTU;

2. subtract protocol headers;

3. subtract encryption overhead;

4. adjust for IPv4 and IPv6;

5. split data when required;

6. avoid unnecessary IP fragmentation.

This is why one fixed packet size does not fit every network.

Production 2.0 should have more complete cross-platform MTU compatibility. If Beta uses more aggressive large frames, it may be faster on some networks but less stable on unusual networks.

Stage 17: Latency, Loss, and Congestion Handling

The client needs to continuously observe:

• RTT latency;

• jitter;

• packet loss;

• send speed;

• receive speed;

• unacknowledged data;

• node response.

It cannot rely on one Ping.

For example:

Normal: 60 ms
Temporary increase: 120 ms
Sustained increase: 500 ms
No response: timeout

Different situations need different handling:

Reconnecting after one lost packet would make the protocol less stable.

Stage 18: Heartbeats and Health Checks

Even when there is no application data for a long time, the system needs to know whether the channel remains alive.

It can use:

PING
↓
PONG

Heartbeats cannot be too frequent.

Excessive frequency:

• wastes battery;

• consumes data;

• increases server load;

• creates a fixed timing characteristic.

Insufficient frequency:

• delays detection of a failed node;

• makes applications wait longer;

• slows recovery after a network change.

Heartbeat frequency can therefore adapt to state:

• when normal traffic is present, do not add heartbeats;

• after an idle period, begin low-frequency heartbeats;

• after a network change, temporarily increase checks;

• after repeated failures, mark the connection interrupted.

Stage 19: Network Changes and Session Recovery

When a phone moves from Wi-Fi to 5G, the original connection usually becomes invalid.

Complete handling should be:

Detect network change
        ↓
Stop sending new data through the failed channel
        ↓
Obtain new local IP and route
        ↓
Reconnect to the original node
        ↓
Submit session-recovery credential
        ↓
Server validates the old Session
        ↓
Recover recoverable logical Streams
        ↓
Tell applications to rebuild TCP connections that cannot be recovered

An important limitation:

Not every application TCP connection can be recovered seamlessly.

The protocol can recover:

• Session state;

• node authorization;

• protocol parameters;

• some Streams whose state remains valid.

But if the destination website’s own TCP connection has ended, the application may still need to reconnect.

It should therefore not be promoted as:

Every application will always experience a network change with no interruption.

A more accurate statement is:

SingLink 2.0 shortens reconnection time, restores protocol and routing state, and attempts to minimize application impact.

Stage 20: Node Failure and Automatic Switching

Node exceptions can be divided into:

Soft failure

• rising latency;

• occasional packet loss;

• temporary lack of response;

• some destinations unavailable.

Handling:

• wait briefly;

• reduce transport pressure;

• measure again;

• reconnect to the same node.

Hard failure

• node cannot be reached;

• authentication interface unavailable;

• sustained timeout;

• node removed from service.

Handling:

1. Stop using the original node.

2. Enable the Kill Switch.

3. Select an alternative from the available list.

4. Establish a new secure Session.

5. Restore DNS and routes.

6. Tell applications to rebuild necessary connections.

Production 2.0 can switch more conservatively so that brief jitter does not cause repeated node hopping.

Beta can reconnect or select high-speed nodes more aggressively, but this may produce greater variation.

Stage 21: Returning Data and Decapsulation

The destination website’s response follows this flow:

Destination website returns data
        ↓
SingLink node receives it
        ↓
Locate matching Session and Stream
        ↓
Encapsulate as SingLink data frame
        ↓
Encrypt and send to client
        ↓
Client verifies integrity
        ↓
Decrypt
        ↓
Demultiplex by Stream ID
        ↓
Write to TUN or system proxy
        ↓
Return to the originating application

The client needs to check:

• whether data was modified;

• whether sequence numbers are correct;

• whether the frame is a duplicate;

• whether the Stream still exists;

• whether length is within limits;

• whether the receive window was exceeded.

Invalid data must not be delivered directly to the application.

Stage 22: Normal Disconnect and Secure Cleanup

When a user selects Disconnect, the client should:

1. stop accepting new proxied traffic;

2. close active Streams normally;

3. send Session termination to the node;

4. erase session keys;

5. revoke or discard short-lived tokens;

6. close the TUN;

7. restore system routes;

8. restore DNS;

9. remove Kill Switch rules;

10. remove unnecessary temporary configuration.

If the client crashes, the operating system or next launch also needs a repair path to avoid leaving:

• an invalid system proxy;

• incorrect DNS;

• residual routes;

• no internet access;

• a permanently locked Kill Switch.

Detailed Strategy Differences Between SingLink Beta and 2.0

The following expresses product technical positioning; exact parameters still require engineering confirmation.

The Complete Processing Principle in One Paragraph

SingLink first has the client take control of device traffic and complete DNS processing, smart routing, and node selection. It then verifies account and node entitlement, negotiates protocol capabilities with the node, and establishes temporary encryption keys. After the connection is created, each application’s TCP and UDP traffic is encapsulated as an independent proxy connection or logical Stream and carried through a protected channel to the node, which accesses the destination website. During transfer, the system continually manages flow windows, data integrity, latency, packet loss, heartbeats, and node state. When the network changes or a node fails, it re-establishes the Session, restores routes, or switches to an available node.

The essential difference between Beta and 2.0 is:

SingLink Beta pursues peak speed more aggressively. SingLink 2.0 adds more complete compatibility, health checks, exception classification, session recovery, and cross-platform handling while retaining high-speed transfer, and therefore achieves higher stability.

Frequently Asked Questions

What is SingLink 2.0?

SingLink 2.0 is the official network transport protocol developed by SingLinkVPN. It handles identity verification, encrypted sessions, traffic encapsulation, TCP and UDP transport, health checks, and exception recovery.

Is SingLink 2.0 a software version?

No. SingLink 2.0 is the protocol’s official name. Windows, macOS, Android, and iOS client versions use a separate versioning system.

What is the difference between SingLink Beta and 2.0?

Beta is a speed-first preview protocol whose peak speed can exceed 1 Gbps under suitable conditions. 2.0 is the production protocol and emphasizes speed, stability, cross-platform compatibility, and disconnection recovery.

What is the stability rate of SingLink 2.0?

In SingLinkVPN’s internal A/B test under specified conditions, SingLink 2.0 reached 99.5% stability and Beta reached up to about 97%.

How does SingLink process network traffic?

The client first takes control of system traffic and performs DNS handling and smart routing. It then verifies account and node entitlement, establishes an encrypted Session, encapsulates TCP or UDP data, and sends it to a node.

How does SingLink handle disconnections?

The system continuously checks latency, packet loss, heartbeats, and node state. After an exception, it can re-establish a Session, restore routes, or switch to an available node.

How is SingLink different from VLESS?

VLESS primarily defines identity, commands, and destination forwarding. SingLink integrates identity, routing, node entitlement, transport policy, health checks, and exception recovery into a broader protocol system.

How is SingLink different from AnyTLS?

AnyTLS mainly carries a Session and multiple Streams over a TLS connection. SingLink has a broader product role that also includes smart routing, membership entitlement, node scheduling, and connection recovery. The actual Session and Stream implementation remains subject to official technical documentation.

Who can use SingLink 2.0?

Production SingLink 2.0 protocol nodes are currently mainly available to Pro, Max, and Rich users. The Beta protocol is open to all members. The latest client display is authoritative for actual access.

Is SingLink 2.0 fully open source?

The core protocol source is not yet fully public, but technical documents, test methods, data formats, validation tools, and the vulnerability-disclosure mechanism are part of the continuing open-source plan.

Sources and Further Reading

This article’s product positioning and public-scope statements also reference the official SingLinkVPN technology center, the May 2026 official milestone, the SingLinkLabs public research repository, and its performance benchmark methodology.

Related reading includes the complete SingLinkVPN Free Plan guide, the SingLinkVPN open-source plan, and the 2026 SingLinkVPN security audit report.

Technical note: The 99.5%, about 97%, and above-1-Gbps figures are respectively internal A/B stability results and peak-throughput results under specified conditions. They do not mean that every region, device, carrier, network, or time period will produce the same outcome. Specific encryption algorithms, packet formats, Session mechanics, and Stream mechanics remain subject to future official SingLink technical documents and published source code.