relay error: h1 open timed out after 8s

[BuffOvrFlw]

Overview

In this issue I'll explain some problems & workarounds for them, plus, a problem with no kinda solution.

• The Script Completed But Did Not Return Anything:
  in case of this error, check 2 key points:

1. Your auth key. instead of generating something random using password managers (or whatever tool which does the same), create a simple long string (same length as the default dummy string is preferred) with no numbers, no symbols, and nothing. just ASCII.
2. Your tunnel node URL is set to HTTPS://, NOT HTTP://. this may be surprising but sometimes only HTTP:// works. DO NOT use HTTPS:// if your tunnel node is misbehaving.

• The tunnel works, there's no problem, but it's not stable

1. this stability problem comes from the fact that your VPS IP is probably blacklisted somewhere OR is being treated as a proxy. what you could do about this is to make a proxy chain, and it would fix the problem.

Here's the new problem I didn't find any kinda workaround for:

• relay error: h1 open timed out after 8s

FULL LOG:

2026-05-13T10:03:51.869669Z  INFO dispatch 149.154.175.54:443 -> full tunnel (via batch mux)
2026-05-13T10:03:51.873858Z  INFO SOCKS5 CONNECT -> 149.154.167.91:443
2026-05-13T10:03:51.873863Z  INFO SOCKS5 CONNECT -> 149.154.167.91:80
2026-05-13T10:03:51.873878Z  INFO dispatch 149.154.167.91:80 -> full tunnel (via batch mux)
2026-05-13T10:03:51.873885Z  INFO dispatch 149.154.167.91:443 -> full tunnel (via batch mux)
2026-05-13T10:03:51.940839Z ERROR tunnel connect error for 149.154.167.91:80: relay error: h1 open timed out after 8s
2026-05-13T10:03:52.186059Z  INFO batch: 1 ops → AKfycbzb, rtt=2.856623029s
2026-05-13T10:03:52.186090Z  INFO tunnel session 896539e1-7814-4a81-b9c1-21c3541bab89 closed for 91.108.56.153:80
2026-05-13T10:03:52.523893Z  INFO batch: 2 ops → AKfycbzb, rtt=3.142594183s

FULL LOG:

2026-05-13T10:23:20.982319Z ERROR tunnel connect_data error for play.google.com:443: json: key must be a string at line 1 column 2
2026-05-13T10:23:24.397707Z  INFO batch: 1 ops → AKfycby_, rtt=8.001397935s
2026-05-13T10:23:24.397720Z  WARN batch failed (script AKfycby_): relay error: h1 open timed out after 8s
2026-05-13T10:23:24.397740Z ERROR tunnel connect_data error for www.googletagmanager.com:443: relay error: h1 open timed out after 8s
2026-05-13T10:23:24.419865Z  INFO batch: 1 ops → AKfycby_, rtt=8.000802008s
2026-05-13T10:23:24.419878Z  WARN batch failed (script AKfycby_): relay error: h1 open timed out after 8s
2026-05-13T10:23:24.419894Z ERROR tunnel connect_data error for www.gstatic.com:443: relay error: h1 open timed out after 8s
2026-05-13T10:23:27.988285Z  INFO batch: 1 ops → AKfycby_, rtt=8.001244176s
2026-05-13T10:23:27.988298Z  WARN batch failed (script AKfycby_): relay error: h1 open timed out after 8s
2026-05-13T10:23:27.988313Z ERROR tunnel connect_data error for script.google.com:443: relay error: h1 open timed out after 8s
2026-05-13T10:23:42.081773Z  INFO pool pre-warmed with 3 connection(s)

[dazzling-no-more]

Hi @BuffOvrFlw — the h1 open timed out after 8s message isn't a new bug. It's a defensive 8s cap on the TCP+TLS handshake to the Google edge, added by #1029 (v1.9.20) to stop a stuck connect from blocking the whole pool for the full 30s batch budget (the v1.9.15 regression in #924).

The rtt=8.001s lines in your log confirm the handshake to connect_host:443 is genuinely taking >8s from your network. #1029 puts this out of scope as "variable network behaviour, not a code bug" — raising the cap would just delay the symptom.

Worth trying:

• mhrv-rs scan-ips to find a faster Google edge IP from your VPS
• verify google_ip / connect_host still points at a real Google frontend
• "force_http1": true won't help here — this is the h1 path
• your own proxy-chain advice applies if the VPS egress is being throttled at the edge

[therealaleph]

Reviewed via Anthropic Claude.

@BuffOvrFlw — thanks for the careful writeup. Three things:

1. Your two empirical workarounds are real and worth documenting:

• AUTH_KEY = ASCII letters only, no numbers/symbols: this is a fresh observation — haven't seen it reported before. Plausible explanation: certain edges (or the user's local DNS resolver doing DPI on Apps Script bodies) may URL-decode or otherwise transform numeric/punctuation runs differently. Worth a config-validation hint in mhrv-rs.
• HTTP:// vs HTTPS:// to tunnel-node: documented elsewhere as a workaround for users behind nginx with broken TLS termination. Your finding matches.

Both noted — will see if either deserves a code-level check or a docs note.

2. h1 open timed out after 8s: this is the H1_OPEN_TIMEOUT_SECS = 8 bound that PR #1029 (v1.9.20) added to wrap the TCP+TLS handshake in open(). The intent was to prevent indefinite stalls during the warm-race, but 8s is too aggressive when Apps Script edges have a cold-start latency >8s — which is what your log shows (rtt=8.001s repeatedly on AKfycby_).

v1.9.24 (just shipped) parameterizes the header-read timeout via request_timeout_secs (PR #1108), but the H1_OPEN_TIMEOUT_SECS constant for handshake is still hardcoded. Will file a follow-up to parameterize that too — likely will land as a 5-line change against domain_fronter.rs. ETA: a few days.

3. Until that follow-up ships, two workarounds:

• Rotate that specific script_id (AKfycby_) out of config.json until you're certain it's healthy again — Apps Script edge state for a given deployment can degrade for hours.
• Try coalesce_max_ms: 5000 to pack more ops per batch — fewer batches per minute means fewer hits on the 8s handshake bound.

Leaving open as the tracking issue for H1_OPEN_TIMEOUT_SECS parameterization.

---

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

[BuffOvrFlw]

@therealaleph
Would you please also check how & why:

ERROR batch JSON parse error: key must be a string at line 1 column 2 (body_len=168)

Happens so frequently after some time using the script? (like a day or two, after being deployed & I DIDNT REACH LIMIT)