Skip to content

README.fa.md

Latest commit

 

History

History
110 lines (70 loc) · 13.3 KB

README.fa.md

File metadata and controls

110 lines (70 loc) · 13.3 KB

خروجی Cloudflare Worker (پشتیبان جایگزین برای Apps Script)

English: README.md

این پوشه یک Cloudflare Worker ارائه می‌کند که همراه با assets/apps_script/Code.cfw.gs شکل متفاوتی از حالت apps_script به شما می‌دهد:

mhrv-rs ──► Apps Script (Code.cfw.gs) ──► Cloudflare Worker ──► مقصد
            ▲ فقط احراز هویت و فوروارد       ▲ گرفتن داده + base64

پشتیبان استاندارد (assets/apps_script/Code.gs) خودِ Apps Script کار fetch به مقصد را انجام می‌دهد. این نسخه‌ٔ جایگزین، Apps Script را به یک رلهٔ نازک تبدیل می‌کند و کارِ اصلی را به لبهٔ Cloudflare می‌سپارد. خود mhrv-rs تغییر نمی‌کند — همان پاکت JSON روی سیم، همان mode: "apps_script" در config.json، همان script_id. تنها تفاوت این است که Apps Script مستقر شدهٔ شما بعد از احراز هویت چه می‌کند.

ایدهٔ اصلی: https://github.com/denuitt1/mhr-cfw. این کپی یک بررسی AUTH_KEY روی خود Worker اضافه می‌کند، رفتار «صفحهٔ تقلبی برای کلید نامعتبر» را از Code.gs به ارث می‌برد، و یک محافظ در برابر حلقه‌شدن دارد.

چه‌وقت ارزش راه‌اندازی دارد؟

✅ مرور وب، باز کردن صفحات جدید، ترافیک گفتگومحور — به‌طور محسوسی سریع‌تر می‌شود. تأخیر هر تماس از کف ۲۵۰ تا ۵۰۰ میلی‌ثانیه‌ٔ Apps Script به ۱۰ تا ۵۰ میلی‌ثانیه‌ٔ لبهٔ Cloudflare کاهش می‌یابد.

✅ تلگرام بلادرنگ — پیام‌های کوتاه و مکرر بیشترین سود را می‌برند.

✅ شبکه‌هایی که در آن‌ها ابتدا سهمیهٔ زمان اجرای Apps Script (۹۰ دقیقه در روز برای حساب‌های مصرفی گوگل) تمام می‌شود، نه شمارش URL fetch. در این حالت GAS تقریباً هیچ زمانی صرف هر تماس نمی‌کند.

❌ امروز هیچ کاهشی در شمارش روزانهٔ UrlFetchApp به دست نمی‌آورید. مسیر رلهٔ HTTP در mhrv-rs همیشه فقط یک پاکت تک‌آدرسی می‌فرستد و هیچ‌گاه شکل دسته‌ای q: [...] را تولید نمی‌کند، پس هر درخواست کاربر همچنان یک UrlFetchApp در GAS مصرف می‌کند — مستقل از اینکه کدام نسخهٔ Code.gs را مستقر کرده باشید. مسیر Code.cfw.gs به سمت Worker قابلیت پشتیبانی از دسته را دارد (قطعه‌بندی ۴۰‌تایی، پخش‌سازی روی Worker با Promise.all، هزینهٔ ceil(N / 40) به جای N)، ولی این شاخه از هیچ کلاینت موجودی فراخوانی نمی‌شود. تا زمانی که mhrv-rs خودش HTTP relay را دسته‌بندی نکند، سقف روزانهٔ ~۲۰٬۰۰۰ مصرف نسبت به Code.gs تغییر نمی‌کند. این پشتیبانی برای سازگاری آینده در کد نگه داشته شده — هزینه‌ای ندارد و روزی که کلاینتِ دسته‌بندی‌کننده برسد، خود به خود فعال می‌شود.

❌ ویدیوهای طولانی یوتیوب — بدتر می‌شود، نه بهتر. Apps Script تا حدود ۶ دقیقه دیوار اجرا (wall) به ازای هر فراخوانی می‌دهد؛ Cloudflare Workers در ۳۰ ثانیه قطع می‌کنند. صخرهٔ SABR زودتر فرا می‌رسد. برای استفادهٔ یوتیوب‌محور، روی Code.gs بمانید.

