CF-ProxyIPChecker

ProxyIP چیست؟

کلادفلر یک محدودیت طراحی دارد (اگرچه بین کاربران به اشتباه «باگ» شناخته می‌شود): از داخل شبکه‌ی خودش نمی‌توان به سرویس‌های دیگر همان شبکه وصل شد. وقتی یک Worker می‌سازیم و از طریق آن بخواهیم به سایتی که پشت کلادفلر قرار دارد (مثلاً داشبورد خود کلادفلر یا سایتی مانند اسپاتیفای) متصل شویم، درخواست از داخل شبکه‌ی کلادفلر به مقصدی داخل همان شبکه می‌رود. این هم خطر حلقه‌ی بی‌نهایت (Loop) دارد — به‌ویژه روی WebSocket و اتصال‌های طولانی‌مدت TCP که برخلاف یک درخواست ساده‌ی HTTP، منابع دیتاسنتر را درگیر می‌کنند — و هم یک قانون امنیتی جلوی آن را می‌گیرد و خطای معروف ۱۰۰۰ (نشانی DNS به آدرسی ممنوعه اشاره دارد) برمی‌گرداند.

پروکسی‌آی‌پی دقیقاً برای شکستن همین حلقه وارد ماجرا می‌شود: یک آی‌پی شخص‌ثالث و خارج از CDN کلادفلر به‌عنوان واسط معرفی می‌شود؛ Worker از طریق آن آی‌پی به مقصد وصل می‌شود و چون از دید کلادفلر این ترافیک از بیرون شبکه آمده، دیگر با مشکل لوپ (Loop) مواجه نمی‌شود.

چرا یک آی‌پی می‌تواند هم‌زمان پروکسی و هم آی‌پی «تمیز» باشد؟

دو سناریو وجود دارد:

1. ریورس‌پراکسی عمومی — بسیاری از پروکسی‌آی‌پی‌های پخش‌شده در کانال‌ها و گیت‌هاب، در واقع آدرس‌های Amazon Cloudfront ، Fastly ، Gcore یا سرورهای Nginx عمومی‌اند که به‌شکل ریورس‌پراکسی باز پیکربندی شده‌اند. چون این سرورها خارج از کلادفلر هستند، هم می‌توانند نقش پروکسی را بازی کنند و درخواست را به مقصد پشت کلادفلر برسانند، هم وقتی به‌عنوان آدرس سرور در کانفیگ استفاده شوند، ترافیک کلاینت را به دامین و SNI درست هدایت می‌کنند.
2. ترفند مسیریابی خودِ کلادفلر — اگر به‌جای یک آی‌پی بیرونی، آی‌پیِ یکی دیگر از دیتاسنترهای Edge کلادفلر (از کشور یا زیرشبکه‌ای دیگر) به کار برود، Worker مجبور می‌شود ترافیک را از شبکه‌ی داخلی‌اش خارج کرده و به آن Edge بفرستد؛ از نگاه کلادفلر این درخواست از یک مرز معتبر بیرونی رسیده و حلقه‌ای تشخیص داده نمی‌شود. چون این آی‌پی اصالتاً متعلق به خودِ کلادفلر است، سمت کلاینت هم نقش آی‌پی تمیز را ایفا می‌کند.

پشتیبان‌گیری با NAT64

برخی پروژه‌های شناخته‌شده (مانند کدهای cmliu و Yong) از فناوری NAT64 به‌عنوان جایگزین یا پشتیبان پروکسی‌آی‌پی استفاده کرده‌اند. NAT64 یک پروکسی نیست، بلکه فناوری ترجمه‌ی آدرس شبکه است: یک آدرس IPv6 مصنوعی (با پیشوند معروف 64:ff9b::/96) می‌سازد که کلادفلر آن را به یک IPv4 واقعی ترجمه می‌کند. پیش‌تر وقتی پروکسی‌آی‌پی از کار می‌افتاد، Worker عملاً نیمه‌فلج می‌شد؛ اکنون با NAT64 به‌عنوان پشتیبان، اگر پروکسی‌آی‌پی تعریف نشده یا خراب باشد، Worker از همین مسیر ترافیک را هدایت می‌کند و از حلقه خارج می‌ماند.

معماری پروژه

سیستم از سه بخش اصلی تشکیل شده که با هم کار می‌کنند:

