erebe/wstunnel

This system is a high-performance tunneling service that encapsulates various network protocols, including TCP, UDP, and SOCKS5, into secure transport layers such as WebSocket, HTTP/2, and WebTransport. It provides robust infrastructure for managing connections through features like mutual TLS authentication, dynamic restriction reloading, and encrypted DNS resolution. The tool supports both client and server roles, enabling the creation of reverse tunnels and local listeners while optimizing performance via connection pooling and modern Rust networking libraries.

16 changes.

The project expanded its tunneling capabilities by introducing WebTransport and HTTP/2 as new transport protocols alongside existing WebSocket support. This period also involved significant architectural refactoring, including modularizing DNS, TLS, and restriction logic, while adding features like mTLS development infrastructure and dynamic configuration reloading.

4 changes.

This period focused on introducing WebTransport as a new tunnel transport option, leveraging HTTP/3 over QUIC for lower latency and improved multiplexing. The work also involved implementing connection pooling for both WebTransport and TCP transports to enhance resource efficiency and reduce handshake latency. Additionally, downstream listeners were refactored into a unified trait-based architecture to standardize connection handling across protocols, and a benchmarking script was added to measure performance.

Users can now establish tunnels using HTTP/2 and WebTransport protocols in addition to the existing WebSocket support. This change introduces new transport implementations (\http2.rs\, \webtransport.rs\) and updates the core transport abstractions (\io.rs\, \types.rs\) to handle these protocols, including specific configuration for HTTP/2 headers and WebTransport over QUIC. The \TransportScheme\ enum now includes \Http\, \Https\, and \Wts\ (WebTransport) variants, allowing clients to select these newer transport methods for potentially improved performance or compatibility in restricted network environments.

wstunnel/src/tunnel/transport · high confidence

Users can now establish tunnels using the WebTransport protocol, which leverages HTTP/3 over QUIC for lower latency and improved multiplexing compared to existing WebSocket or HTTP/2 transports. This new transport module includes a dedicated client implementation that manages QUIC endpoints, handles session pooling, and supports dynamic reverse tunnels via JWT-based stream preambles. It also features optimized read/write paths using vectored I/O and buffer pooling to improve throughput, along with specific fixes for IPv4/IPv6 compatibility on BSD operating systems.

wstunnel/src/tunnel/transport/webtransport · high confidence

A new \scripts/bench.sh\ script has been added to allow users to benchmark wstunnel transport performance end-to-end. The script supports measuring throughput, CPU usage, and memory consumption across various transports (wts, wss, ws, https, http) using iperf3, and includes options for profiling with perf and dhat-heap.

scripts · high confidence

The repository now includes a complete set of mTLS (mutual TLS) certificates and configuration files for local development under \certs/mTLS\. This addition provides a self-signed Root CA, along with corresponding server and client certificates and private keys, enabling secure, mutually authenticated WebSocket tunneling during development without requiring external certificate authorities.

certs · high confidence

This change establishes the foundational repository structure for the wstunnel project, introducing essential build and release tooling. It adds a multi-stage Dockerfile for containerized builds, a .goreleaser.yaml configuration to manage binary releases across multiple operating systems and architectures (including Linux, macOS, Windows, FreeBSD, and Android), and a helper script to map Go build targets to Rust artifacts. Additionally, it provides developer convenience files such as a justfile and mise.toml for running tests and linters, configuration files for Rust formatting (rustfmt.toml) and TOML linting (taplo.toml), and documentation files including CONTRIBUTING.md, SECURITY.md, and a comprehensive README.md detailing usage, command-line options, and supported protocols.

(repo-wide) · high confidence

Adds a new UDP protocol implementation to wstunnel, exposing types like UdpStream and UdpStreamWriter along with server-side logic for handling UDP connections. This enables users to tunnel UDP traffic over WebSocket connections, expanding the tunnel's capabilities beyond TCP.

wstunnel/src/protocols/udp · high confidence

