افزودن ده‌ها پروکسی یکجا بدون لمس هر لینک

مشکل لمس تک‌تک لینک‌ها

پاسخ کوتاه: بله، راهش هست، اما نه آن‌طور که توقع داری. تلگرام رسمی فقط لینک‌های tg://proxy را با یک‌بار لمس می‌پذیرد و API عمومی‌ای برای ایمپورت لیست ارائه نمی‌دهد؛ پس هر روشی که می‌بینی یا یک خودکارسازی در سطح سیستم‌عامل است یا یک کلاینت سوم‌شخص که فایل کانفیگ را خودش می‌خواند. انتخاب بین این دو مسیر به معیارهایت بستگی دارد: امنیت، سرعت چرخش، و تحمل خطا.

اگر فقط ۵-۱۰ پروکسی داری، لمس دستی شاید مزاحمت‌آمیز نباشد. اما وقتی لیست از ۵۰ رد می‌شود و نیمی از آن‌ها فردا مرده‌اند، مدیریت دستی به یک کار پاره‌وقت تبدیل می‌شود. این مقاله بررسی می‌کند که کدام کلاینت‌ها لیست را قبول می‌کنند، چطور یک مجموعه چرخشی لوکال با اسکریپت بسازی، و چطور ورودی‌های مرده را بدون تست تک‌تک جدا کنی.

کلاینت‌های اصلی و پشتیبانی از لیست

وضعیت در ۲۰۲۵ بهتر از قبل است، اما هنوز پراکنده است. جدول زیر توانایی کلاینت‌های رایج در دریافت لیست پروکسی و نحوه عرضه آن را نشان می‌دهد:

نکته ظریف: Nekogram تنها کلاینتی است که یک بلوک متنی حاوی ده‌ها لینک tg://proxy را به‌صورت یک‌جا می‌پذیرد؛ داخل تنظیمات، گزینه «Import from clipboard» را بزنید و انتظار تأیید جداگانه برای هر ورودی را نداشته باشید — آن‌ها را یکجا اضافه می‌کند اما همه را فعال نمی‌کند. سقف واقعی حدود ۲۰۰ ورودی در یک ایمپورت است؛ بیشتر از آن را بی‌صدا نادیده می‌گیرد، نه خطایی نشان می‌دهد.

نسخه رسمی دسکتاپ اگر فایل config را دستکاری کنی، بعد از راه‌اندازی مجدد اعتراض نمی‌کند، اما لینک‌های تکراری را حذف نمی‌کند؛ اگر دو بار ایمپورت کنی، دو ورودی جدا خواهی داشت که به یک سرور می‌روند و فقط حافظه را هدر می‌دهند.

ساخت یک مجموعه چرخشی لوکال با اسکریپت

وقتی تعداد پروکسی‌ها از ۳۰ می‌گذرد، کار با رابط کاربری احمقانه است. یک اسکریپت Bash ساده می‌تواند لیست را از یک فایل متنی بخواند، ترتیب را بچرخاند و یک‌خروجی سازگار با کلیپ‌بورد Nekogram بسازد. نکته مهم: نباید پروکسی‌ای که در ۲۴ ساعت گذشته استفاده شده را دوباره اول لیست بگذاری، چون احتمال مرگ آن بالا رفته است.

