کانفیگ‌های رایگان V2Ray — تجمیعِ خودکار، تکراری‌زداییِ CDN-aware، اعتبارسنجی با کلاینتِ واقعی، تستِ در دسترس بودن

هر شمارندهٔ زیر به‌صورت زنده از index.json / health.jsonِ خودِ همین ریپازیتوری خوانده می‌شود — پس نمی‌تواند کهنه شود:

🇬🇧 English version · 🇨🇳 中文版 · 🇷🇺 Русская версия

🚀 از اینجا شروع کنید — یک خط را کپی کنید

فهرستِ ۱۰۰ برتر کوتاه‌ترین راه به یک اتصالِ کارآمد است: همان فهرستِ verified است که بر اساسِ تأخیرِ میانه مرتب و در ۱۰۰ موردِ سریع‌تر بریده شده — آن‌قدر کوچک که همه‌جا وارد شود، و هر مورد از قبل سه بار به یک درخواستِ واقعی پاسخ داده است.

https://raw.githubusercontent.com/0xRadikal/Free-v2ray-Configs/main/top100.txt

بیش از ۱۰۰ سرور می‌خواهید؟ به‌جایش فهرستِ کاملِ verified را بردارید — همان استانداردِ اثبات، فقط بلندتر:

https://raw.githubusercontent.com/0xRadikal/Free-v2ray-Configs/main/verified/configs_base64.txt

📱 با گوشی آمده‌اید؟ اسکنرِ کلاینت‌تان را روی یکی از این‌ها بگیرید.

_{هر کیو‌آرکد خودِ آدرسِ اشتراک را رمزگذاری می‌کند — کلاینتِ شما هر بار فهرستِ تازه می‌گیرد؛ این یک عکسِ منجمد نیست.}

⚡ لینک‌های اشتراک

مطمئن نیستید کدام را بردارید؟ از verified استفاده کنید — هر مورد در هر سه دورِ مستقلِ تست، یک درخواستِ واقعیِ HTTP را از داخلِ پروکسی پاسخ داده است:
https://raw.githubusercontent.com/0xRadikal/Free-v2ray-Configs/main/verified/configs_base64.txt
به‌جای مطمئن‌ترین فهرست، بزرگ‌ترین فهرست را می‌خواهید؟ verified را با all عوض کنید.

🎛️ یک دسته (tier) انتخاب کنید

در هر اجرا شش دسته منتشر می‌شود. این‌ها منابعِ متفاوت نیستند — همان استخرِ واحد هستند که بر اساسِ میزانِ شواهدی که نشان می‌دهد یک کانفیگ واقعاً کار می‌کند فیلتر شده‌اند.

دسته	چه چیزی وارد می‌شود	ساده	Base64	Clash	Sing-box
🏆 `verified`	در هر ۳ دور یک درخواستِ واقعی از داخلِ پروکسی موفق بوده — پیشنهادی	txt	b64	yaml	json
⚡ `fast`	`verified` و تأخیرِ میانه `< ۸۰۰ms`	txt	b64	yaml	json
🔐 `secure`	`verified` و دارای forward secrecy، و لینک اعتبارسنجیِ گواهی را غیرفعال نکرده باشد	txt	b64	yaml	json
🌐 `all`	همه‌چیز، تکراری‌زدایی‌شده — بزرگ‌ترین فهرست، عمدتاً تست‌نشده	txt	b64	yaml	json
📦 `heavy`	فقط ۱۴ منبعِ پرحجم	txt	b64	yaml	json
⭐ `light`	فقط ۵ منبعِ گزیده / سرعت‌تست‌شده	txt	b64	yaml	json

کدام فرمت؟ configs_base64.txt فرمتِ کلاسیکِ اشتراک و امن‌ترین پیش‌فرض است. configs.txt همان فهرست بدونِ رمزگذاری است. clash.yaml یک پروفایلِ کاملِ mihomo/Clash و singbox.json یک کانفیگِ کاملِ sing-box است — و هر دو پیش از انتشار با باینریِ واقعی اعتبارسنجی می‌شوند (پایین‌تر را ببینید).

📋 کپی-پیست: آدرسِ همهٔ دسته‌ها

# ── verified — قبول‌شده در هر ۳ دور (پیشنهادی) ─────────────────────────────────
https://raw.githubusercontent.com/0xRadikal/Free-v2ray-Configs/main/verified/configs.txt
https://raw.githubusercontent.com/0xRadikal/Free-v2ray-Configs/main/verified/configs_base64.txt
https://raw.githubusercontent.com/0xRadikal/Free-v2ray-Configs/main/verified/clash.yaml
https://raw.githubusercontent.com/0xRadikal/Free-v2ray-Configs/main/verified/singbox.json

# ── fast — verified و تأخیرِ میانه < 800 ms ────────────────────────────────────
https://raw.githubusercontent.com/0xRadikal/Free-v2ray-Configs/main/fast/configs.txt
https://raw.githubusercontent.com/0xRadikal/Free-v2ray-Configs/main/fast/configs_base64.txt
https://raw.githubusercontent.com/0xRadikal/Free-v2ray-Configs/main/fast/clash.yaml
https://raw.githubusercontent.com/0xRadikal/Free-v2ray-Configs/main/fast/singbox.json

# ── secure — verified و دارای forward secrecy ──────────────────────────────────
https://raw.githubusercontent.com/0xRadikal/Free-v2ray-Configs/main/secure/configs.txt
https://raw.githubusercontent.com/0xRadikal/Free-v2ray-Configs/main/secure/configs_base64.txt
https://raw.githubusercontent.com/0xRadikal/Free-v2ray-Configs/main/secure/clash.yaml
https://raw.githubusercontent.com/0xRadikal/Free-v2ray-Configs/main/secure/singbox.json

