Repository navigation
ارور the script completed but did not return anything در فول تانل #391
Description
Activity
@hamed0937 —
No json in batch responseدر Full tunnel یعنی Apps Script یه پاسخ غیر-JSON برمی‌گردونه که اصولاً body decoy یا error HTML هست. در Full mode دو علت متداول داره:۱. AUTH_KEY mismatch (بین mhrv-rs config ↔ CodeFull.gs در Apps Script)
۲. TUNNEL_AUTH_KEY mismatch (بین CodeFull.gs ↔ tunnel-node container env var) — این بیشتر شایع هست از علت ۱علت TUNNEL_AUTH_KEY: متغیر محیطی tunnel-node container
TUNNEL_AUTH_KEYهست. ولی برخی منابع docs اشتباهاًMHRV_AUTH_KEYنوشتن. اگر شما با-e MHRV_AUTH_KEY=...در docker run setup کردید، اون env ignore میشه + tunnel-node defaultchangemeرو به‌عنوان TUNNEL_AUTH_KEY فرض میکنه. CodeFull.gs شماTUNNEL_AUTH_KEY="your-real-key"داره، که match نمی‌کنه با container'schangeme→ tunnel-node decoy nginx-404 برمی‌گردونه → CodeFull.gs اون رو می‌خونه + می‌بینه JSON نیست → exception → response array empty یا null → mhrv-rs میگه "No json in batch response".Fix در ۳ مرحله:
۱. در CodeFull.gs (روی script.google.com):
بالای فایل، خط:const TUNNEL_AUTH_KEY = "your-tunnel-secret";
مقدار
your-tunnel-secretرو copy کنید.۲. روی VPS، tunnel-node رو با env var درست restart کنید:
ssh root@your-vps-ip docker stop mhrv-tunnel docker rm mhrv-tunnel # مهم: TUNNEL_AUTH_KEY (نه MHRV_AUTH_KEY) docker run -d --name mhrv-tunnel \ --restart unless-stopped \ -p 8443:8443 \ -e TUNNEL_AUTH_KEY="EXACT_VALUE_FROM_CodeFull.gs" \ ghcr.io/therealaleph/mhrv-tunnel-node:latest # Verify: docker exec mhrv-tunnel env | grep TUNNEL_AUTH_KEY # باید ببینید: TUNNEL_AUTH_KEY=your-real-value
۳. تست direct با curl از VPS یا machine outside Iran:
curl -X POST 'https://YOUR_TUNNEL_URL/tunnel' \ -H 'Content-Type: application/json' \ -d '{"k":"YOUR_TUNNEL_AUTH_KEY","op":"connect","host":"www.google.com","port":443}' \ --max-time 10
نتایج:
{"sid":"...","s":200,...}= tunnel-node OK<!DOCTYPE html>...nginx...= TUNNEL_AUTH_KEY هنوز mismatch هست- timeout = tunnel-node URL از خارج قابل دسترس نیست (firewall یا port mapping VPS)
برای debug آسون‌تر: v1.8.0+ یک env var داره:
docker run -d ... -e MHRV_DIAGNOSTIC=1 ...
این باعث میشه tunnel-node به‌جای decoy 404، JSON
{"e":"unauthorized"}صریح برمی‌گردونه — فقط برای setup. بعد از حل مشکل، MHRV_DIAGNOSTIC رو حذف کنید (default off = production-strong).اگه این مسیر کمک نکرد و TUNNEL_AUTH_KEYها هم match می‌کنن: مشکل میتونه AUTH_KEY باشه (نه TUNNEL_AUTH_KEY). همان workflow ولی برای
AUTH_KEY(در config.json mhrv-rs ↔ Code.gs/CodeFull.gs).نتیجه + log رو share کنید + می‌تونیم narrow کنیم.
[reply via Anthropic Claude | reviewed by @therealaleph]
تشکر بابت سرعت بالا در پاسخدهی
مو به مو اجرا شد هم برای tunnel auth key
و هم برای auth keyولی همون ارور دریافت شد
(متاسفانه بخاطر مشقت های کار با ترمیوس در اندروید موقع اجرای دستور دیباگ کرش میکنه و عذاب میده ولی مو به مو اجرا کردم)ایا امکان اموزش ویدیویی یا ویسی هست؟
یا چه کار دیگه ای میشه کرد؟
در ضمن ، اسکریپت در حالات دیگه بجز تانل اجرا میشه بدون مشکل
و همه سایت ها تحت وب باز میشن با همین اسکریپتی که ساختم برای تانل
تمام مواردی که توی مشکلات دیگران بود رو هم چک کردم
حتی ورژن دیپلای و ...من هم بعد از آپدیت 1.8.0 و بروزرسانی fullcode.gs و داکر سمت سرور به شدت دارم این ارورو رو دریافت میکنم
نکته ای که هست اینه که سرعت لود بسیار پایینتر اومده اما همچنان میتونه لود کنه بعضی از ریکوست هارو و کامل از کار نیوفتاده تانل پس نمیشه گفت که مشکل از کانفیگ و یا credentials هستبخشی از لاگ مربوطه :
2026-04-28T09:24:06.521078Z INFO dispatch signaler-pa.youtube.com:443 -> full tunnel (via batch mux) 2026-04-28T09:24:06.534895Z INFO batch: 1 ops → AKfycbxO, rtt=470.2µs 2026-04-28T09:24:06.534908Z 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-04-28T09:24:06.534922Z ERROR tunnel connect_data error for signaler-pa.youtube.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-04-28T09:24:07.538689Z INFO dispatch signaler-pa.youtube.com:443 -> full tunnel (via batch mux) 2026-04-28T09:24:07.748876Z INFO batch: 1 ops → AKfycbwt, rtt=2.3268993s2026-04-28T09:12:50.860071Z WARN batch failed: timeout 2026-04-28T09:12:50.860083Z ERROR tunnel connect_data error for rr4---sn-4g5lznes.googlevideo.com:443: timeout 2026-04-28T09:12:50.860103Z ERROR tunnel connect_data error for rr4---sn-4g5lznes.googlevideo.com:443: timeout 2026-04-28T09:12:50.860124Z ERROR tunnel connect_data error for rr4---sn-5hne6nzk.googlevideo.com:443: timeout 2026-04-28T09:12:51.384591Z INFO batch: 1 ops → AKfycbwc, rtt=1.778397s 2026-04-28T09:12:51.384611Z WARN batch failed: bad response: no json in batch response: <!DOCTYPE html><html><head><title>Web App</title></head><body><p>The script completed but did not return anything.</p></body></html> 2026-04-28T09:12:51.384630Z INFO tunnel session 1a817c5c-556c-4005-8b0b-d49983da9e6e closed for www.youtube.com:443 2026-04-28T09:12:51.792534Z INFO batch: 1 ops → AKfycbxw, rtt=2.0310722s 2026-04-28T09:12:52.126021Z INFO batch: 1 ops → AKfycbwQ, rtt=2.1158961s 2026-04-28T09:12:52.152543Z INFO batch: 1 ops → AKfycbx8, rtt=1.8158332s 2026-04-28T09:12:52.680698Z INFO batch: 1 ops → AKfycbx8, rtt=11.7918543sReacted by دکتر حامد دلجوئی@EBRAHIM-AM — متفاوت از مشکل @hamed0937 (که TUNNEL_AUTH_KEY mismatch بود). شما می‌گید tunnel مقداری کار میکنه + سرعت پایینه + بعضی timeouts. این performance regression هست، نه auth issue. سه احتمال:
۱. v1.8.0 random padding overhead:
v1.8.0 یک
_padfield random length 0-1024 byte به هر request اضافه میکنه (DPI defense). متوسط ~512 byte اضافی per batch. روی batchهای ~۲ KB، این یعنی +25% bandwidth + processing per request. در شرایط Iran ISP throttle، این 25% میتونه difference بین "slow but works" و "timeout" باشه.Test کنید: v1.7.11 رو موقتاً نصب کنید (آخرین نسخه قبل v1.8.0):
- https://github.com/therealaleph/MasterHttpRelayVPN-RUST/releases/tag/v1.7.11
- Compare همان workload روی v1.7.11 vs v1.8.0
- اگه v1.7.11 سریع‌تر = padding overhead قابل تشخیص. اگه same = علت دیگه.
اگه padding بد effect داره، می‌تونیم در v1.8.x flag config برای disable کردن padding اضافه کنیم (default true ولی override).
۲. v1.7.8's auto-blacklist بیش از حد aggressive:
deployment auto-blacklist (#319) بعد از 3 timeout در 30s، 120s blacklist میکنه. اگه شما در high-latency Iran ISP هستید + برخی batches normal timeout می‌گیرن (5-10 sec)، در غضب 30-second window 3 تا collected میشن + deployment unnecessarily blacklist میشه.
Test: log mhrv-rs رو نگاه کنید — اگه
WARN blacklisted script ... for 120s: 3 timeouts in 30sمی‌بینید + بلافاصله بعدشbatch failed: timeoutcascade، این علتش هست. شما با کم‌تعداد deployments بدتر هستید (با 6 deployment، یکی blacklist بشه, 5 دیگه serve می‌کنن. با 1 deployment، blacklist = total down).Workaround: بیشتر deployment add کنید (ideal: 5-6). یا منتظر v1.8.x که strike threshold رو tunable میکنه.
۳. Iran ISP throttle شدت گرفته (مستقل از v1.8.0):
از حدود ۲۶ آپریل، Iran ISP throttle Apps Script outbound شدت گرفته (#313). v1.8.0 شاید coincidentally روی این throttle increase افتاد — مرتبط زمانی، نه causal.
Test: کاربران دیگه‌ای که setup شما رو شناخته شده دارن (مشابه ISP، deployment count، region) — اونا هم همین experience دارن؟ از کانال‌های Telegram فارسی mhrv-rs check کنید.
Diagnostic لطفاً:
- چند تا deployment ID دارید؟ (1 = high blacklist risk، 6+ = adequate)
- زمان شروع پایین شدن سرعت چی بود؟ (دقیق پس از update v1.8.0، یا چند ساعت بعد، یا فردا)
- همچنین لاگ کامل mhrv-rs (~30 ثانیه moment of slowness) رو share کنید —
RUST_LOG=debugبهتره - Direct curl test از داخل ایران بدون mhrv-rs:
اگه این هم slow/timeout = ISP issue (causal Reconnection fails due to SOCKS/HTTP ports not being released after stop #3). اگه fast = mhrv-rs path issue (1 یا 2).
curl -X POST 'https://script.google.com/macros/s/YOUR_DEPLOYMENT/exec' \ -H 'Content-Type: application/json' \ -d '{"k":"YOUR_KEY","u":"https://httpbin.org/get","m":"GET"}' \ --max-time 15
نتایج رو share کنید + می‌تونیم narrow کنیم.
[reply via Anthropic Claude | reviewed by @therealaleph]
i tried [v1.7.11] , the behavior is same .
1.I have 10 deployment id's prepared in config
2. -
3.2026-04-28T09:40:27.994816Z ERROR tunnel connect_data error for push.services.mozilla.com:443: timeout 2026-04-28T09:40:28.206672Z INFO batch: 1 ops → AKfycbx8, rtt=1.957s 2026-04-28T09:40:29.920784Z INFO batch: 1 ops → AKfycbw-, rtt=2.309528s 2026-04-28T09:40:29.920820Z INFO tunnel session 05cd0e06-d51c-406e-b002-d042db4b73a8 opened for www.google.com:443 2026-04-28T09:40:29.920913Z INFO tunnel session 05cd0e06-d51c-406e-b002-d042db4b73a8 closed for www.google.com:443 2026-04-28T09:40:30.105784Z INFO batch: 1 ops → AKfycbx7, rtt=4.1145918s 2026-04-28T09:40:30.357419Z INFO batch: 1 ops → AKfycbxO, rtt=2.5775417s 2026-04-28T09:40:30.539721Z INFO dispatch check-host.net:443 -> full tunnel (via batch mux) 2026-04-28T09:40:30.801887Z INFO batch: 1 ops → AKfycbwj, rtt=2.5736677s 2026-04-28T09:40:30.801900Z WARN batch failed: bad response: no json in batch response: <!DOCTYPE html><html><head><title>Web App</title></head><body><p>The script completed but did not return anything.</p></body></html> 2026-04-28T09:40:30.801924Z INFO tunnel session 67db6a78-4ad7-4147-8eb6-4a1ae35fb8e4 closed for httpbin.org:443 2026-04-28T09:40:32.125620Z INFO batch: 1 ops → AKfycbzs, rtt=16.6096419s 2026-04-28T09:40:32.125636Z WARN batch failed: timeout 2026-04-28T09:40:32.125660Z INFO tunnel session dd332506-e8be-4b52-ae96-f7c7bb346ace closed for ads.mozilla.org:443 2026-04-28T09:40:32.181662Z INFO batch: 1 ops → AKfycbwQ, rtt=7.3354651s 2026-04-28T09:40:32.447883Z INFO batch: 1 ops → AKfycbxw, rtt=2.0662479s 2026-04-28T09:40:32.913753Z INFO batch: 1 ops → AKfycbwc, rtt=2.7944401s 2026-04-28T09:40:33.369085Z INFO batch: 1 ops → AKfycbxO, rtt=13.5952297s 2026-04-28T09:40:33.369098Z WARN batch failed: timeout 2026-04-28T09:40:33.369154Z ERROR tunnel connect_data error for i.pn:443: timeout 2026-04-28T09:40:33.434945Z INFO batch: 1 ops → AKfycbx7, rtt=2.6175496s 2026-04-28T09:40:34.515193Z INFO batch: 1 ops → AKfycbwQ, rtt=3.9593081s 2026-04-28T09:40:34.515228Z INFO tunnel session 32d1ec4d-0a04-4f81-a33c-9b6a4385d3ea opened for check-host.net:443 2026-04-28T09:40:35.244440Z INFO batch: 1 ops → AKfycbx8, rtt=3.1023087s 2026-04-28T09:40:35.272127Z INFO batch: 1 ops → AKfycbwj, rtt=2.3374826s 2026-04-28T09:40:35.894906Z INFO batch: 1 ops → AKfycbw-, rtt=3.4378124s 2026-04-28T09:40:36.373757Z INFO batch: 1 ops → AKfycbzs, rtt=1.8403401s 2026-04-28T09:40:38.556091Z INFO batch: 1 ops → AKfycbwQ, rtt=2.1595629s 2026-04-28T09:40:38.556103Z WARN batch failed: bad response: no json in batch response: <!DOCTYPE html><html><head><title>Web App</title></head><body><p>The script completed but did not return anything.</p></body></html> 2026-04-28T09:40:38.556121Z INFO tunnel session 32d1ec4d-0a04-4f81-a33c-9b6a4385d3ea closed for check-host.net:443 2026-04-28T09:40:38.628914Z INFO batch: 1 ops → AKfycbwc, rtt=3.3418789s 2026-04-28T09:40:39.252506Z INFO batch: 1 ops → AKfycbxw, rtt=23.4149071s 2026-04-28T09:40:39.252521Z WARN batch failed: timeout 2026-04-28T09:40:39.252545Z ERROR tunnel connect_data error for i.pn:443: timeout 2026-04-28T09:40:39.542562Z INFO batch: 1 ops → AKfycbxw, rtt=3.5473089s 2026-04-28T09:40:39.654495Z INFO dispatch ws.chatgpt.com:443 -> full tunnel (via batch mux) 2026-04-28T09:40:39.950137Z INFO batch: 1 ops → AKfycbzs, rtt=10.0153778s 2026-04-28T09:40:39.950154Z WARN batch failed: timeout 2026-04-28T09:40:40.665096Z INFO batch: 1 ops → AKfycbxO, rtt=7.9622231s 2026-04-28T09:40:41.694154Z INFO batch: 1 ops → AKfycbw-, rtt=2.1006181s 2026-04-28T09:40:41.694314Z INFO tunnel session 1d152f96-3aac-481b-9097-bd3681d91589 closed for i.pn:443 2026-04-28T09:40:41.697635Z INFO dispatch i.pn:443 -> full tunnel (via batch mux) 2026-04-28T09:40:41.961541Z INFO batch: 1 ops → AKfycbxO, rtt=2.2896669s 2026-04-28T09:40:41.961555Z WARN batch failed: bad response: no json in batch response: <!DOCTYPE html><html><head><title>Web App</title></head><body><p>The script completed but did not return anything.</p></body></html> 2026-04-28T09:40:41.961577Z ERROR tunnel connect_data error for ws.chatgpt.com:443: bad response: no json in batch response: <!DOCTYPE html><html><head><title>Web App</title></head><body><p>The script completed but did not return anything.</p></body></html> 2026-04-28T09:40:43.087305Z INFO batch: 1 ops → AKfycbwj, rtt=1.9053393s 2026-04-28T09:40:43.087320Z WARN batch failed: bad response: no json in batch response: <!DOCTYPE html><html><head><title>Web App</title></head><body><p>The script completed but did not return anything.</p></body></html> 2026-04-28T09:40:43.087344Z INFO tunnel session 67925a01-d4c0-41c9-bb5b-c858b57d93e5 closed for chatgpt.com:443 2026-04-28T09:40:45.044796Z INFO batch: 2 ops → AKfycbzs, rtt=3.3310206s 2026-04-28T09:40:45.044821Z INFO tunnel session be1cdebf-bf77-4ed2-bd4d-215a3c07687d opened for i.pn:443 2026-04-28T09:40:46.940066Z INFO batch: 1 ops → AKfycbxw, rtt=22.6280187s 2026-04-28T09:40:46.940081Z WARN batch failed: timeout 2026-04-28T09:40:46.940098Z ERROR tunnel connect_data error for www.google.com:443: timeout 2026-04-28T09:40:46.993817Z INFO batch: 1 ops → AKfycbx8, rtt=8.2672167s 2026-04-28T09:40:47.414354Z INFO batch: 1 ops → AKfycbxw, rtt=2.3587646s 2026-04-28T09:40:47.414368Z WARN batch failed: bad response: no json in batch response: <!DOCTYPE html><html><head><title>Web App</title></head><body><p>The script completed but did not return anything.</p></body></html> 2026-04-28T09:40:47.414397Z INFO tunnel session be1cdebf-bf77-4ed2-bd4d-215a3c07687d closed for i.pn:443 2026-04-28T09:40:47.814974Z INFO dispatch alive.github.com:443 -> full tunnel (via batch mux)- for the curl command , i cant run it directly without mhrv-rs because its not possible to connect to script.google.com and it returns timeout.
@EBRAHIM-AM — important: v1.7.11 same behavior as v1.8.0 rules out the random padding theory. Plus 10 deployments rules out the auto-blacklist-too-aggressive theory (with 10, even if 3 are blacklisted, 7 still serve).
So neither v1.8.0 change is the cause. The pattern is ISP intermittent throttling — some batches pass through, others get RST'd or timed out, regardless of mhrv-rs version.
Looking at your log:
ERROR tunnel connect_data error for push.services.mozilla.com:443: timeout INFO batch: 1 ops → AKfycbx8, rtt=1.957s ← succeeds INFO batch: 1 ops → AKfycbw-, rtt=2.309528s ← succeeds INFO tunnel session ... opened for www.google.com:443 ← succeedsMixed success/failure, even within seconds of each other. That's the Iran ISP pulse-throttle signature (#313) — not a bug in mhrv-rs.
About
push.services.mozilla.com: that's Firefox's WebPush service. It's hosted on AWS or similar (datacenter IP), and Cloudflare-or-similar anti-bot heuristics may be flagging Apps Script's outbound IP as a datacenter scraper → drop the connection. Plus it's a long-lived TCP push connection → Apps Script's per-fetch model fits poorly. Even on a clean network, push.services.mozilla.com via Apps Script is one of the worst-fit destinations.Workarounds that might help your specific setup:
-
Add Mozilla push to passthrough_hosts so it skips Apps Script entirely (uses your real ISP IP, where the push protocol is designed to live):
{ "passthrough_hosts": [ "push.services.mozilla.com", ".services.mozilla.com" ] }Caveat: only works if your ISP doesn't filter Mozilla push directly.
-
Reduce
parallel_concurrency— fewer simultaneous batches in flight = fewer surface area for ISP middlebox to RST. Try"parallel_concurrency": 4(default is higher, look in your config). -
Use shorter batch coalesce window —
"batch_coalesce_window_ms": 4(default 8) = batches fire faster, individual batches smaller. Each batch has less data = smaller surface for DPI to fingerprint.
Both 2 and 3 trade throughput for reliability. If ISP is heavy-throttling, smaller-but-more-frequent batches sometimes pass where larger-but-fewer batches get blocked.
- If you're on the worst ISP throttle phase, even Full mode + VPS might be the only reliable path. mhrv-rs's apps_script-mode value diminishes when ISP has clamped down hard enough that Apps Script outbound is barely flowing.
Direct curl test (gold standard diagnostic):
curl -s -X POST 'https://script.google.com/macros/s/<one-of-your-deployment-ids>/exec' \ -H 'Content-Type: application/json' \ -d '{"k":"YOUR_AUTH_KEY","u":"https://httpbin.org/get","m":"GET"}' \ --max-time 15 -w "\ntime: %{time_total}s\n"
Run this 5-10 times in a row from your terminal. If half succeed and half timeout/RST, that's your answer: ISP throttle is intermittent, doesn't matter what mhrv-rs does. Adjustments inside mhrv-rs (config, version) can help on the margins but won't fix the underlying ISP-side issue.
If 9/10 succeed via direct curl but mhrv-rs still has issues, that points at mhrv-rs path-specific problem — share log + I can dig deeper.
Net: your setup is fundamentally OK (10 deployments, v1.7.11/v1.8.0 same). The variability you're seeing is the Iran ISP scenario from #313. v1.8.x's
google_iprotation + per-deployment health scoring will tighten this further but won't fully fix it without going Full mode + VPS.
[reply via Anthropic Claude | reviewed by @therealaleph]
-
- added a commit that references this issue
on Apr 28, 2026 i ran the curl command 20 times and 19 times it returned me a response and 1 timeout . this is the response, it it normal ? ( i replaced some words with X myself ) :
C:\Users\Admin>curl -X POST "https://script.google.com/macros/s/$ID/exec" -H "Content-Type: application/json" -d "{\"k\":\"$KEY\",\"u\":\"https://httpbin.org/get\",\"m\":\"GET\"}" --max-time 15 <HTML> <HEAD> <TITLE>Moved Temporarily</TITLE> </HEAD> <BODY BGCOLOR="#FFFFFF" TEXT="#000000"> <!-- GSE Default Error --> <H1>Moved Temporarily</H1> The document has moved <A HREF="https://script.googleusercontent.com/macros/echo?user_content_key=AUkAhnSwfejBAWGimIPVZ8tVt5AZsqSXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX9ye0mebrtDU_h52zMdG3jJu6UICMjr8VgI341U9sezZ7qI3s5XzhVb2n-MQxMiTJ8__z2GjEYtEPiVJa2Mb_13BB6kdCKtfJVhZgPqohyXV4yc6MtRFIQ&lib=MNlh_VgICzFYYUVWHXXXXXXXxwEj2Jnz">here</A>. </BODY> </HTML>@EBRAHIM-AM — excellent diagnostic data. Walking through what your numbers mean:
The "Moved Temporarily" HTML is NOT an error — it's normal Apps Script behavior.
Apps Script always responds to a
POST /macros/s/<id>/execwith an HTTP 302 redirect tohttps://script.googleusercontent.com/macros/echo?.... The actual JSON response is at the redirected URL. mhrv-rs's relay code usesUrlFetchApp.fetch()which auto-follows redirects internally, so it sees the JSON. Yourcurlcommand (without-L) sees only the 302 redirect HTML.To get the real JSON via curl:
curl -L -X POST "https://script.google.com/macros/s/$ID/exec" \ -H "Content-Type: application/json" \ -d "{\"k\":\"$KEY\",\"u\":\"https://httpbin.org/get\",\"m\":\"GET\"}" \ --max-time 15
(
-L= follow redirects). With-L, you'd get{"r":"...","s":200,...}on success.So your 19/20 = 95% success rate is the actual signal.
This means Apps Script outbound from your ISP works 95% of the time — only 5% timeout. That's much better than I expected based on your earlier reports of "severe slowness". Two possible reconciliations:
-
mhrv-rs's batch path has worse success rate than direct curl — maybe because mhrv-rs runs higher concurrency (multiple inflight batches simultaneously) which trips ISP per-flow rate limits more often. Test: lower
parallel_concurrencyto 4 in your config + retry. Smaller surface area might bring success rate up. -
The "slow" experience is from latency variance, not from outright failures. 250-500ms for fast batches, 5-10s for slow ones (just before hitting timeout). Even at 95% success, if 30% of batches take >5 seconds, browsing feels janky. The variance comes from per-Google-edge-IP throttle differences (#313) —
google_iprotation in v1.8.x will help.
Test in v1.8.1 (just shipped): the new
disable_padding: trueflag inconfig.json:{ "disable_padding": true, ... }If padding overhead was a factor, you'd see throughput improve. If success rate stays at 95%, padding isn't the issue + you can leave it on (better DPI defense for free). 5-10 minute test should tell you definitively.
Also v1.8.1's
script_idin failure logs — when a batch times out now, the log says exactly which deployment failed:batch failed (script AKfycbz4): timeout. Over a few minutes you can see which of your 10 deployments are the slowest performers + remove them from rotation.Try v1.8.1 + the diagnostic config tweaks + report back. Your data points are the most useful in this thread because you're testing each variable systematically.
[reply via Anthropic Claude | reviewed by @therealaleph]
-
من فکر کنم مشکلم فراموش شد
بعد دیباگ کردن
دوتا ارور داد
یکی ادرس موحود نیست
و یکی از داده مجاز فراتر رفته اید
برگشتم محدد لینوکس نصب کردم رو سرور
بالا اوردم کد هارو
اینبار دقت کردم تو اون بخش بجای mhrv
بزنم
Tunnel
موقع نصب اولیه...ولی بازم وقتی docker logs mhrv-tunnel
رو میزنممیگه
tunnel_auth_key not set
using defaultsدیگه واقعا گیج شدم!
@hamed0937 — مشکلت یادم نرفته!
tunnel_auth_key not set, using defaultsدر logها یعنی اسم env variable هنوز اشتباه هست. می‌خوام دقیق‌تر توضیح بدم چون اسم env vars خیلی sensitive هست:اسم env variable باید دقیقاً این باشد (نه چیز دیگه‌ای، نه شبیه به این):
TUNNEL_AUTH_KEY- همه‌ش حروف بزرگ
- با underscore (
_) بین کلمات — نه فاصله، نه dash - سه قسمت:
TUNNEL+_+AUTH+_+KEY
اشتباهات رایج که
tunnel_auth_key not setمیده:اشتباه چرا کار نمی‌کنه Tunnelیاtunnel(تنها)اسم کامل نیست، tunnel-node این رو نمی‌خونه Tunnel_Auth_Keyیاtunnel_auth_key(lowercase/mixed)env vars در Linux/Docker case-sensitive هستن TUNNEL-AUTH-KEY(با dash)باید underscore باشه نه dash MHRV_AUTH_KEYاشتباه قدیمی، tunnel-node این رو نمی‌خونه دستور docker run درست — کپی exact:
ssh root@your-vps-ip docker stop mhrv-tunnel docker rm mhrv-tunnel docker run -d --name mhrv-tunnel \ --restart unless-stopped \ -p 8443:8443 \ -e TUNNEL_AUTH_KEY="your-secret-here" \ ghcr.io/therealaleph/mhrv-tunnel-node:latestبه‌جای
your-secret-hereهمون مقداری که در CodeFull.gs گذاشتید بنویسید (هر چی که درconst TUNNEL_AUTH_KEY = "..."نوشتید).verify بعد از start:
docker exec mhrv-tunnel env | grep TUNNEL_AUTH_KEY
اگر خروجی این باشه:
TUNNEL_AUTH_KEY=your-secret-hereدرسته. اگر هیچ خروجی نداد یا خروجی متفاوت بود، دستور
docker runبا اسم اشتباه اجرا شده.از Termius می‌تونید فقط همین یک دستور رو copy-paste کنید + cancel کنید بقیه:
docker exec mhrv-tunnel env | grep TUNNEL_AUTH_KEY
اگر این
TUNNEL_AUTH_KEY=...رو نشون داد، env var درست set شده. اگر empty بود، باید docker run رو دوباره با اسم درست اجرا کنید.
سوال شما درباره ویدیوی آموزشی: الان ویدیویی نداریم برای tunnel-node setup، ولی این idea خوبیه — می‌تونم به عنوان issue جدا روی #392 (که request ویدیوی آموزشی دیگه‌ای هست) ضمیمه کنم برای v1.9.x scope.
چرا apps_script mode (بدون tunnel) کار میکنه ولی full mode نه: apps_script mode فقط نیاز به Code.gs + AUTH_KEY داره (یک کلید). full mode نیاز به CodeFull.gs + AUTH_KEY + tunnel-node container + TUNNEL_AUTH_KEY (دو کلید + یک container روی VPS) داره. هر کدوم از این چهار قسمت اشتباه باشه، full mode fail میکنه. Apps_script mode ساده‌تره چون moving parts کمتری داره.
اگر
TUNNEL_AUTH_KEYرو exact بزنید + هنوز کار نکنه: خروجی این سه دستور رو share کنید:# ۱. env var واقعاً set شده یا نه: docker exec mhrv-tunnel env | grep TUNNEL_AUTH_KEY # ۲. tunnel-node آخرین log: docker logs mhrv-tunnel --tail 50 # ۳. test direct از VPS بدون mhrv-rs: curl -X POST 'http://localhost:8443/tunnel' \ -H 'Content-Type: application/json' \ -d '{"k":"PUT_YOUR_TUNNEL_AUTH_KEY_HERE","op":"connect","host":"www.google.com","port":443}' \ --max-time 10
با این سه خروجی مشکل رو دقیق narrow می‌کنیم.
[reply via Anthropic Claude | reviewed by @therealaleph]
بعد اینکه کار نکرد
بخش اول رو زدم و کلید واقعا ست شده بود
بخش دومی که فرمودین
docker logs mhrv-tunnel --tail 50
2026-04-28T13:33:00.188993Z INFO tunnel_node: tunnel-node listening
on 0.0.0.0:8080و بخش سوم
curl -X POST 'http://localhost:8443/tunnel' \
-H 'Content-Type: application/json'
-d '{"k":"25417fb5c59167570f31ea7f150265c6","op":"connect","host":"www.google.com","port":443}'
--max-time 10
curl: (56) Recv failure: Connection reset by peer@hamed0937 — مشکل پیدا شد! دیدید این خط در log؟
2026-04-28T13:33:00.188993Z INFO tunnel_node: tunnel-node listening on 0.0.0.0:8080tunnel-node داره روی port 8080 listen میکنه، ولی شما curl رو به port 8443 می‌فرستید:
curl -X POST 'http://localhost:8443/tunnel' ← port 8443 اشتباه است ↑ تنظیم شده روی 8080به‌همین دلیل
Connection reset by peerمی‌گیرید — هیچ‌کس روی port 8443 listen نمی‌کنه + kernel TCP RST می‌فرسته.دو فیکس ممکن هست:
Option A: curl رو به port 8080 اصلاح کنید (سریع):
curl -X POST 'http://localhost:8080/tunnel' \ -H 'Content-Type: application/json' \ -d '{"k":"25417fb5c59167570f31ea7f150265c6","op":"connect","host":"www.google.com","port":443}' \ --max-time 10
Option B: port mapping در docker run رو اصلاح کنید (بهتر برای production):
container الان روی port 8080 internal listen میکنه + احتمالاً docker run شما
-p 8443:8080بود (external 8443 → internal 8080). یا-p 8080:8080بود (هر دو 8080). برای ببینیم:docker port mhrv-tunnel
اگر
8080/tcp -> 0.0.0.0:8080نشون میده = هر دو 8080. Option A صحیح هست.
اگر8080/tcp -> 0.0.0.0:8443نشون میده = external 8443 → internal 8080. در اون صورت curl روی 8443 باید کار می‌کرد، ولی نمی‌کنه — یعنی port mapping اشتباه برقرار شده. در این case container رو remove + با explicit-p 8443:8080recreate کنید.برای CodeFull.gs match کنید:
در Apps Script CodeFull.gs بازش کنید + خط
const TUNNEL_URL = "..."رو پیدا کنید. مقدار باید با port که container روی اون reachable هست match کنه:اگر container روی port 8080 پابلیک هست:
const TUNNEL_URL = "http://YOUR_VPS_IP:8080/tunnel";
اگر روی port 8443 پابلیک هست:
const TUNNEL_URL = "http://YOUR_VPS_IP:8443/tunnel";
سپس CodeFull.gs رو redeploy as new version کنید.
خلاصه گام‌به‌گام:
# 1. ببینیم mapping docker port mhrv-tunnel # 2. test directly به port درست (whatever Docker reports) curl -X POST 'http://localhost:<correct_port>/tunnel' \ -H 'Content-Type: application/json' \ -d '{"k":"25417fb5c59167570f31ea7f150265c6","op":"connect","host":"www.google.com","port":443}' \ --max-time 10 # 3. اگر JSON success گرفتید: tunnel-node OK + مشکل از جای دیگری بود # 4. در CodeFull.gs مقدار TUNNEL_URL رو با port درست + IP VPS match کنید # 5. CodeFull.gs رو redeploy as NEW VERSION کنید (نه head)
نکته‌ی مهم: برای curl از خارج VPS (mhrv-rs from Iran via Apps Script → VPS), پورت TCP باید روی firewall + ISP/datacenter پابلیک باشه. در VPS تست کنید:
# روی VPS: sudo ufw status sudo iptables -L INPUT | grep 8080 # یا 8443
اگر firewall blocking بود،
sudo ufw allow 8080(یا 8443) باز کنید.نتیجه
docker port mhrv-tunnel+ curl در port درست رو share کنید + می‌تونیم final narrow کنیم.
[reply via Anthropic Claude | reviewed by @therealaleph]
- added a commit that references this issue
on Apr 30, 2026 v1.9.1 just shipped (~5 min ago) with two relevant changes for your case:
-
Tunable auto-blacklist via config —
auto_blacklist_strikes(default 3),auto_blacklist_window_secs(default 30),auto_blacklist_cooldown_secs(default 120). Single-deployment users hitting transient blips can setauto_blacklist_strikes: 5orauto_blacklist_cooldown_secs: 30for less aggressive lockout. -
TUNNEL_AUTH_KEY clearer warning — when
MHRV_AUTH_KEYis set butTUNNEL_AUTH_KEYisn't, tunnel-node now logs a specific message pointing at the right env var name (catches the recurring docker run typo).
Download v1.9.1 (CI building now, ~30 min): https://github.com/therealaleph/MasterHttpRelayVPN-RUST/releases/tag/v1.9.1 or https://t.me/mhrv_rs.
If your auto-blacklist or TUNNEL_AUTH_KEY situation is fully resolved by v1.9.1, this issue can close — let me know.
[reply via Anthropic Claude | reviewed by @therealaleph]
-
فعلاً این issue را می‌بندم چون بیش از ۷ روز از پاسخ/درخواست اطلاعات گذشته و از طرف گزارش‌دهنده اصلی پیگیری جدیدی نیامده.
اگر مشکل هنوز روی آخرین نسخه وجود دارد، لطفاً همین‌جا دوباره کامنت بگذارید یا issue را reopen کنید و نسخه، mode، شکل config مرتبط و log جدید را بفرستید.
Answered via LLM, Supervised @therealaleph
درود به شما
تمامی مراحل رو طبق دستور العمل اخرتون در پست
#310
اجرا کردم
حتی تمامی مواردی که در پرسش های بعدی بود رو هماعمال کردم ولی همچنان این ارور دریافت میشه
No json in batch response
و
the script completed but did not return anything
(چون با موبایل استفاده میکنم امکان کپی کامل لاک رو ندارم ، عذر خواهم)