full tunnel slow

[madkobs1242]

سلام و درود

Hello, don't be discouraged. I used version 1.9.22 on the server and client.
The result was very slow and only Google would bring it up at a terrible speed.
I went to version 1.7.1 on both the server and client and the result was still the same
I also used 1 and 4 deployments id but the problem is the same.

My log on version 1.7.1

INFO dispatch www.google.com:443 -> full tunnel (via batch mux)
2026-05-12T10:24:09.972589Z INFO batch: 1 ops → AKfycbzB, rtt=152.2µs
2026-05-12T10:24:09.972599Z WARN batch failed: io: peer closed connection without sending TLS close_notify: https://docs.rs/rustls/latest/rustls/manual/_03_howto/index.html#unexpected-eof
2026-05-12T10:24:09.972632Z ERROR tunnel connect_data error for www.google.com:443: io: peer closed connection without sending TLS close_notify: https://docs.rs/rustls/latest/rustls/manual/_03_howto/index.html#unexpected-eof
2026-05-12T10:24:10.714080Z INFO batch: 1 ops → AKfycbzd, rtt=2.1977987s
2026-05-12T10:24:10.714146Z INFO tunnel session 13d64ac7-61b9-44f1-90a6-737cf1bd35e1 opened for www.bing.com:443
2026-05-12T10:24:11.478588Z INFO dispatch www.google.com:443 -> full tunnel (via batch mux)
2026-05-12T10:24:14.829383Z INFO batch: 1 ops → AKfycbwJ, rtt=4.0832562s

my log on version 1.9.22:

INFO tunnel session e3a8f64b-c1c6-4a2c-9c44-a1b3351288b2 closed for assets.msn.com:443
2026-05-12T10:33:27.301658Z INFO batch: 1 ops → AKfycbzd, rtt=10.0088695s
2026-05-12T10:33:27.301679Z WARN blacklisted script AKfy...UMiR for 120s: 3 timeouts in 30s
2026-05-12T10:33:27.301684Z WARN batch failed (script AKfycbzd): timeout
2026-05-12T10:33:27.301707Z INFO tunnel session cb6d1b53-d717-4e5a-8ddd-7aedb55a93c9 closed for browser.events.data.msn.com:443
2026-05-12T10:33:27.301797Z INFO dispatch assets.msn.com:443 -> full tunnel (via batch mux)
2026-05-12T10:33:27.557442Z INFO batch: 1 ops → AKfycbzd, rtt=10.0158517s
2026-05-12T10:33:27.557468Z WARN batch failed (script AKfycbzd): timeout
2026-05-12T10:33:27.557510Z INFO tunnel session c6644c79-e2f3-4629-b7b8-60bdccf93167 closed for access-point.cloudmessaging.edge.microsoft.com:443
2026-05-12T10:24:09.972599Z WARN batch failed: io: peer closed connection without sending TLS close_notify: https://docs.rs/rustls/latest/rustls/manual/_03_howto/index.html#unexpected-eof
2026-05-12T10:33:27.791227Z INFO batch: 1 ops → AKfycbzd, rtt=11.3118499s
2026-05-12T10:33:27.791256Z WARN batch failed (script AKfycbzd): timeout

[madkobs1242]

....

[therealaleph]

Reviewed via Anthropic Claude.

@madkobs1242 — "v1.9.22 ultra-slow, v1.7.1 better" pattern is consistent with the v1.9.15-1.9.21 Full-mode warm-race regression (#924) that's been the longest-running thread in the project.

v1.9.20 fixed it (PR #1029): h1 prewarm in parallel with h2 handshake. v1.9.21 followed up with H2-skip for tunnel batches. v1.9.24-1.9.25 further hardened with header timeout cascade fix + udpgw clash fix.

Latest is v1.9.25 (just shipped). Try the binaries from the Releases page. For Full mode specifically + slow VPS connection, also set in config.json:

{
  "request_timeout_secs": 60,
  "coalesce_max_ms": 3000
}

request_timeout_secs was hardcoded 10s internally until v1.9.24 — your v1.9.22 was hitting that cliff. v1.9.24 makes it configurable.

v1.7.1 "better" because pre-h2 era used a simpler h1-only path that didn't have the warm-race. The h2 path is genuinely faster in steady state (PR #1040's A/B confirmed) but needed v1.9.20's fix to actually work on cold start.

می‌بندم — try v1.9.25 with the config tweaks above. Reopen with v1.9.25 log if still slow.