# ── all — سبک + انبوه، تکراری‌زدایی‌شده ────────────────────────────────────────
https://raw.githubusercontent.com/0xRadikal/Free-v2ray-Configs/main/all/configs.txt
https://raw.githubusercontent.com/0xRadikal/Free-v2ray-Configs/main/all/configs_base64.txt
https://raw.githubusercontent.com/0xRadikal/Free-v2ray-Configs/main/all/clash.yaml
https://raw.githubusercontent.com/0xRadikal/Free-v2ray-Configs/main/all/singbox.json

# ── heavy — منابعِ پرحجم ───────────────────────────────────────────────────────
https://raw.githubusercontent.com/0xRadikal/Free-v2ray-Configs/main/heavy/configs.txt
https://raw.githubusercontent.com/0xRadikal/Free-v2ray-Configs/main/heavy/configs_base64.txt
https://raw.githubusercontent.com/0xRadikal/Free-v2ray-Configs/main/heavy/clash.yaml
https://raw.githubusercontent.com/0xRadikal/Free-v2ray-Configs/main/heavy/singbox.json

# ── light — منابعِ گزیده ───────────────────────────────────────────────────────
https://raw.githubusercontent.com/0xRadikal/Free-v2ray-Configs/main/light/configs.txt
https://raw.githubusercontent.com/0xRadikal/Free-v2ray-Configs/main/light/configs_base64.txt
https://raw.githubusercontent.com/0xRadikal/Free-v2ray-Configs/main/light/clash.yaml
https://raw.githubusercontent.com/0xRadikal/Free-v2ray-Configs/main/light/singbox.json

# ── ۱۰۰ برتر — همان فهرستِ verified، مرتب‌شده بر اساسِ تأخیرِ میانه ─────────────
https://raw.githubusercontent.com/0xRadikal/Free-v2ray-Configs/main/top100.txt

🎯 لینک‌های تفکیک‌شده بر اساسِ پروتکل

از all/ جدا می‌شوند. یک فایل فقط وقتی خالی نباشد منتشر می‌شود، پس ۴۰۴ یعنی «در این دور هیچ‌چیز از این پروتکل نبود» — و هرگز به معنیِ اشتراکِ خالی نیست که فهرستِ کلاینتِ شما را پاک کند.

پروتکل	ساده	Base64
VLESS	`…/main/protocols/vless.txt`	`…/main/protocols/vless_base64.txt`
VMess	`…/main/protocols/vmess.txt`	`…/main/protocols/vmess_base64.txt`
Trojan	`…/main/protocols/trojan.txt`	`…/main/protocols/trojan_base64.txt`
Shadowsocks	`…/main/protocols/shadowsocks.txt`	`…/main/protocols/shadowsocks_base64.txt`
ShadowsocksR	`…/main/protocols/shadowsocksr.txt`	`…/main/protocols/shadowsocksr_base64.txt`
Hysteria2	`…/main/protocols/hysteria2.txt`	`…/main/protocols/hysteria2_base64.txt`
TUIC	`…/main/protocols/tuic.txt`	`…/main/protocols/tuic_base64.txt`
SOCKS	`…/main/protocols/socks.txt`	`…/main/protocols/socks_base64.txt`

📎 آدرسِ کاملِ هر پروتکل (کپی-پیست)

https://raw.githubusercontent.com/0xRadikal/Free-v2ray-Configs/main/protocols/vless.txt
https://raw.githubusercontent.com/0xRadikal/Free-v2ray-Configs/main/protocols/vless_base64.txt
https://raw.githubusercontent.com/0xRadikal/Free-v2ray-Configs/main/protocols/vmess.txt
https://raw.githubusercontent.com/0xRadikal/Free-v2ray-Configs/main/protocols/vmess_base64.txt
https://raw.githubusercontent.com/0xRadikal/Free-v2ray-Configs/main/protocols/trojan.txt
https://raw.githubusercontent.com/0xRadikal/Free-v2ray-Configs/main/protocols/trojan_base64.txt
https://raw.githubusercontent.com/0xRadikal/Free-v2ray-Configs/main/protocols/shadowsocks.txt
https://raw.githubusercontent.com/0xRadikal/Free-v2ray-Configs/main/protocols/shadowsocks_base64.txt
https://raw.githubusercontent.com/0xRadikal/Free-v2ray-Configs/main/protocols/shadowsocksr.txt
https://raw.githubusercontent.com/0xRadikal/Free-v2ray-Configs/main/protocols/shadowsocksr_base64.txt
https://raw.githubusercontent.com/0xRadikal/Free-v2ray-Configs/main/protocols/hysteria2.txt
https://raw.githubusercontent.com/0xRadikal/Free-v2ray-Configs/main/protocols/hysteria2_base64.txt
https://raw.githubusercontent.com/0xRadikal/Free-v2ray-Configs/main/protocols/tuic.txt
https://raw.githubusercontent.com/0xRadikal/Free-v2ray-Configs/main/protocols/tuic_base64.txt
https://raw.githubusercontent.com/0xRadikal/Free-v2ray-Configs/main/protocols/socks.txt
https://raw.githubusercontent.com/0xRadikal/Free-v2ray-Configs/main/protocols/socks_base64.txt

پارسر پروتکل‌های hysteria · wireguard · juicity · anytls · snell · mieru را هم می‌شناسد، ولی در عکسِ لحظه‌ایِ پایین خالی بودند — هیچ منبعی موردی منتشر نکرده بود. فهرستِ مرجع و همیشه‌به‌روزِ فایل‌های پروتکلی که همین حالا وجود دارند، بلوکِ protocol_files در index.json است.

🧭 متادیتای ماشین‌خوان

فایل	چیست
`index.json`	همهٔ شمارنده‌ها، زمان‌ها، زمانِ تقریبیِ به‌روزرسانیِ بعدی و آدرسِ همهٔ فایل‌ها (raw + آینه)
`health.json`	سلامتِ هر منبع، حذفیاتِ مبدل‌ها، آمارِ جغرافیایی و گزارشِ کاملِ تستِ `cascade`
`state.json`	تاریخچهٔ چرخشیِ بازدهِ هر منبع و تصمیم‌های غیرفعال‌سازیِ خودکار
`top100.txt`	۱۰۰ کانفیگِ verified با کمترین تأخیر
`archive/all_broken.txt`	آنچه رد شده و عمداً قابلِ‌مشاهده نگه داشته شده (+ `_base64`، + `heavy_broken*`)

