مشکل در دانلود فایل

[MSLight]

موقع دانلود فایل از سایت هایی مثل گیت هاب خطای 502 دریافت میکنم و تو IDM هم خطای ssl connect error 5 میگیرم. داخل IDM پروکسی ست شده.

[creep247]

از یک وب پروکسی استفاده کن مثل این:

https://power.re/proxy/

یا از outbound proxy باید استفاده کرد که نمی دونم چرا برای من کار نمی‌کنه

[therealaleph]

خطای ‫502‬ روی دانلود از ‫GitHub‬ معمولاً یکی از سه چیزه — بستگی به اینکه کدوم نسخه mhrv-rs رو می‌زنید و چه حجم فایلی:

۱. ‫50 MB per-fetch limit‬ Apps Script: هر فراخوانی ‫UrlFetchApp‬ حداکثر ۵۰ مگابایت پاسخ می‌تونه برگردونه. برای فایل‌های بزرگتر ما از ‫range-parallel‬ استفاده می‌کنیم (هر ‫chunk‬ 256 KB، هم‌زمان چندتا) که از ‫v1.1.4‬ پیاده‌سازی شد. اگه فایل خیلی بزرگه و سرور Accept-Ranges: bytes نمی‌ده (که GitHub می‌ده)، کار می‌کنه. اگه نمی‌ده، خطا می‌دیم.

۲. ‫IDM‬'s multi-connection downloads: ‫IDM‬ فایل‌ها رو با ۸-۱۶ کانکشن همزمان می‌کشه، هر کانکشن ‫Range‬ خودش رو می‌فرسته. روی ‫Apps Script‬ این یعنی ۸-۱۶ تا ‫HTTP request‬ موازی تو چند ثانیه — هر کدوم شمردهٔ سهمیه. ممکنه سریعاً به rate-limit بخورید یا دو تا request روی هم بیفتن و متناقض بشن.

۳. ‫SSL Connect Error 5‬ in IDM: این خطای ‫WinINET/Schannel‬ می‌گه "سرور TLS درست رو نتونست handshake کنه". دو علت شناخته‌شده:

• ‫CA‬ ما روی ‫Windows certificate store‬ نصب نشده. فقط روی مرورگر نصب کردید؟ ‫IDM‬ از ‫Windows‬ store استفاده می‌کنه. دستور:

  certutil -addstore -user ROOT "%APPDATA%\mhrv-rs\mitm-ca.crt"

• ‫TLS 1.3‬ که ‫IDM‬ با ‫Windows 7/8‬ قدیمی نمی‌تونه مذاکره کنه — ولی ‫mhrv-rs‬ فعلاً ‫TLS 1.2‬ پاسخ می‌ده به inbound.

پیشنهاد عملی:

برای دانلود فایل‌های حجیم از GitHub، حالت ‫google_only‬ رو امتحان کنید (از ‫v1.2.0‬):

{ "mode": "google_only", ... }

تو این حالت ترافیک غیر Google (مثل GitHub که از طریق Fastly CDN هست) مستقیم ‫plain-TCP passthrough‬ می‌شه — بدون Apps Script quota، بدون size limit. اگه ISP شما مستقیم به ‫GitHub Fastly IPs‬ دسترسی داره، دانلود کامل عبور می‌کنه. اگه نداره، این روش کار نمی‌کنه.

راه دوم: تنظیم ‫upstream_socks5‬ به یه VPS خارج کشور → همه fetch های Apps Script + plain-TCP از اون VPS خارج می‌شن → GitHub IP VPS رو می‌بینه، رمز CDN blocking نمی‌خوره.

لطفاً بفرمایید:

• نسخهٔ ‫mhrv-rs‬؟
• حجم فایلی که دانلود می‌کنید؟
• ‫CA‬ رو تو ‫Windows certificate store‬ نصب کردید یا فقط مرورگر؟

---

_{[پاسخ از ‫Anthropic Claude‬ | بازبینی‌شده توسط ‫@therealaleph‬]}

[creep247]

پیشنهاد عملی:

Can you implement this in RUST? maybe this can fix this problem:
masterking32/MasterHttpRelayVPN#18

[therealaleph]

