# mhrv-rs: a Rust DPI bypass that hides behind your own Google Apps Script

> A Rust port of MasterHttpRelayVPN that tunnels blocked traffic through a Google Apps Script you deploy in your own free Google account, with a CLI and an egui desktop UI. Here is how the relay works, how to set it up, and where the design breaks down.

**therealaleph/MasterHttpRelayVPN-RUST** — Rust port of @masterking32's MasterHttpRelayVPN — all credit to @masterking32 for the original idea and Python implementation. Free DPI bypass via a Google Apps Script relay with TLS SNI concealment. CLI + cross-platform desktop UI, HTTP + SOCKS5 proxy, no runtime deps.

- Repository: https://github.com/therealaleph/MasterHttpRelayVPN-RUST
- Website: https://github.com/masterking32/MasterHttpRelayVPN
- Stars: 3,592 · Forks: 542
- Language: Rust
- License: MIT
- Published: 2026-09-23 · Updated: 2026-09-23 · Language: en
- Canonical page: https://hysenlabs.com/projects/therealaleph-masterhttprelayvpn-rust

## The censorship problem mhrv-rs actually targets

Deep packet inspection does not need to break TLS to be effective. It only needs to see the Server Name Indication field in the ClientHello, which is sent in the clear, and then drop the connection. That is the mechanism mhrv-rs is built around. The README states the goal plainly: "Your ISP only sees encrypted traffic to www.google.com, it can't tell what you're really visiting." The project is aimed at users in networks where SNI-based blocking is the primary filter, with Iran named in the repository topics and Persian-language guides linked from the README.

The intended user is someone with a free Google account and a machine that can run a small binary. The README lists Mac, Windows, Linux, Android and OpenWRT as targets, and describes the download as a single file of roughly 3 MB with no Python, no Node.js and no dependencies. That constraint matters in practice: on a router or an older laptop, a runtime-free binary is the difference between something that runs and something that does not.

What this is not is a general-purpose VPN. The README's own diagram shows a proxy sitting between the browser and Google's network, not a tunnel that captures all system traffic by default. Applications have to be told to use it.

## How the Apps Script relay and SNI concealment fit together

The data flow has three legs. The client (mhrv-rs) accepts a local HTTP or SOCKS5 connection. It then opens an outbound TLS connection to Google's edge, where the SNI is www.google.com. Inside that connection, the request is addressed to the user's own Apps Script deployment. The Apps Script runs inside Google's network, fetches the real target site, and returns the response back down the same tunnel.

The README's diagram states this directly: the browser talks to mhrv-rs, the ISP sees www.google.com, Google's network carries the request to the user's Apps Script, and the Apps Script fetches the blocked site. The censorship filter never sees the real destination because it is inside the encrypted payload.

The build reflects this design. Cargo.toml declares tokio-rustls and rustls with the ring provider and tls12 enabled, plus webpki-roots for trust anchors and rcgen for certificate generation. The rcgen dependency lines up with the README's claim that a certificate is generated on the user's computer and never leaves it, which is what lets the browser trust the local proxy. The crate-type list (rlib, cdylib, staticlib) is not incidental: the comment in Cargo.toml says cdylib lets the Android app load libmhrv_rs.so through System.loadLibrary, and staticlib produces libmhrv_rs.a for the iOS NetworkExtension target.

The repository also ships several example configs beyond the basic one: config.direct.example.toml, config.exit-node.example.toml, config.fronting-groups.example.toml and config.full.example.toml. The presence of a fronting-groups config and an exit-node config indicates the relay can be chained or grouped rather than used as a single flat path. The README does not document those modes; only the example files exist in the repository listing.

## Installing mhrv-rs and getting one request through

Setup has two halves: the Google side and the local side. The Google side is a one-time job. Go to script.google.com, create a new project, delete the default code, and paste the contents of assets/apps_script/Code.gs from the repository. Near the top of that file is the line the README quotes:

```js
const AUTH_KEY = "CHANGE_ME_TO_A_STRONG_SECRET";
```

Replace the placeholder with a long random string and keep it, because it goes into the app later. Save, then Deploy, New deployment, choose Web app as the type, set Execute as to Me and Who has access to Anyone, and deploy. Google returns a Deployment ID, which is the second value you need. The README adds a maintenance note: if you edit Code.gs afterwards, use Deploy, Manage deployments, then set Version to New version rather than creating a new deployment, so the Deployment ID stays the same.

The local side starts with a download from the releases page. The README gives a table mapping platform to filename, including mhrv-rs-windows-amd64.zip, mhrv-rs-linux-amd64.tar.gz, mhrv-rs-macos-arm64-app.zip and mhrv-rs-android-universal-v*.apk. On Linux, a GLIBC error means you should take the musl build instead.

Unzip and launch with run.command on macOS, run.bat on Windows, or the shell script on Linux:

```bash
./run.sh
```

The first run asks for the computer password so it can install the locally generated certificate. The window then asks for the Apps Script ID (the Deployment ID) and the Auth key. Save config, then Start. The README says the status circle turns green on success, and there is a Test button that sends one request through the relay.

Finally, point a browser at the proxy. For Firefox, the README's steps end at HTTP Proxy 127.0.0.1 port 8085 with "Also use this proxy for HTTPS" checked. For Chrome or Edge it recommends the Proxy SwitchyOmega extension with the same address. On macOS the whole system can be pointed at 127.0.0.1:8085 through the Proxies panel.

## Where the design puts you at risk