🪞 آینه (jsDelivr) — فقط اگر `raw.githubusercontent.com` مسدود بود

پیشوندِ https://raw.githubusercontent.com/0xRadikal/Free-v2ray-Configs/main را با https://cdn.jsdelivr.net/gh/0xRadikal/Free-v2ray-Configs@main جایگزین کنید — همهٔ مسیرهای بالا روی آینه بدونِ تغییر وجود دارند.

https://cdn.jsdelivr.net/gh/0xRadikal/Free-v2ray-Configs@main/verified/configs_base64.txt

تا می‌توانید raw را ترجیح دهید. این نظر نیست؛ همان link_policyِ خودِ ریپازیتوری است:

	دستورِ کش	بدترین حالتِ کهنگی
`raw.githubusercontent.com`	`max-age=300`	۵ دقیقه
`cdn.jsdelivr.net` (رفرنسِ شاخه)	`s-maxage=43200`	۱۲ ساعت — ۱۴۴ برابر بیشتر

کشِ CDN در هر اجرا purge می‌شود، ولی purge فقط لبه (edge) را پاک می‌کند؛ مبدأِ خودِ jsDelivr هنگامِ resolve کردنِ نامِ شاخه می‌تواند باز هم عقب بماند. اگر از طریقِ CDN نسخهٔ دقیقاً یکسان می‌خواهید، به‌جای شاخه یک کامیت را پین کنید: @<commit-sha>/….

📌 همه‌چیز روی شاخهٔ پیش‌فرض (main) است. نه تغییرِ شاخه، نه محلِ پنهان — لینکی که ماه‌ها پیش کپی کرده‌اید هنوز کار می‌کند. اینکه چرا این به آن بدیهی‌ای که به‌نظر می‌رسد نیست: چطور هزینهٔ انتشار پایین می‌ماند.

🧪 واقعاً کار می‌کند؟

بیشترِ ریپازیتوری‌های کانفیگِ رایگان یک عددِ بزرگ منتشر می‌کنند و بقیه‌اش را به حدسِ شما می‌سپارند. پاسخِ ناخوشایند، که اندازه‌گیری شده و نه تخمین زده، این است: در هر لحظه، اکثریتِ قاطعِ هر استخرِ کانفیگِ رایگان مرده است. این ویژگیِ خودِ کانفیگِ رایگان است، نه ایرادِ این ریپازیتوری — پس به‌جای پنهان‌کردنش، هر اجرا آن را اندازه می‌گیرد و بر اساسِ همان مرتب می‌کند.

هر کانفیگ از چهار مرحله عبور می‌کند. هر مرحله آن‌قدر ارزان است که روی کلِ استخر اجرا شود، و هر کدام کاری را دور می‌ریزد که مرحلهٔ بعدی رویش هدر می‌داد:

خط‌لولهٔ چهارمرحله‌ای: جمع‌آوری، ترمیم، اتصال، اثبات، انتشار

مرحله	سؤالی که می‌پرسد	هزینه
L0 / L1	قابلِ پارس است؟ endpoint یکتاست؟ قابلِ مسیریابی است؟	بدونِ شبکه
L2	آیا پورتِ TCP واقعاً اتصال را می‌پذیرد؟	یک connect برای هر endpointِ یکتا
L3	آیا یک درخواستِ واقعیِ HTTP از داخلِ پروکسی موفق می‌شود؟	handshakeِ کامل، ۳ بار تکرار
دسته‌ها	کدام‌ها در هر دورِ L3 قبول شدند؟	فقط مرتب‌سازی

یک کانفیگ فقط وقتی به verified/ می‌رسد که در هر دور قبول شده باشد — نه صرفاً در بهترین دورش.

📉 قیف، روی یک انتشارِ واقعی

عکسِ لحظه‌ای: 2026-08-02 08:38:43 UTC · اجرا ۲۱۳ ثانیه طول کشید · تست از یک رانرِ 🇺🇸 آمریکا (کلوی Cloudflare با کدِ IAD) اجرا شد

مرحله	کانفیگ	سهم از استخر
واکشی‌شده از ۱۷ منبعِ زنده	۱۴٬۲۱۲	—
یکتا پس از تکراری‌زداییِ CDN-aware	۱۰٬۱۱۸	۱۰۰ ٪
ساختاراً معتبر (L0/L1)	۱۰٬۰۷۱	۹۹٫۵ ٪
پورتِ TCP باز (L2)	۵٬۲۸۵	۵۲٫۲ ٪
حداقل یک بار کار کرد (L3)	۱٬۲۳۱	۱۲٫۲ ٪
در هر ۳ دور کار کرد ← `verified/`	۸۵۶	۸٫۵ ٪

سه دورِ L3 به‌تنهایی ۱٬۰۴۰ / ۱٬۰۶۹ / ۱٬۰۷۴ موفقیت برگرداندند — ولی فقط ۸۵۶ کانفیگ در هر سه مجموعه هستند. یعنی ۳۰٫۴۶ ٪ از هر چیزی که تا به حال کار کرده، بی‌ثبات (flaky) است. انتشارِ «هر چیزی که یک بار کار کرد» نتیجه را ۱٫۴۴ برابر بزرگ‌نمایی می‌کرد؛ انتشارِ بهترین دورِ تکی، ۱٫۲۵ برابر. همین شکاف، تمامِ دلیلِ اجرای بیش از یک‌بارهٔ مرحلهٔ L3 است.

⚠️ پیش از نقلِ این درصد، این را بخوانید