اسکریپت زیر یک فایل proxies.txt (هر خط یک لینک tg://proxy) را می‌خواند، ورودی‌های دارای تاریخ‌گذشته را حذف می‌کند و خروجی را با xclip در کلیپ‌بورد می‌گذارد:

#!/bin/bash
FILE="$HOME/.config/mtproto/proxies.txt"
STALE_DAYS=7
LAST_USED="$HOME/.config/mtproto/last_used"

# فیلتر خطوط دارای timestamp قدیمی‌تر از STALE_DAYS
awk -v stale="$STALE_DAYS" -v now="$(date +%s)" '
/^tg:\/\/proxy/ {
    if (match($0, /#([0-9]+)$/)) {
        ts = substr($0, RSTART+1, RLENGTH-1);
        if ((now - ts) / 86400 > stale) next;
    }
    print $0;
}' "$FILE" | shuf | head -30 | xclip -selection clipboard

این روش دو ضعف دارد: اول، timestamp از خود لینک tg://proxy می‌آید که اکثر تولیدکننده‌ها آن را نمی‌گذارند (پروژه‌هایی مثل free-mtproto-proxies گاهی آن را در توضیحات HTML دارند، نه داخل لینک). دوم، shuf ترتیب تصادفی می‌سازد که ممکن است ۳ پروکسی مرده را پشت سر هم بیاورد؛ بهتر است یک فایل last_used نگه داری و پروکسی‌هایی که در ۲ ساعت اخیر رد شده‌اند را در ابتدای چرخه قرار ندهی.

برای تشخیص مرده بودن، نمی‌توانی به اتصال TCP اکتفا کنی. یک پروکسی MTProto می‌تواند پورت ۴۴۳ را باز بگذارد اما کلید اشتراک را رد کند. تست واقعی باید یک دست‌دهی کامل انجام دهد:

# نمونه تست با openssl s_client فقط برای بررسی TLS نیست
# تست واقعی: پاس دادن یک ClientHello جعلی به IP و بررسی پاسخ
timeout 3 bash -c '</dev/tcp/127.0.0.1/8443' && echo "port open" || echo "port closed"

در عمل، ساده‌ترین راه‌حل این است که قبل از ایمپورت، ۵-۱۰ پروکسی آخر را با خود تلگرام تست کنی (وضعیت اتصال را چک کنی)؛ چراکه تلگرام به محض ارسال اولین packet متوجه سوءکلید می‌شود و در ۲ ثانیه خطای «Proxy is not responding» را نشان می‌دهد. یک اسکریپت نمی‌تواند این کار را به‌طور قابل اعتماد تقلید کند بدون اینکه پروتکل MTProto را دوباره پیاده‌سازی کند، که ارزشش را ندارد.

جدول زمانی مرگ پروکسی‌ها و معیارهای پالایش

بزرگ‌ترین اشتباه در مدیریت انبوه، حذف نکردن ورودی‌های قدیمی است. آمار پروژه‌های عمومی مانند https://github.com/dubblebyte/free-mtproto-proxies نشان می‌دهد که حدود ۶۰٪ پروکسی‌های رایگان در ۴۸ ساعت اول می‌میرند و از آن میان، پروکسی‌های روی پورت‌های غیراستاندارد (مثل ۴۴۳ و ۸۴۴۳) عمر طولانی‌تری دارند — گاهی سه برابر پروکسی‌های روی پورت ۱۰۸۰.

یک قانون سرانگشتی عملی: هر لیستی که می‌گیری را سه دسته کن — «تازه»، «۲۴-۴۸ ساعت»، «بیشتر از ۴۸ ساعت». ورودی‌های دسته سوم را بدون تست حذف نکن، اما هرگز در ابتدای چرخه قرار نده. آن‌ها را فقط به‌عنوان آخرین راه‌حل در نظر بگیر.

معیارهای فنی برای پالایش خودکار:

• تغییر IP دامنه: اگر لینک دارای دامنه است و رزولوشن DNS آن بعد از یک روز عوض شده، احتمال دارد مدیر پروکسی IP را عوض کرده باشد و لینک قدیمی همچنان به IP مرده اشاره کند.
• پورت‌های پرخطر: پورت‌های ۱۰۸۰، ۳۱۲۸، ۸۸۸۸ به‌شدت توسط فیلترینگ برخی کشورها شناخته شده‌اند؛ اگر در لیست تو هستند، انتظار مرگ سریع‌تر را داشته باش.
• موفقیت پس از ۵ تلاش: اگر یک پروکسی پس از ۵ بار چرخش، هرگز مورد استفاده موفق نگرفت، احتمال خطای کانفیگ ما بیشتر است تا مرگ پروکسی؛ آن را از چرخه خارج کن و با یک کلاینت دستی تست کن.

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

ایده پیچیده‌تر: به‌جای مدیریت یک لیست، یک فید محلی بساز که خودش آخرین پروکسی‌های زنده را با یک درخواست HTTP برمی‌گرداند. در این سناریو، یک کرون‌جاب هر ۱۵ دقیقه لیست را از یک منبع عمومی می‌گیرد، ۱۰ موردی را که از لحظه ساخته شدن کمتر از ۲ ساعت عمر دارند نگه می‌دارد، و آن‌ها را در یک فایل JSON در localhost می‌نویسد.

کلاینتی مثل Nekogram نمی‌تواند مستقیم به localhost وصل شود (آن‌جا فقط HTTP را برای ثبت لینک‌ها دارد، نه برای لیست‌ها). بنابراین یا باید خروجی را به کلیپ‌بورد بفرستی و چسبانی، یا یک کانال تلگرام خصوصی داشته باشی که ربات پروکسی‌های تازه را به‌صورت پیام‌های چندخطی ارسال کند؛ سپس در Nekogram از «Import from Message» استفاده کنی.

محدودیت این روش: اگر منبع عمومی خودش دروغ بگوید (مثلاً تبلیغ پروکسی‌های پولی به‌جای رایگان)، فید شما هر ۱۵ دقیقه همان زباله را تکرار می‌کند. یک هشدار ساده: اگر بیش از ۵۰٪ پروکسی‌های یک فید در تست‌های دستی مرده بودند، منبع را عوض کن، نه فیلتر را.

امنیت و هزینه پنهان ایمپورت انبوه

وقتی ۲۰۰ پروکسی را یکجا فعال می‌کنی، داری به هر کدام از آن‌ها اجازه می‌دهی کل ترافیک تلگرام تو (به‌صورت رمزنگاری‌شده) را ببیند. با Fake-TLS این ترافیک شبیه HTTPS است، اما خود پروکسی نقطه پایانی رمزگشایی است. پروکسی‌های رایگان معمولاً لاگ نمی‌گیرند، اما نمی‌توانی مطمئن باشی.

یک قانون ساده: هرگز از یک پروکسی رایگان برای اکانتی که شماره موبایل اصلی به آن وصل است استفاده نکن. یک اکانت دوم با شماره مجازی و یک زمان‌بندی چرخش ۱-۲ ساعته راه‌اندازی کن و پروکسی‌های اکانت اصلی را روی «استفاده فقط وقتی اتصال مستقیم قطع است» بگذار.

هزینه دیگر، باتری و پهنای باند است. مدیریت مدام اتصال به پروکسی‌های مرده (هر کدام یک timeout سه ثانیه‌ای) باعث می‌شود تلگرام ۵-۱۰٪ بیشتر باتری مصرف کند. اگر در تنظیمات، «استفاده از پروکسی فقط برای داده مصرفی» را فعال کرده‌ای، مرگ یک پروکسی به‌معنای قطع کامل تلگرام است؛ این یک شکست واحد (single point of failure) است که بسیاری آن را نادیده می‌گیرند.

FAQ

آیا می‌توانم از یک لینک tg://proxy چندبار استفاده کنم؟

بله، لینک یک کلید پیکربندی است نه یک توکن یک‌بارمصرف. می‌توانی آن را در چند کلاینت و چند دستگاه وارد کنی، تا زمانی که سرور پشت آن زنده باشد، همه وصل می‌شوند. اما اگر پروکسی به تعداد اتصال‌های همزمان محدودیت دارد (بسیاری از آن‌ها سقف ۲۰-۵۰ اتصال دارند)، استفاده چندبرابری ممکن است آن را از کار بیندازد.

بهترین فاصله زمانی برای چرخش پروکسی چیست؟

در عمل، فاصله ۳۰-۴۵ دقیقه بهینه است؛ کوتاه‌تر از آن باعث قطع‌وبرگشت مداوم و افزایش مصرف باتری می‌شود، و طولانی‌تر از آن (بیش از ۲ ساعت) شانس استفاده از یک پروکسی مرده را بالا می‌برد. اگر در منطقه‌ای با فیلترینگ لحظه‌ای هستی، هر ۱۵ دقیقه را امتحان کن و ببین آیا باتری در یک روز بیش از ۲۰٪ کاهش پیدا می‌کند یا نه؛ اگر بله، فاصله را دو برابر کن.

آیا یک پروکسی با پورت ۴۴۳ همیشه قابل اعتمادتر است؟

نه به‌تنهایی. پورت ۴۴۳ شانس عبور از DPI برخی کشورها را بالا می‌برد، اما پروکسی روی آن هم می‌میرد؛ فقط آهسته‌تر. اگر پروکسی‌ای روی پورت ۸۴۴۳ پیدا کردی که SNI معتبری دارد و گواهی TLS 1.3 را پاس می‌کند، احتمال عمر مفید بالاتری دارد، اما هیچ تضمینی نیست. مهم‌ترین معیار، آدرس IP تمیز است، نه پورت؛ یک IP که در لیست سیاه فیلترینگ است روی پورت ۴۴۳ هم فوراً قطع می‌شود.