Apps like Telegram maintain persistent XMPP connections (:5222) and Google Push uses :5228 — both rely on long-lived sessions with periodic heartbeats. At the previous 5s long-poll deadline, the tunnel-node returned empty responses frequently enough that Telegram interpreted it as connection instability and rotated sessions. Each reconnect costs a full TLS handshake (~4s through Apps Script), causing visible video/voice interruptions and buffering. Raising the long-poll deadline to 15s keeps these persistent connections alive: the tunnel-node holds the response open until server data actually arrives (push notification, chat message, media chunk) rather than returning empty every 5s. Tested on censored networks in Iran where users reported smoother Telegram video playback and fewer session resets. The straggler settle is now adaptive (40ms steps, 500ms max): after the first session in a batch gets data, keep checking every 40ms whether neighboring sessions also have data. Break early when all sessions are ready — no fixed 500ms wait when data is already there. On high-latency relays where each Apps Script call costs ~1.5s overhead, packing more session responses into one batch saves quota and reduces total round-trips. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Tunnel Node
Persian / فارسی: README.fa.md
HTTP tunnel bridge server for MasterHttpRelayVPN "full" mode. Bridges HTTP tunnel requests (from Apps Script) to real TCP connections.
Architecture
Phone → mhrv-rs → [domain-fronted TLS] → Apps Script → [HTTP] → Tunnel Node → [real TCP] → Internet
The tunnel node manages persistent TCP and UDP sessions. TCP sessions are real TCP connections to a destination server; UDP sessions are connected UDP sockets to one destination host:port. Data flows through a JSON protocol:
- connect — open TCP to host:port, return session ID
- data — write client data, return server response
- udp_open — open UDP to host:port, optionally send the first datagram
- udp_data — send one UDP datagram, or poll for returned datagrams when
dis omitted - close — tear down session
- batch — process multiple ops in one HTTP request (reduces round trips)
Deployment
Cloud Run
cd tunnel-node
gcloud run deploy tunnel-node \
--source . \
--region us-central1 \
--allow-unauthenticated \
--set-env-vars TUNNEL_AUTH_KEY=$(openssl rand -hex 24) \
--memory 256Mi \
--cpu 1 \
--max-instances 1
Docker — prebuilt image (any VPS)
The fastest path. Pull a prebuilt image and run it; no Rust toolchain needed on the VPS.
# Generate a strong secret. Save it — you'll paste the same value into CodeFull.gs.
SECRET=$(openssl rand -hex 24)
echo "Your TUNNEL_AUTH_KEY: $SECRET"
# Pull + run.
docker run -d \
--name mhrv-tunnel \
--restart unless-stopped \
-p 8080:8080 \
-e TUNNEL_AUTH_KEY="$SECRET" \
ghcr.io/therealaleph/mhrv-tunnel-node:latest
The :latest tag tracks the most recent release. To pin a specific version (recommended for production), use ghcr.io/therealaleph/mhrv-tunnel-node:v1.5.0 (or whatever release you're on). Image is available for linux/amd64 and linux/arm64.
docker-compose.yml if you prefer:
services:
tunnel:
image: ghcr.io/therealaleph/mhrv-tunnel-node:latest
restart: unless-stopped
ports:
- "8080:8080"
environment:
TUNNEL_AUTH_KEY: ${TUNNEL_AUTH_KEY}
Then TUNNEL_AUTH_KEY=your-secret docker compose up -d.
Docker — build from source
If you'd rather build the image yourself (or add custom changes):
cd tunnel-node
docker build -t tunnel-node .
docker run -p 8080:8080 -e TUNNEL_AUTH_KEY=your-secret tunnel-node
Direct binary
cd tunnel-node
cargo build --release
TUNNEL_AUTH_KEY=your-secret PORT=8080 ./target/release/tunnel-node
Environment Variables
| Variable | Required | Default | Description |
|---|---|---|---|
TUNNEL_AUTH_KEY |
Yes | changeme |
Shared secret — must match TUNNEL_AUTH_KEY in CodeFull.gs |
PORT |
No | 8080 |
Listen port (Cloud Run sets this automatically) |
Protocol
Single op: POST /tunnel
{"k":"auth","op":"connect","host":"example.com","port":443}
{"k":"auth","op":"data","sid":"uuid","data":"base64"}
{"k":"auth","op":"close","sid":"uuid"}
Batch: POST /tunnel/batch
{
"k": "auth",
"ops": [
{"op":"data","sid":"uuid1","d":"base64"},
{"op":"udp_data","sid":"uuid2","d":"base64"},
{"op":"close","sid":"uuid3"}
]
}
→ {"r": [{...}, {...}, {...}]}
Health check: GET /health → ok
Performance: deployment count and pipeline depth
The mhrv-rs client runs a pipelined batch multiplexer in full mode. Each Apps Script round-trip takes ~2s, so the client fires multiple batch requests concurrently — the pipeline depth equals the number of configured script deployment IDs (minimum 2, no upper cap).
More deployments = more concurrent batches hitting the tunnel-node = lower per-session latency. With 6 deployments, a new batch arrives every ~0.3s instead of every 2s.
The tunnel-node itself is stateless per-request (sessions are keyed by UUID), so it handles concurrent batches naturally. For best results, deploy 3–12 Apps Script instances across separate Google accounts and list all their deployment IDs in the client config.