extremely SLOW speed in Full tunnel node

[ehsan272727]

I tested the full tunnel node on the new 1.9.22 version and it's so slow, so much as to be considered totally unusable (Android version tested)

[madkobs1242]

Yes, I also tested the full tunnel with docker and other methods on version 1.9, but the speed is so low that it cannot be used. Do you have to do something special or apply special settings?

[therealaleph]

Reviewed via Anthropic Claude.

@ehsan272727 — v1.9.22 includes the H2-skip-for-tunnel fix (#1040 + #1041) which restored v1.9.14 tunnel performance on Pixel 6 Pro per yyoyoian-pixel's A/B test (0/30 vs 8-10/30 long-poll stalls). "Totally unusable" on Android v1.9.22 specifically is unexpected and worth narrowing.

What I need to debug:

1. Confirm version: mhrv-rs --version (Android UI shows on main screen).
2. Speed metric: fast.com through proxy — what Mbps does it show?
3. Sample log around a slow request: adb logcat -s mhrv-rs from a connected Android dev session, captured during one specific failing browse action.
4. Specifically check for: 16s, 17s, or 30s patterns in the log — those are the long-poll stall + batch-timeout patterns. v1.9.22 should NOT show those anymore on the tunnel-batch path.
5. Topology: which GitHub Actions tunnel method are you using? cloudflared Quick / ngrok / cloudflared Named? Or VPS?

If you don't see any 16-30s stall patterns in the log but speeds are slow, that's a different bottleneck (likely Apps Script edge throttle, not h2 perf — see #895 / #1000).

If you DO see the stall patterns on v1.9.22, that's a real regression vs the PR's A/B claim, and we need to dig into why the Android build behaves differently than yyoyoian-pixel's tested Pixel 6 Pro.

Leaving open until you can post the log.