Repository navigation
[v1.9.24] SLOW throughput and speed in FULL-TUNNEL mode #1147
Description
In full tunnel mode, internet access speed with nginx (and even without nginx, i.e., direct HTTP connection) is extremely low — practically unusable.
I have tested this on multiple accounts and spent a lot of time tuning and optimizing nginx, but only saw minor improvements.
All code was on version 1.9.22. I have now updated to 1.9.24 — the speed and connection quality improved slightly, but it is still about one third of the speed compared to Appscript mode, Zyrln, or MHR-CFW (both of which are implemented using the same VPS as the exit node and in MITM mode).
I also tried older versions (e.g., 1.9.8), but the speed was even worse.
If this speed issue can be resolved, this solution would become better and more powerful than all currently available methods based on GAS.
Activity
dazzling-no-more commentedon May 13, 2026
Can you post the logs?
mirbaagheri commentedon May 13, 2026
مدل Full tunnel خیلی بد کار میکنه و بعد از چند دقیقه کار کردن کلا از کار میفته و باید برنامه را Stop و Start کنیم.
گوگل اسکریپت متاسفانه از وب سوکت پشتیبانی نمیکنه. اگر نه وضعیت خیلی فرق میکرد. بنابراین ما مجبوریم تمام درخواست ها را از طریق پروتکل HTTP ارسال کنیم.
با کمک جمینای به این 4 پیشنهاد رسیدم:
1. حذف یا جایگزینی Base64 (بهینه‌سازی پهنای باند)
راهکار حرفه‌ای: استفاده از Protobuf یا MessagePack.
فکر میکنم این روش رو بشه روی همه مدل ها پیاده کرد و سرعت رو بالاتر برد.
2. به جای ارسال JSON (که متنی است)، دیتا را به صورت باینری فشرده بین کلاینت و VPS جابه‌جا کنید.
گوگل اسکریپت از Utilities.newBlob() و getBytes() پشتیبانی می‌کند. می‌توانید به جای رشته متن، دیتا را به صورت application/octet-stream ارسال کنید. این کار سرعت لود شدن صفحات سنگین را به شدت بالا می‌برد.
3. پیاده‌سازی Multiplexing (چندکاناله کردن)
4. استفاده از الگوریتم فشرده‌سازی در سمت VPS
چون VPS متعلق به خودتان است، می‌توانید قبل از فرستادن دیتا به گوگل، آن را با الگوریتم Zstd یا Brotli فشرده کنید.
این پیشنهاد هوشمندانه‌ترین راه برای بهبود سرعت بدون دستکاری زیاد در کلاینت است، اما یک نکته فنی دارد.
اگر بخواهید از Zstd یا Brotli استفاده کنید، چون گوگل اسکریپت به صورت داخلی آن‌ها را نمی‌شناسد، باید کتابخانه آن‌ها را به صورت دستی در گوگل پیاده کنید که سرعت اسکریپت را کم می‌کند. اما Gzip در خود گوگل اسکریپت تعبیه شده (Native) و بسیار سریع است.
گوگل اسکریپت می‌تواند دیتای Gzip شده را باز کند (Utilities.ungzip()).
نتیجه: در اینترنت‌های ضعیف ایران، فشرده‌سازی دیتا قبل از ورود به شبکه بین‌المللی، تأثیر معجزه‌آسایی روی سرعت حس‌شده توسط کاربر دارد.
@therealaleph #1137 #1144
therealaleph commentedon May 13, 2026
Reviewed via Anthropic Claude.
@mirbaagheri and original reporter — bringing this thread up to date with the recent perf push:
Already shipped post-this-issue:
tunnel_requestsingle-op path (completed perf: skip H2 for full-tunnel batch requests #1040).request_timeout_secs. Previously a hardcoded 10s inner timeout was cascade-killing tunnel sessions whenever a single Apps Script edge ran cold (8-12s start). Real user-visible fix.udpgwmagic IP moved out of tun2proxy's virtual-DNS range. Fixes "Google + most websites broken while Telegram works" on Android.On Gemini's 4 suggestions (per your comment):
WebSocket support — Apps Script's
UrlFetchAppgenuinely can't do WebSocket (Google's restriction, not ours). Two workarounds for users who need WebSocket: (a) route the WS host via exit_node, which uses realfetchand supports streaming; (b) use Full mode where tunnel-node forwards raw TCP — WebSocket upgrade traverses fine through the tunnel-node leg, the Apps Script leg just sees opaque TCP body bytes. Both paths exist today; we just don't document them as "WebSocket support" because the Apps Script leg isn't WebSocket-aware (it's HTTP request/response that happens to carry bytes either direction).gzip on the wire — already shipped in PR feat: zero-copy full-tunnel mux + base64 off mux thread #881 (v1.9.18, the zero-copy mux + base64-off-mux-thread refactor). Doesn't compress wire (Apps Script's response cap is still on the base64 body), but does eliminate redundant copies. PR feat(code.gs): gzip cache bodies + status-aware TTL (skip 5xx, cap persistent 4xx) #953 (v1.9.x — Code.gs gzip cache bodies) saves quota at the cache layer.
Chunk packing / coalesce tuning — already in config:
coalesce_step_ms(default 10ms) andcoalesce_max_ms(default 1000ms). Increasecoalesce_max_ms: 5000if you want bigger chunks at the cost of latency.Skip GAS for Full mode — defeats the whole project. Apps Script is the DPI-bypass layer; without it, direct Iran-to-VPS HTTP is what gets DPI'd. If raw speed without DPI bypass is what you want, use xray-core + Reality directly on the same VPS (without mhrv-rs).
For your topology specifically (your own VPS + SSL, nginx OR direct): try the latest v1.9.25 binaries (after the release CI finishes in ~30min) + verify
coalesce_max_ms: 5000set + dropforce_http1: trueif you still have it from older workarounds. Should be meaningfully faster than v1.9.22 numbers.In community testing (not yet merged but worth watching): PR #903 (per-session pipelining), PR #958 (CacheService.getAll batching), PR #963 (utls Chrome ClientHello). All target perf.
Closing — v1.9.20-1.9.25 is the perf push response to this issue. If specific topology still slow, post fresh log + current config.
[reply via Anthropic Claude | reviewed by @therealaleph]