۸٫۵ ٪ یک ثابت نیست، و ادعایی دربارهٔ اتصالِ شما هم نیست. این عدد از یک میزبان، در ایالات متحده، در یک روز اندازه‌گیری شده است. کانفیگی که از یک رانرِ گیت‌هاب در ویرجینیا شکست می‌خورد، ممکن است از تهران عالی کار کند — و برعکسش هم به همان اندازه درست است.

پس: verified/ یعنی «این کانفیگ به یک درخواستِ واقعی از همان ماشینی که تست را اجرا کرد پاسخ داد» — نه «این کانفیگ برای شما کار خواهد کرد». اعدادِ دقیقاً همان انتشاری که دارید دانلود می‌کنید، به‌همراهِ کشوری که تست از آن اجرا شده، در بلوکِ cascadeِ health.json ثبت است. به آن فایل بیشتر از هر عددی که در این README نوشته شده اعتماد کنید، چون این‌ها ذاتاً یک عکسِ لحظه‌ایِ تاریخ‌دارند.

📊 هر چیزِ دیگری که آن عکسِ لحظه‌ای اندازه گرفت


اندازهٔ دسته‌ها	`all` ۱۰٬۱۱۸ · `heavy` ۸٬۴۰۹ · `light` ۲٬۵۲۱ · `verified` ۸۵۶ · `fast` ۵۷۸ · `secure` ۴۹۵ · `top100` ۱۰۰
پروتکل‌ها	vless ۳٬۶۵۵ · vmess ۳٬۲۱۷ · shadowsocks ۲٬۱۱۳ · trojan ۹۷۸ · hysteria2 ۱۲۳ · shadowsocksr ۲۸ · tuic ۲ · socks ۲
تکراری‌زدایی	۴٬۰۹۳ تکراری حذف شد؛ ۱۰٬۱۱۸ کانفیگ به ۸٬۵۶۰ endpointِ یکتا جمع می‌شوند (۱۵٫۰ ٪ صرفه‌جویی در کارِ L2)
حذف‌شده در L0/L1	مجموعاً ۴۷ — غیرقابلِ پارس ۱۸ · سرورِ غیرقابلِ مسیریابی ۱۶ · سرورِ نامعتبر ۱۰ · UUIDِ نامعتبر ۲ · پورتِ نامعتبر ۱
DNS	۳۲۳ endpoint در L2 وضوح نشد؛ ۶٬۲۳۷ میزبان مکان‌یابی شد، ۳۰۳ نامعلوم
حذفیاتِ مبدل	Clash ۴۷ · sing-box ۳۶۴ (که ۳۱۹ موردش اساساً در طرح‌وارهٔ sing-box قابلِ بیان نیستند)
منابع	۲۱ پیکربندی‌شده (۷ سبک + ۱۴ انبوه) · ۱۷ کانفیگ برگرداندند · ۰ خالی · ۰ ناموفق
زمانِ مراحل	L0/L1 ۰٫۳۳ ثانیه · L2 ۳۳٫۵ ثانیه · L3 ۱۷۸٫۸ ثانیه · مجموع ۲۱۳٫۰ ثانیه

✅ هر انتشار با کلاینت‌های واقعی بررسی می‌شود

یک ورودیِ خراب باعث می‌شود کلاینت کلِ فایل را رد کند — پس خروجیِ «تقریباً معتبر» هیچ ارزشی ندارد. پیش از هر انتشار، هر clash.yaml و singbox.jsonِ تولیدشده با همان باینری‌هایی پارس می‌شود که خودتان اجرا می‌کنید:

sing-box check -c <file>      # sing-box 1.13.14
mihomo -t -f <file>           # mihomo   v1.19.29

هر دو باینری در زمانِ دانلود داخلِ ورک‌فلو به نسخه پین شده و با SHA256 راستی‌آزمایی می‌شوند. اگر هر فایلی در اعتبارسنجی رد شود، اجرا متوقف می‌شود و هیچ چیز کامیت نمی‌شود — انتشارِ سالمِ قبلی دقیقاً سرِ جای خودش می‌ماند.

⚠️ معتبر بودنِ ساختاری با کار کردن یکی نیست. ورودی‌هایی که ساختارشان شکسته است (UUIDِ صفر، App not supported، رمزنگاری‌های پشتیبانی‌نشده، کلیدهای خرابِ REALITY) حذف می‌شوند — اما یک کانفیگ با نحوِ کاملاً درست هم می‌تواند مرده باشد. آن پرسشِ دیگری است و جداگانه توسطِ آبشارِ L3 در بالا پاسخ داده می‌شود.

🏷️ نام‌های پایدار و مشتق‌شده از محتوا

هر remark به {CC} {flag} | @Raydikalx | {id} بازنویسی می‌شود که در آن {id} برابرِ sha256(dedup-key)[:6] است — از خودِ کانفیگ مشتق می‌شود، نه از جایگاهش در فهرست. پس یک سرورِ یکسان همیشه همان برچسب را می‌گیرد و نامِ ورودی‌ها در کلاینتِ شما بینِ به‌روزرسانی‌ها پایدار می‌ماند، به‌جای اینکه هر ۱۵ دقیقه دوباره درهم شود.

🗂️ ساختار ریپازیتوری

فقط یک شاخه — main. کدِ منبع و خروجیِ منتشرشده کنارِ هم روی شاخهٔ پیش‌فرض زندگی می‌کنند، یعنی دقیقاً همان چیزی که بازدیدکننده هنگامِ بازکردنِ ریپازیتوری می‌بیند.

تولیدشده توسطِ ماشین، در هر اجرا تازه می‌شود (۴۸ فایل):