The trust model is the first limitation, and it is worth stating without softening. Every request passes through a Google Apps Script running in your own account, inside Google's infrastructure. The README's claim is about what your ISP can see, not about what Google can see. If your threat model includes the relay operator observing traffic, this design does not address it, and no amount of local certificate generation changes that. The certificate protects the browser-to-local-proxy hop; it does nothing for the Google-side hop.

The second limitation is that this is a proxy, not a tunnel. The README's setup instructions are all about configuring Firefox, Chrome, or the macOS system proxy. Applications that ignore system proxy settings will not use it, and there is no mention of a TUN device or a transparent redirect. That puts it in a different category from tools that capture traffic at the network layer.

The third is the dependency on a third-party service you do not control. Google Apps Script quotas, deployment permission changes, or a policy shift on script.google.com would break the relay. The README does not document quota limits or fallback behaviour when the Apps Script is unreachable. The repository does include config.exit-node.example.toml and config.fronting-groups.example.toml, which suggests chaining is possible, but the README does not explain when to use them.

Finally, the Auth key is the only thing standing between your deployment and anyone who learns the Deployment ID. The README calls it a secret and tells you to treat it like a password. Note that the deployment is set to Who has access: Anyone, which is required for the relay to work without OAuth, so the key is doing real work.

## How mhrv-rs differs from the Python original and from a plain VPN

The README is explicit that this is a Rust port of @masterking32's MasterHttpRelayVPN, with all credit for the original idea and Python implementation going to the original author. The homepage field points at masterking32/MasterHttpRelayVPN. The practical difference is packaging: the Rust version ships as a single binary with no Python or Node.js runtime, and it adds a cross-platform desktop UI built on egui (the ui feature pulls in eframe, and the second binary target is mhrv-rs-ui). Cargo.toml shows the UI is behind a feature flag, so a headless build is the default.

The comparison to a conventional VPN is a different axis. A VPN moves your traffic to an exit server you or a provider operates, and the whole system follows it. mhrv-rs keeps traffic on your machine and forwards only what you point at it, through a relay that is a Google-hosted script rather than a rented VPS. That means no server to pay for, but also no control over the relay's availability, and no clean answer to the question of who can observe the traffic at the far end. The README's own framing, "bypass censorship for free, with your own Google account," is accurate about the trade being made: you are trading control for cost and for the cover of Google's address space.

## Licence, maintenance and the cost of upgrades

The project is MIT licensed, and Cargo.toml declares license = "MIT". MIT permits commercial and private use, modification and redistribution provided the copyright notice and permission notice are retained. That is a permissive arrangement, but it is worth noting that the project is a port of someone else's work, so anyone redistributing a modified build should keep both the original attribution and the licence text intact. This is not legal advice; read the LICENSE file in the repository before shipping a fork.

On maintenance, the last push was on 2026-09-01, and the most recent release, v1.9.37, is dated the same day. The two previous releases, v1.9.36 and v1.9.35, are dated 2026-05-28 and 2026-05-25. The repository is not archived. The gap between the May releases and the September release is roughly three months, so the cadence is not continuous, and there is no stated release policy in the README.

The upgrade cost is low on the client side: replace the binary. The Apps Script side is where the friction lives. The README warns that editing Code.gs should go through Deploy, Manage deployments, then Version: New version, because creating a new deployment changes the Deployment ID and forces you to re-enter it in the app. If you keep the version pinned and never update the script, the Apps Script half stays stable while the client half can be upgraded freely. That is the cheaper path, and it is the one the README's tip is steering you toward.

## Conclusion

mhrv-rs fits users who already have a free Google account, are comfortable pasting a Code.gs file into script.google.com, and want a single roughly 3 MB binary instead of a Python or Node runtime. It does not fit anyone whose threat model includes Google observing their traffic, or anyone who needs a stable long-lived tunnel rather than an HTTP or SOCKS5 proxy that each application must be pointed at manually. Before adopting it, verify three things: that your Apps Script deployment is set to Execute as Me and Who has access Anyone, that the Auth key in Code.gs matches the Auth key in the app, and that the Test button returns success. If the Test button fails, the problem is almost always one of those three, not the binary.

## FAQ

### What is mhrv-rs and how is it different from the original MasterHttpRelayVPN?

mhrv-rs is a Rust port of @masterking32's MasterHttpRelayVPN, which the README credits as the original idea and Python implementation. The Rust version ships as a single roughly 3 MB binary with no Python or Node.js runtime, and adds a cross-platform desktop UI behind the ui feature flag.

### Does mhrv-rs work on Android and Windows?

The README lists Mac, Windows, Linux, Android and OpenWRT as supported targets, with separate downloads including mhrv-rs-windows-amd64.zip and mhrv-rs-android-universal-v*.apk. Cargo.toml notes that the cdylib crate type exists so the Android app can load libmhrv_rs.so through System.loadLibrary.

### Which proxy address and port does mhrv-rs use?

The README's browser setup instructions point Firefox at HTTP Proxy 127.0.0.1 port 8085 with "Also use this proxy for HTTPS" checked, and give the same address for the Proxy SwitchyOmega extension on Chrome or Edge. The macOS system proxy instructions also use 127.0.0.1:8085.

## Sources

- [License: MIT](https://github.com/therealaleph/MasterHttpRelayVPN-RUST/blob/main/LICENSE)
- [Project website](https://github.com/masterking32/MasterHttpRelayVPN)
- [README](https://github.com/therealaleph/MasterHttpRelayVPN-RUST/blob/main/README.md)
- [Releases](https://github.com/therealaleph/MasterHttpRelayVPN-RUST/releases)
- [therealaleph/MasterHttpRelayVPN-RUST on GitHub](https://github.com/therealaleph/MasterHttpRelayVPN-RUST)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/therealaleph-masterhttprelayvpn-rust