Read through the upstream PR (masterking32/MasterHttpRelayVPN#18) — it's a substantial rework, ~1900 lines across 10 files, currently still open (not merged). The scope includes:

• A new stream_parallel_download path that starts sending bytes to the client immediately while fetching remaining ranges in parallel (instead of buffering whole file then delivering at once)
• Disk-backed spooling for ordered chunk delivery during streaming
• Per-range Content-Range validation → we already landed this in PR domain_fronter: validate range-parallel 206 responses before stitching #78 (v1.2.4)
• Initial range-probe retries
• Host cooldown for flaky download targets
• Moved range downloads off H2 onto H1 pool
• Progress logging
• Configurable timeouts + body cap
• Safer retry-on-non-idempotent

What matters for your specific IDM case:

The piece that would measurably help is the streamed delivery. Current behaviour: we buffer the entire response body, then flush to the client. With IDM pulling 8-16 parallel connections per file, that's 8-16 full-file buffers fighting for memory + quota, and the browser / IDM sits idle until each one finishes. Streamed delivery means IDM gets progress bytes immediately per range, which matches its download model.

Why I'm not porting it yet:

1. The upstream PR isn't merged. If I port it now and the design shifts during their review, we have to reconcile twice.
2. It's a big architectural move (swaps relay_parallel_range's whole shape for a streaming + spool-to-disk variant). We currently buffer-then-send. That's a fundamental state-machine change that needs its own dedicated review cycle, not a one-line patch.
3. Our existing relay_parallel_range (ported in v1.1.4 + hardened in v1.2.4 via PR domain_fronter: validate range-parallel 206 responses before stitching #78) already works for most cases — GitHub downloads ≤50 MB should already succeed. For files >50 MB or with IDM-style multi-connection patterns, the streaming version would genuinely fix what the current code can't.

What I'll do:

• Track this issue for when upstream PR no file descriptors available (os error 24) #18 merges, then port as a focused follow-up.
• In the meantime, the concrete workarounds for your specific case:
  • google_only mode — GitHub traffic goes direct plain-TCP (no Apps Script, no size limit). Works if your ISP doesn't block GitHub Fastly directly.
  • upstream_socks5 to a VPS — egress via the VPS so GitHub sees the VPS IP and Apps Script limits stop mattering for GitHub traffic.
  • Disable multi-connection downloads in IDM — set "Max connections per download = 1". Single connection will go through our existing range-parallel path cleanly.

If any of these works for your case, please report which so I can add it to the FAQ. And if you want to be the tester when we port upstream PR #18, I'll ping you on the follow-up.

---

_{[reply via Anthropic Claude | reviewed by @therealaleph]}

[creep247]

The upstream PR is now merged
masterking32/MasterHttpRelayVPN#18

[therealaleph]

Thanks for the heads up — confirmed: upstream PR #18 merged as commit [check the merge]. Now that it's landed upstream, the port is unblocked.

I'll schedule it as a follow-up: streaming parallel download path + per-range validation + host-cooldown + progress logging. It's a ~1900-line rework of domain_fronter.rs so it won't be a quick port — it needs its own focused PR and careful side-by-side testing to make sure we don't regress the v1.2.4 range-parallel validation or v1.2.10 JoinSet shutdown. Not batching into a bug-fix release.

Tracking this here. Will reply with a PR link when the port starts.

---

_{[reply via Anthropic Claude | reviewed by @therealaleph]}

[Plangto]

از یک وب پروکسی استفاده کن مثل این:

https://power.re/proxy/

یا از outbound proxy باید استفاده کرد که نمی دونم چرا برای من کار نمی‌کنه

چطوری باید ازش استفاده کرد؟

[therealaleph]

@Plangto در پاسخ سؤالتون دربارهٔ outbound proxy:

upstream_socks5 فیلدی در تنظیمات mhrv-rs هست که ترافیک خروجی خود mhrv-rs رو از طریق یک SOCKS5 proxy (معمولاً روی VPS خارج از کشور) رد می‌کنه. در UI دسکتاپ این فیلد در بخش Advanced هست؛ در config.json هم به این شکل:

{
  "upstream_socks5": "socks5://127.0.0.1:1080"
}

یا با احراز هویت:

{
  "upstream_socks5": "socks5://username:password@host:port"
}

ولی مهم: این فیلد فقط کاربرد داره اگه یک SOCKS5 server واقعی در دسترستون هست. خود mhrv-rs یه SOCKS5 server نیست — این گزینه بهش میگه "ترافیکت رو به این آدرس SOCKS5 بده". سه سناریوی معمول:

۱. Xray / V2Ray روی یک VPS خارجی — اکثر کاربران ایرانی این رو دارن. آدرسش معمولاً یه چیزی مثل socks5://127.0.0.1:10808 بعد از اینکه کلاینت Xray روی ویندوز/مک بالا میاد.

۲. Tor — اگه Tor Browser رو نصب کردید، SOCKS5 روی socks5://127.0.0.1:9050 گوش میده. کنده ولی رایگان و بدون نیاز به VPS.

۳. SSH SOCKS5 tunnel — اگه دسترسی SSH به یه سرور خارج کشور دارید:

ssh -D 1080 user@your.server.com

بعد "upstream_socks5": "socks5://127.0.0.1:1080".

چرا برای creep247 کار نمی‌کرد: احتمالاً SOCKS5 proxy که استفاده می‌کرد روی یک IP ایرانی بوده، که GitHub Fastly رو نمی‌تونه حل کنه. یا آدرس proxy اشتباه وارد شده بوده، یا خود proxy در حال کار نبوده. هیچ جادویی در upstream_socks5 نیست — تونل شما فقط به اندازهٔ proxy که بهش وصلید خوب هست.

اگه VPS خارجی ندارید و فقط می‌خواید فایل‌های بزرگ از GitHub دانلود کنید، راه‌حل ساده‌تر:

• حالت google_only رو امتحان کنید. در این حالت GitHub مستقیم plain-TCP passthrough میشه (بدون Apps Script)، اگه ISP شما بتونه Fastly IPs رو حل کنه، فایل‌ها کامل دانلود میشن بدون محدودیت حجم.

در مورد دربارهٔ web proxy که creep247 معرفی کرد (power.re/proxy): این یک وب‌سایت third-party هست که URLها رو رله می‌کنه. کنترلش در دست ما نیست، توصیه نمی‌کنیم برای چیزهای حساس، ولی برای دانلود یه فایل عمومی احتمالاً کار می‌کنه. روش استفاده: آدرس سایت رو باز می‌کنید، URL فایل هدف رو می‌چسبونید، دانلود می‌کنید.

---

_{[reply via Anthropic Claude | reviewed by @therealaleph]}

[therealaleph]

بسته می‌شه — رو با مثال توضیح دادم. اگه با proxy خارجی شما کار نکرد، یه issue جدید با خروجی log باز کنید — اون یه case متفاوت از این هست.

---

_{[reply via Anthropic Claude | reviewed by @therealaleph]}

[Plangto]

از یک وب پروکسی استفاده کن مثل این:

https://power.re/proxy/

یا از outbound proxy باید استفاده کرد که نمی دونم چرا برای من کار نمی‌کنه

سلام چطوری از این میشه استفاده کرد؟