بخش	نقش
رابط کاربری (Frontend)	صفحه‌ی وب استاتیکی که روی Cloudflare Pages یا Workers سرو می‌شود؛ با ظاهر شیشه‌ای (glassmorphism)، تم روشن/تاریک الهام‌گرفته از گیت‌هاب و چیدمانی سازگار با موبایل
Cloudflare Worker	منطق اصلی برنامه؛ درخواست‌های رابط کاربری را مدیریت می‌کند، دامنه‌ها را ریزالو می‌کند (هم IPv4 هم IPv6) و با سرویس‌های پشتیبان ارتباط برقرار می‌کند
سرویس پشتیبان (Backend API)	سرویس بیرونی‌ای که تست واقعی اتصال TCP به پروکسی‌آی‌پی‌ها را انجام می‌دهد — چون Worker در برقراری اتصال TCP دلخواه به بیرون محدودیت دارد و در نتیجه برخی از پراکسی‌آیپی ها را به درستی صحت سنجی نمی‌کند. این سرویس روی Vercel، Render یا یک سرور شخصی قابل اجرا است و در گیت هاب من یا انتهای این نوشته میتوانید به آن دسترسی داشته باشید.

جریان کار به‌طور خلاصه: کاربر با رابط کاربری (روی Pages/Workers) تعامل می‌کند، رابط کاربری با Cloudflare Worker در ارتباط است، و Worker با سرویس پشتیبان و Scamalytics تعامل داده می‌کند — هر دوی این پارامتر ها پشتیبان خودکار دارند.

قابلیت‌های کلیدی

• پذیرش فرمت‌های ورودی متنوع: یک آی‌پی، فهرستی از آی‌پی‌ها یا دامنه‌ها، بازه‌ی آی‌پی (CIDR یا با خط‌تیره)، یا حتی نشانی یک فایل TXT/CSV خام
• پشتیبانی کامل از IPv4 و IPv6: هم فرم ساده، هم با کروشه، هم با کروشه به‌همراه پورت — همه‌ی حالت‌های ورودی آی‌پی ها را می‌توانید در ابزار وارد کنید.
• تحلیل ریسک با پشتیبان خودکار: برای هر آی‌پی یک امتیاز ریسک («کم»، «متوسط»، «زیاد») از Scamalytics گرفته می‌شود. اگر سرویس رسمی پیکربندی نشده، رِیت لیمیت خورده یا موقتاً در دسترس نباشد، Worker به‌طور خودکار به یک میرور (Mirror) عمومی سوییچ می‌کند؛ به همین دلیل تنظیم کلید Scamalytics اختیاری است و برای استفاده سبک نیازی به API رسمی Scamalytics نخواهید داشت.
• اندپوینت مقاوم بررسی: اگر سرویس پشتیبان بیرونی به هر دلیل خطا بدهد، خودِ Worker به‌عنوان آخرین راه‌حل یک تست مستقیم TCP انجام می‌دهد تا یک درخواست ناپایدار کل تجربه‌ی کاربری را خراب نکند.
• نمایش آی‌پی‌های ناموفق: هر صفحه‌ی نتیجه (دامنه، چندین-آیپی، بازه آیپی و یا فایل) آی‌پی‌های ناموفق را هم به‌همراه دلیل خطا نمایش می‌دهد.
• اسکن قابل‌ازسرگیری: نتایج به‌تدریج (به‌ازای هر آی‌پی، نه کل دسته) ذخیره می‌شوند و پیش از بستن یا تازه‌سازی تب هم به‌اجبار ذخیره می‌شوند؛ رفرش وسط یک اسکن بزرگ باعث شروع از صفر نخواهد شد.
• اطلاعات کامل: تأخیر، کشور، سازمان/ASN و امتیاز ریسک برای هر پروکسی موفق.
• رابط کاربری مدرن: گوشه‌های نرم و گرد، کارت‌های شیشه‌ای، تم روشن/تاریک.
• دسترس‌پذیری بالا: امکان تعریف چند نشانی سرویس پشتیبان برای افزونگی، جدا از پشتیبان‌های Scamalytics و موقعیت‌یابی جغرافیایی
• کاملاً بدون سرور: کل زیرساخت روی پلتفرم‌های سرورلس (Serverless) اجرا می‌شود؛ نیازی به نگه‌داری سرور اختصاصی نیست.

پیش‌نیازها

• حساب کاربری Cloudflare
• حساب کاربری GitHub
• حساب کاربری Vercel یا Render (بسته به روش دپلوی سرویس پشتیبان)
• یک سرور مجازی (VPS) با پایتون و Pip نصب‌شده (در صورت انتخاب استقرار شخصی)
• حساب کاربری Scamalytics — اختیاری؛ بدون آن هم امتیاز ریسک از طریق آینه‌ی عمومی محاسبه می‌شود

راهنمای نصب و استقرار

مرحله‌ی ۱ — استقرار سرویس پشتیبان (Backend API)

سه روش برای اجرای این سرویس وجود دارد؛ هر کدام را که راحت‌تر هستید انتخاب کنید.

گزینه‌ی الف) استقرار روی Vercel (ساده‌ترین روش): Vercel