verified/   configs.txt · configs_base64.txt · clash.yaml · singbox.json   هر ۳ دور را رد کرد
fast/       configs.txt · configs_base64.txt · clash.yaml · singbox.json   verified + میانه < 800ms
secure/     configs.txt · configs_base64.txt · clash.yaml · singbox.json   verified + forward secrecy
all/        configs.txt · configs_base64.txt · clash.yaml · singbox.json   light + heavy، تکراری‌زدایی‌شده
heavy/      configs.txt · configs_base64.txt · clash.yaml · singbox.json   ۱۴ منبعِ پرحجم
light/      configs.txt · configs_base64.txt · clash.yaml · singbox.json   ۵ منبعِ گزینش‌شده
protocols/  vless.txt · vmess.txt · trojan.txt · … (+ *_base64.txt)        تفکیک‌شده از all/
archive/    all_broken.txt · heavy_broken.txt (+ _base64)                  آنچه رد شد
top100.txt  ۱۰۰ کانفیگِ verified با کمترین تأخیر
index.json  شمارش‌ها · زمان‌ها · تفکیکِ پروتکل · آدرسِ همهٔ فایل‌ها
health.json سلامتِ هر منبع · حذفیاتِ مبدل · موقعیتِ جغرافیایی · گزارشِ کاملِ آبشار
state.json  تاریخچهٔ غلتانِ بازدهیِ هر منبع و تصمیم‌های غیرفعال‌سازیِ خودکار

نوشتهٔ انسان، با تاریخچه و blameِ عادیِ گیت:

scripts/    خطِ لوله — core · sources · filters · converters · geo · reachability
            realtest · pipeline · aggregate · validate · state (+ test_pipeline.py)
.github/    ورک‌فلوی زمان‌بندی‌شده · پیکربندیِ Dependabot · قالب‌های issue
docs/       داشبوردِ زندهٔ وضعیت (index.json / health.json را در مرورگر می‌خواند)
README.md · README_FA.md · README_ZH.md · README_RU.md
SECURITY.md · CONTRIBUTING.md · LICENSE

دو قاعده که به‌راحتی از قلم می‌افتند و خیلی مهم‌اند:

فایلِ خالی هرگز منتشر نمی‌شود. فایلی در protocols/ یا archive/ فقط وقتی ظاهر می‌شود که محتوا داشته باشد. فایلِ خالی بدتر از ۴۰۴ است: کلاینتی که مشترکِ آن است فهرستِ کارآمدش را با هیچ جایگزین می‌کند، در حالی که ۴۰۴ باعث می‌شود کلاینت‌ها همان چیزی را که دارند نگه دارند.
index.json دقیقاً همان فایل‌هایی را اعلام می‌کند که وجود دارند — فهرستِ آدرس‌هایش هرگز وعده‌ای نیست که ریپازیتوری نتواند به آن عمل کند.

🌿 چطور انتشار ارزان می‌ماند (و چرا فایل‌ها روی `main` هستند)

گیت هیچ blobی را فراموش نمی‌کند. هر اجرای زمان‌بندی‌شده همان مجموعهٔ فایل‌های بزرگ را دوباره تولید می‌کند، و افزودنِ آن‌ها به یک شاخه به روشِ معمول یک نسخهٔ دائمیِ جدید از هر فایلِ تغییرکرده را برای همیشه به تاریخچه اضافه می‌کند. آنگاه هزینهٔ انتشار O(تعدادِ اجراها) می‌شود، بدون هیچ سقفی. با حدودِ ۹۶ اجرا در روز این یک نگرانیِ نظری نیست: تاریخچهٔ همین ریپازیتوری پیش از اصلاح تا ≈ ۳٫۶ گیبی‌بایت رشد کرده بود.

❌ راه‌حلِ غلط (امتحان شد و برگردانده شد)

انتقالِ خروجی به یک شاخهٔ orphan که با force به‌صورتِ یک کامیتِ واحد push شود. هزینهٔ انتشار واقعاً به O(1) افت کرد — و پروژه بی‌سروصدا خراب شد:

هر لینکِ اشتراکی که قبلاً کپی شده بود HTTP 404 برگرداند. کاربری که کلاینتش به …/main/all/configs.txt اشاره می‌کرد پیامِ خطایی نمی‌دید؛ اشتراک فقط بی‌صدا خالی می‌شد.
بازدیدکننده‌ای که ریپازیتوری را باز می‌کرد هیچ کانفیگی نمی‌دید — فقط کد. بیشترِ کسانی که دنبالِ کانفیگ‌اند اصلاً نمی‌دانند شاخهٔ گیت چیست، چه رسد به اینکه باید به شاخهٔ دومی سوئیچ کنند و دوباره بگردند.
قابلیتِ کشف‌شدن فرو ریخت. جست‌وجوی گیت‌هاب، صفحهٔ اصلی و موتورهای جست‌وجو همگی شاخهٔ پیش‌فرض را ایندکس می‌کنند.
حتی یک ریپازیتوریِ موفق در این حوزه چنین نمی‌کند. مستقیماً بررسی شد: Epodonios/v2ray-configs، mahdibland/V2RayAggregator، Pawdroid/Free-servers — همه روی شاخهٔ پیش‌فرضشان منتشر می‌کنند.

تاریخچهٔ ارزان وقتی هیچ‌کس نتواند فایل‌ها را پیدا کند هیچ ارزشی ندارد.

✅ راه‌حلِ درست — «rolling squash» روی `main`

خروجی روی شاخهٔ پیش‌فرض منتشر می‌شود، اما شاخه در وضعیتِ تاریخچهٔ منبع + دقیقاً یک کامیتِ خروجی نگه داشته می‌شود:

تازه‌ترین کامیتی که [auto-output] ندارد پیدا می‌شود — لنگر (anchor).
یک درخت ساخته می‌شود = درختِ لنگر + خروجیِ تازهٔ همین اجرا.
git commit-tree <tree> -p <anchor> و سپس push با lease.

کامیتِ خروجیِ قبلی غیرقابلِ دسترس می‌شود و توسطِ زباله‌روب پاک می‌شود. این را می‌توانید مستقیماً از لاگ بخوانید — به‌طور دقیق یک‌درمیان است، یک کامیتِ خروجی به‌ازای هر کامیتِ انسانی، فارغ از اینکه در این میان چند اجرا رخ داده باشد:

