no file descriptors available (os error 24)

[Behzad9]

متاسفانه در آخرین نسخه نیز همچنان مشکل no file descriptors available (os error 24) در روتر مبتنی بر OpenWRT x86/64 باقی است با این تفاوت که این بار یک اتصال لحظه‌ای وجود داره ولی بعد از اون دوباره ارور no file descriptors available (os error 24) ظاهر میشه.
بنظر میاد موقع فعالسازی کانکشن و ارسال حجم نسبتاً بالای درخواست‌ها، برنامه دچار مشکل میشه (چون قبل از فعالسازی کانکشن در پسوال، اگر یک پینگ ساده میگیرم، برقراری اتصال رو نشان میده) که یک احتمالش میتونه بخاطر محدودیت منابع در روترها باشه، هرچند من از یک تین کلاینت با 4 گیگ رم، استفاده میکنم.

این بخشی از لاگ برنامه هست که پشت سرهم تکرار و ظاهر میشه:

2026-04-22T12:01:26.500760Z INFO SOCKS5 CONNECT -> 8.8.8.8:53
2026-04-22T12:01:26.500891Z INFO SOCKS5 CONNECT -> 8.8.8.8:53
2026-04-22T12:01:26.501405Z INFO plain-tcp passthrough -> 8.8.8.8:53
2026-04-22T12:01:26.501689Z INFO plain-tcp passthrough -> 8.8.8.8:53
2026-04-22T12:01:26.501924Z INFO SOCKS5 CONNECT -> 8.8.8.8:53
2026-04-22T12:01:26.502374Z INFO plain-tcp passthrough -> 8.8.8.8:53
2026-04-22T12:01:26.502475Z ERROR accept (socks): No file descriptors available (os error 24)
2026-04-22T12:01:26.502673Z ERROR accept (socks): No file descriptors available (os error 24)
2026-04-22T12:01:26.502699Z ERROR accept (socks): No file descriptors available (os error 24)

[therealaleph]

ممنون از گزارش دقیق @Behzad9 — در v0.9.3 حل شد: https://github.com/therealaleph/MasterHttpRelayVPN-RUST/releases/tag/v0.9.3

دو باگ واقعی بود:

۱. حلقهٔ accept بدون backoff. وقتی فضای file descriptor تمام می‌شود، accept() فوراً EMFILE برمی‌گرداند و حلقهٔ قبلی بدون وقفه دوباره فراخوانی می‌کرد — هم لاگ هزار خط یکسان می‌شد، هم CPU از تسک‌های دیگر دزدیده می‌شد پس اتصال‌های موجود هم نمی‌توانستند تمام شوند و fd آزاد کنند. چرخهٔ خودخوشبختی.

در v0.9.3: وقتی EMFILE ببیند، backoff می‌کند (۵۰ms اول، تا ۲s)، لاگ هر ۱۰۰ خطا یک‌بار می‌افتد، و به محض اینکه یک accept موفق شود شمارنده صفر می‌شود. به‌جای هزار خط ERROR، فقط یک WARN با دستورِ درست فیکس.

۲. تلاش بالا بردن RLIMIT_NOFILE خیلی محافظه‌کارانه و بی‌صدا بود. قبلاً فقط به ۱۶۳۸۴ soft می‌رساندیم و اگر hard limit سیستم کمتر بود، ساکت می‌ماند. الان:

• هدف روی ۶۵۵۳۶ soft
• روی لینوکس hard limit هم تا سقف /proc/sys/fs/nr_open بالا می‌آید (معمولاً ۱ میلیون)
• اگر soft پایین‌تر از ۴۰۹۶ ماند، یک WARN در شروع با دستور دقیق fix چاپ می‌شود
• و هر بار در شروع RLIMIT_NOFILE = X/Y (was A/B at startup) لاگ می‌کند تا دقیقاً ببینید چه مقداری در سیستم شماست

لطفاً: بعد از نصب v0.9.3، خروجی اولین لاگ بعد از شروع را اینجا بفرستید — خط RLIMIT_NOFILE = .... این به ما می‌گوید روتر شما اجازهٔ چه مقداری fd می‌دهد.

اگر از procd init استفاده می‌کنید (فایل mhrv-rs.init در آرشیو musl)، این script خودش procd_set_param limits nofile="16384 16384" را ست می‌کند، پس اصلاً نباید EMFILE ببینید. اگر دستی اجرا می‌کنید، قبلش بزنید:

ulimit -n 65536
./mhrv-rs ...

Verified locally — با ulimit -n 128 شبیه‌سازی شد، ۲۴۷ کانکشن همزمان EMFILE زد، اما به‌جای هزار خط فقط یک warning لاگ شد و listener سالم ماند.

[Behzad9]

