OnionHop V3 puts a Tor client behind a desktop GUI

A Tor client, not a browser, with two ways to route traffic

The problem is that Tor on the desktop is either a browser you use for everything or a daemon you configure by hand. OnionHop V3 is a native desktop application in C# that sits in between, and it makes two routing decisions for you. The project description is direct: a privacy-first desktop app that routes your traffic through Tor, and the README expands it as a modern cross-platform app for Windows, macOS and Linux that runs Tor either as a local SOCKS proxy or as a system-wide tunnel. The app also carries a disclaimer that it is provided as-is and that Tor usage can be illegal or restricted in some jurisdictions, with the responsibility for local law compliance placed on the user. The intended audience is a person on a restricted network who wants working Tor with a GUI, and the topic tags on the repository are limited to the project name itself.

Proxy mode needs no admin rights, TUN mode routes everything

The two modes are the first choice a user makes, and the README recommends the first one. Proxy Mode is marked as recommended and no admin, running Tor locally and pointing the OS system proxy at Tor's local SOCKS5 endpoint, with the best compatibility for proxy-aware apps. TUN and VPN Mode needs admin and does system-wide routing through sing-box, using Wintun on Windows and the system TUN on macOS and Linux, and it is described as needed for apps that ignore proxy settings, being leak-resistant with DNS through Tor and UDP blocked. The two mode descriptions in full are:

   - **Proxy Mode (recommended, no admin):** runs Tor locally and points the OS system proxy at Tor's local SOCKS5 endpoint. Best compatibility for proxy-aware apps.
   - **TUN/VPN Mode (admin):** system-wide routing via **sing-box** (Wintun on Windows, the system TUN on macOS/Linux); needed for apps that ignore proxy settings. Leak-resistant (DNS through Tor, UDP blocked).

That split has a consequence worth naming. Proxy mode leaves anything that ignores proxy settings unencrypted and reachable, and TUN mode closes that hole but hands the machine's routing to sing-box and asks for elevated rights every time you connect unless you enable the persistent admin helper, which is off by default.

Three Tor engines with different circuit shapes

The V3 rebuild added a choice of three engines, and this is the part that distinguishes it from a plain Tor GUI. Classic is tor.exe with full control, covering bridges, country and entry pinning, exit pinning and the control-port New Identity command. Arti is the Rust Tor implementation with native bridge and pluggable transport configuration. ArtiHop is the interesting one, described as shortened two-hop Guard to Exit circuits for lower latency, which trades the usual three-hop anonymity for a faster path. The README is clear about which features require which: country and relay pinning and control-port New Identity require the Classic engine, and while Arti and ArtiHop support OnionHop bridge and transport configuration, Classic remains the most complete choice for manual circuit control. That is a real trade-off a user has to make, since the engine that gives the most control is also the one with the most hops.

Smart Connect races strategies and remembers the winner

The connection engine is the other half of the V3 rewrite, and Smart Connect is described as an offline censorship brain that auto-picks the best connection strategy for your network and country. The mechanics it claims are specific: it knows where Tor is blocked, prefers transports that survive there, pre-tests bridge reachability, races strategies in parallel, fails fast off dead paths, and remembers what worked on each network so the next connect is instant. The offline part is the notable detail, since the decision logic does not need a call home to choose a transport. The alternatives to it are manual: you can pick a Tor engine, an exit location and bridges yourself, and in a censored network you can enable bridges or open the scanner to find ones that work in your region before clicking connect.

The bridge scanner tests reachability rather than guessing

Bridge configuration is the part of Tor that breaks in practice, because a bridge that is valid can still be unreachable from your network, and the list of bridges you were handed may all be blocked. The Bridge Scanner fetches and reachability-tests bridges of every transport, shows colour-coded latency, and offers one-click apply for the ones that actually work on your network. The transports it supports are obfs4, snowflake with optional AMP-cache fronting, webtunnel, conjure, meek and dnstt, the last being a DNS tunnel that gets Tor through when only DNS is allowed. On the source side there are several: the official Tor bridge service, the censorship-resistant OnionHop Bridges Collector derived from Delta-Kronecker's Tor-Bridges-Collector, built-in community bridges, and a thin-set top-up so that a tiny live fetch is automatically backed by bundled bridges.

