Full Tunnel problem

[creep247]

in Full Tunnel mode I get this error: (v 1.6.0)
ERROR tunnel connect_data error for incoming.telemetry.mozilla.org:443: missing response in batch

ERROR tunnel connect_data error for script.google.com:443: missing response in batch

Also i dont see this text printed after visiting page: This application is running normally.
but app script mode works fine using CodeFull.gs meaning only a problem in Full Tunnel mode

Also which one is the correct format for TUNNEL_SERVER_URL in CodeFull.gs? I used the first format

const TUNNEL_SERVER_URL = "https://12.12.12.12:8080";
const TUNNEL_SERVER_URL = "https://12.12.12.12:8080/";

This page in GUI does not exist in reality: https://script.google.com/home/usage

[therealaleph]

@creep247 three separate things in your report — let me handle each:

1. tunnel connect_data error for incoming.telemetry.mozilla.org:443: missing response in batch

This is the fallback path firing — the connect_data op was sent in a batch and the tunnel-node's batch response didn't include a reply for that specific op. Most common causes:

• Old tunnel-node that doesn't know connect_data and dropped the op silently instead of returning UNSUPPORTED_OP. The sticky AtomicBool fallback only kicks in when we see UNSUPPORTED_OP; a silent drop bypasses it.
• tunnel-node crashed mid-batch and the batch came back with fewer responses than ops.
• Genuine response loss — the op landed but the upstream connection failed in a way that didn't write a reply.

incoming.telemetry.mozilla.org is Firefox's telemetry beacon — Firefox fires hundreds of these per session, so any flaky path will show up there first.

To diagnose:

• What version is your tunnel-node? If it's pre-v1.4.0 (before connect_data shipped), upgrade — the prebuilt Docker image at ghcr.io/therealaleph/mhrv-tunnel-node:1.6.0 has both connect_data AND the new long-poll drain (feat(tunnel): event-driven drain with adaptive long-poll #173) AND UDP support (Feature: udp support #183).
• After upgrading, error should disappear OR mutate to UNSUPPORTED_OP (which is harmless, sticky fallback handles it). If it's actually a crash, tunnel-node logs will show it.

2. TUNNEL_SERVER_URL trailing slash

Either form works — the server normalizes. But for cleanliness use without the trailing slash:

const TUNNEL_SERVER_URL = "https://12.12.12.12:8080";

The path /tunnel and /tunnel/batch get appended programmatically; a trailing slash in the base would result in //tunnel which most servers normalize but is technically incorrect.

3. https://script.google.com/home/usage returns 404

You're right — Google moved/retired that URL recently. Looking at the current Apps Script dashboard: the canonical place to see UrlFetchApp quota usage is now under Executions in each script project's left nav (not a separate global usage page).

The View quota on Google → button in mhrv-rs should point at a working page. I'll fix that in v1.6.x — for now, in your Apps Script project, click Executions in the left nav to see per-script usage. Aggregate quota dashboard for the whole account no longer has a stable URL we can link.

Tracking the URL fix as a follow-up; closing the rest as answered. If after upgrading tunnel-node to 1.6.0 you still see missing response in batch, reopen with a log snippet showing the full error context (5-10 lines around the error).

---

_{[reply via Anthropic Claude | reviewed by @therealaleph]}

[creep247]

I found the problem. it works with "http://12.12.12.12:8080"; using http protocol not https. but isn't that insecure? letsencrypt allows issuing 6-day IP-only certificate without need for a domain name that we could use. also full tunnel mode is very slow!

https://letsencrypt.org/2025/07/01/issuing-our-first-ip-address-certificate

[therealaleph]

@creep247 nice find on the http vs https. Three things to address:

Why http works and https doesn't (but isn't necessarily insecure):

The tunnel-node serves plain HTTP on port 8080. It's never publicly reached — Apps Script is the ONLY thing that calls it, and the call from Apps Script's UrlFetchApp to your tunnel-node travels Google's network, not yours. So three security model points:

1. The wire from your browser to Apps Script is HTTPS via your already-installed mhrv-rs MITM CA + Google's edge cert. End-to-end encrypted.
2. The wire from Apps Script (Google datacenter) to tunnel-node (your VPS) is what the URL scheme controls. If TUNNEL_SERVER_URL = "http://...", that leg is plain HTTP. If "https://...", you'd need a valid TLS cert on your VPS at that hostname:port.
3. The plain-HTTP leg is not "your traffic over the public internet" — it's Apps Script's outbound fetch from a Google IP to your VPS IP, which goes over the public internet but the only entity that can read it is Google's network and your VPS's transit provider.

Is plain HTTP "insecure"? Threat model:

• Eavesdropping on the Google-DC-to-VPS path: yes, possible for transit operators between Google and your VPS. If your VPS is on Google Cloud (same network) the path stays internal. If it's on Hetzner, OVH, AWS — the traffic crosses public internet.
• Modification: same threat surface, plus any active MITM on that path can rewrite responses.
• The TUNNEL_AUTH_KEY does prevent random outsiders from sending fake requests, but it's transmitted plaintext on the HTTP path, so a passive eavesdropper sees the secret too.

For most users, plain HTTP is acceptable because:

• The tunneled content is whatever the user is browsing — already wrapped in app-level TLS for sensitive sites (Google login, banking, etc.). The middlebox sees encrypted HTTPS bytes flowing in/out, not the plaintext.
• Google → VPS path is short and high-quality on most major clouds.

For higher-threat users: add a real TLS cert. Three options:

1. Caddy or Traefik in front of tunnel-node with their auto-Let's-Encrypt — needs a domain pointing at your VPS IP. Add tunnel.yourdomain.com and Caddy gets a cert in 30 seconds. TUNNEL_SERVER_URL = "https://tunnel.yourdomain.com:443".
2. Cloud Run — gets HTTPS for free (Cloud Run terminates TLS at the load balancer, container speaks HTTP internally). Already what most users do because it's free; this is also why their TUNNEL_SERVER_URL = "https://..." works without DNS or cert setup.
3. LetsEncrypt IP-only certs (your suggestion) — interesting and worth tracking. The blog post you linked says LE will issue 6-day certs for IPs in 2025+, no domain needed. Once acme.sh / certbot ship support, we can add a docs section pointing at it. For now, easier paths in 1 and 2 above.

Full Tunnel mode being slow:

Same root cause as #179. Each Apps Script batch round-trip is ~2s (fixed, regardless of payload). Bursty 0 → 200KB → 0 → 200KB pattern is inherent to Apps-Script-as-relay. v1.5.0 (long-poll) and v1.6.0 (UDP support, just merged today) help push notifications and DNS/QUIC. For sustained throughput, the architectural fix is upstream_socks5 to a VPS — Apps Script is bypassed for that traffic. Detailed walkthrough in #144.

I'll add a note to tunnel-node/README.md clarifying the http vs https tradeoff so the next user doesn't trip on this. Closing this issue since the connect_data error you reported is resolved (it was the http/https mismatch, not the version skew I initially diagnosed) and the slow-tunnel observation is covered elsewhere.

---

_{[reply via Anthropic Claude | reviewed by @therealaleph]}