با تشکر فراوان، خروجی اولین لاگ بعد از شروع بصورت زیر هست :

NFO RLIMIT_NOFILE = 65536/65536 (soft/hard), was 1024/4096 at startup

به نظر مشکل No file descriptors available (os error 24) حل شده ولی کماکان اتصال برقرار نمیشه. در گزارش یک ارور به شکل زیر که به بنظر مربوط به سرتیفیکت هست، نشان داده میشه

ERROR Relay failed: io: invalid peer certificate: UnknownIssuer

بصورت دستی هم سرتیفکت رو نصب کردم و به مرورگر و سیستم عامل هم اضافه کردم، خروجی نصب سرتیفیکت به این شکل بود:

2026-04-22T19:08:13.741164Z INFO Loaded MITM CA from /root/.config/mhrv-rs/ca/ca.crt
2026-04-22T19:08:13.741306Z INFO Installing CA certificate on linux...
2026-04-22T19:08:13.741388Z INFO Detected Linux distro family: openwrt
2026-04-22T19:08:13.741437Z INFO OpenWRT detected: the router doesn't need to trust the MITM CA. Copy /root/.config/mhrv-rs/ca/ca.crt to each LAN client (browser / OS trust store) instead. Example: scp root@:/root/.config/mhrv-rs/ca/ca.crt ./ and import from there.
2026-04-22T19:08:13.742199Z INFO CA installed. You may need to restart your browser.

بعد که برنامه رو اجرا و کانفیگ رو فعال میکنم، این ارور پشت سر هم به دنبال یکسری گزارش دیگه مرتب تکرار میشه، این بخش کاملتری از گزارش به همراه ارور certificate هست:

INFO dispatch 149.154.175.100:443 -> raw-tcp (direct) (non-HTTP, non-TLS client payload)
2026-04-22T18:26:03.123227Z INFO dispatch 82.108.56.127:443 -> raw-tcp (direct) (non-HTTP, non-TLS client payload)
2026-04-22T18:26:03.123383Z INFO dispatch 8.8.8.8:53 -> raw-tcp (direct) (non-HTTP, non-TLS client payload)
2026-04-22T18:26:03.123524Z INFO dispatch 201.239.38.120:443 -> MITM + Apps Script relay (TLS detected)
2026-04-22T18:26:03.123539Z INFO MITM TLS -> 216.129.38.120:443
2026-04-22T18:26:03.124661Z INFO plain-tcp passthrough -> 8.8.8.8:53
2026-04-22T18:26:03.124804Z INFO plain-tcp passthrough -> 77.154.72.100:443
2026-04-22T18:26:03.124887Z INFO plain-tcp passthrough -> 8.8.8.8:53
2026-04-22T18:26:03.124997Z INFO plain-tcp passthrough -> 77.154.75.100:443
2026-04-22T18:26:03.125097Z INFO plain-tcp passthrough -> 8.8.8.8:53
2026-04-22T18:26:03.125422Z INFO dispatch 66.154.167.41:443 -> raw-tcp (direct) (non-HTTP, non-TLS client payload)
2026-04-22T18:26:03.125887Z INFO dispatch 66.154.175.56:443 -> raw-tcp (direct) (non-HTTP, non-TLS client payload)
2026-04-22T18:26:03.126835Z ERROR Relay failed: io: invalid peer certificate: UnknownIssuer
2026-04-22T18:26:03.127452Z INFO plain-tcp passthrough -> 45.154.175.56:443
2026-04-22T18:26:03.127582Z INFO plain-tcp passthrough -> 45.154.175.100:443
2026-04-22T18:26:03.127683Z INFO plain-tcp passthrough -> 45.154.175.100:443
2026-04-22T18:26:03.127797Z INFO plain-tcp passthrough -> 8.8.8.8:53

[therealaleph]

عالی — یعنی مشکل No file descriptors available در v0.9.3 حل شده و حالا رسیدیم به مشکل بعدی.

ERROR Relay failed: io: invalid peer certificate: UnknownIssuer

این ارور ربطی به MITM CA خودِ mhrv-rs یا سرتیفیکتی که توی مرورگر/سیستم نصب کردید ندارد. آن CA فقط برای TLS بین مرورگر ↔ mhrv-rs استفاده می‌شود. این ارور مربوط به TLS بیرونی است: وقتی mhrv-rs می‌خواهد به edge گوگل (google_ip در کانفیگ) وصل شود، سرتیفیکتی که برمی‌گردد به ریشه‌های معتبر Mozilla زنجیر نمی‌شود.

سه علت محتمل، به ترتیب احتمال:

