v1.6.4

• رفع باگ "L7 multiplexer در Full mode batch نمی‌کنه" (#231): در حالت Full، انتظار می‌رفت که چند op به یک batch HTTP request به Apps Script ترکیب بشن (batch: 5 ops یا batch: 10 ops)، ولی log نشون می‌داد همیشه batch: 1 ops — یعنی هر op جدا یه round-trip Apps Script می‌گرفت (که هر کدوم 2 تا 7 ثانیه طول می‌کشن). علت: loop دریافت پیام بلافاصله بعد از اولین message با try_recv() (non-blocking) صف رو drain می‌کرد، بدون pause برای جمع‌آوری بقیه ops. Fix: بعد از اولین op، یه پنجرهٔ ۸ میلی‌ثانیه‌ای باز می‌مونه تا opهای بعدی (مثل parallel fetches، HTTP/2 streams) همون batch رو پر کنن. ۸ms در مقابل ~۲ تا ۷ ثانیه RTT Apps Script اصلاً ناچیزه ولی efficiency batching رو برمی‌گردونه. ریپورت شده توسط w0l4i با log واضح

• Fix "L7 multiplexer not batching in Full mode" bug (#231): in full mode, multiple ops should coalesce into a single batched HTTP request to Apps Script (batch: 5 ops or batch: 10 ops), but logs showed batch: 1 ops consistently — each op got its own Apps Script round-trip (2-7 s each). Cause: the receive loop drained the channel via try_recv() (non-blocking) immediately after the first message arrived, with no window to let concurrent ops accumulate. Fix: after the first op lands, hold the buffer open for an 8 ms coalescing window so concurrent ops (parallel fetches, HTTP/2 stream openings, etc.) land in the same batch. 8 ms is rounding error against the ~2-7 s Apps Script RTT but restores the entire batching premise. Reported by w0l4i with a clean log snippet

Full Changelog: v1.6.3...v1.6.4

v1.6.3

• رفع باگ "نوتیفیکیشن سرور اندروید پورت اشتباه SOCKS5 رو نشون می‌داد" (#211): با تنظیمات پیش‌فرض اندروید (listenPort=8080, socks5Port=1081)، نوتیفیکیشن می‌نوشت Routing via SOCKS5 127.0.0.1:8081 که اشتباه بود — listener واقعی روی 1081 اجرا می‌شد. هر کاربری که پروکسی تلگرام رو روی پورت نوتیفیکیشن (8081) ست می‌کرد، در سکوت fail می‌شد. علت: تابع buildNotif به‌جای خوندن cfg.socks5Port، hardcode می‌کرد proxyPort + 1. حالا متن نوتیفیکیشن همون منطق elvis fallback cfg.socks5Port ?: (cfg.listenPort + 1) رو که در تنظیم listener واقعی استفاده می‌شه می‌خونه و علاوه بر SOCKS5، پورت HTTP رو هم نشون می‌ده: HTTP 127.0.0.1:8080 · SOCKS5 127.0.0.1:1081. ۲ کاربر مستقل ریپورت کردن (vpnineh، l3est)

• Fix "Android server notification showed wrong SOCKS5 port" bug (#211): with the default Android config (listenPort=8080, socks5Port=1081), the foreground-service notification read Routing via SOCKS5 127.0.0.1:8081 — wrong, since the real listener was on 1081. Anyone configuring Telegram (or any per-app SOCKS5 client) against the notification value silently failed. Cause: buildNotif hardcoded proxyPort + 1 instead of reading cfg.socks5Port. The notification now uses the same elvis fallback cfg.socks5Port ?: (cfg.listenPort + 1) that the actual listener uses, and shows both ports for clarity: HTTP 127.0.0.1:8080 · SOCKS5 127.0.0.1:1081. Two independent users (vpnineh, l3est) reported this

Full Changelog: v1.6.2...v1.6.3

v1.6.2

• رفع باگ "همهٔ دانلودها روی ۲۵۶ کیلوبایت قطع میشن" (#162): در relay range-parallel، اگه validation هر chunk رد می‌شد (مثلاً Apps Script هدر Content-Range رو حذف می‌کرد، یا origin روی chunkهای بعدی به جای 206 یه 200 برمی‌گردوند)، fallback اشتباهی پاسخ probe (یعنی فقط ۲۵۶ کیلوبایت اول) رو به‌عنوان فایل کامل برمی‌گردوند. مرورگر HTTP 200 با Content-Length=262144 می‌دید و دانلود رو "کامل" تلقی می‌کرد. حالا fallback یک GET تک‌مرحله‌ای جدید بدون Range هدر می‌فرسته که Apps Script کل URL رو fetch کنه (تا سقف ۵۰ مگ). برای فایل‌های بزرگ‌تر کندتره از مسیر parallel، ولی پاسخ کامل می‌ده — که اون چیزی هست که اهمیت داره. ۲ کاربر مستقل این رو ریپورت کردن (Ehsan، Recruit1992)

• Fix "every download capped at 256 KB" bug (#162): in range-parallel relay, when any chunk failed validation (e.g. Apps Script stripping the Content-Range header on follow-up chunks, or origin returning 200-instead-of-206 on later chunks), the fallback path silently returned the probe response (the first 256 KiB) as if it were the full file. Browsers saw HTTP 200 with Content-Length=262144 and treated the download as complete. The fallback now does a fresh single GET without the Range header, letting Apps Script fetch the full URL (up to its 50 MiB cap). Slower than the parallel path for large files, but produces a complete response — which is what matters. Two independent users (Ehsan, Recruit1992) reported this; closed-loop with both

Full Changelog: v1.6.1...v1.6.2

v1.6.1

• پایداری چرخه‌ٔ سشن VPN در اندروید (#187): پنج رفع باگ کوچک ولی واقعی در سرویس VPN اندروید: (۱) دکمهٔ Connect/Disconnect حالا روی state-flow VpnState.isRunning گیت میشه (با backstop ۱۲ ثانیه‌ای) به جای تایمر ثابت ۲ ثانیه — جلوی race condition بین Stop و Connect رو می‌گیره که قبلاً منجر به Address already in use می‌شد. (۲) Tun2proxy.stop() حالا با timeout ۲ ثانیه‌ای بسته شده تا اگر روی native call hang کنه، کل teardown thread رو نگه نداره. (۳) رفع نشت file descriptor بین detachFd() و Thread.start() — اگه start بخاطر OOM throw می‌کرد، fd یتیم می‌شد. (۴) doc-comment گمراه‌کننده در teardown اصلاح شد. (۵) handler crash trap حالا Log.e رو در try/catch می‌پیچه تا اگه خود لاگ throw کنه، handler بازگشتی نشه

• Android VPN session lifecycle reliability (#187): five small but real fixes in the Android VPN service. (1) Connect/Disconnect button is now gated on the VpnState.isRunning state flow with a 12 s backstop instead of a fixed 2 s transitionCooldown timer — closes the race window where users tapping Connect right after Stop would hit "Address already in use" because the previous teardown's listener-socket release hadn't completed yet. (2) Tun2proxy.stop() is now wrapped in a 2 s join() timeout — if the native call hangs, the bounded tun2proxy thread join + bounded rt.shutdown_timeout below it still release the listener port instead of holding the teardown thread. (3) File-descriptor leak fixed between parcelFd.detachFd() and Thread.start() — if start() threw (OOM under memory pressure), the detached fd had no owner and leaked for the process lifetime; now adopted into a fresh ParcelFileDescriptor purely so we can close() it. (4) Misleading teardown doc-comment rewritten — the "step 2 closes the TUN fd to force EBADF on read" claim has been factually wrong since detachFd landed; corrected so future debuggers don't chase a phantom safety net. (5) Recursive crash trap in MhrvApp's uncaught-exception handler — Log.e is now wrapped in try/catch so a logd failure during exception logging falls through to the previous handler with the real exception

What's Changed

• fix(android): tighten VPN session lifecycle reliability by @dazzling-no-more in #187

Full Changelog: v1.6.0...v1.6.1

v1.6.0

• پشتیبانی کامل UDP در حالت Full Tunnel (#183): SOCKS5 UDP ASSOCIATE کلاینت → opهای جدید udp_open و udp_data در tunnel-mux → سشن‌های UDP در tunnel-node. حالا QUIC/HTTP3، DNS، و STUN از داخل تونل عبور می‌کنن، نه از طریق fallback به TCP یا leak خارج تونل. سقف ۲۵۶ سشن UDP در هر UDP ASSOCIATE، سقف ۹ کیلوبایت برای datagram، source-IP pinning به peer کنترل، long-poll مبتنی بر event برای drain (با همون knobهای ACTIVE_DRAIN_DEADLINE / LONGPOLL_DEADLINE که در v1.5.0 معرفی شدن). افزودن backward-compatible: tunnel-nodeهای قدیمی‌تر با UNSUPPORTED_OP پاسخ میدن و کلاینت به مسیر TCP-only برمی‌گرده. CodeFull.gs بدون نیاز به redeploy — opها به‌صورت opaque عبور می‌کنن

• End-to-end UDP support in Full Tunnel mode (#183): SOCKS5 client UDP ASSOCIATE → new udp_open / udp_data ops on the tunnel mux → UDP sessions on the tunnel-node. QUIC/HTTP3, DNS, and STUN now traverse the tunnel instead of falling back to TCP or leaking outside it. 256 UDP sessions per UDP ASSOCIATE cap with FIFO eviction, 9 KB datagram size guard, source-IP pinning to the control TCP peer, event-driven drain reusing the v1.5.0 long-poll knobs. Wire-additive: older tunnel-nodes return UNSUPPORTED_OP and clients fall back to TCP-only. CodeFull.gs doesn't need re-deploy — the new ops pass through opaquely. 98 lib tests + 22 tunnel-node tests pass (was 92 + 17; 6 new SOCKS5 UDP parser tests + 5 new UDP session lifecycle tests including a mixed TCP/UDP batch regression test)

What's Changed

• Feature: udp support by @dazzling-no-more in #183

Full Changelog: v1.5.0...v1.6.0

v1.5.0

• پیام‌های push در حالت Full Tunnel حالا تقریباً با تأخیر RTT می‌رسن، نه بعد از یک کامل tick کلاینت (#173): مکانیزم drain خود tunnel-node از sleep ثابت ۱۵۰ms به wake مبتنی بر Notify (event-driven) تبدیل شد. session‌های idle حالا long-poll دارن تا ۵ ثانیه — اولین بایت ورودی wake می‌کنه. تلگرام و چت‌ها به‌طور قابل‌توجه قابل لمس‌تر شدن. backward-compat با tunnel-nodeهای قدیمی‌تر خودکار: اگه empty poll round-trip در زیر ۱.۵ ثانیه با هیچ data برمی‌گرده، کلاینت تشخیص میده server long-poll پشتیبانی نمی‌کنه و به cadence قدیمی برمی‌گرده — sticky AtomicBool برای کل عمر mux
• تصویر Docker آماده برای tunnel-node (ghcr.io/therealaleph/mhrv-tunnel-node): راه‌اندازی Full Tunnel mode حالا یک خطی هست به جای rustup + cargo build. multi-arch (amd64 + arm64). تگ‌های :latest, :1.5, :1.5.0. اجرا به‌عنوان non-root user. مستندات کامل در tunnel-node/README.md
• یادداشت کوتاه فارسی "تغییرات این نسخه" بالای لینک‌های پست تلگرام: تیترهای bullet از فایل docs/changelog/v<ver>.md خودکار استخراج میشن و به‌عنوان

بالای دو لینک repo و release میان. کلیک‌پذیری روی شمارهٔ issue/PR از طریق تبدیل markdown به HTML
• body صفحهٔ release گیت‌هاب دیگه فقط لینک comparison نیست — حالا محتوای کامل docs/changelog/v<ver>.md (فارسی + انگلیسی) به‌عنوان توضیحات اصلی release نمایش داده میشه، و **Full Changelog**: ...compare... به‌عنوان footer اضافه میشه

• Full Tunnel mode push notifications now arrive in roughly RTT instead of waiting for the next client poll tick (#173): the tunnel-node's batch drain switched from a fixed 150 ms sleep to an event-driven Notify wait. Idle sessions now hold open in a long-poll up to 5 s — the first incoming byte wakes the batch. Telegram, chat apps, and any push-driven flow feel noticeably snappier. Backward compat with pre-#173 tunnel-nodes is automatic: if an empty round-trip returns under 1.5 s with no data, the client concludes the server is doing the legacy fixed-sleep drain and reverts to the pre-long-poll cadence (sticky for the lifetime of the mux). 92 client tests + 17 tunnel-node tests including end-to-end TCP-pair verification of the notify wiring
• Prebuilt Docker image for tunnel-node (ghcr.io/therealaleph/mhrv-tunnel-node): setting up Full Tunnel mode is now a one-liner instead of rustup + cargo build on a small VPS. Multi-arch (linux/amd64 + linux/arm64), tagged :latest, :1.5, :1.5.0. Runs as a non-root user. Full deployment docs in tunnel-node/README.md. The image is ~32 MB compressed
• Brief Persian "what's new" note above the links in every Telegram release post: bullet headlines are auto-extracted from docs/changelog/v<ver>.md and rendered as a Telegram <blockquote> above the two existing repo + release links. Markdown links / inline-code in the headlines convert to Telegram HTML so issue/PR refs stay clickable. Cap-budget-aware truncation at bullet boundaries keeps total caption under Telegram's 1024-char limit
• GitHub Releases page bodies now lead with the changelog content (Persian section + --- separator + English section) instead of just the auto-generated **Full Changelog**: …compare… link, which was empty for fix-forward releases like v1.4.1. The auto comparison link is appended at the bottom rather than removed

What's Changed

• feat(tunnel): event-driven drain with adaptive long-poll by @dazzling-no-more in #173

Full Changelog: v1.4.1...v1.5.0

v1.4.1

• رفع گمراه‌کنندگی دکمهٔ Test Relay در حالت Full Tunnel (#160): قبلاً وقتی mode روی full بود، Test Relay بی‌سر و صدا از مسیر apps_script استفاده می‌کرد و IP دیتاسنتر گوگل رو نشون می‌داد — که با IP واقعی tunnel-node کاربر متفاوت بود و این تناقض گیج‌کننده بود. حالا در حالت full، Test Relay صریحاً پیغام میده که این دکمه برای حالت Full پشتیبانی نمی‌کنه و راهنمایی می‌کنه که برای تست واقعی، مرورگر رو از طریق پروکسی محلی به whatismyipaddress.com ببرید. تست واقعی Full mode از طریق tunnel mux در ریلیزهای آینده اضافه میشه
• انتشار آرتیفکت mhrv-rs-openwrt-mipsel-softfloat.tar.gz که در v1.4.0 بیلد نشده بود: PR #153's connect_data instrumentation از std::sync::atomic::AtomicU64 استفاده می‌کرد، که روی هدف 32-بیتی MIPS (mipsel-unknown-linux-musl) موجود نیست. تغییر به portable_atomic::AtomicU64 (که بقیهٔ کد به همین دلیل ازش استفاده می‌کنه) و انتشار از طریق workflow_dispatch جدید — همون آرتیفکت روی صفحهٔ ریلیز v1.4.0 هم اضافه شد

• Fix misleading Test Relay button behaviour in Full Tunnel mode (#160): when mode was set to full, Test Relay used to silently fall through to the apps_script code path and report a Google datacenter IP — which contradicted what the user actually saw in their browser via their tunnel-node, and looked like the relay was broken when it wasn't. Now in full mode, Test Relay returns a clear error explaining that this button isn't wired for full mode, with a recommendation to verify by loading whatismyipaddress.com through the local proxy. A real Full-mode test (via the tunnel mux) is on the queue
• Publishes the mhrv-rs-openwrt-mipsel-softfloat.tar.gz artifact that failed to build in v1.4.0: PR #153's connect_data instrumentation imported AtomicU64 from std::sync::atomic, which doesn't exist on 32-bit MIPS (mipsel-unknown-linux-musl for OpenWRT routers). Switched to portable_atomic::AtomicU64 (already used elsewhere in the codebase for the same reason). The artifact was re-published to the v1.4.0 release page directly via the new workflow_dispatch path, and is shipped natively in v1.4.1

Full Changelog: v1.4.0...v1.4.1

v1.4.0

What's Changed

• fix(android): keep empty ONLY split lists self-excluded by @freeinternet865 in #150
• fix(relay): cap synthetic range stitching size by @freeinternet865 in #151
• feat(tunnel): save one RTT per new HTTPS flow via connect_data op by @dazzling-no-more in #153

Full Changelog: v1.3.0...v1.4.0

What's Changed

• fix(android): keep empty ONLY split lists self-excluded by @freeinternet865 in #150
• fix(relay): cap synthetic range stitching size by @freeinternet865 in #151
• feat(tunnel): save one RTT per new HTTPS flow via connect_data op by @dazzling-no-more in #153

Full Changelog: v1.3.0...v1.4.0

v1.3.0

What's Changed

• Feature/youtube sni relay in #117
• feat: remove pipeline depth cap — scales with deployment count by @vahidlazio in #131
• feat: per-deployment concurrency (30 req/account) by @vahidlazio in #142
• fix(android): app splitting ONLY mode don't mix allowed/disallowed apps by @dazzling-no-more in #143

Full Changelog: v1.2.14...v1.3.0

v1.2.14

Full Changelog: v1.2.13...v1.2.14