❌ سایت‌هایی که پشت ضدبات Cloudflare هستند (توییتر/X، OpenAI، …) — IP خروجی حالا داخل خود Cloudflare است، که ضدبات Cloudflare آن را به‌عنوان «درخواست داخلی Worker» انگشت‌نگاری می‌کند. اغلب سختگیرانه‌تر از IP گوگل برخورد می‌شود. این مشکلی جدا از عبور از DPI است و هیچ‌کدام از این دو نسخه آن را حل نمی‌کنند.

❌ اگر/زمانی که HTTP relay دسته‌ای فعال شود، سقف ۳۰ ثانیه‌ٔ Cloudflare روی کندترین آدرس در هر قطعه اعمال خواهد شد، نه به‌ازای هر URL — یک مقصد قفل‌شده می‌تواند کل قطعهٔ ۴۰ آدرسی را به timeout بکشاند. تلاش مجدد تک‌به‌تک در mhrv-rs این را پوشش می‌دهد، اما تفاوت رفتاری نسبت به دیوار per-URL در fetchAll استانداردِ Code.gs است. (امروز بی‌اثر است چون کلاینت دسته نمی‌فرستد.)

راه‌اندازی

سه رشتهٔ هم‌خوان نیاز دارید: یک AUTH_KEY که بین worker.js، Code.cfw.gs و config.json خود mhrv-rs مشترک است. یک رمز تصادفی قوی انتخاب کنید و در هر سه جا paste کنید.

۱. استقرار Worker

۱. وارد https://dash.cloudflare.com/ شوید → Workers & Pages → Create → Hello World → Deploy. ۲. روی Edit code بزنید، کد پیش‌فرض را پاک کنید و محتوای worker.js را paste کنید. ۳. ثابت AUTH_KEY در بالای فایل را به رمز قوی خودتان تغییر دهید. ۴. روی Deploy بزنید. آدرس *.workers.dev را کپی کنید — در مرحلهٔ بعد لازم است.

۲. استقرار Apps Script

۱. وارد https://script.google.com با حساب گوگلتان شوید → New project → کد پیش‌فرض را پاک کنید.

۲. محتوای ../apps_script/Code.cfw.gs را paste کنید.

۳. هر دو ثابت بالای فایل را تنظیم کنید:

  • مقدار AUTH_KEY را همان رمزی بگذارید که در worker.js گذاشتید.
  • مقدار WORKER_URL را آدرس کامل https://…workers.dev همان Worker که الان مستقر کردید بگذارید (حتماً با پیشوند https://).

۴. از مسیر Deploy → New deployment → Web app استقرار را شروع کنید: مقدار Execute as را روی Me و Who has access را روی Anyone بگذارید.

۵. سپس Deployment ID را کپی کنید.

۳. اشاره دادن mhrv-rs به این Apps Script

در config.json (یا از طریق فرم UI):

{
  "mode": "apps_script",
  "script_id": "PASTE_DEPLOYMENT_ID_HERE",
  "auth_key": "SAME_SECRET_AS_BOTH_FILES_ABOVE"
}

تمام. mhrv-rs لازم نیست بداند Cloudflare در کار است؛ از نگاه او این script_id مثل هر Deployment دیگری رفتار می‌کند. اگر چند Deployment دارید (بعضی استاندارد، بعضی CFW)، می‌توانید همه را در script_ids: [...] بگذارید — round-robin و parallel-relay همچنان روی همه‌شان کار می‌کند.

چرا هر سه AUTH_KEY باید یکی باشند؟

  • بین mhrv-rs و Apps Script: جلوی این را می‌گیرد که هر POST تصادفی روی آدرس *.googleusercontent.com شما رله شود. درخواست‌هایی که این کلید را نداشته باشند، یک صفحهٔ HTML تقلبی می‌گیرند (به‌خاطر DIAGNOSTIC_MODE = false در Code.cfw.gs) و Deployment شما به‌جای یک تونل، شبیه یک پروژهٔ فراموش‌شده دیده می‌شود.
  • بین Apps Script و Worker: اگر آدرس Worker لو برود، جلوی این را می‌گیرد که به یک رلهٔ HTTP باز برای مهاجم تبدیل شود. بدون این بررسی، Worker شما برای هر کسی که URL را پیدا کند، قابل سوءاستفاده است. نسخهٔ بالادست mhr-cfw این بررسی را ندارد؛ این کپی آن را اضافه می‌کند.

اگر می‌خواهید برای امنیت بیشتر روی هر بخش رمز جدا داشته باشید، Code.cfw.gs را ویرایش کنید تا یک k متفاوت از آن چیزی که از mhrv-rs می‌گیرد به Worker بفرستد. تنظیم تک‌رمز ساده‌ترین حالتِ درست است.

