Two transports carry TCP traffic from a SOCKS5 proxy
OpenFlux currently has 2 backends for the same tunnel shape. A client listens as a SOCKS5 proxy, TCP packets cross a transport, and an exit node reconstructs connections to their destinations. The Yandex backend uses cursor messages in a document. The MAX backend uses a WebRTC DataChannel and its messaging infrastructure for coordination. Applications see an ordinary proxy on port 1080, while the unusual part stays between the client and exit process.
The code is compact enough to study. Our measured checkout contained 36 files and about 3,077 lines of source, occupying 17.3 MB. The repository separates SOCKS5 handling, packet parsing, the tunnel, and provider code, with a Transport interface for another backend. That makes OpenFlux more interesting as a networking specimen than as a finished consumer product. Its own README calls it a research tool and restricts the stated use to machines and networks the user owns.
Root access and an OUTPUT rule change the whole exit host
The documented Linux exit node needs root because it works with raw sockets. Setup also adds an iptables rule that drops outbound TCP RST packets, then starts the binary against a Yandex document URL. Issue 27 points out that the shown rule has no source, port, or process condition, so unrelated services cannot send normal resets and closed ports appear filtered to scanners. The current main README still presents that host-wide command.
A separate network namespace, container, or dedicated egress address could narrow the blast radius, but OpenFlux does not package that isolation. Our checkout had no Dockerfile. The repository's instructions expect the operator to understand the firewall change and remove it correctly after the experiment. Running the exit node on a general-purpose VPS that also hosts SSH or web services is a bad default because the rule applies to the entire OUTPUT chain.
What happened when we ran it
Our sandbox installed OpenFlux at commit c2a512d in 43 seconds, with 160 packages installed. The build finished successfully in 38 seconds inside an unprivileged Debian container with 3 CPUs and 8 GB of RAM. This proves that the Go source built in our stated environment. It does not prove that raw-socket exit mode, the firewall rule, Yandex Docs, MAX, Android, or iOS worked there.
The test command returned success after 19 seconds, yet go test reported 0 passed and 0 failed out of 0. OpenFlux had no tests directory, no CI workflow files, and no Dockerfile. A green exit status therefore gives no coverage for packet checksums, reconnect behavior, SOCKS5 requests, or either remote transport. The build is a useful first check; treating the empty test result as transport validation would be misleading.
Current Yandex documents can reject the legacy protocol
OpenFlux says its Yandex transport supports only the legacy document editor. Issue 10 documents a current failure where public links returned OnlyOffice or Volga configuration, followed by WebSocket close code 1005. One commenter tested 5 URLs across 3 documents and concluded that changing the link, browser identity, or cookies did not restore the old protocol. Another reported a working result only after changing the transport for current OnlyOffice behavior.
The September 11 main branch did merge error handling for an unexpected Yandex document configuration, replacing a startup panic with a returned error and reconnect path. That is worthwhile, but it does not make the legacy wire protocol compatible with a newer editor. A buyer should obtain a known-working document and prove traffic in both directions before doing any wider setup. The README gives no fallback transport beyond MAX when Yandex changes the service again.
MAX may restrict the account used for transport
The README carries 5 direct warnings around MAX. It says to avoid a primary account, avoid any account whose loss matters, expect possible restrictions when using an external VPS, and understand that a restriction may remain after OpenFlux stops. It calls the backend experimental until the blocking mechanism is understood. Issue 25 supplied the report behind that warning, describing a restriction after use from a foreign VPS.
Authentication between tunnel peers is another unresolved concern. Issue 14 asks whether anyone with the document link can connect to the exit node and requests encryption. The owner answered that AES-GCM is intended, which means readers should not assume it exists in release 0.0.1. HTTPS or WebRTC protection between a process and the provider does not by itself document who may use the exit or what OpenFlux adds around the carried packets.
Release 0.0.1 has activity, not operating history
Release 0.0.1 was published September 10, 2026, and GitHub recorded another push on September 11. The repository had 968 stars and 23 combined open issues and pull requests when fetched. That is substantial attention for a project created on June 21, yet most issue traffic clustered around the first public release. Reports already cover Yandex compatibility, account safety, firewall scope, mobile packaging, and DNS behavior.
OpenFlux is worth reading if the goal is to understand how a small Go program moves TCP through an unlikely carrier. The 38-second build keeps that inspection cheap. Running it is a different decision: isolate the host, use a disposable account, inspect the packet path, and assume either provider can break the transport without notice. A conventional VPN is the better choice when reliability or confidentiality matters.