۱. به ریپوی ProxyIP-Checker-Vercel-API بروید ۲. روی دکمه‌ی «Deploy» در README همان ریپو کلیک کنید تا Vercel یک نسخه از پروژه را خودکار برایتان مستقر کند ۳. نشانی نهایی (مانند https://my-proxy-api.vercel.app) را ذخیره کنید — در مرحله‌ی ۳ لازمش دارید.

گزینه‌ی ب) استقرار روی Render: Render

Render هم مثل Vercel یک پلتفرم بدون‌سرور با استقرار مستقیم از گیت‌هاب است، با این تفاوت که برای یک سرویس پایتونِ طولانی‌مدت (نه فقط تابع‌های کوتاه) مناسب‌تر است:

۱. وارد داشبورد Render شوید و روی New + سپس Web Service کلیک کنید ۲. ریپوی ProxyIP-Checker-API را از گیت‌هاب متصل کنید (یا ابتدا آن را Fork کنید تا به اکانت خودتان متصل شود) ۳. تنظیمات سرویس را وارد کنید:

• Runtime: Python 3
• Build Command: pip install -r requirements.txt
• Start Command: uvicorn checker:app --host 0.0.0.0 --port $PORT
• Plan: برای شروع، پلن رایگان کافی است ۴. توجه داشته باشید که Render شماره پورت را از طریق متغیر محیطی PORT به برنامه می‌دهد، نه یک مقدار ثابت مثل ۸۰۸۰؛ به همین دلیل دستور اجرا باید از $PORT استفاده کند، نه یک عدد هاردکد ۵. روی Create Web Service بزنید؛ بعد از پایان بیلد، Render یک نشانی HTTPS دائمی (مانند https://proxy-api.onrender.com) در اختیارتان می‌گذارد — همین را در مرحله‌ی ۳ استفاده کنید

نکته‌ی پلن رایگان

در پلن رایگان Render، اگر سرویس مدتی درخواست دریافت نکند به خواب می‌رود و اولین درخواست بعدی چند ثانیه تأخیر می‌خورد (Cold Start). اگر می‌خواهید سرویس همیشه بیدار بماند، یا از پلن پولی استفاده کنید یا یک Cron/Ping دوره‌ای برای بیدار نگه‌داشتنش تنظیم کنید.

گزینه‌ی ج) استقرار شخصی روی VPS (کنترل کامل): VPS

git clone https://github.com/mehdi-hexing/ProxyIP-Checker-API.git
cd ProxyIP-Checker-API
pip install -r requirements.txt

# اجرا داخل یک نشست screen تا بعد از قطع اتصال هم فعال بماند
screen -S proxy-api
python main.py --port 8080

بعد از اجرا، با فشردن Ctrl+A و سپس D از نشست خارج شوید (سرویس در پس‌زمینه باقی می‌ماند). نشانی سرویس شما می‌شود: http://<Your_Server_IP>:8080 برای تست:

curl http://<Your_Server_IP>:8080/api/v1/check?proxyip=1.1.1.1

مرحله‌ی ۲ — دریافت کلید Scamalytics (اختیاری)

با ثبت‌نام در Scamalytics و درخواست کلید API؛ فعال‌سازی دستی است و تا ۲۴ ساعت طول می‌کشد. حتی اگر کلید خودتان را هم تنظیم کنید، در صورت اتمام سهمیه یا قطعی موقت سرویس رسمی، Worker به‌طور خودکار به آینه‌ی عمومی سوییچ می‌کند.

مرحله‌ی ۳ — پیکربندی و استقرار Worker

۳.۱) ویرایش فایل _worker.js: داخل تابع checkProxyIP، آرایه‌ی apiUrls را با نشانی سرویس پشتیبانی که در مرحله‌ی ۱ مستقر کردید جایگزین کنید (می‌توانید چند نشانی برای افزونگی اضافه کنید — مثلاً هم آدرس Render، هم Vercel):

const apiUrls = [
    `https://proxy-api.onrender.com/api/v1/check?proxyip=${encodeURIComponent(proxyIPInput)}`, // نشانی Render
    `https://my-proxy-api.vercel.app/api/v1/check?proxyip=${encodeURIComponent(proxyIPInput)}`  // نشانی Vercel
];

اگر همه‌ی این نشانی‌ها با خطا یا تایم‌اوت مواجه شوند، خودِ Worker یک تست مستقیم TCP انجام می‌دهد تا یک قطعی موقت سرویس پشتیبان کل ابزار را از کار نیندازد.

۳.۲) استقرار روی Cloudflare Pages:

1. پوشه‌ی پروژه (همراه با _worker.js ویرایش‌شده) را در قالب یک فایل zip فشرده کنید.
2. سپس در داشبورد Cloudflare به بخش «Workers & Pages» بروید و بر روی گزینه «Create application» کلیک کنید
3. سپس در زیر یک بخش مربوط به تب «Pages» را مشاهده خواهید کرد؛ برروی آن کلیک کنید و در صفحه جدید، بر روی گزینه «Upload Assets» کلیک کرده و بر روی گزینه file کلیک کنید.
4. فایل zip را آپلود کنید و سپس روی «Deploy site» کلیک کنید.