بررسی اینکه کار می‌کند

همان روش پشتیبان استاندارد: https://ipleak.net را از طریق پروکسی باز کنید. باید یک IP متعلق به Cloudflare ببینید (چون fetch واقعی حالا از شبکهٔ Cloudflare خارج می‌شود)، نه یک IP متعلق به گوگل که با Code.gs می‌دیدید. اگر IP واقعی خودتان را ببینید، پروکسی استفاده نمی‌شود؛ اگر IP گوگل ببینید، اشتباهاً Code.gs را به‌جای Code.cfw.gs مستقر کرده‌اید.

دکمهٔ Test در UI دسکتاپ همچنان کار می‌کند — یک درخواست HEAD از طریق هر Apps Script Deployment که تنظیم کرده‌اید رله می‌کند.

جدول مقایسه در یک نگاه

محور Code.gs (استاندارد) Code.cfw.gs (این نسخه)
کف تأخیر هر تماس ۲۵۰–۵۰۰ میلی‌ثانیه (هاپ داخلی GAS) ۱۰–۵۰ میلی‌ثانیه (لبهٔ CF)
سهمیهٔ UrlFetchApp در روز، آنچه mhrv-rs امروز می‌فرستد ۱ سهمیه به‌ازای هر درخواست ۱ سهمیه به‌ازای هر درخواست — یکسان (mhrv-rs فقط پاکت تک‌آدرسی تولید می‌کند)
سهمیهٔ UrlFetchApp در روز، اگر کلاینتی در آینده دسته بفرستد تعداد N سهمیه (یکی برای هر آدرس از طریق fetchAll) تعداد ceil(N / 40) سهمیه (قطعه‌بندی ۴۰‌تایی؛ پخش‌سازی روی Worker با Promise.all)
سقف درخواست Cloudflare Workers در روز (پلن رایگان) ندارد ۱۰۰٬۰۰۰ — بسیار بالاتر از چیزی که GAS می‌تواند تغذیه‌اش کند؛ گلوگاه نیست
سهمیهٔ زمان اجرای Apps Script در روز ۹۰ دقیقه، اغلب گلوگاه ۹۰ دقیقه، به‌ندرت گلوگاه
دیوار اجرای هر فراخوانی ~۶ دقیقه، به‌ازای هر آدرس ۳۰ ثانیه، به‌ازای هر تماس (اگر دسته‌بندی فعال شود، به‌ازای هر قطعه)
سقف اندازهٔ پاسخ ~۵۰ مگابایت (مستندات Apps Script) محدود به حافظهٔ Worker (۱۲۸ مگابایت در پلن رایگان)؛ در عمل با تبدیل base64 چند ده مگابایت
حروف بزرگ/کوچک هدرهای پاسخ همان‌طور که مبدأ فرستاده کاملاً کوچک می‌شود (Headers.forEach در Workers نرمال می‌کند). فقط برای ابزارهای پایین‌دستی که نام هدر را حساس به حروف مقایسه می‌کنند مهم است؛ mhrv-rs خود حساس به حروف نیست.
پخش ویدیوی طولانی یوتیوب قابل قبول (صخرهٔ ۶ دقیقه) بدتر (صخرهٔ ۳۰ ثانیه)
سرعت تلگرام / گفتگو پایه محسوساً بهتر
ضدبات Cloudflare روی مقصد یک IP دیتاسنتر یک IP داخلی Worker (اغلب سخت‌گیرانه‌تر)
کش پاسخ روی Spreadsheet موجود (اختیاری) در این نسخه نیست
پیچیدگی استقرار ۱ چیز برای نگه‌داری ۲ چیز که باید همگام بمانند

اگر این مبادلات به نفع شماست، این نسخه را مستقر کنید. اگر نیست — یا حساب Cloudflare ندارید — روی Code.gs بمانید.

محدودیت مهم: این نسخه با mode: "full" کار نمی‌کند

این فایل فقط مسیر رلهٔ HTTP (حالت‌های ۱ و ۲ در CodeFull.gs) را پورت می‌کند. عملیات تونل TCP/UDP خام (حالت‌های ۳ و ۴ در CodeFull.gs که برای mode: "full" و کاربری اپلیکیشن‌های موبایل مثل واتس‌اَپ روی اندروید لازم‌اند) در Code.cfw.gs پشتیبانی نمی‌شوند. اگر در حالت full هستید و WhatsApp کند است، این تغییر کمکی نمی‌کند — این مسئلهٔ متفاوتی است که نیاز به طراحی جداگانه دارد.