Downloads come as installers, AppImages and a separate macOS build

There is no build step for an end user, the artefacts are published on the releases page. The Windows build is an installer called OnionHop-Setup-v3.exe that is self-contained with the .NET runtime bundled, alongside a portable zip that needs no install. Linux is an AppImage, and macOS is a signed and notarized universal dmg for Apple Silicon and Intel. The platform table also lists separate CLI packages, a Windows CLI setup or portable zip, a Linux tarball and two macOS tarballs for Apple Silicon and Intel. The macOS artefacts come from a dedicated code-signing repository, rana-gmbh/onionhopMac, and the README says the same for the CLI packages. The relevant rows are:

| **Windows** | `OnionHop-Setup-v3.exe` | Installer (self-contained, .NET runtime bundled) |
| **Windows** | `OnionHopV3-Portable-…win-x64.zip` | Portable, no install |
| **Linux** | `OnionHop-x86_64.AppImage` | `chmod +x` and run |
| **macOS** | `OnionHop-3.x-macOS.dmg` | Signed & notarized; universal (Apple Silicon + Intel) — from the [macOS repo](https://github.com/rana-gmbh/onionhopMac/releases/latest) |
| **Windows CLI** | `OnionHop-CLI-Setup-3.x.exe` / portable ZIP | Terminal interface |
| **Linux CLI** | `OnionHopCLI-…linux-x64.tar.gz` | Terminal interface |

A separate CLI package for each platform, plus a command line interface described as a full-featured TUI with a live status dashboard, connect, scan, bridges, snowflake and relays commands and settings persistence, built by CI on Windows, Linux and macOS.

Leak protection options, and a volunteer mode

The leak-related features are optional and clearly labelled as such. There is optional full DNS-over-Tor, a kill switch, UDP blocking in TUN mode, and an in-app WebRTC and UDP privacy notice. The kill switch is the piece that matters most in TUN mode, where the alternative to a tunnel is a bare SOCKS proxy that applications can route around. Two quality-of-life details are worth knowing: the system proxy toggle is decoupled, so you can turn the proxy off while Tor stays connected, and there is an opt-in persistent admin helper that skips repeat UAC prompts in TUN mode, which is off by default for the obvious reason. On the other side of the coin there is a volunteer mode, letting you act as a Snowflake proxy to help censored users reach Tor, straight from Settings.

A relay browser and a GPL-3.0 licence on a C# codebase

The V3 feature set also includes a relays browser, which searches the live Tor relay list by nickname, country, role, flags and bandwidth and lets you pin a preferred entry, middle or exit. That is the tool you need before country pinning becomes useful, since pinning without knowing which relays exist is guesswork. The project is licensed GPL-3.0 with the LICENSE file at the root, and the repository layout shows how it is built: an OnionHop/ directory for the application source, packaging/ and installer/ directories, a CHANGELOG.md, assets/ for the screenshots, and dependency fetch scripts for each platform in download-deps.sh, download-deps.ps1 and download-deps-macos.sh. The macOS build pipeline is separate from the application, which is a reminder that a desktop app with platform signing requirements accumulates build infrastructure around it.

Editorial conclusion

OnionHop V3 suits someone on a censored or restricted network who wants Tor without running the browser and without hand-editing a torrc, and who values the bridge scanner and the parallel strategy racing more than a minimal footprint. It does not suit a user who needs a full VPN that carries all traffic and UDP without elevated rights, because TUN mode is the only system-wide option and it requires administrator access. Before adopting, decide between proxy mode and TUN mode, check that the Classic engine is the one you need if you want country pinning and control-port New Identity, and note that the last push to the repository was on 2026-10-14 with release v3.9 on the same day.

Frequently asked questions

Official sources

1. center2055/OnionHop on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases