SingLink Protocol Technical Whitepaper

The client obtains the available packages, nodes and protocol permissions of the current account. Authentication credentials should be short-lived, revocable, and decoupled from subsequent data forwarding status.

The control plane returns the node address, port, available protocols and necessary policies, and should not directly deliver long-term master keys or unnecessary sensitive fields to the client.

The client receives the traffic that needs to be processed through TUN mode, system proxy or platform network extension. The specific entrance depends on the capabilities of the operating system.

Consistent policies must be used for DNS requests and subsequent connections to avoid domain names going through proxies while DNS is still leaking from the local network or causing erroneous diversion.

Determines connections as direct, proxy, or blocked based on rules, application, target domain name, IP, and network status.

The manual mode uses user-specified nodes; the intelligent mode can select candidate nodes based on latency, availability, load, region and package permissions.

The client and server confirm the protocol generations and capabilities supported by both parties. The old client should not silently enable incompatible behaviors when it cannot recognize new capabilities.

Nodes verify that the account or session is valid and should prevent old authentication data from being reused through aging, randomization, or equivalent mechanisms.

The protocol requires establishing a separate encryption context for the current connection. The specific cipher suites, handshake fields and rotation periods must be subject to future public specifications.

Session represents the transmission session between the client and the node, which can carry connection status, capability information, heartbeats, and one or more logical flows.

Each application request can be mapped to a logical Stream within the Session, or an independent connection can be established; the final method depends on the public implementation.

Destination information, stream identification, payload length, control commands, and data are required to form a parsable frame; this page does not invent undocumented binary fields.

TCP byte streams need to maintain order, handle half-closes and abnormal closes, and pass application-side backpressure to the transport side.

UDP datagrams need to retain message boundaries and manage session timeouts; UDP-type services such as QUIC also need to avoid unnecessary head-of-line blocking.

When the consumption speed of the client, node or target service slows down, the buffer growth should be limited to prevent a single Stream from bringing down the entire Session.

Packetization and padding can only be used as part of the transmission strategy and cannot be described as absolute stealth; its enabling conditions and overhead require testing and verification.

Tunnel overhead will reduce the available MTU, and large packet failures need to be reduced through fragmentation avoidance, MSS adjustment, or equivalent mechanisms.

The protocol should control the sending rhythm and retransmission based on network feedback, and distinguish between real packet loss, queuing delay and short-term network jitter.

Continuously monitor session and node status to avoid relying solely on the operating system's long timeouts to detect dead connections.

After switching between Wi-Fi and mobile networks, the client re-confirms the network entrance, DNS, routing and transmission sessions, and resumes the connection according to its capabilities.

In the case of a soft failure, the session can be rebuilt first, and in the case of a hard failure, available nodes can be switched. During the switching process, system routing must be restored and traffic should be avoided from unexpected direct connections.

The client verifies and decapsulates the returned data, and clears temporary session status, cache keys, routing and DNS changes after the connection is completed.