Adds end-to-end UDP support: SOCKS5 client UDP ASSOCIATE → tunnel-mux
udp_open/udp_data ops → tunnel-node UDP sessions → real UDP to upstream.
QUIC/HTTP3, DNS, and STUN now traverse full mode without falling back to
TCP or leaking outside the tunnel.
Apps Script proxies the new ops opaquely through the existing batch
endpoint; CodeFull.gs only gets a doc-comment update.
Highlights:
- proxy_server.rs: SOCKS5 UDP ASSOCIATE handler with per-session task,
bounded uplink mpsc channel, adaptive empty-poll backoff (500 ms → 30 s),
source-IP validation against the control TCP peer, port-locking on
first valid datagram, and self-removal from the dispatch map on eof.
- tunnel_client.rs: UdpOpen / UdpData / close_session mux variants
alongside the existing TCP plumbing; pkts decoder helper.
- tunnel-node: UdpSessionInner with bounded VecDeque queue, drop-oldest
on overflow with queue_drops counter and warn-then-throttled logs,
last_active refreshed only on real activity (uplink send or upstream
recv — empty polls do not refresh), independent TCP/UDP drain in
handle_batch Phase 2, separate active-drain (150 ms) and retry
(250 ms) windows for UDP, idle long-poll (5 s).
- Tests: SOCKS5 UDP packet parser (IPv4/IPv6/DOMAIN round-trips,
truncation rejects, fragmented rejects), UDP queue overflow drop +
counter, regression test that batch with both UDP and TCP-data ops
still runs the TCP retry pass.
Docs: README + android.{md,fa.md} updated to reflect UDP availability
in full mode; tunnel-node/README documents the new ops.
New config field `passthrough_hosts: Vec<String>` that lists hostnames
which should bypass Apps Script relay entirely and pass through as
plain TCP (via upstream_socks5 if set). Applies across all modes —
apps_script, google_only, and full — because it expresses user intent
("never relay this host") that should win over the default routing.
Matching rules:
- Exact: "example.com" matches only example.com
- Suffix: ".example.com" matches example.com AND any subdomain
- Case-insensitive; trailing dots normalized
- Empty / whitespace-only entries are ignored
Dispatch order is now:
0. passthrough_hosts ← new, highest priority
1. Mode::Full → batch tunnel
2. SNI-rewrite → direct Google edge
3. Mode::GoogleOnly → plain-tcp
4. Mode::AppsScript → peek + MITM/relay/plain-tcp
Wired through:
- src/config.rs: new Config field with serde default
- src/proxy_server.rs: RewriteCtx.passthrough_hosts + matches_passthrough()
helper + dispatch check as step 0 + 5 new unit tests
- src/bin/ui.rs: FormState + ConfigWire round-trip so the desktop UI
preserves user entries across save/load
Android ConfigStore.kt wiring and a UI editor will land in a follow-up.
80 tests pass (75 → 80 with the new passthrough match tests).
Adds a new `mode: full` that tunnels ALL traffic end-to-end through Apps Script → a remote tunnel node. Browser does TLS directly with the destination. No MITM, no CA installation needed on the client device.
Ships as part of the 3-PR series: #93 (tunnel-node service + CodeFull.gs, merged) + this (Rust-side Mode::Full + batch tunnel client) + #95 (Android UI dropdown, now rolled into this PR post-rebase).
### Architecture
- Client → mhrv-rs → script.google.com (Apps Script fetch) → tunnel-node on user's VPS → real destination
- Apps Script is the transport to reach the VPS; works even when the ISP blocks direct VPS IPs
- Batch multiplexer collects data from all active sessions and ships one Apps Script request per tick
### Safety properties of this merge
- AppsScript + GoogleOnly dispatch paths are **unchanged**; Full mode is an additive branch at the top of `dispatch_tunnel`.
- `tunnel_client.rs` is a new isolated module (387 LOC).
- `tunnel_request()` is a new method on `DomainFronter`, no change to `relay()` / `relay_parallel_range()`.
- Config: additive `Mode::Full` variant + validation tests (2 new); existing validation rules untouched.
- Local build: clean compile. `cargo test --quiet`: 75 passed (73 → 75 with 2 new config tests).
### Closes
Unblocks the feature requested in #61, #69, #100, #105, #110, #111, #113, #116.
### Testing
vahidlazio has iterated on prior review feedback. End-to-end testing with a real tunnel-node deployment will follow post-merge from @Feiabyte (volunteered in #61). Post-merge CI will exercise compile + full test matrix across all targets; any regression caught there gets a fast-follow fix.
The x.com GraphQL URL-length fix added in v1.2.1 (08fe691) only
matched exact host "x.com". But browsers actually navigate to
www.x.com, and api.x.com serves GraphQL endpoints too — the original
fix never fired for real traffic.
@pourya-p's log in #64 made this unambiguous:
relay GET https://www.x.com/i/api/graphql/<hash>/HomeTimeline?variables=...&features=...
...
ERROR Relay failed: relay error: Exception: بیش از حد مجاز: طول نشانی وب URLFetch.
(That Persian text is Apps Script's "URLFetch URL length exceeded"
error, which is exactly what the truncation was supposed to prevent.)
Widened the host matcher to `host == "x.com" || host ends with
".x.com"` so www.x.com / api.x.com / any future x.com subdomain all
hit the rewrite. The path-pattern constraint
(`/i/api/graphql/... ?variables=`) already filters to the right
endpoints.
73 tests still pass.
Before: `ProxyServer::run()` aborted only the two accept tasks on
shutdown (`http_task`, `socks_task`), but every per-client task was
spawned as a bare `tokio::spawn(...)` whose JoinHandle was discarded.
Aborting the accept loop stopped taking new connections, but in-flight
clients kept running on the runtime with their captured (stale)
`Arc<DomainFronter>`.
User-visible symptoms reported by @r-safavi in #99:
1. Hitting Stop in the UI didn't actually stop serving: Firefox still
reached x.com through the proxy even though the user expected a
"connection refused."
2. Starting again with a changed auth_key worked for NEW domains
(yahoo.com) but not for domains with a live keep-alive (x.com) —
because the old child task was still using the old fronter with the
old key.
3. Apps Script quota could be consumed after the user thought they'd
stopped. Arguably the worst of the three.
Fix: wrap per-client spawns in a `tokio::task::JoinSet<()>` scoped
inside each accept task. When the accept task is aborted on shutdown,
the JoinSet is dropped, and `JoinSet::drop` aborts every still-running
child — closing their sockets and dropping their Arc clones of the
fronter, which in turn drops the pool.
Also added an opportunistic `try_join_next()` drain before each
accept() so the JoinSet doesn't grow unbounded with completed-task
handles on long-running proxies.
Covers Finding 2 of #99. Finding 1 (quota-exceeded → timeout instead
of surfacing Apps Script's 502) is a separate pool-staleness issue and
stays open for now.
Ports the upstream Python `youtube_via_relay` flag (commit a0fd8a0 in
masterking32/MasterHttpRelayVPN). When enabled, YouTube-family
suffixes (youtube.com, youtu.be, youtube-nocookie.com, ytimg.com)
opt out of the SNI-rewrite tunnel and fall through to the Apps Script
relay path.
Why it helps some users: when YouTube is reached via SNI-rewrite to
google_ip with SNI=www.google.com, Google's frontend can enforce
SafeSearch / Restricted Mode based on the SNI name, causing "video
restricted" errors on some regular videos. Routing through Apps
Script bypasses that specific filter at the cost of (a) UrlFetchApp's
fixed `User-Agent: Google-Apps-Script`, and (b) counting YouTube
traffic against the script's daily quota.
Off by default so existing behaviour is unchanged. Users who hit the
SafeSearch-on-SNI issue can set `"youtube_via_relay": true` in their
config.json and observe.
Explicit `hosts` overrides always beat the toggle — that's a user
choice and should win over the default policy. Added tests for all
three branches (youtube_via_relay off, on, and with hosts override).
Matching Android-side UI toggle deferred — `normalize_x_graphql` is
also config-only on Android today; users can edit config.json
directly if needed.
Three ports from the upstream Python repo — all straightforward wins for
user-facing connection reliability:
- plain-tcp: 4s connect timeout for IP literals (10s for hostnames).
Ported from upstream 7b1812c. When Telegram MTProto (or any protocol
that CONNECTs to a raw IP) hits a DPI-dropped DC, failing fast lets
the client rotate to the next DC roughly twice as quickly. Users
previously sat on "connecting..." for nearly a minute walking DC1→DC3.
- SNI rotation pool: add maps/chat/translate/play/lens.google.com to
both the Rust DEFAULT_GOOGLE_SNI_POOL and the Android DEFAULT_SNI_POOL.
Ported from upstream 57738ec. Extra fingerprint spread plus a couple
of SNIs (maps, play) that reliably pass DPI where shorter
*.google.com names don't.
- x.com GraphQL URL truncation: when the path matches
/i/api/graphql/<hash>/<op>?variables=..., drop everything from the
first `&` onward. The combined variables+features+fieldToggles
query string regularly exceeds Apps Script's URL length cap and
returns a generic relay error; `variables=` alone is enough for
x.com's timeline to render. Ported from upstream 2d959d4.
No version bump — these are low-risk infrastructure patches; they'll
fold into the next release.
Second operating mode for users whose network already blocks
script.google.com and therefore cannot reach it to deploy Code.gs
in the first place. In google_only, the client runs only the
SNI-rewrite tunnel to *.google.com and the other Google-edge
suffixes that are already allowlisted; non-Google traffic falls
through to direct TCP. No script_id or auth_key is required. Once
Code.gs is deployed, the user switches to apps_script mode and
pastes the Deployment ID.
- config: Mode enum, relaxed validation when mode is google_only
- proxy_server: mode check in dispatch_tunnel; DomainFronter is now
Option<Arc<_>> so it is not constructed in google_only
- desktop UI and Android app: Mode dropdown, Apps Script fields
disable in google_only
- README: bootstrap subsection in English and Persian
- config.google-only.example.json
- version bump to 1.2.0 + changelog entry
Backward compatible with existing apps_script configs.
dispatch_tunnel() is only used by the HTTP CONNECT and SOCKS5 listeners.
It previously forced hosts matched by matches_sni_rewrite() or the hosts
override map into do_sni_rewrite_tunnel_from_tcp() regardless of port.
That tunnel is TLS-specific: it accepts inbound TLS from the client and
opens a second TLS connection to the Google edge. For non-HTTPS targets
such as :80, selecting that path makes the proxy wait for a ClientHello
that will never arrive.
Introduce should_use_sni_rewrite() and require port 443 before forcing the
rewrite tunnel from dispatch_tunnel(). Non-HTTPS targets now remain on the
normal dispatch path.
The tests now cover both suffix-based and hosts-map matches on ports 443
and 80.
Co-authored-by: freeinternet865 <free@internet865.com>
Users of the upstream Python port
(github.com/masterking32/MasterHttpRelayVPN) reported that YouTube
videos render fine through theirs while the Rust port stalls. Diff
against the Python source exposed two substantive gaps we were
missing:
1. SNI-rewrite list was much shorter than upstream. Added:
gvt1.com, gvt2.com — Google Video Transport CDN (YouTube
video chunks + Chrome auto-updates +
Play Store downloads)
doubleclick.net — ads
googlesyndication.com
googleadservices.com
google-analytics.com
googletagmanager.com
googletagservices.com
fonts.googleapis.com — already covered by the googleapis.com
suffix but mirrored explicitly for clarity
These are all on Google's GFE IP pool, so they route over the
existing SNI-rewrite tunnel (direct to `google_ip` with SNI
rewritten) instead of the quota-limited Apps Script relay.
2. No range-parallel download path. Apps Script's per-call latency
is ~flat (~1-2s regardless of payload), so a 10 MB single GET
takes ~10s round-trip; the player times out or stutters. Upstream
Python's `relay_parallel` probes with Range: bytes=0-262143, and
if the origin supports ranges, fetches the rest in parallel
256 KB chunks (up to 16 concurrent). Ported that logic as a new
`DomainFronter::relay_parallel_range` method, called from both
MITM-HTTPS and plain-HTTP handlers for GETs without a body. Rust
implementation uses `futures::stream::buffered` for ordered
bounded-concurrency fan-out; cache layer already skips Range
requests (added defensive check in relay() too).
The existing single-script fan-out (`parallel_relay` config) is
complementary — it races N script IDs for each individual chunk,
where the range-parallel path slices the overall download. Both are
active simultaneously when both are configured.
Helper functions for HTTP parsing (split_response,
parse_content_range_total, rewrite_206_to_200, assemble_full_200)
mirror the Python equivalents.
No behaviour change for non-GET requests; no cache-correctness
changes for GETs that don't return 206.
The app is a Kotlin/Compose front-end that reuses the mhrv-rs crate
via JNI. It speaks VpnService to get a TUN fd, hands that to tun2proxy,
and funnels every app's traffic through the in-process SOCKS5 listener —
no per-app proxy setup on the device.
Two fixes in `src/proxy_server.rs` apply to desktop builds too:
* SNI peek via `LazyConfigAcceptor`. When a browser uses DoH (Chrome's
default), tun2proxy hands us a raw IP in the SOCKS5 CONNECT. Minting
a MITM cert for the IP produced `ERR_CERT_COMMON_NAME_INVALID` on
Cloudflare-fronted sites. We now read the ClientHello's SNI first
and use that both as the cert subject and as the upstream host for
the Apps Script relay (fetching `https://<IP>/...` with an IP in the
Host header gets rejected by CF anyway).
* Short-circuit CORS preflight at the MITM boundary. `UrlFetchApp.fetch()`
rejects `OPTIONS` with a Swedish "Ett attribut med ogiltigt värde
har angetts: method" error, which silently broke every fetch()/XHR
preflight and was the root cause of "JS doesn't load" on Discord,
Yahoo, and similar. Since we already terminate the TLS the browser
talks to, answering the preflight with a permissive 204 is safe —
the real request still goes through the relay.
Android-side capabilities (feature-parity with `mhrv-rs-ui` where it
fits on a phone):
* multi-deployment ID editor
* SNI rotation pool + per-SNI "Test" + "Test all" (JNI into scan_sni)
* live logs panel (JNI ring buffer drained on a 500 ms poll)
* Advanced section: verify_ssl, parallel_relay, log_level, upstream_socks5
* CA install flow that matches modern Android's reality: saves
`Downloads/mhrv-ca.crt` via MediaStore, deep-links Security settings,
then verifies post-hoc by fingerprint lookup in AndroidCAStore (the
KeyChain intent dead-ends with a Close-only dialog on Android 11+)
* Start/Stop debounced to dodge an emulator EGL renderer crash on
rapid taps
Theme matches the desktop palette exactly — always-dark, accent
`#4678B4`, card fill `#1C1E22`, 4dp button / 6dp card radii.
No dynamic color, no light scheme: the desktop is always dark and
we follow.
Build wiring:
* `Cargo.toml`: `cdylib` crate-type added; `jni` + `tun2proxy`
scoped to `cfg(target_os = "android")` so desktop builds pay
nothing.
* `src/data_dir.rs`: `set_data_dir()` override so the Android app's
private filesDir replaces the `directories` crate's desktop default.
* `src/android_jni.rs`: JNI entry points for start/stop/exportCa plus
a ring buffer draining to `Native.drainLogs()` and `testSni()` that
wraps `scan_sni::probe_one`.
* Gradle task chain runs `cargo ndk` before each assemble; post-step
normalizes tun2proxy's hash-suffixed cdylib to a stable filename
so `System.loadLibrary("tun2proxy")` works.
Verified end-to-end on an API 34 emulator: ipleak, yahoo, discord,
cloudflare.com all render; TLS is MITM-ed under our user-installed
CA; service survives rapid Stop/Start cycles.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Teach the incoming HTTP request parser to handle Transfer-Encoding:
chunked instead of only Content-Length-framed bodies.
Also reply with 100 Continue when a client sends Expect:
100-continue before waiting for the request body.
This keeps request framing correct for POST/PUT-style clients and
adds focused tests for chunked decoding and 100-continue handling.
Co-authored-by: freeinternet865 <free@internet865.com>
@Behzad9 on #18: the OpenWRT 'No file descriptors available' errors
are back in v0.8.0+, this time logged as a wall of thousands of
identical ERRORs within seconds of activating the proxy. Two real
bugs, now fixed:
=== 1. accept() loop had no backoff ===
Previous code:
loop {
match listener.accept().await {
Ok(x) => ...,
Err(e) => { tracing::error!(...); continue; } // tight loop
}
}
On EMFILE (RLIMIT_NOFILE exhausted), accept() returns synchronously,
the match re-runs instantly, accept() EMFILEs again, forever. The tight
loop ALSO starves the tokio runtime of CPU that existing connections
need to finish and close their fds — so the problem never clears on its
own. It's a self-sustaining meltdown.
New accept_backoff() helper (in proxy_server.rs) wraps both the HTTP
and SOCKS5 accept loops:
- Detects EMFILE/ENFILE via raw_os_error (24 or 23).
- Sleeps proportional to how long the pressure has lasted (50 ms
first hit, ramping to a 2 s cap around hit #40). Gives existing
connections a chance to finish and free fds.
- Rate-limits the log line: one WARN on the first EMFILE with fix
instructions, then one every 100 retries. No more walls of
identical errors.
- Resets the counter on the next successful accept.
- Non-EMFILE errors (ECONNABORTED from clients that went away during
handshake, etc.) get a plain single-line error + 5 ms sleep so we
still don't tight-loop on any unexpected error.
End-to-end verified: ran mhrv-rs under , flooded the
SOCKS5 port with 247 concurrent connections to trip EMFILE. Before:
log would have been 1000s of identical lines. After: exactly 1 warning,
listener stayed quiet, fds drained, accept resumed.
=== 2. RLIMIT_NOFILE bump was too conservative + silent ===
Previous behavior: target 16384 soft, cap to existing hard limit,
no log. On constrained systems where hard is already tiny, we'd
stay at the tiny limit silently.
rlimit.rs now:
- Targets 65536 soft.
- ALSO tries to raise the hard limit up to /proc/sys/fs/nr_open
on Linux (Linux allows a non-privileged process to bump its own
hard limit up to the kernel ceiling, usually 1048576 on modern
kernels). On macOS/BSD we skip this — only bump soft.
- Logs WARN on startup if soft ends up <4096 with the exact fix
('ulimit -n 65536' or use the procd init). No more silent
failure.
- Logs INFO with the before/after limits otherwise, so field bug
reports tell us immediately whether the kernel cap is the real
bottleneck.
Moved the rlimit call from main() pre-logging to post-init_logging so
its tracing output actually lands in the log panel + stderr. Small
reorganization only.
49 tests pass, musl x86_64 cross-compile verified locally.
Two reported issues:
1. Log level in the form had no visible effect — trace produced the
same panel output as warn.
2. upstream_socks5 was reported as never being attempted.
(1) was because the UI binary never installed a tracing subscriber.
Every tracing::info!/debug!/trace! from the proxy was discarded; only
the handful of manual push_log() calls for start/stop/test reached
the 'Recent log' panel. Swapping the log level in the combo-box just
rewrote the config field — nothing consumed it.
Fix: install_ui_tracing() at startup registers a tracing_subscriber
fmt layer with a custom MakeWriter that mirrors each formatted event
line into shared.state.log. Respects RUST_LOG, defaults to 'info'
with hyper pinned to warn so the panel isn't swamped by low-level
HTTP chatter. Now the log level switch actually filters panel
output, and routing decisions show up live.
(2) is a documentation / visibility issue more than a bug. Our
upstream_socks5 routing is intentionally scoped to raw-TCP traffic
(non-HTTP, non-TLS) — HTTPS goes through the Apps Script relay,
which is the whole reason mhrv-rs exists. But without working logs,
it looks like upstream_socks5 is dead code.
Fix: every branch of dispatch_tunnel now emits a tracing::info! that
says exactly which path the connection took and, where applicable,
whether upstream_socks5 was used:
dispatch api.telegram.org:443 -> raw-tcp (127.0.0.1:50529)
dispatch www.google.com:443 -> sni-rewrite tunnel (Google edge direct)
dispatch httpbin.org:443 -> MITM + Apps Script relay (TLS detected)
Combined with (1), users can now see in real time whether their
traffic is hitting upstream_socks5. If it says 'raw-tcp (direct)'
after they set the field, that's evidence of a real bug; if it
never reaches the raw-tcp branch at all, that's the documented
design (HTTPS → Apps Script).
Also per user request, updated README:
- Shields.io badges up top: latest release, total downloads, CI
status, license, stars.
- Short 'Heads up on authorship' note crediting Anthropic's Claude
for the bulk of the Rust port (with the human-on-every-commit
caveat). English and Persian mirrors both have it.
All 37 unit tests pass.
Tier-1 perf changes from the brainstorm, all on by default except where
they change semantics (parallel_relay is opt-in).
Connection pool pre-warm (domain_fronter.rs):
On startup, open 3 TLS connections to Google edge in parallel and
park them in the pool. First user request skips the ~300-500 ms
handshake cost. Best-effort: warm failures are logged at debug and
ignored. Triggered from ProxyServer::run() in a fire-and-forget
tokio spawn.
SNI rotation (domain_fronter.rs):
Replace the single sni_host String with a Vec<String> plus an atomic
round-robin index. When front_domain is one of the known Google-edge
subdomains, build_sni_pool() expands it to include the other four
(www/mail/drive/docs/calendar.google.com), so outbound TLS connection
counts get spread across names instead of concentrating on one. Custom
front_domain values are preserved as the single entry (we can't verify
siblings of a non-Google edge).
Expanded SNI-rewrite suffix list (proxy_server.rs):
Added gstatic.com, googleusercontent.com, googleapis.com, ggpht.com,
ytimg.com, blogspot.com, blogger.com to the list of domains routed
directly via the Google-edge tunnel instead of through the Apps Script
relay. Bigger bypass = less UA-locking, less quota burn on static CDN
content.
Per-site stats (domain_fronter.rs + ui.rs):
New HostStat struct {requests, cache_hits, bytes, total_latency_ns}
tracked per URL host. Records on both cache hits and relay calls, not
on SNI-rewrite bypasses (those never touch the fronter). UI renders
a collapsible table under the existing stats grid with the top 60
hosts sorted by request count, showing req count, cache hit %, bytes,
avg latency ms.
Parallel script-ID dispatch (config.rs, domain_fronter.rs, ui.rs):
New config field parallel_relay: u8 (default 0 = off). When >= 2 and
there are enough non-blacklisted IDs, do_relay_with_retry fans out
the request to N script instances concurrently via futures_util's
select_ok, returns first success, cancels the rest. Kills long-tail
latency when one Apps Script instance happens to be slow, at the
cost of N× quota per request. UI exposes it as a DragValue 0-8.
TCP_NODELAY audit (proxy_server.rs):
Added the missing set_nodelay(true) call on the SNI-rewrite outbound
TCP stream. All six TcpStream::connect sites in the user traffic path
now disable Nagle.
Expanded feature list in README, added futures-util dep, added unit
tests for extract_host and build_sni_pool.
Verified end-to-end locally:
- Pool pre-warm log line appears on startup: 'pool pre-warmed with 3
connection(s)'.
- Static asset hit 3x: first = 2.2s (Apps Script), 2-3 = 6ms (cache).
- youtube.com / google.com: SNI-rewrite tunnel (unchanged).
- All 28 unit tests pass.
Deferred (not in this release, each needs its own cycle):
- uTLS / Chrome fingerprint mimicry (TLS stack swap)
- QUIC/HTTP3 transport (new transport)
- ETag / If-None-Match revalidation (needs cache schema change)
- JSON envelope gzip on request (needs Code.gs change)
- Firebase Cloud Functions as alt backend (new architecture)
- MSS clamp / TCP Fast Open (platform-specific, marginal)
The Apps Script relay is HTTP-only, and the SNI-rewrite tunnel only
works for Google-hosted domains — so MTProto / IMAP / SSH / anything
else used to drop to a direct-TCP passthrough, which provides zero
circumvention. Users behind a DPI that blocks Telegram saw constant
disconnect/reconnect loops because the raw TCP ran right into the
block.
Fix: add an optional 'upstream_socks5' config field. When set, the
raw-TCP fallback chains the flow into that SOCKS5 proxy (typically a
local xray / v2ray / sing-box with a VLESS / Trojan / Shadowsocks
outbound to your own VPS) instead of connecting directly. The whole
rest of the pipeline is unchanged:
- HTTP / HTTPS still MITMs and relays via Apps Script
- SNI-rewrite suffixes (google.com, youtube.com, …) still hit the
direct Google-edge tunnel (so YouTube stays fast)
- Only the raw-TCP bucket (Telegram MTProto, SSH, IMAP, …) gets the
new upstream chain
Changes:
- config.rs: add Option<String> upstream_socks5 field
- proxy_server.rs: thread it through RewriteCtx; rewrite
plain_tcp_passthrough to call a new socks5_connect_via() helper
when configured, with graceful fallback to direct
- ui.rs: new 'Upstream SOCKS5' input with tooltip + placeholder,
ConfigWire round-trip
- README.md: new 'Pair with xray for Telegram' section (EN + FA)
with the architecture diagram and example config
Verified end-to-end in Docker: xray with the user's working VLESS
Reality config, mhrv-rs with upstream_socks5 pointing at it.
- HTTPS via mhrv-rs SOCKS5: origin = Google IP (Apps Script path) ✓
- Raw TCP to 3 Telegram DCs + api.telegram.org: all SOCKS5 rep=0, log
shows 'tcp via upstream-socks5 127.0.0.1:50529 -> …' ✓
- youtube.com / google.com: 'SNI-rewrite tunnel' (unchanged) ✓
- Real Telegram Desktop stayed connected cleanly (user-confirmed).
The UI was creating its own DomainFronter instance and polling stats
from it, while traffic actually went through the ProxyServer's own
internal fronter. Result: stats grid stuck at zero even with traffic
flowing.
Fix: expose ProxyServer::fronter() and have the UI pick up that handle
once the server is built, instead of constructing a parallel fronter.
User reported log spam on Windows with many 'relay failed: خطای SSL'
errors for IP-literal targets like 172.105.237.214:443. Root cause:
xray/VLESS, torrent, SSH, and other app-level clients use raw IPs in
CONNECT/SOCKS5 targets. Our previous logic would MITM these, see
'POST /' inside the xhttp wrapping, forward to Apps Script, which
would then fail SSL-verifying the app's self-signed backend.
New heuristic: if the CONNECT target is an IP literal, skip MITM
entirely and do plain TCP passthrough. Reasoning: browsers never
use raw IPs in CONNECT -- they always have a domain. Any client
using an IP literal is using a custom protocol that we have no
business MITMing.
Effect: xray/VLESS tunnels now work through mhrv-rs SOCKS5 (the
app's own TLS wrap passes through untouched). Browser HTTPS still
MITM'd + relayed as before (domain CONNECTs).
Also downgraded 'relay failed' logs from error to warn so they don't
spam the ERROR channel on misrouted traffic.
Ports the SOCKS5 + fallback-chain design from @masterking32's
MasterHTTP-WithSOCKS branch so xray / Telegram / app-level TCP
clients work through this proxy.
Changes:
- New SOCKS5 listener on listen_port+1 (configurable via socks5_port)
- RFC 1928 CONNECT handshake (v5, no-auth, ATYP IPv4/domain/IPv6)
- Shared smart dispatch with the HTTP-CONNECT path
- Unified dispatch_tunnel() used by both CONNECT entry points:
1. If host matches SNI-rewrite suffix or hosts override: go direct
to google_ip via the MITM+TLS tunnel (fast path for google.com,
youtube, etc.)
2. Peek the first byte (300ms timeout for server-first protocols):
- 0x16: TLS client hello -> MITM + relay via Apps Script (scheme=https)
- HTTP method signature: HTTP relay via Apps Script (scheme=http)
- Anything else or timeout: plain TCP passthrough to the target
- handle_mitm_request() now takes a scheme arg (http/https) so the
same code path handles both MITM'd HTTPS and port-80 plain HTTP
- New plain_tcp_passthrough helper: bidirectional TCP bridge used as
the final fallback (covers MTProto / raw TCP / server-first protos)
Config:
- Added optional socks5_port field; defaults to listen_port+1
README:
- Added browser vs xray/Telegram instructions under 'Step 6'
Live-tested: HTTP proxy, HTTP proxy -> HTTPS, SOCKS5 -> HTTP,
SOCKS5 -> HTTPS, Google search via SNI-tunnel (now returns full
JS page) all pass.
Context: user reported Google search showing no-JS fallback page
('JS is off apparently'). Root cause is Apps Script's fixed
'Google-Apps-Script; beanserver' User-Agent that UrlFetchApp.fetch
does not let you override. Google detects the bot UA and serves
the degraded HTML.
Fix: add google.com to SNI_REWRITE_SUFFIXES so google.com requests
bypass Apps Script entirely and go direct to Google's edge via the
MITM+TLS tunnel. Real browser UA is sent; full JS version is served.
Also documented this and other inherent limitations (WebSockets,
2FA 'unknown device', video chunk slowness, brotli stripping) in
the README under 'Known limitations' in English + Persian so users
aren't surprised. These are platform limits of Apps Script, not
bugs -- same issues exist in the original Python project.
Two bug fixes surfaced in user testing:
1. Invalid HTTP methods forwarded to Apps Script
- Browser/xray sent HTTP/2 PRI preface through our MITM despite ALPN
being set to http/1.1 only (some clients ignore ALPN).
- Our parser accepted 'PRI' as a method and forwarded to Apps Script,
which rejected it: 'Exception: parameter provided with invalid value: method'.
- Fix: validate method against the standard list (GET/POST/PUT/DELETE/
HEAD/OPTIONS/PATCH/TRACE/CONNECT) at parse time. Non-matching requests
close the connection cleanly instead of forwarding garbage.
2. YouTube video playback broken by over-broad SNI-rewrite list
- Previous list included googlevideo.com, ytimg.com, doubleclick.net,
etc. -- but these are served from SEPARATE CDN pools, NOT from
Google's 216.239.38.120 frontend. Rewriting sent traffic to the
wrong backend, which Google dropped.
- Shrunk to a conservative list that's actually served from the
main Google frontend: youtube.com, youtu.be, youtube-nocookie.com,
fonts.googleapis.com. Everything else falls through to MITM+relay
(slower but actually works).
- YouTube video chunks now route through Apps Script which is slow
and quota-limited. This is a known limitation inherent to the
approach; same issue exists in the original Python version.
Tracks relay_calls, failures, bytes, coalesced requests, cache hit rate,
and active scripts (total minus blacklisted). Logs only if there's been
traffic since the last tick. Visible when running with RUST_LOG=info or
log_level=info in config.
SNI-rewrite tunnels (src/proxy_server.rs):
- CONNECT to youtube.com / googlevideo.com / doubleclick / etc. now bypasses
the Apps Script relay entirely and goes direct to the Google edge IP
with SNI=front_domain.
- Accepts browser TLS with our MITM cert, opens outbound TLS to
config.google_ip with SNI=config.front_domain, bridges decrypted bytes.
- Matches Python's _do_sni_rewrite_tunnel behavior. Faster than relay for
large streams (video).
- Also respects config.hosts override map (custom IP per suffix).
gzip decode fix (src/domain_fronter.rs):
- Apps Script outer response is gzipped. Previous stub always failed,
causing 'non-utf8 json' errors. Swapped in flate2::GzDecoder.
- Verified end-to-end: HTTP and HTTPS requests through apps_script
relay succeed and return real Google IPs.
dazzling-no-more