از قالب تا لینک
اشتراک یک کاربر وقتی ساخته می‌شود که اپش آن را می‌خواهد، از روی آنچه پنل در آن لحظه می‌داند. هیچ چیزی کش نمی‌شود و هیچ چیزی برای نود فرستاده نمی‌شود، پس ویرایش یک آدرس، یک فرانت یا یک قالب نام در دریافت بعدی اعمال می‌شود. این صفحه ساخت اشتراک را از قالب‌های کاربر تا بایت‌هایی که اپش دریافت می‌کند دنبال می‌کند. خود تنظیمات در اشتراک‌ها و صفحه‌ی اشتراک آمده‌اند.
۱. کاربر به کدام اینباندها می‌رسد
پنل از حساب شروع می‌کند:
- قالب‌ها. هر کاربر به یک قالب، چند قالب، یا همه‌ی آن‌ها تعلق دارد.
- نودها. هر نود فعال روی آن قالب‌ها به کاربر سرویس می‌دهد.
- اینباندها. هر اینباند قالب نود یک راه ورود است، و هر کدام ورودی‌هایی در فایل می‌شود.
بعضی اینباندها در این مسیر کنار گذاشته یا تغییر داده می‌شوند:
- اینباندی پشت یک اینگرس از راه پورت اینگرس و با نامی که route آن تطبیق می‌دهد در دسترس است، چون اپ کاربر اول با اینگرس حرف می‌زند. اینباندی که پورت خودش را هم نگه می‌دارد دو ورودی می‌گیرد: یکی مستقیم و یکی از راه اینگرس. اینباندی که از هیچ راهی در دسترس نیست کنار گذاشته می‌شود.
- فقط از راه فرانت، وقتی برای یک اینباند روشن باشد، ورودی‌های مستقیم آن را برای هر کاربری که فرانتی برایش رندر شده حذف می‌کند.
- ورودی‌ای که اپ نمی‌توانست استفاده کند به‌جای نوشته شدن به شکل خراب حذف می‌شود، چون یک ورودی بد باعث می‌شود بعضی اپ‌ها کل فایل را رد کنند.
اندپوینت‌ها (WireGuard، OpenVPN، OpenConnect) به شکل تونلی ظاهر می‌شوند که اپ به آن وصل می‌شود. کلیدهای WireGuard و آدرس کاربر درون تونل را پنل از روی شناسه‌ی کاربر می‌سازد، پس فایل و نود همیشه با هم می‌خوانند.
۲. آدرس‌ها و فرانت‌ها: جمع، هرگز ضرب
هر اینباند روی هر نود به ازای هر آدرس لینک آن نود یک ورودی می‌شود. سپس هر فرانت دامنه روی اینباند یک ورودی دیگر اضافه می‌کند، یک بار، هر چقدر هم نود باشد.
3 nodes × 2 link addresses = 6 direct entries
2 fronts on the inbound = 2 front entries
8 entriesدلیلش این است که هر کدام به چه کسی تعلق دارد. آدرس لینک راه دیگری برای رسیدن به یک ماشین است، پس به ازای هر نود تکرار می‌شود. فرانت نام CDN برای اینباند است، و CDN انتخاب می‌کند ترافیک را به کدام سرور مبدأ بفرستد، پس یک فرانت همه‌ی نودهایی را که اینباند را سرو می‌کنند پوشش می‌دهد.
- اولین آدرس لینک، آدرس اصلی است. ورودی‌های WireGuard، OpenVPN و OpenConnect، و فایل‌های دانلودی
.confو.ovpn، فقط از آن استفاده می‌کنند، چون فایل ذخیره‌شده نمی‌تواند گزینه‌های جایگزین داشته باشد. - آدرسی که پنل با آن به نود وصل می‌شود جداست از آدرس‌های لینک آن. پنل می‌تواند روی یک آدرس خصوصی به نود برسد در حالی که کاربرها روی یک آدرس عمومی به آن می‌رسند.
- فرانت جایگزین می‌کند آدرس، پورت، نام سرور، هدر Host، ALPN و fingerprint ورودی را، و پین گواهی و هر بازه‌ی پرش پورتی را حذف می‌کند: CDN گواهی خودش را ارائه می‌دهد و روی یک پورت گوش می‌دهد.
۳. گزینه‌های کلاینت برای هر اینباند
هر اینباند تنظیماتی برای نود و تنظیماتی برای اپ دارد. نوع دوم، زیر تنظیمات سمت کلاینت (لینک و اشتراک)، فقط هنگام ساختن لینک‌ها استفاده می‌شود و هیچ‌وقت برای نود فرستاده نمی‌شود. از جمله می‌تواند:
- آدرس یا پورتی غیر از آدرس و پورت نود اعلام کند، برای اینباندی که از راه چیزی جلوی آن در دسترس است؛
- نام سرور، ALPN، fingerprint یا دیگر گزینه‌های TLS کلاینت را تعیین کند؛
- گزینه‌هایی را تعیین کند که فقط کلاینت می‌خواند، مثل فاصله‌ی پرش پورت.
ورودی‌ای که آدرسش را تنظیمات کلاینت اینباند نام برده، روی آدرس‌های لینک دیگر نود کپی نمی‌شود: آن آدرس را عمداً نام برده‌اید.
۴. TLS کلاینت: سه لایه، ادغام فیلد به فیلد
آنچه درباره‌ی TLS به اپ گفته می‌شود از سه جا می‌آید. هر فیلد از دقیق‌ترین جایی برداشته می‌شود که آن را تعیین کرده است:
| اولویت | کجا تعیین می‌شود | کاربرد معمول |
|---|---|---|
| ۱ (برنده) | تنظیمات سمت کلاینت اینباند | نام سرور یا ALPN یک اینباند |
| ۲ | تنظیمات کلاینت گواهی نود | همان، برای هر اینباندی که از گواهی آن نود استفاده می‌کند |
| ۳ | تنظیمات کلاینت یک گواهی پنل | پیش‌فرض‌های مشترک برای گواهی‌ای که چند نود از آن استفاده می‌کنند |
زیر هر سه، مقدارهایی هستند که از خود گواهی به دست می‌آیند: نام سرور اولین نام DNS روی گواهی است (هرگز wildcard)، و گواهی خودامضا به‌عنوان گواهی‌ای که باید پین شود علامت می‌خورد. اینباندهای REALITY از لایه‌های گواهی به‌کلی رد می‌شوند: به‌جای آن کلید عمومی و short id خودشان را حمل می‌کنند.
۵. پین‌های گواهی
پین اثر انگشت گواهی‌ای است که کلاینت باید بپذیرد. پنل آن را هنگام صدور یا تمدید گواهی حساب می‌کند؛ شما هیچ‌وقت پینی تایپ نمی‌کنید.
- گواهی‌های خودامضا همیشه پین می‌شوند، تا اپ به‌جای پذیرفتن هر گواهی‌ای، دقیقاً همان گواهی را بررسی کند.
- گواهی بارگذاری‌شده فقط وقتی پین می‌شود که تنظیمات کلاینتش بررسی را خاموش کرده باشد.
- گواهی ACME هیچ‌وقت پین نمی‌شود: یک مرجع عمومی ضامن آن است، و با هر تمدید تغییر می‌کند.
هر فرمت پین را به شکلی حمل می‌کند که اپ‌هایش می‌خوانند، و به اپی که از پین پشتیبانی می‌کند به‌جای خاموش کردن بررسی، پین داده می‌شود. وقتی گواهی خودامضایی تمدید شود، پینش تغییر می‌کند و اپ‌ها در تازه‌سازی بعدی پین تازه را می‌گیرند. ببینید گواهی‌ها، صدور و تمدید.
۶. نام‌ها
هر ورودی نامی لازم دارد که اپ نشان دهد. وقتی قالب نام زیر نام لینک‌ها خالی باشد، ورودی‌ها نام‌های ثابت پنل را نگه می‌دارند. قالبی مثل {USER} · {ROUTE} · {REMAINING} برای هر ورودی با حساب، اینباند، نود، route (برچسب آدرس لینک یا فرانت)، آدرسی که به آن وصل می‌شود، مصرف و انقضا پر می‌شود. متغیری که خالی است جداکننده‌اش را هم با خودش می‌برد، متغیر ناشناخته همان‌طور که نوشته شده می‌ماند، و نامی که به هیچ چیزی نرسد به نام ثابت برمی‌گردد. اپ‌ها ورودی انتخاب‌شده‌ی کاربر را با نامش به یاد می‌سپارند، پس قالب چیزی است که یک بار انتخاب می‌کنید، نه چیزی که مدام عوضش کنید.
۷. فرمتی که هر اپ می‌خواند
یک آدرس اشتراک با چند فرمت جواب می‌دهد:
| فرمت | چه چیزی می‌خواند |
|---|---|
| لینک‌های اشتراک‌گذاری، base64 (پیش‌فرض) | بیشتر اپ‌ها: v2rayNG، v2rayN، Streisand، Happ، Shadowrocket |
| لینک‌های اشتراک‌گذاری ساده | هر چیزی که در هر خط یک لینک می‌خواند |
| Clash | اپ‌های Clash Meta و Stash |
| پروفایل sing-box | اپ‌های sing-box: SFA، SFI، Hiddify، Karing |
| پروفایل Xray JSON | اپ‌های مبتنی بر Xray که یک پروفایل کامل وارد می‌کنند |
| صفحه‌ی اشتراک | مرورگر |
فرمت به این ترتیب انتخاب می‌شود: فرمتی که در آدرس نام برده شده (یک مسیر فرمت یا ?format=) همیشه برنده است. در غیر این صورت مرورگر صفحه‌ی اشتراک را می‌گیرد، و اپ از روی نامش شناخته می‌شود و فرمت خودش را می‌گیرد. فرمت‌های ساختاریافته از یک سند پایه شروع می‌شوند که می‌توانید زیر پیش‌فرض‌های اشتراک جایگزینش کنید؛ ورودی‌های ساخته‌شده در آن ادغام می‌شوند، با یک گروه پیش‌فرض که همه‌ی ورودی‌ها را آزمایش می‌کند.
۸. چه چیزی همراه فایل می‌رود
پاسخ اشتراک هدرهایی هم دارد که اپ‌ها بدون اینکه کاربر چیزی باز کند نشانشان می‌دهند: عنوان پروفایل، نوار سهمیه و انقضا، فاصله‌ی تازه‌سازی، یک اطلاعیه، لینک پشتیبانی و لینکی به صفحه. متن به الفباهای دیگر همان‌طور کدگذاری می‌شود که این اپ‌ها انتظار دارند. جزئیات در اشتراک‌ها و صفحه‌ی اشتراک آمده است.
۹. پیش از تحویل فایل
- محدودیت دستگاه. اپی که دستگاهش را معرفی می‌کند، پیش از فرستادن هر چیزی در محدودیت دستگاه کاربر شمرده می‌شود. دستگاهی که از سقف بگذرد پاسخ رد می‌گیرد، در حالی که دستگاه‌هایی که از قبل شمرده شده‌اند به دریافت ادامه می‌دهند. اپ‌هایی که شناسه‌ی دستگاه نمی‌فرستند سرویس می‌گیرند، مگر تنظیم سخت‌گیرانه روشن باشد. این تنها جایی است که محدودیت دستگاه عمل می‌کند؛ نودها هیچ‌وقت دستگاه‌ها را نمی‌بینند. ببینید ترافیک، سهمیه‌ها و محدودیت‌ها.
- دریافت ثبت می‌شود. زمان، اپ و آدرس هنگام تحویل بدنه نوشته می‌شوند. اولین دریافت یک حساب یک رویداد ایجاد می‌کند. باز کردن صفحه در مرورگر جداگانه ثبت می‌شود، پس هیچ‌وقت نام اپی را که کاربر با آن وصل می‌شود بازنویسی نمی‌کند.
آدرس از کجا می‌آید
خود آدرس اشتراک روی اولین دامنه از دامنه‌های اشتراک شما ساخته می‌شود، یا یک نام میزبان برای هر مشترک زیر یک دامنه‌ی wildcard، یا آدرس عمومی پنل. هر دامنه‌ای در فهرست به سرو کردن لینک‌هایی که صادر کرده ادامه می‌دهد، پس دامنه‌ی مسدودشده با افزودن اول یک دامنه‌ی تازه جایگزین می‌شود. روی این نام‌ها پنل فقط در مسیر پایه‌اش جواب می‌دهد، پس آدرسی که مشتری‌هایتان دارند چیزی درباره‌ی جایی که پنل از آن مدیریت می‌شود نمی‌گوید. ببینید اشتراک‌ها و صفحه‌ی اشتراک و دامین فرانتینگ.