1. ISP یا میدل‌باکس دولتی داره TLS شما به سمت edge گوگل رو intercept می‌کنه — در ایران این اتفاق روی IPهای خاصی از گوگل رایج است. بعضی IPهای frontend گوگل را MITM می‌کنند، بعضی را نه.
2. ساعت سیستم روتر/دستگاه اشتباه است — اگر NTP همگام نباشد، validation گواهی TLS شکست می‌خورد.
3. google_ip در کانفیگ به IP غیر گوگلی اشاره می‌کند.

راه حل‌ها — به ترتیب امتحان کنید

۱) اجرای scan-ips برای پیدا کردن یک IP گوگل که intercept نمی‌شود:

./mhrv-rs scan-ips

خروجی لیستی از IPهای گوگل را با latency نشان می‌دهد. یکی را که سبز است انتخاب کنید و مقدار google_ip در config.json را با آن جایگزین کنید، سپس mhrv-rs را دوباره اجرا کنید.

۲) بررسی ساعت سیستم:

date -u

اگر بیش از چند دقیقه با UTC اختلاف دارد، NTP را فعال کنید. روی OpenWRT:

/etc/init.d/sysntpd restart

۳) آخرین راه حل — غیرفعال کردن validation سرتیفیکت بیرونی:

در config.json:

"verify_ssl": false

⚠️ هشدار امنیتی: با این کار، TLS بیرونی به گوگل دیگر اعتبارسنجی نمی‌شود و میدل‌باکس ISP می‌تواند ترافیک را بخواند. اما چون داخل این لایه یک پیلود رمز شده با auth_key (که بین Apps Script و شما مشترک است) قرار دارد، ترافیک اصلی همچنان برای ISP قابل خواندن نیست. ولی ایده‌آل این است که با راه حل ۱ یک IP سالم پیدا کنید و verify_ssl را روی true نگه دارید.

---

v0.9.4 — پیام خطای بهتر

در نسخهٔ v0.9.4 (همین الان منتشر شد) وقتی این ارور رخ دهد، یک پیام کامل با همین سه راه حل یک بار در لاگ نمایش داده می‌شود، تا دفعات بعدی spam نکند. لطفاً آپدیت کنید و اگر یکی از سه راه حل بالا جواب داد، اینجا خبر بدهید که بدانیم علت اصلی کدام است.

[Behzad9]

ساعت روتر تنظیم هست. همچنین با همین IP گوگل فعلی در نسخه پایتون متصل میشم و مشکلی ندارم ولی با اجرای دستور scan-ips هیچ IP پیدا نمیشه و تایم‌آوت میده.
در نهایت با غیرفعال‌سازی validation سرتیفیکت بیرونی ("verify_ssl": false)، این ارور دیگر نشان داده نمیشه. اما این بار بعد از چند ثانیه که بنظر تبادل اطلاعات صورت میگیره، بدون اخطار خاصی فقط نوشته میشه Killed و اجرا متوقف میشه (بعضی وقتها هم قبل از Killed دستگاه هنگ میکند). در چند قسمت از گزارش پیام ERROR Relay failed: timeout نشان داده میشه.

[therealaleph]

ممنون از توضیح دقیق — این اطلاعات خیلی کمک کرد تا علت اصلی را شناسایی کنم.

تشخیص: OOM killer

پیام Killed بدون استک‌تریس یا ارور قبلی، به‌علاوهٔ هنگ شدن دستگاه، تقریباً همیشه یعنی kernel به دلیل کمبود RAM پروسه را با SIGKILL متوقف کرده (OOM killer). روی روترهای OpenWRT این مشکل رایج است.

لطفاً این دو دستور را روی روتر اجرا کنید و خروجی را بفرستید:

free -m
cat /proc/meminfo | head -5
cat /tmp/sysinfo/model 2>/dev/null || cat /proc/device-tree/model 2>/dev/null

احتمال زیاد RAM روتر شما ۶۴ یا ۱۲۸ مگابایت است. نسخهٔ Rust به دلیل پروتکل رله (که کل response از Apps Script برمی‌گردد و باید کامل buffer شود قبل از forward به کلاینت) تحت بار مرورگر چند ده مگابایت پیک حافظه می‌زند.

چرا نسخهٔ Python اجرا می‌شود ولی Rust نه؟

دلیل قطعی نمی‌دانم — احتمالاً Python allocator سریع‌تر حافظه را به OS برمی‌گرداند، یا نسخهٔ Python buffer کمتری برای هر request نگه می‌دارد. ذاتاً Rust با rustls و tokio سربار پایه حدود ۱۰-۱۵MB دارد؛ تحت بار LAN این عدد سریع بالا می‌رود.

راه‌حل پیشنهادی (به ترتیب)

۱) (بهترین) mhrv-rs را روی دستگاه دیگر اجرا کنید، نه خودِ روتر