94a939f23  bot     chore: update configs — 07:42 UTC — 10116 configs   ← تنها خروجیِ زنده
e5a0e7dbf  human   docs: rebuild the status dashboard …
a72b66717  bot     chore: update configs — 22:12 UTC — 10146 configs
19b8d6cca  human   docs(security): document the branch and tag rulesets …

هزینهٔ انتشار O(1) است — در حالی که هر فایل دقیقاً همان‌جایی می‌ماند که کاربران و خزنده‌ها از قبل دنبالش می‌گردند.

هر یک از ویژگی‌های ایمنیِ زیر با یک تستِ اجراشدنی پشتیبانی می‌شود:

--force-with-lease، هرگز --forceِ خالی. انتشار همان شاخه‌ای را هدف می‌گیرد که انسان‌ها رویش کامیت می‌کنند، پس یک force-pushِ ساده‌لوحانه کارِ آن‌ها را پاک می‌کرد. در اجرای کنترلِ منفی، یک --forceِ ساده تعدادِ کامیت‌های مالک روی ریموت را به ۰ رساند. با lease، یک pushِ واقعاً متعارض رد می‌شود، مرحله دوباره لنگر می‌گیرد، و هم کامیتِ مالک و هم خروجیِ جدید زنده می‌مانند.
نگهبانِ پس‌رفتِ منبع. هر مسیری که بینِ لنگر و نوک تفاوت دارد دسته‌بندی می‌شود؛ اگر چیزی بیرون از مجموعهٔ خروجی تغییر کرده باشد، مرحله به‌جای برگرداندنِ کدِ کسی، از انتشار خودداری می‌کند.
آگاه به checkoutِ کم‌عمق. actions/checkout با عمقِ ۱ واکشی می‌کند، پس تنها کامیتِ قابلِ مشاهده معمولاً یک کامیتِ خروجی است و جست‌وجوی لنگر چیزی پیدا نمی‌کرد — و انتشار برای همیشه متوقف می‌شد. این مرحله عمق را به‌تدریج زیاد می‌کند (۲ ← ۴ ← ۸ ← ۳۲) تا لنگر پیدا شود. (fetch-depth: 0 رد شد: کلونِ گیگابایتی ۹۶ بار در روز.)
همه‌جا fail-closed. نبودِ خروجی، فایلِ کانفیگِ مشکوکانه کوچک، یا درختِ خالی انتشار را متوقف می‌کند و انتشارِ سالمِ قبلی را سرِ جایش می‌گذارد.
بدونِ بازگشت. pushهایی که با GITHUB_TOKEN انجام می‌شوند اجرای ورک‌فلوی جدید را تحریک نمی‌کنند، و تریگرِ push علاوه بر آن به scripts/** محدود شده که ربات هرگز در آن نمی‌نویسد.

🧊 قطعی‌بودنِ خروجی عمدی است

rolling squash تاریخچه را کران‌دار می‌کند؛ قطعی‌بودن باعث می‌شود diffِ هر دور واقعاً کوچک بماند. سه منبعِ churnِ بی‌فایده با اندازه‌گیری پیدا و حذف شدند:

قبلاً	اکنون
برچسبِ کشور از هر منبعی که اول واکشی می‌شد گرفته می‌شد — همان سرور بینِ اجراها `RU 🇷🇺` ⇄ `US 🇺🇸` می‌شد	برچسب به endpoint قفل شده؛ نخستین تشخیصِ قاطع برنده و منجمد می‌شود
برچسبِ remark یک شمارندهٔ مکانی بود — افزودنِ یک کانفیگ نامِ هر خطِ بعدش را عوض می‌کرد	برچسب `sha256(dedup-key)[:6]` است، مشتق از محتوا و مصون از جایگاه
ترتیبِ خطوط از ترتیبِ پاسخِ شبکه پیروی می‌کرد	مرتب‌شده بر اساسِ dedup key — همان مجموعه کانفیگ همان فایل را بایت‌به‌بایت تولید می‌کند

قطعی‌بودن به معنای توقفِ تغییرِ فایل‌ها نیست؛ یعنی فایل‌ها فقط وقتی داده تغییر کند تغییر می‌کنند — و آن churnی که قبلاً بدونِ تغییرِ داده رخ می‌داد از بین رفته است.

🩹 یک هشدارِ صادقانه

آن ≈ ۳٫۶ گیبی‌بایتی که از قبل در تاریخچه است بازنویسی نشد. چون گیت‌هاب اشیا را در کلِ شبکهٔ fork به اشتراک می‌گذارد، بازنویسی تقریباً هیچ فضایی آزاد نمی‌کرد ولی هر کلونِ موجود و هر دو fork را می‌شکست. خون‌ریزی از این پس متوقف شده؛ زخمِ قدیمی عمداً دست‌نخورده رها شده است.

📊 متادیتای زنده — `index.json`

https://raw.githubusercontent.com/0xRadikal/Free-v2ray-Configs/main/index.json

شمارشِ هر دسته (یکتا / تکراری / خراب / منابعِ فعال)، تفکیکِ پروتکل، زمانِ آخرین به‌روزرسانی، تخمینِ زمانِ به‌روزرسانیِ بعدی، آدرسِ همهٔ فایل‌ها (rawِ اصلی + آینهٔ CDN)، و یک بلوکِ link_policy که می‌گوید کدام را ترجیح دهید و چرا.

سه دستهٔ همیشه‌موجود (all / heavy / light) زیرِ کلیدِ categories هستند. آبشارِ راستی‌آزمایی جداگانه زیرِ cascade_categories (verified / fast / secure) و یک بلوکِ سطح‌بالای top100 منتشر می‌شود؛ هرکدام کنارِ آدرسِ فایل‌هایش یک criterionِ یک‌خطیِ ماشین‌خوان هم دارد. این جدایی عمدی است: آبشار پس از ساختِ اصلی اجرا می‌شود و مجاز است اجرا نشود، پس هر مصرف‌کننده‌ای که روی categories حلقه می‌زند بی‌تغییر کار می‌کند و هرگز برای اجرایی که آبشار نداشته لینکی نشان نمی‌دهد.

اگر دارید چیزی روی این ریپازیتوری می‌سازید، به‌جای hardcode کردنِ مسیرها index.json را بخوانید — آن قرارداد است، و هرگز نمی‌تواند فایلی را اعلام کند که وجود ندارد.

🩺 سلامتِ منابع و گزارشِ تست — `health.json`

https://raw.githubusercontent.com/0xRadikal/Free-v2ray-Configs/main/health.json

در هر اجرا بازتولید می‌شود. برای هر یک از ۱۹ منبع، status (ok / empty / fail)، کدِ HTTP، تعدادِ تلاش، تأخیر، تعدادِ کانفیگِ برگردانده‌شده و آخرین خطا را ثبت می‌کند — پس یک منبعِ مرده یا تغییرکرده بی‌درنگ دیده می‌شود، به‌جای اینکه بی‌صدا خروجی را آب کند.

همین فایل بلوکِ cascade را هم دارد: اعداد از همان ماشینی می‌آیند که انتشار را تولید کرده، نه از این README. این همان بلوکِ عکسِ لحظه‌ایِ بالاست، به‌صورتِ خلاصه:

"cascade": {
  "exit_country": { "colo": "IAD", "loc": "US",          // تست از کجا اجرا شد
                    "source": "https://cp.cloudflare.com/cdn-cgi/trace" },
  "layers": {
    "l0_l1": { "in": 10118, "out": 10071, "seconds": 0.33,
               "endpoints_unique": 8560, "dedup_saving_pct": 15.0,
               "dropped": { "unparsable": 18, "invalid_port": 1, "invalid_uuid": 2,
                            "unroutable_server": 16, "invalid_server": 10 } },
    "l2":    { "in": 10071, "out": 5285, "open_pct": 52.48,
               "open_pct_of_raw_input": 52.23, "dns_failed": 323,
               "dns_seconds": 17.52, "tcp_seconds": 15.58, "seconds": 33.47 },
    "l3":    { "in": 5285, "rounds": 3, "per_run_ok": [1040, 1069, 1074],
               "ever_ok": 1231, "stable": 856, "flaky_pct": 30.46,
               "seconds": 178.77 }
  },
  "buckets": { "verified": 856, "fast": 578, "secure": 495, "top": 100,
               "top_short_by": 0, "fast_threshold_ms": 800 },
  "total_seconds": 213.03
}

سه نکته که دانستنشان می‌ارزد:

exit_country کشوری است که تست از آنجا اجرا شده — مهم‌ترین هشدار هنگامِ خواندنِ هر نرخِ موفقیتی. فقط loc و colo ثبت می‌شوند؛ نشانیِ IPِ رانر عمداً هرگز منتشر نمی‌شود.
dropped دلیلِ ردشدنِ هر کانفیگ را نام می‌برد، پس منبعی که شروع به فرستادنِ آشغال کند دیده می‌شود، نه اینکه فقط بی‌صدا خروجی را کوچک کند.
per_run_ok در برابرِ stable بی‌ثباتی را مستقیم نشان می‌دهد. stable فقط کانفیگ‌هایی را می‌شمارد که هر دور را رد کرده‌اند — و verified/ از همین ساخته می‌شود.

📈 داشبوردِ زنده

https://0xradikal.github.io/Free-v2ray-Configs/

یک صفحهٔ کاملاً خودبسنده که index.json و health.json را در مرورگرِ شما واکشی می‌کند و آبشار، دسته‌ها، سلامتِ هر منبع، تفکیکِ جغرافیایی و حذفیاتِ مبدل را رسم می‌کند. هیچ درخواستِ بیرونی نمی‌فرستد — نه CDN، نه ردیاب، نه فونت — و اگر raw در دسترس نباشد به‌صورتِ خودکار به آینهٔ jsDelivr برمی‌گردد.

⚙️ چطور کار می‌کند

واکشی — ۱۹ منبع به‌صورتِ هم‌زمان دانلود می‌شوند، با تشخیصِ خودکارِ base64/متنِ ساده. در خطاهای گذرا دوباره تلاش می‌کند، اما روی ۴xx سریع شکست می‌خورد تا یک آدرسِ مرده گزارش شود، نه اینکه بی‌صدا تا ابد دوباره تلاش شود.
پاک‌سازی — حذفِ ورودی‌های ساختگی و ساختاراً خراب (UUIDِ صفر، App not supported، پراکسیِ خالی، سرورهای غیرقابلِ مسیریابی).
تکراری‌زدایی — اثرانگشتِ هویتِ سرور با آگاهی از CDN، پس میزبانی که پشتِ IPهای چرخانِ CDN است به یک ورودیِ واحد جمع می‌شود، نه اینکه ده‌ها بار ظاهر شود.
برچسب‌گذاری — هر remark به {CC} {flag} | @Raydikalx | {id} بازنویسی می‌شود با {id}ِ مشتق از محتوا و برچسبِ کشورِ قفل‌شده به endpoint.
تبدیل — ترجمهٔ طرح‌واره برای هر کلاینت با اعتبارسنجیِ سخت‌گیرانهٔ فیلدها: فهرستِ سفیدِ cipherها، طولِ کلیدِ SS-2022، uTLS برای REALITY، بررسیِ قالبِ short-id / کلیدِ عمومی، و انتشارِ کاملِ transport (ws / grpc / h2 / http / httpupgrade / xhttp). ورودی‌هایی که کلاینت نمی‌تواند بیانشان کند حذف می‌شوند، نه اینکه بی‌صدا تنزل داده شوند — یک کانفیگِ تنزل‌یافته معتبر به نظر می‌رسد و هرگز وصل نمی‌شود.
راستی‌آزمایی — sing-box check + mihomo -t روی هر فایلِ تولیدشده. هر شکستی اجرا را متوقف می‌کند.
تست — آبشارِ L0→L3 واقعاً از طریقِ پراکسی‌ها وصل می‌شود، سه بار، و verified/، fast/، secure/ و top100.txt را می‌سازد.
انتشار — کامیتِ rolling-squash روی main، به‌علاوهٔ purge کردنِ jsDelivr.

⏱️ زمان‌بندیِ قابلِ اتکای ~۱۵ دقیقه‌ای

schedule:ِ کرانِ گیت‌هاب «حداکثرِ تلاش» است و در دوره‌های شلوغ مکرراً تأخیر می‌خورد یا رد می‌شود. برای حفظِ آهنگِ ثابت با این حال، این ریپازیتوری از سه لایه استفاده می‌کند:

کرانِ پرتکرار (*/5 * * * *) — شانسِ بیشتری برای اینکه واقعاً شلیک شود.
دروازهٔ تازگی — هر تیک بی‌درنگ خارج می‌شود اگر index.json کمتر از ۱۳ دقیقه پیش به‌روز شده باشد، پس کارِ سنگین تقریباً هر ۱۵ دقیقه یک‌بار اجرا می‌شود: نه اجرای هدررفته، نه به‌روزرسانیِ دوتایی.
پشتیبانِ repository_dispatch — یک رباتِ همیشه‌روشن هر ۱۵ دقیقه رویدادِ aggregate-now می‌فرستد و اجرا را تضمین می‌کند، حتی اگر کران کاملاً حذف شود. workflow_dispatchِ دستی (با forceِ اختیاری) هم پشتیبانی می‌شود.

