A successful honk build doesn't verify transparent proxying
Honk built in the recorded sandbox run, but the evidence does not establish packet interception. The README explicitly warns against production use. Honk is a candidate for controlled Linux networking experiments on a recoverable host, with management access that does not depend on the traffic path being changed.
Honk is an experimental transparent-proxy engine for Linux, written in Rust. Transparent proxying captures traffic through the network machinery rather than requiring each application to select a proxy. The README documents transparent TCP and UDP handling for LAN-forwarded and host-originated traffic through Linux eBPF hooks and compiled routing. Those capabilities were not verified by the sandbox results.
What happened when we ran it
The October 30, 2026 run used commit cdc3017. Installation succeeded in 30 seconds with 393 dependencies recorded. The build succeeded in 313 seconds. Tests failed with exit 101 after 400 seconds; the recorded aggregate reports 2,082 passed and 4 failed out of 2,086.
The visible log tail separately reports a library result of 1,493 passed, 4 failed and 3 ignored, followed by an instruction to rerun honk-core with --lib. That excerpt does not show the failing names or assertions, so it cannot establish their cause. The aggregate counts and the library summary describe different scopes and should not be substituted for each other.
The sandbox configuration lists 3 CPUs, 12 GB RAM and image lab-rust:1. The image label does not establish the actual Rust compiler or operating-system version. The checkout scan detected 6 CI workflow files, no Dockerfile and no tests directory. The Cargo output confirms that the directory observation does not mean the repository lacks tests.
These are installation, compilation and test results, not connectivity or throughput measurements. The build record does not identify whether the real eBPF datapath was enabled. The supplied README says plain cargo build --release does not enable it and --mock-ebpf does not intercept traffic or test the datapath. No additional execution is claimed here.
Check the host and recovery path first
The README requires root, Linux 6.12+, the required kernel options and bpffs for transparent proxying. The supplied startup guide also requires cgroup v2 with CONFIG_CGROUP_BPF and says older kernels are rejected before attachment.
The guide distinguishes traffic entering from a LAN from traffic originating on the gateway itself. Selecting both captures both categories. Real mode loads eBPF programs, attaches TC and cgroup hooks, creates network resources and changes sysctls. Keep the documented out-of-band management path available during initial deployment.
For an evaluation, follow the guide's direct-only configuration first and verify connectivity from a real LAN client before adding proxy nodes. Then exercise the direct and proxied TCP, UDP and DNS flows the deployment needs, including IPv4 and IPv6 where required. These are recommended next checks, not checks completed in the recorded run. The guide explicitly says a running process, an existing interface or a reachable API is insufficient evidence of a working traffic path.
Select the build for the interface you need
The documented full release includes the native API, the Clash-compatible API and embedded doona interfaces. The lean native-api and clash-api variants provide their respective API without an embedded UI. Archive selection therefore affects available controls as well as platform compatibility.
The startup guide says incompatible interface settings can fail startup in lean variants. For doona, check the native API and selected UI path. For a Clash dashboard, check the Clash-compatible interface. Neither the interface name nor familiar configuration syntax establishes that an existing deployment can migrate unchanged.
The README lists outbounds including SOCKS5 and Shadowsocks, plus direct and block actions, and documents DNS routing and caching. That list does not verify interoperability with a particular server configuration. It also explicitly excludes a FakeIP engine, full mihomo parity and a Windows/macOS datapath. Choose another candidate if any of those is a requirement.
A beta release does not remove the alpha warning
The supplied release listing shows v0.1.0-beta.4 as a prerelease, released on October 30. This is release-list evidence, not the identity of the measured checkout: the sandbox run is recorded at cdc3017.
The supplied latest-release lookup is null; it does not establish whether a stable release exists. The supplied issues listing includes an October 30, 2026 proposal to separate graceful restart from shutdown draining. That proposal does not establish implemented or verified recovery behavior.
The README still says early alpha and not recommended for production. It also warns that pre-1.0 minor releases may change configuration or behavior. Read the selected release's notes before upgrading and keep the working configuration recoverable. The supplied documentation is not pinned to cdc3017, so its capabilities and instructions should not be presented as exact-commit test findings.
Compare candidates against the required traffic path
dae documents traffic selection by local process name and LAN MAC address, using Linux eBPF. It is a relevant candidate when comparing that routing approach. Honk says it follows dae's datapath design and configuration syntax while remaining an independent implementation. Shared lineage does not establish a drop-in migration.
sing-box describes itself as a universal proxy platform. Consider it as a separate candidate when honk's documented limits rule honk out, then check the required capabilities in its documentation. The supplied sing-box extract does not establish which of those requirements it meets. No comparative speed or reliability result is available for either alternative.
Documentation receives 4/5 on the existing narrow editorial scale: 1 means no usable orientation, 3 means a documented path with gaps, and 5 requires independently verified coverage. The README and startup guide explain kernel prerequisites, build variants and mock-mode limits, but their instructions were not exercised in the recorded evaluation. This score assesses the supplied documentation, not setup success, compatibility or production readiness. Setup ease, community and maturity remain unassessed.
The next useful result is a controlled connectivity check on a compatible Linux host, with a verified way to recover management access.