Overview

This trace follows an OpenFlux HTTPS connection from SOCKS5 negotiation through IPv4/TCP state, wrapper transformation, carrier delivery, exit forwarding, and the return path. It distinguishes local acceptance from remote progress and maps shared symptoms—stalls, resets, timeouts, rejected frames—to the state owner that can explain them.

Learning outcomes

A proxy reply or queue admission acknowledges local work, not destination delivery.
The same timeout can arise from unsupported traffic, wrapper rejection, carrier state, exit-host interference, or the destination.
A working page demonstrates one aligned path, not universal protocol coverage, anonymity, or durable availability.

Keywords

OpenFluxTraceSOCKS5TCPDiagnosticsLifecycle

One Connection, Traced End to End

OpenFlux becomes easiest to judge when one connection is followed across every boundary instead of when its components are considered separately. This checkpoint connects the application entry point, userspace TCP stack, wrappers, carrier, exit node, and destination, then uses the same trace to explain why a page can fail for several unrelated reasons. The practical outcome is a reusable diagnostic model: identify who owns the state that stopped moving before blaming the carrier.

One request crosses several kinds of state

Take a browser that wants to open an HTTPS site through OpenFlux. The browser first connects to the local SOCKS5 listener and asks for a TCP CONNECT to the site’s host and port. At this point, the relevant state is a proxy negotiation and an application-facing stream. The browser does not know which service will carry the connection, and OpenFlux has not yet sent an Internet packet.

The SOCKS5 server accepts the no-auth method, parses the target, and asks the tunnel to dial it. If the target is a domain name, the client-side resolver must produce an IPv4 address that the tunnel can use. If the request uses an unsupported SOCKS5 command or resolves only to IPv6, the flow stops here. The carrier is not involved, so changing from one carrier to another cannot fix this particular failure.

After a successful dial, the browser receives the proxy’s success response and begins its own HTTPS exchange. OpenFlux’s userspace TCP stack now owns the connection behind the proxy. It tracks the TCP state that the browser expects while emitting IPv4/TCP packets through its custom link endpoint. The endpoint hands those packets to the outer transport pipeline rather than to an ordinary host socket.

The wrapper path then determines the representation that leaves the client. Compression may keep a small payload raw or encode a larger beneficial payload. If encryption is enabled, the compressed representation is authenticated and encrypted with the directional key for that side. The selected carrier receives the resulting byte payload, along with whatever framing its own service protocol requires. The carrier is carrying the packet representation; it is not terminating the browser’s TLS session.

sequenceDiagram participant App as Browser participant Proxy as SOCKS5 proxy participant Stack as Client TCP stack participant Edge as Packet boundary participant Wrap as Wrapper layers participant Carrier as Selected carrier participant Exit as Exit node participant Site as Destination App->>Proxy: CONNECT host and port Proxy->>Stack: Dial TCP after resolution Stack->>Edge: Emit IPv4/TCP packet Edge->>Wrap: Packet bytes Wrap->>Carrier: Compress then encrypt if enabled Carrier->>Exit: Deliver carried bytes Exit->>Site: Forward TCP packet Site-->>Exit: Return TCP packet Exit-->>Carrier: Send response packet Carrier-->>Wrap: Deliver carrier payload Wrap-->>Edge: Decrypt then decompress Edge-->>Stack: Inject inbound packet Stack-->>Proxy: Deliver stream bytes Proxy-->>App: Return HTTPS data

At the exit node, the carried bytes are injected into the tunnel-side userspace stack.

Published by DeepMox

FAQ

How does OpenFlux’s trace identify which layer failed?

It identifies the layer by checking where progress stops: proxy entry, address resolution, userspace stack, wrapper, carrier queue, exit host, or destination. Each boundary owns different state, so a carrier reconnect is not a universal remedy.

What does a transport send mean in an OpenFlux trace?

It may mean only that packet bytes entered a local queue or inner adapter; it does not confirm exit-side acceptance or destination delivery.

Why can the same stalled page have different causes in OpenFlux?

Unsupported protocols, protection failures, queue delays, kernel resets, and destination behavior can all surface as a timeout or stalled page. The visible symptom must be paired with boundary-specific evidence.

Previous12 minOpenFlux: Transport Contract Limits

Next11 minOpenFlux: Yandex Docs Transport

OpenFlux: End-to-End Connection Trace

One Connection, Traced End to End

One request crosses several kinds of state

FAQ