Repository navigation
relay error: h1 open timed out after 8s #1131
Description
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:
- 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.
- 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
- 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)
Activity
dazzling-no-more commentedon May 13, 2026
Hi @BuffOvrFlw — the
h1 open timed out after 8smessage 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.001slines in your log confirm the handshake toconnect_host:443is 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-ipsto find a faster Google edge IP from your VPSgoogle_ip/connect_hoststill points at a real Google frontend"force_http1": truewon't help here — this is the h1 pathfix(tunnel): batch header read honors request_timeout_secs (#1088, #1108
therealaleph commentedon May 13, 2026
Reviewed via Anthropic Claude.
@BuffOvrFlw — thanks for the careful writeup. Three things:
1. Your two empirical workarounds are real and worth documenting:
Both noted — will see if either deserves a code-level check or a docs note.
2.
h1 open timed out after 8s: this is theH1_OPEN_TIMEOUT_SECS = 8bound that PR #1029 (v1.9.20) added to wrap the TCP+TLS handshake inopen(). 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.001srepeatedly onAKfycby_).v1.9.24 (just shipped) parameterizes the header-read timeout via
request_timeout_secs(PR #1108), but theH1_OPEN_TIMEOUT_SECSconstant for handshake is still hardcoded. Will file a follow-up to parameterize that too — likely will land as a 5-line change againstdomain_fronter.rs. ETA: a few days.3. Until that follow-up ships, two workarounds:
script_id(AKfycby_) out ofconfig.jsonuntil you're certain it's healthy again — Apps Script edge state for a given deployment can degrade for hours.coalesce_max_ms: 5000to 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_SECSparameterization.[reply via Anthropic Claude | reviewed by @therealaleph]
BuffOvrFlw commentedon May 13, 2026
@therealaleph
Would you please also check how & why:
Happens so frequently after some time using the script? (like a day or two, after being deployed & I DIDNT REACH LIMIT)