What the sandbox results establish
Our run took place on 2026-09-21 at commit 9bbeecf37bcc6509057c22958a6c2406a5ad40b2. The recorded install stage took 107 seconds, the build stage took 43 seconds, and the test stage took 233 seconds. All three stages recorded success, exit code 0 and no timeout.
The stored parser summary reports 64 passed, 0 failed and 64 total. The matching raw record labels these as package outcomes: 64 packages OK, 0 packages failed and 9 packages with no test files. This does not establish 64 individual tests or exhaustive unique coverage. The supplied output repeats package results under a summary marker; those lines must not be added together. Packages with no test files are not failed tests. Skipped-test counts are unknown.
The build tail records vet-exit:0. The install log records a Go 1.26.0 toolchain download, so this run does not demonstrate compilation with Go 1.24. Neither successful repository commands nor a package named e2e establishes that the harness deployed a working tunnel across two VPS hosts.
The run did not measure tunnel throughput, packet loss, latency, filtering resistance or production recovery. No audit result or scanned-package coverage is supplied, so security scan coverage is unknown. The MrKeyoor testing methodology explains how command outcomes and parsed counts reach reviews. That page was retrieved on 2026-10-31; it does not establish which methodology version governed this September run. No new execution was performed for this correction.
Decide from the route and server roles
The commit-pinned README describes reverse forwarding, direct connections and a full IP tunnel. In the reverse arrangement, the overseas server dials the Iran server. Users connect to forwarded ports on the Iran server, and the overseas side sends that traffic to the real service.
The current README describes the direct wizard as creating a private network interface between the machines and carrying complete IP packets. These are documented capabilities, not deployment results from the sandbox.
Transport counts need a version attached. The measured commit's README advertises thirteen choices; the current README describes twelve reverse-tunnel transports and discusses direct carriers separately. Neither count demonstrates how many transports the run exercised.
Check credential protection before tuning
Plain TCP, TCP Mux, UDP, WS and WS Mux do not encrypt the tunnel credential at the transport layer. The current README states this limitation explicitly and lists encrypted options separately. Treat credential protection as a selection requirement before comparing carrier behavior.
Forwarded UDP is separate from the carrier. Choosing a UDP-based transport does not by itself enable UDP on forwarded service ports. The current documentation says forwarding uses TCP by default and requires a per-tunnel UDP setting.
For a trial, first confirm which host accepts the tunnel connection, where users connect and which backend receives their traffic. Then check the token, transport and firewall configuration on both ends. Test the required application traffic and a recovery procedure before depending on the link. These are recommended acceptance checks; the recorded run did not perform them.
Verify recovery behavior on the deployment
The current README documents health checks, route diagnostics, transport fallback, backups and rollback. It says the update flow verifies downloaded release archives against published SHA-256 checksums. These controls give operators reasons to evaluate BackPack, but the command results do not verify their behavior during a live outage.
The v1.8.1 release notes list fixes for memory and socket leaks, reconnect behavior, occupied forwarded ports and layer-3 tunnels that completed handshakes without carrying traffic. Those are maintainer-reported fixes. They do not prove that the measured commit is free of similar faults.
The current README identifies AGPL-3.0 and states attribution and branding conditions. Review those terms before modifying or redistributing the project.
When frp or rathole fits the job
frp exposes services behind NAT or a firewall and supports TCP, UDP, HTTP and HTTPS. Its README also documents KCP, QUIC, monitoring and health checks. Consider frp as a replacement candidate when exposing internal services is the main requirement; compare the specific configuration you need.
rathole exposes a service behind NAT through a server with a public IP. Its README documents optional Noise encryption and TLS. Consider rathole as a replacement candidate when its service-based client and server configuration matches the deployment. Its published performance discussion warns that loopback benchmarks do not imply the same gains on a network-limited route. Neither alternative was benchmarked against BackPack in the supplied run.
These alternatives can replace the forwarding component for suitable requirements. Their supplied documentation does not establish equivalent Iran-route behavior or a replacement for every BackPack management feature.
How to read the ratings
The numeric ratings are editorial judgments, not measured performance or adoption scores. The scale is 1 for major documented obstacles, 2 for substantial constraints, 3 for a workable option requiring operator judgment, 4 for strong supporting evidence with identified limits, and 5 for comprehensive evidence across the dimension. An unassessed dimension has no numeric rating.
Setup ease is 3/5: the documented installer helps, but two-host configuration, privileges and firewall work remain. Documentation is 4/5: the supplied README gives concrete roles, credential, forwarding and recovery guidance, although current documentation must be distinguished from the measured checkout. Community is unassessed: the supplied primary extracts do not corroborate the earlier star-count, response-speed or pull-request-age rationale. Maturity is 3/5: repository commands completed, while operational reliability was not tested and the release notes document consequential fixes.