🤝 مشارکت، امنیت، مجوز


🐛 منبعِ خراب یا کانفیگِ بد پیدا کردید؟	یک issue باز کنید — قالب‌ها در `.github/` هستند
🔐 سیاستِ امنیتی	`SECURITY.md`
📐 راهنمای مشارکت	`CONTRIBUTING.md`
📜 مجوز	MIT

🙌 منابع

با تشکر از همهٔ نگهدارندگانِ منابعِ بالادستی — mahdibland، peasoft، mahsanet، barry-far، roosterkid، 4n0nymou3، ALIILAPRO، Epodonios، V2RAYCONFIGSPOOL، ShadowException، w1770946466 و دیگران. این ریپازیتوری فقط کانفیگ‌های در دسترسِ عموم را گردآوری، تکراری‌زدایی، اعتبارسنجی و تست می‌کند. فهرستِ کامل و به‌روز به‌همراهِ سلامتِ هر منبع در health.json است.

📜 سلبِ مسئولیت

برای مقاصدِ آموزشی و پژوهشی. هیچ تضمینی برای در دسترس بودن یا کیفیت وجود ندارد — به واقعیتِ اندازه‌گیری‌شدهٔ بالا نگاه کنید، که دقیقاً به همین دلیل منتشر می‌شود که لازم نباشد هیچ‌چیزِ اینجا را بر اساسِ اعتماد بپذیرید. مسئولانه و مطابقِ قوانینِ محلِ خودتان استفاده کنید.