۳.۳) تنظیم متغیرهای محیطی (همگی اختیاری):

متغیر	مقدار	اجباری
SCAMALYTICS_USERNAME	نام کاربری حساب Scamalytics	خیر
SCAMALYTICS_API_KEY	کلید API شما	خیر
SCAMALYTICS_API_BASE_URL	نشانی پایه‌ی اختصاصی	خیر

بعد از افزودن متغیرها، یک‌بار از تب Deployments دوباره استقرار (Re-deploy) انجام دهید.

مرحله‌ی ۴ — تست و استفاده

نشانی Pages خودتان ( https://your-project-name.pages.dev) را باز کنید و یک آی‌پی شناخته‌شده مانند 1.1.1.1 یا دامنه‌ای مانند di.nscl.ir را بررسی کنید. مسیرهای مستقیم دیگری هم قابل استفاده‌اند:

• چند آی‌پی:/proxyip/1.1.1.1,8.8.8.8,[2606:4700:4700::1111]:443
• بازه‌ی آی‌پی: /iprange/1.1.1.0/24
• از روی فایل: /file/https://raw.githubusercontent.com/user/repo/main/ips.txt
• دامنه: /domain/google.com (هم رکورد A هم AAAA)

اسکن قابل‌ازسرگیری و کش

برای بازه‌های بزرگ یا فهرست‌های طولانی که مدتی طول می‌کشند:

• نتیجه‌ی هر آی‌پی بلافاصله بعد از اتمام (نه بعد از پایان کل دسته) در حافظه‌ی محلی (cache) مرورگر ذخیره می‌شود.
• پیش از رفرش ، بستن یا مخفی‌شدن تب، ذخیره‌سازی به‌اجبار انجام می‌شود.
• با تازه‌سازی صفحه، فقط آی‌پی‌هایی که هنوز بررسی نشده‌اند دوباره تست می‌شوند؛ نتایج قبلی (موفق و ناموفق) بلافاصله نمایش داده می‌شوند.
• هر ورودی متفاوت (دامنه، بازه یا فهرست جدید) کش جداگانه‌ی خودش را دارد و با نتایج قدیمی قاطی نمی‌شود.

پشتیبانی از IPv6

آدرس‌های IPv6 در کل زیرساخت پشتیبانی می‌شوند: در باکس تک/چند-آی‌پی، بازه‌ی آی‌پی (فقط با فرم کروشه‌دار)، فهرست فایلی و ریزالو دامنه (هر دو رکورد A و AAAA). موقعیت‌یابی جغرافیایی و امتیاز ریسک (چه سرویس اصلی، چه آینه‌ی جایگزین) هم با IPv6 درست کار می‌کنند. سرویس پشتیبان ProxyIP-Checker-API هم همه‌ی این فرمت‌ها را به‌درستی تفسیر می‌کند.

عیب‌یابی

• خطای «API check failed»: چون Worker خودش پشتیبان بازگشت به TCP مستقیم دارد، این خطا نادر است؛ در صورت مشاهده، مطمئن شوید سرویس پشتیبان (Vercel، Render یا سرور شخصی) در دسترس است و پورت لازم در فایروال باز است.
• امتیاز ریسک «N/A» یا خطا: چون پشتیبان خودکار به آینه‌ی عمومی وجود دارد، این هم نادر است؛ در صورت استفاده از حساب اختصاصی Scamalytics، درستی مقادیر SCAMALYTICS_USERNAME و SCAMALYTICS_API_KEY را در تنظیمات Cloudflare بررسی کنید.
• اسکن بعد از تازه‌سازی از اول شروع می‌شود: مطمئن شوید دقیقاً همان ورودی قبلی را دارید؛ ورودی متفاوت عمداً کش جداگانه می‌گیرد.
• خطای ۵۰۰ روی Worker: معمولاً به‌دلیل جاافتادن یک متغیر محیطی است؛ پس از تنظیم صحیح متغیرها، دوباره استقرار دهید.
• سرویس روی Render کند بالا می‌آید: در پلن رایگان طبیعی است (Cold Start)؛ برای رفع آن یا از پلن پولی استفاده کنید یا سرویس را با یک پینگ دوره‌ای بیدار نگه دارید.

لینک‌های مرتبط

• ریپوی اصلی: https://github.com/mehdi-hexing/CF-ProxyIPChecker
• سرویس پشتیبان (Vercel): https://github.com/mehdi-hexing/ProxyIP-Checker-vercel-API
• سرویس پشتیبان (Python — قابل استقرار روی Render یا VPS): https://github.com/mehdi-hexing/ProxyIP-Checker-API