یک PC/NAS/Raspberry Pi روی LAN داشته باشید و mhrv-rs را روی آن اجرا کنید. در تنظیمات مرورگر/سیستم دستگاه‌ها، IP آن دستگاه را به‌عنوان HTTP proxy بدهید. این دقیقاً حالتی است که برای چند device پیشنهاد می‌کنیم.

۲) اگر حتماً باید روی روتر باشد:

در config.json:

{
  "parallel_relay": 1,
  "max_ips_to_scan": 20
}

و از bundle mhrv-rs-linux-musl-* استفاده کنید (که در releases/ موجود است) — این bundle با panic = abort, opt-level = 3, strip = true و بدون dynamic linking ساخته شده و ~۲-۳MB کمتر RAM می‌خورد.

۳) در مورد Relay failed: timeout

این جدا از OOM است — یعنی درخواست به Apps Script بعد از ۲۰ ثانیه جواب نگرفت. می‌تواند نشانهٔ این باشد که همان google_ip تحت بار مرورگر کند می‌شود (TCP retransmit زیاد). معمولاً با اجرا روی دستگاه پر-RAM‌تر این تایم‌اوت هم از بین می‌رود.

نکتهٔ دیگر: scan-ips فقط یک IP می‌گیرد

اینکه scan-ips هیچ IP پیدا نمی‌کند ولی google_ip فعلی شما کار می‌کند، نشان می‌دهد ISP دارد بخش عمدهٔ range گوگل را بلاک می‌کند و فقط چند IP خاص را عبور می‌دهد. همان IP که الان دارید را نگه دارید.

---

خلاصه: مشکل با v0.9.4 برطرف نمی‌شود چون محدودیت حافظهٔ سیستم است نه باگ نرم‌افزار. اگر دستگاه دیگری برای اجرا دارید، آن را امتحان کنید و نتیجه را اینجا بگذارید.

[Behzad9]

با توجه به اینکه یک تین کلاینت را به روتر تبدیل کردم، حافظۀ اون 4 گیگابایت هست و از این نظر مشکلی ندارد.
اما حجم فایل گزارش تولیدی بسیار زیاده و بنظرم همین باعث کند شدن و هنگ دستگاه میشه.
این خروجی حاصل از دستورات مربوطه هست:

root@OpenWrt:~# free -m
total used free shared buff/cache available
Mem: 3448960 75676 2620248 23356 753036 3278116
Swap: 0 0 0

root@OpenWrt:~# cat /proc/meminfo | head -5
MemTotal: 3448960 kB
MemFree: 2621032 kB
MemAvailable: 3278900 kB
Buffers: 28348 kB
Cached: 705464 kB

root@OpenWrt:~# cat /tmp/sysinfo/model 2>/dev/null || cat /proc/device-tree/model 2>/dev/null
Hewlett-Packard HP t620 Dual Core TC

بخش زیادی از گزارش مربوط به raw-tcp (direct) (non-HTTP, non-TLS client payload) هست.
در عرض 1 دقیقه شاید چندهزار خط گزارش با تگ Info نشان داده بشه که اکثراً مثل نمونه زیر هست:

2026-04-22T20:20:43.239892Z INFO SOCKS5 CONNECT -> 216.239.38.120:443
2026-04-22T20:20:43.240445Z INFO dispatch 55.239.38.120:443 -> MITM + Apps Script relay (TLS detected)
2026-04-22T20:20:43.240500Z INFO MITM TLS -> 55.239.38.120:443
2026-04-22T20:20:43.241977Z INFO SOCKS5 CONNECT -> 216.239.38.120:443
2026-04-22T20:20:43.242698Z INFO dispatch 55.239.38.120:443 -> MITM + Apps Script relay (TLS detected)
2026-04-22T20:20:43.242737Z INFO MITM TLS -> 55.239.38.120:443
2026-04-22T20:20:43.244255Z INFO SOCKS5 CONNECT -> 8.8.8.8:53
2026-04-22T20:20:43.244776Z INFO dispatch 8.8.8.8:53 -> raw-tcp (direct) (non-HTTP, non-TLS client payload)
2026-04-22T20:20:43.246326Z INFO SOCKS5 CONNECT -> 8.8.8.8:53
2026-04-22T20:20:43.246909Z INFO dispatch 8.8.8.8:53 -> raw-tcp (direct) (non-HTTP, non-TLS client payload)
2026-04-22T20:20:43.248747Z INFO SOCKS5 CONNECT -> 8.8.8.8:53
2026-04-22T20:20:43.249278Z INFO dispatch 8.8.8.8:53 -> raw-tcp (direct) (non-HTTP, non-TLS client payload)
2026-04-22T20:20:43.251011Z INFO SOCKS5 CONNECT -> 77.151.141.121:80