دو چیز این پروژه را زنده نگه می‌دارد

اینجا نه ثبت‌نامی هست، نه تبلیغی، نه دیوارِ پرداختی — و هرگز هم نخواهد بود. آن دو چیزی که واقعاً زنده نگهش می‌دارند هیچ هزینه‌ای برای شما ندارند:

⭐ یک ستاره تنها راهی است که کسی این پروژه را پیدا می‌کند. گیت‌هاب جست‌وجو و «ریپازیتوری‌های مرتبط» را بر اساسِ ستاره رتبه‌بندی می‌کند، پس یک کلیک واقعاً تعیین می‌کند که نفرِ بعدی که دنبالِ یک کانفیگِ کارآمد است اصلاً این صفحه را ببیند یا نه.

📣 @Raydikalx جایی است که قطعی، منبعِ مرده یا لینکِ تغییرکرده پیش از آنکه متوجه سکوتِ کلاینتتان شوید اعلام می‌شود. پرسش‌ها و گزارشِ کانفیگ‌های خراب هم آنجا پذیرفته می‌شود.

💜 اختیاری — یک انعام بگذارید

هیچ‌چیز در این صفحه پشتِ پرداخت نیست و هرگز نخواهد بود: هر لینکِ بالا دقیقاً یکسان کار می‌کند، چه این بخش را بخوانید چه نخوانید. اما اگر این پروژه یک شب گشتن به‌دنبالِ کانفیگی که واقعاً وصل شود را برایتان صرفه‌جویی کرد، می‌توانید انعامی بفرستید. هر مبلغی قدردانی می‌شود — مبلغِ کوچک کاملاً خوب است.

TRC20 — شبکهٔ Tron

TYBumju6Mjd8JCn4RTq95Kk2HPsdcinuz5

زنجیره‌های EVM — Ethereum، BSC، Polygon، Arbitrum، Base، …

0x2F6ec47e416B42C623cF81a64266EE4910a698Cf

TON — The Open Network

UQBbZrE5aDsdGVi6enpf_vPuG022W4KjkJNzTDkjVEn4gmu6

Important

فقط روی شبکه‌ای بفرستید که بالای هر نشانی نام برده شده است. هر QR دقیقاً همان نشانیِ چاپ‌شده زیرش را رمزگذاری می‌کند و هیچ‌چیزِ دیگری — نه مبلغ، نه memo، نه قراردادِ توکن — پس کد و متن دو راهِ خواندنِ یک چیزِ واحدند. هرکدام را بیشتر باور دارید، اسکن یا کپی کنید.

کانال: @Raydikalx · ربات: @RaydikalxBot · داشبورد: وضعیتِ زنده

_{هر عددی که در این README نوشته شده یک عکسِ لحظه‌ایِ تاریخ‌دار است. اعداد زنده همیشه در
index.json و
health.json هستند.}

FilesExpand file tree

README_FA.md

Latest commit

History