The client now uses a pooled connection model for both WebTransport (wts://) and standard TCP-based transports (ws, wss, http, https). A new \L4StreamManager\ manages the lifecycle of these connections, establishing WebTransport sessions via QUIC/HTTP-3 or TCP/TLS streams as needed. This allows multiple tunnels to share a single underlying connection, improving resource efficiency and reducing handshake latency for subsequent tunnel requests.

_wstunnel/src/tunnel/client/connection\pool · high confidence

The client module now supports the WebTransport protocol (Wts scheme) in addition to existing WebSocket and HTTP/2 transports. The \Client\ struct manages connections via a pooled \L4StreamManager\ and routes traffic through \TransportReader\/\TransportWriter\ wrappers that handle WebTransport-specific logic, including UDP packet boundary preservation. Configuration is extended with a \webtransport\ field in \ClientConfig\ to hold the QUIC endpoint, enabling users to establish tunnels over WebTransport.

wstunnel/src/tunnel/client · high confidence

A new \wstunnel/src/protocols/dns\ module has been added, introducing a \DnsResolver\ abstraction that allows users to configure custom DNS resolvers via URLs. This change enables DNS over HTTPS (\dns+https\) and DNS over TLS (\dns+tls\) by parsing resolver URLs, extracting SNI parameters, and configuring the underlying \hickory\_resolver\ library. The module also includes logic to sort IPv4/IPv6 addresses according to RFC8305 and handles platform-specific optimizations, such as cache size adjustments for Windows. This provides users with greater control over DNS resolution, particularly in environments requiring encrypted DNS queries or specific resolver configurations.

wstunnel/src/protocols/dns · high confidence

A new TCP protocol module has been introduced, providing the core networking logic for establishing TCP connections. This implementation supports dual-stack connectivity (IPv4 and IPv6) by attempting connections to all resolved addresses concurrently, with staggered delays as per RFC8305 to optimize connection times. It includes configurable socket options such as TCP\_NODELAY, platform-specific TCP keepalive settings, and SO\_MARK support for traffic marking. Additionally, it features an HTTP proxy connector that handles CONNECT requests, including Basic authentication for proxies requiring credentials.

wstunnel/src/protocols/tcp · high confidence

The server now supports WebTransport (HTTP/3 over QUIC) as a transport protocol, allowing clients to establish tunnels over UDP with mandatory TLS 1.3. This is implemented via a new \handler\_webtransport.rs\ module that manages QUIC endpoints, certificate reloading, and session handling. Additionally, a new \handler\_http2.rs\ module has been added to handle HTTP/2 server upgrades, enabling tunneling over HTTP/2 connections alongside the existing WebSocket support. The server module (\mod.rs\) now exports these new handlers, and the main \server.rs\ integrates them into the request handling flow.

wstunnel/src/tunnel/server · high confidence

The tunnel module now automatically detects and reloads TLS certificates and private keys when they change on disk, ensuring that certificate renewals (including those that replace files via symlinks) are applied without restarting the service. Additionally, system CA certificates are periodically reloaded in the background to keep the trusted root store up to date.

wstunnel/src/tunnel · high confidence

The HTTP proxy implementation has been updated to handle authentication for regular HTTP requests, not just CONNECT tunnels. Users can now configure credentials (username/password) which are validated via the Proxy-Authorization header for both standard HTTP methods and CONNECT requests. Additionally, the proxy now supports non-HTTP CONNECT methods for non-TLS connections, allowing it to forward regular HTTP traffic directly rather than requiring a tunnel setup for all requests.

_wstunnel/src/protocols/http\proxy · high confidence

The wstunnel-cli now features a new main.rs entry point that allows users to configure the number of Tokio worker threads via the --nb-worker-threads flag (or TOKIO\_WORKER\_THREADS env var), disable colored log output with --no-color (or NO\_COLOR env var), and adjust log verbosity via --log-lvl (or RUST\_LOG env var). The CLI also integrates a system CA certificate reloader and optionally uses Jemalloc for memory allocation when the jemalloc feature is enabled.

wstunnel-cli · high confidence

The downstream listener implementations for TCP, UDP, HTTP proxy, SOCKS5, stdio, and Unix sockets have been refactored to implement a new \DownstreamListener\ trait with explicit \DownstreamRead\ and \DownstreamWrite\ interfaces. This change standardizes how local connections are exposed to the tunnel core, ensuring consistent handling of connection streams and remote address metadata across all supported protocols. The refactoring also introduces a \DownstreamWrite\ trait that allows specific protocols (like SOCKS5) to defer connection acknowledgments until the tunnel is confirmed ready, while others use a no-op default.

_wstunnel/src/tunnel/downstream\listeners · high confidence

The restrictions logic has been restructured into a dedicated module with a new \RestrictionsRulesReloader\ that watches a configuration file for changes and automatically reloads rules without restarting the service. The underlying data types now explicitly define separate allow configurations for standard tunnels and reverse tunnels, introducing specific fields for reverse tunnel constraints such as \unix\_path\ and \port\_mapping\. This change enables more granular control over reverse tunnel access, including the ability to restrict connections by Unix socket path, while maintaining the existing capability to reload restriction rules dynamically via file system events.

wstunnel/src/restrictions · high confidence

The SOCKS5 implementation in wstunnel has been refactored to ensure that TCP connections are not acknowledged to the client until the underlying tunnel is confirmed to be established. Previously, the server might have replied to the SOCKS5 handshake before knowing if the remote tunnel could be created; now, the write half holds the connection state (\TcpPending\) and only sends the success or error reply via \on\_tunnel\_ready\ once the tunnel outcome is known. This prevents clients from attempting to send data over a tunnel that has already failed to initialize. Additionally, a 10-second timeout is enforced on the initial SOCKS5 handshake to prevent idle clients from blocking the accept loop.

wstunnel/src/protocols/socks5 · high confidence

The TLS connection and server configuration logic has been extracted from the existing protocol implementation into a new, dedicated \wstunnel/src/protocols/tls\ module. This change introduces a \server.rs\ file that centralizes the creation of TLS connectors and acceptors, including support for mTLS, ECH (Encrypted Client Hello), and QUIC-specific TLS 1.3 configurations, alongside a \utils.rs\ file for certificate parsing utilities. This reorganization improves code clarity and maintainability by isolating TLS-specific concerns from the broader tunneling logic.

wstunnel/src/protocols/tls · high confidence

The wstunnel source code has been reorganized into a modular library structure, introducing a new WebTransport (WTS) transport protocol alongside existing WebSocket and HTTP transports. This update adds support for reverse Unix-domain tunnels, allows restricting reverse tunnels, and improves Socks5 client handling by waiting for tunnel establishment. Configuration options now include ECH (Encrypted Client Hello) support, HTTP upgrade path customization, and self-signed certificate validity extended to 2027. The executor trait has been refactored for better performance, and the library exposes public types like HeaderName and HeaderValue for easier integration.

wstunnel/src · high confidence

The project has been updated to use the Rust 2024 edition and upgraded to Hyper 1.x (specifically hyper 1.11.1 and hyper-util 0.1.20). This change affects the underlying HTTP handling and requires a corresponding update to the Cargo.lock file to resolve the new dependency tree.

(dependencies) · high confidence

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

• CAI 53 → 58 (+4.8)
• Rubric changed (rubric-2026.09.9 → rubric-2026.09.18) — scores are not directly comparable.

• Code Health 94 → 94 (+0.0)
• Architecture 100 → 86 (-13.6)
• Maturity 55 → 55 (-0.0)
• Readiness 43 → 49 (+5.3)
• Security 46 → 61 (+15.4)
• Performance 100 (new)

• Documentation: no architecture or design documentation (README.md)
• Documentation: no installation or build instructions (README.md)
• Documentation: no usage examples (README.md)
• Duplicated block (11–12 lines × 2) (wstunnel/src/lib.rs)

• Duplicate intent across transport modules. Both http2 and websocket modules expose a connect function with identical signatures and likely similar internal logic (establishing a tunnel connection). This suggests a lack of a unified Transport trait or factory pattern, forcing users to import specific transport modules to connect.
• Duplicated block (11–12 lines × 2) (wstunnel/src/lib.rs)
• Inconsistent method naming for proxy support. connect is the primary method, but connect_with_http_proxy is a separate method. This breaks the expectation that proxy configuration would be part of the RemoteAddr or a context object, or that a single connect method would handle proxy logic internally. It forces users to know whether to use the proxy variant based on external state not visible in the signature's primary argument.
• Inconsistent naming for bidirectional data flow. propagate_local_to_remote and propagate_remote_to_local are verbose and asymmetric in naming convention compared to standard Rust idioms like forward or copy. While distinct, they represent the same logical operation (data forwarding) in opposite directions. The verb 'propagate' is also less standard than 'forward' or 'relay' for I/O streams.
• Low cohesion: L4Stream (LCOM4 6) (wstunnel/src/tunnel/client/connection_pool/l4_stream.rs)
• Off the main sequence: wstunnel
• Outdated: hyper-util
• Outdated: tokio-rustls
• Projects may be oversized for their cohesion
• Redundant entry points with confusing semantic distinction. run_client and create_client appear to perform the same high-level operation (initializing a client), but differ in the executor type consumed (TokioExecutor vs TokioExecutorRef) and likely in lifecycle management (run vs create). This forces users to guess which function to use based on subtle executor trait differences rather than clear operational intent.

• 14 commits — 10 feature/other, 4 fixes

• wstunnel/src — 6 commits
• (root) — 5 commits
• .github/workflows — 2 commits
• wstunnel-cli/Cargo.toml — 1 commit

• fix: fix(revere-tunnel): force reconnect on idle reverse tunnel
• fix: fix(tcp-listener): configure the tcp socket to have TCP_NO_DELAY
• fix: fix(webtransport): Reload restriction on new stream
• fix: fix: Don't use IPv4 mapped IPv6 on BSD like OS
• change: Bump version v11.0.0
• change: Bump version v11.0.0
• change: Revise README for improved documentation and examples
• change: Revise security support information and reporting method
• change: Update Android SDK setup in release workflow
• change: Upgrade Android SDK setup action to v4
• change: bump
• change: bumps deps
• change: chore(webtransport): improve read throughput
• change: reverse-tunnel: speedup dispatch of reverse tunnel

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

erebe/wstunnel was measured the same way every project in this corpus was: the same rubric, at a pinned commit, with the result published in full. Point a surveyor at a repository you know and see whether you agree with it.