تونل‌های DNS

در شبکه‌هایی که فقط DNS از آن‌ها عبور می‌کند، از راه پرس‌وجوهای DNS به سرور خود برسید: نمایه‌های DNSTT، VayDNS، MasterDNS و Xray XDNS، ریزالورهای آن‌ها و پیدا کردن ریزالورهایی که کار می‌کنند.

از نسخهٔ 1.4.0، Throne می‌تواند ترافیک شما را درون پرس‌وجوهای DNS حمل کند. تونل DNS در شبکه‌هایی کار می‌کند که همه‌چیز جز DNS را مسدود می‌کنند. این تونل بسیار کندتر از یک نمایهٔ معمولی است و اولین اتصال مدتی طول می‌کشد. فقط وقتی از آن استفاده کنید که نمایه‌های دیگرتان وصل نمی‌شوند.

تونل DNS چگونه کار می‌کند

Throne به سرور تونل وصل نمی‌شود. پرس‌وجوهای DNS را برای نام‌هایی زیر دامنهٔ تونل، برای مثال t.example.com، به ریزالورها می‌فرستد: سرورهای DNS، مانند سرورهای شبکهٔ شما یا سرورهای عمومی مثل 8.8.8.8. این دامنه به سرور تونل واگذار (delegate) شده است، بنابراین ریزالورها پرس‌وجوها را به آن می‌رسانند. سرور داده‌هایش را در پاسخ‌های DNS برمی‌گرداند.

یعنی:

  • نمایهٔ تونل DNS نشانی و درگاه سرور ندارد. به دامنهٔ تونل، کلید سرور و ریزالورهایی نیاز دارد که پرس‌وجوها را منتقل کنند.
  • سرعت بیشتر به ریزالورها بستگی دارد. بسیاری از ریزالورها اندازه یا تعداد پرس‌وجوها را محدود می‌کنند یا پرس‌وجوهای غیرعادی را دور می‌اندازند. یافتن ریزالورهای کارآمد به شما کمک می‌کند ریزالورهای خوب را انتخاب کنید.
  • سرور به دامنه‌ای نیاز دارد که زیردامنه‌اش به آن واگذار شده باشد، و به برنامهٔ سروری که با نوع نمایه جور باشد.

Throne از سه نوع تونل DNS پشتیبانی می‌کند:

نوع نوع (Type) در نمایه جدید (New profile) سرور هسته
DNSTT و VayDNS DNSTT / VayDNS dnstt-server یا vaydns-server sing-box
MasterDNS MasterDNS MasterDnsVPN یا StormDNS sing-box
XDNS VLESS (Xray) با شبکهٔ kcp و ماسک xdns Xray با mKCP و xdns Xray

برای ساختن نمایه به‌صورت دستی، برنامه (Program) ← نمایه جدید (New profile) را باز کنید (Ctrl+N) و نوع را انتخاب کنید. همچنین می‌توانید لینک‌ها و پیکربندی‌ها را وارد کنید؛ وارد کردن و اشتراک‌گذاری را ببینید. تونل‌های DNS فقط در نسخهٔ دسکتاپ در دسترس‌اند؛ Android را ببینید.

DNSTT و VayDNS

نمایه‌های DNSTT / VayDNS با سرورهای dnstt و VayDNS کار می‌کنند. حالت (Mode) پروتکل را انتخاب می‌کند:

حالت سرور
DNSTT (پیش‌فرض) dnstt-server، یا vaydns-server -dnstt-compat
VayDNS vaydns-server
VayDNS (سازگار با dnstt) (VayDNS (dnstt-compatible)) همان سرورهای DNSTT. کلاینت مانند vaydns-client -dnstt-compat کار می‌کند و بیشینهٔ طول QNAME (Max QNAME Length) را دارد.

تنظیمات تونل:

فیلد پیش‌فرض کارکرد
دامنه (Domain) الزامی دامنهٔ تونل که به سرور واگذار شده است، برای مثال t.example.com.
کلید عمومی (Public Key) الزامی کلید عمومی سرور: 64 رقم شانزده‌شانزدهی (hex)، همان‌طور که سرور آن را چاپ می‌کند.
نوع رکورد (Record Type) پیش‌فرض (Default) (TXT) فقط VayDNS. نوع رکورد DNS که داده‌های سرور را حمل می‌کند: TXT، NULL، CNAME، A، AAAA، MX، NS، SRV یا CAA. نوعی را بگذارید که سرور به کار می‌برد. حالت‌های دیگر همیشه TXT به کار می‌برند.
اندازهٔ شناسهٔ کلاینت (Client ID Size) 2 فقط VayDNS. اندازهٔ شناسهٔ کلاینت بر حسب بایت. باید با -clientid-size سرور یکی باشد.
بیشینهٔ طول QNAME (Max QNAME Length) 101 (VayDNS)، 253 (VayDNS (سازگار با dnstt)) هر دو حالت VayDNS. بلندترین نام پرس‌وجو، حداکثر 253. نام‌های بلندتر دادهٔ بیشتری حمل می‌کنند، اما برخی ریزالورها آن‌ها را دور می‌اندازند.
بار مفید هر پرس‌وجو (Payload per Query) نشان می‌دهد هر پرس‌وجو چند بایت دادهٔ تونل حمل می‌کند. دامنهٔ بلندتر جای کمتری باقی می‌گذارد. تونل دست‌کم به 25 بایت نیاز دارد؛ اگر کمتر باشد، ویرایشگر خطا نشان می‌دهد. دامنهٔ کوتاه‌تر یا بیشینهٔ طول QNAME بزرگ‌تری به کار ببرید.

گروه ریزالورها (Resolvers) ریزالورها را نگه می‌دارد (ریزالورها را ببینید) و همچنین راهبرد (Strategy) را (ریزالورها چگونه انتخاب می‌شوند را ببینید). تلاش دوباره برای پاسخ‌های بریده‌شده روی TCP (Retry truncated replies over TCP) وقتی پاسخی بریده‌شده برمی‌گردد، همان پرس‌وجو را روی TCP دوباره از آن ریزالور UDP می‌پرسد.

گروه پیشرفته (Advanced) (فقط در حالت پیشرفته، حالت ساده و پیشرفته را ببینید):

فیلد پیش‌فرض کارکرد
مهلت بیکاری (Idle Timeout) 2m، و با VayDNS برابر 10s اگر این مدت چیزی نرسد، نشست بسته می‌شود. آن را با سرور هماهنگ نگه دارید.
فاصلهٔ keepalive (Keepalive Interval) 10s، و با VayDNS برابر 2s هر چند وقت یک بار کلاینت keepalive می‌فرستد. باید کوتاه‌تر از مهلت بیکاری باشد.
پرس‌وجو در ثانیه (Queries per Second) خالی، بدون محدودیت بیشترین تعداد پرس‌وجویی که تونل در هر ثانیه می‌فرستد.

بک‌اند

گروه بک‌اند (Backend) مشخص می‌کند که روی سرور چه چیزی پشت تونل اجرا می‌شود. نوع (Type) را همانی بگذارید که سرور به کار می‌برد:

نوع کارکرد
هیچ‌کدام (فقط زنجیره) (None (chain only)) (پیش‌فرض) سرور تونل را به یک سرور پروکسی دیگر می‌رساند. ویرایشگر هشدار می‌دهد که فقط نمایه‌ای که روی این نمایه زنجیر شده می‌تواند از تونل استفاده کند. یک زنجیره بسازید که نمایهٔ تونل DNS در بالا و نمایهٔ سرور پروکسیِ پشت تونل زیر آن باشد.
SOCKS5 یک پروکسی SOCKS5 پشت تونل. اگر لازم است نام کاربری (Username) و کلمه عبور (Password) را پر کنید. برای حمل UDP، UDP روی TCP (UDP over TCP) را تیک بزنید.
Shadowsocks یک سرور Shadowsocks پشت تونل: رمزگذاری (Encryption) و کلمه عبور (Password). برای حمل UDP، UDP روی TCP (UDP over TCP) را تیک بزنید.
SSH یک سرور SSH پشت تونل: کاربر (User)، و کلمه عبور (Password) یا کلید خصوصی (Private Key) (یا مسیر کلید خصوصی (Private Key Path) با انتخاب پرونده (Choose File))، و گذرواژه کلید خصوصی (Private Key Password). کلیدهای میزبان (Host Keys)، الگوریتم‌های کلید میزبان (Host Key Algorithms) و نسخهٔ کلاینت (Client Version) مانند نمایهٔ SSH کار می‌کنند.

MasterDNS

نمایه‌های MasterDNS با سرورهای MasterDnsVPN و StormDNS کار می‌کنند. آن‌ها فقط TCP حمل می‌کنند. تنظیمات باید با پیکربندی سرور یکی باشد:

فیلد پیش‌فرض کارکرد
دامنه‌ها (Domains) الزامی دامنه‌های تونل سرور (تنظیم DOMAIN آن)، هر خط یکی. همهٔ آن‌ها باید به همان سرور برسند. Throne پرس‌وجوها را میان همهٔ جفت‌های دامنه و ریزالور پخش می‌کند.
حالت (Mode) SOCKS5 باید با PROTOCOL_TYPE سرور یکی باشد. SOCKS5: سرور به‌جای شما به وب‌سایت وصل می‌شود. TCP / زنجیرهٔ سفارشی (TCP / custom chain): سرور هر اتصال را به مقصد ارسال خودش می‌فرستد، بنابراین نمایهٔ آن مقصد را زیر این نمایه زنجیر کنید، مانند هیچ‌کدام (فقط زنجیره) در بالا.
رمزگذاری (Encryption) xor باید با DATA_ENCRYPTION_METHOD سرور یکی باشد: none (0)، xor (1)، chacha20 (2)، aes-128-gcm (3)، aes-192-gcm (4) یا aes-256-gcm (5).
کلید (Key) الزامی، به‌جز با none کلید سرور، یعنی متن درون ENCRYPTION_KEY_FILE آن.

گروه انتقال داده (Transfer):

فیلد پیش‌فرض کارکرد
تکرار ارسال (Duplication) 3 Throne از هر بسته چند نسخه می‌فرستد، هر کدام از راه جفت دیگری از ریزالور و دامنه، حداکثر 10. سرور ممکن است آن را کم کند.
تکرار ارسال هنگام اتصال (Setup Duplication) 4 تعداد نسخه‌های بسته‌هایی که اتصال را باز می‌کنند، از مقدار تکرار ارسال تا 12.
فشرده‌سازی بارگذاری (Upload Compression)، فشرده‌سازی بارگیری (Download Compression) پیش‌فرض (خاموش) خاموش (Off)، zstd، lz4 یا zlib. سرور ممکن است آن را نپذیرد.
پاسخ‌های کدگذاری‌شده با Base64 (Base64-encoded replies) خاموش از سرور پاسخ‌های Base64 می‌خواهد، برای ریزالورهایی که رکوردهای TXT دودویی را خراب می‌کنند. پاسخ‌های Base64 یک‌چهارم دادهٔ کمتری حمل می‌کنند.

پیش از شروع نشست، Throne همهٔ جفت‌های دامنه و ریزالور را تست می‌کند تا بفهمد یک پرس‌وجو (بارگذاری) و یک پاسخ (بارگیری) چه مقدار داده می‌توانند حمل کنند. نشست از کمترین مقدارهای ریزالورهایی استفاده می‌کند که از تست گذشته‌اند. گروه MTU حدود این تست را تعیین می‌کند:

فیلد پیش‌فرض کارکرد
کمینهٔ بارگذاری (Min Upload)، کمینهٔ بارگیری (Min Download) 38، 200 ریزالورهایی که اندازه‌شان بر حسب بایت کمتر از این مقدارهاست کنار گذاشته می‌شوند.
بیشینهٔ بارگذاری (Max Upload)، بیشینهٔ بارگیری (Max Download) 150، 4000 بزرگ‌ترین اندازه‌هایی که Throne امتحان می‌کند، بر حسب بایت. سرور هم می‌تواند آن‌ها را محدود کند.

گروه پیشرفته (Advanced) (فقط در حالت پیشرفته) این گزینه‌ها را دارد: تلاش‌های دوبارهٔ تست MTU (MTU Test Retries) (پیش‌فرض 2 تلاش برای هر اندازه)، مهلت تست MTU (MTU Test Timeout) (پیش‌فرض 2s برای هر تلاش)، هم‌زمانی تست MTU (MTU Test Parallelism) (پیش‌فرض 32 ریزالور هم‌زمان) و کنار گذاشتن ریزالورهای با MTU کمتر از کمینه (Drop resolvers below the minimum MTU) (به‌طور پیش‌فرض روشن). وقتی این گزینه روشن است و دست‌کم 5 ریزالور از تست می‌گذرند، Throne آن چند ریزالوری را کنار می‌گذارد که اندازه‌های پایینشان کل نشست را کند می‌کند.

نشست با اولین اتصال و پس از این تست‌ها شروع می‌شود. اگر هیچ ریزالوری از تست نگذرد، Throne تست‌ها را هر 5 ثانیه تکرار می‌کند. ریزالورهایی که رد می‌شوند در پس‌زمینه دوباره تست می‌شوند.

XDNS

از نسخهٔ 1.4.0، نمایه‌های VLESS (Xray) می‌توانند ترابرد mKCP را به کار ببرند که اتصال را روی UDP حمل می‌کند. XDNS همان mKCP با یک ماسک xdns در Finalmask است: Xray بسته‌های mKCP را به‌صورت پرس‌وجوهای DNS از راه ریزالورها می‌فرستد. روی سرور باید Xray با یک ورودی mKCP و یک ماسک xdns برای همان دامنه اجرا شود.

ساده‌ترین راه برای داشتن نمایهٔ XDNS، وارد کردن آن است: یک لینک vless:// با type=kcp و finalmask در fm، پیکربندی JSON سرور در Xray، یا یک لینک Throne. لینک‌های vless:// با type=kcp همیشه نمایهٔ VLESS (Xray) می‌شوند، هر چه انتخاب هسته برای لینک‌های VLESS باشد.

برای راه‌اندازی دستی XDNS:

  1. برنامه (Program) ← نمایه جدید (New profile) را باز کنید، نوع (Type) را VLESS (Xray) بگذارید و تنظیمات VLESS را که سرور به شما می‌دهد وارد کنید.

  2. شبکه (Network) را kcp بگذارید. فیلدهای mKCP ظاهر می‌شوند.

  3. روی دکمهٔ Finalmask کلیک کنید و یک ماسک xdns با دامنهٔ تونل و، در صورت تمایل، ریزالورها به فهرست udp اضافه کنید:

    {
      "udp": [
        {
          "type": "xdns",
          "settings": {
            "domains": [{ "names": ["t.example.com"] }],
            "resolvers": [{ "addrs": ["udp://8.8.8.8:53"] }]
          }
        }
      ]
    }
    
  4. ردیف ریزالورها (Resolvers) زیر MTU و TTI ظاهر می‌شود. ریزالورهایی که آنجا وارد می‌کنید جای ریزالورهای ماسک را می‌گیرند؛ ریزالورها را ببینید.

  5. روی تایید (OK) کلیک کنید.

ویرایشگر ماسک را بررسی می‌کند. ماسک xdns باید آخرین ماسک در udp باشد و دست‌کم یک دامنه داشته باشد. اگر نه در ماسک و نه در ردیف ریزالورها ریزالوری نباشد، ویرایشگر هشدار می‌دهد که Xray نمی‌تواند وصل شود. یک ریزالور DNS-over-HTTPS (https://…) در ماسک به tlsConfig با serverName نیاز دارد، برای مثال "tlsConfig": {"serverName": "dns.google"}.

فیلدهای mKCP. برای استفاده از مقدار پیش‌فرض Xray، فیلد را خالی بگذارید:

فیلد پیش‌فرض کارکرد
MTU 1350 بزرگ‌ترین بسته‌ای که mKCP می‌فرستد، بر حسب بایت، از 21 تا 8192.
TTI 50 هر چند وقت یک بار mKCP ارسال می‌کند، بر حسب میلی‌ثانیه، از 10 تا 1000.
ظرفیت ارسال (Uplink Capacity) 5 بیشترین دادهٔ ارسالی در هر ثانیه، بر حسب MB/s.
ظرفیت دریافت (Downlink Capacity) 20 بیشترین دادهٔ دریافتی در هر ثانیه، بر حسب MB/s.
ضریب CWND (CWND Multiplier) 1 تعداد بسته‌هایی را که هم‌زمان می‌توانند در راه باشند چند برابر می‌کند.
بیشینهٔ پنجرهٔ ارسال (Max Sending Window) 2097152 بیشترین داده‌ای که منتظر ارسال یا تأیید دریافت می‌ماند، بر حسب بایت. دست‌کم به اندازهٔ MTU.

چهار فیلد آخر در گروه تنظیم دقیق (Tuning) هستند (فقط در حالت پیشرفته). در حالت ساده، دکمهٔ Finalmask فقط برای kcp نشان داده می‌شود.

نکته‌های دیگر:

  • وقتی چندگانه‌سازی (Multiplex) روی نگه داری مقدار پیشفرض (Keep Default) است، Throne برای نمایه‌های XDNS، mux را روشن می‌کند، حتی اگر Default Mux On خاموش باشد. بدون mux، هر اتصال یک نشست mKCP جدا با سوکت‌های خودش به همهٔ ریزالورها می‌شد.
  • لینک‌ها و پیکربندی‌های قدیمی‌تر mKCP یک نوع سرآیند (headerType) یا seed تعیین می‌کنند. نسخه‌های جدیدتر Xray این تنظیمات را حذف کرده‌اند، بنابراین Throne هنگام وارد کردن، آن‌ها را به ماسک‌های mkcp-legacy در Finalmask تبدیل می‌کند. قالب‌های قدیمی‌تر ماسک xdns را هم به‌روز می‌کند.
  • وقتی Show Config Security روشن است، ستون نوع (Type) برای این نمایه‌ها XDNS را نشان می‌دهد.

mKCP بدون ماسک xdns هم کار می‌کند، به‌عنوان یک ترابرد UDP ساده تا یک سرور Xray.

ریزالورها

هر نمایهٔ تونل DNS تنظیمات ریزالور دارد: گروه ریزالورها (Resolvers) برای DNSTT و MasterDNS، و ردیف ریزالورها برای XDNS. این تنظیمات سه بخش دارند:

  • یک کادر متنی، در هر خط یک ریزالور. خط‌هایی که با # شروع می‌شوند توضیح‌اند.
  • فهرست IP (IP list): یک فهرست IP از IP Scanner، برای مثال نتایج یک اسکن ریزالور. نشانی‌های آن پس از خط‌های کادر متنی به کار می‌روند. برای مدخلی که درگاه ندارد، درگاه 53 به کار می‌رود.
  • یافتن ریزالور… (Find resolvers…)؛ یافتن ریزالورهای کارآمد را ببینید.

آنچه یک خط می‌تواند داشته باشد:

خط DNSTT / VayDNS MasterDNS XDNS
system: سرورهای DNS سیستم شما بله بله خیر
یک نشانی IP، در صورت نیاز با درگاه: 8.8.8.8، 1.1.1.1:53، [2001:db8::1]:53 بله بله بله
یک بازه: 192.0.2.0/24 تا 256 نشانی (/24 یا بلندتر، /120 برای IPv6) تا 65536 نشانی (/16 یا بلندتر، /112 برای IPv6) فقط از یک فهرست IP، تا 256 نشانی
udp:// یا tcp:// و یک نشانی بله خیر بله
tls:// (DNS over TLS) بله خیر خیر
https:// (DNS over HTTPS)، در صورت نیاز با مسیر بله خیر بله

درگاه پیش‌فرض 53 است، و برای DNSTT، 853 برای tls:// و 443 برای https://. ریزالورهای tls:// و https:// در DNSTT از Default Fingerprint در uTLS استفاده می‌کنند؛ اثر انگشت uTLS را ببینید. Throne هر ریزالور را یک بار به کار می‌برد، و حداکثر 4096 ریزالور برای DNSTT و 256 ریزالور برای XDNS.

وقتی نه کادر متنی و نه فهرست IP ریزالوری اضافه نمی‌کنند:

  • DNSTT و MasterDNS از system استفاده می‌کنند. Throne هنگام تغییر شبکه سرورهای DNS سیستم را دوباره می‌خواند و از سرورهایی که درون بازهٔ نشانی آداپتور TUN هستند می‌گذرد.
  • XDNS ریزالورهای ماسک xdns را نگه می‌دارد. به محض اینکه ریزالوری وارد کنید، جای ریزالورهای ماسک را می‌گیرد.

Throne هر بار که نمایه شروع می‌شود فهرست IP را می‌خواند، بنابراین شروع بعدی از تازه‌ترین مدخل‌ها استفاده می‌کند. اگر فهرست IP حذف شده باشد، نمایه هیچ ریزالوری از آن نمی‌گیرد: ویرایشگر «این فهرست IP دیگر وجود ندارد، بنابراین ریزالوری اضافه نمی‌کند.» (This IP list no longer exists, so it adds no resolvers.) را نشان می‌دهد و هنگام شروع نمایه، گزارش هم همین را می‌گوید.

ریزالورها چگونه انتخاب می‌شوند

DNSTT و VayDNS: راهبرد (Strategy) در گروه ریزالورها.

راهبرد پرس‌وجوها به کجا می‌روند
پیش‌فرض (Default)، round_robin به نوبت به هر ریزالور.
failover به اولین ریزالوری که کار می‌کند.
fanout هم‌زمان به همهٔ ریزالورهایی که کار می‌کنند.

ریزالوری که 8 پرس‌وجو را در 2 ثانیه بی‌پاسخ بگذارد، 1 ثانیه کنار گذاشته می‌شود. هر بار که این اتفاق دوباره بیفتد، این مکث دو برابر می‌شود، تا 30 ثانیه. پس از یک شکست، نشست دوباره شروع می‌شود، با مکث‌هایی از 1 تا 30 ثانیه میان تلاش‌ها.

MasterDNS: راهبرد (Strategy) در گروه ریزالورها.

راهبرد پرس‌وجوها به کجا می‌روند
پیش‌فرض (Default)، least_loss به ریزالوری که کمترین اتلاف را دارد.
round_robin به نوبت به هر ریزالور.
random به یک ریزالور تصادفی.
lowest_latency به ریزالوری که کمترین تأخیر را دارد.
hybrid به ریزالوری که بهترین امتیاز اتلاف و تأخیر را دارد.
loss_then_latency به کم‌تأخیرترین ریزالور در میان ریزالورهایی که کمترین اتلاف را دارند.
least_loss_top_random به یک ریزالور تصادفی از میان 10٪ برتر از نظر اتلاف.
least_loss_top_round_robin به نوبت به هر ریزالور از میان 10٪ برتر از نظر اتلاف.

اتصالی که بسته‌هایش مدام دوباره فرستاده می‌شوند به ریزالور دیگری می‌رود، حداکثر هر 2.5 ثانیه یک بار. ریزالورهایی که مدام به مهلت می‌خورند کنار گذاشته می‌شوند تا دوباره از تست بگذرند.

XDNS: Xray پرس‌وجوها را به نوبت میان همهٔ ریزالورها پخش می‌کند.

یافتن ریزالورهای کارآمد

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

  1. نمایه را ذخیره کنید. تا وقتی این کار را نکنید، یافتن ریزالور… (Find resolvers…) غیرفعال می‌ماند، چون اسکن نمایهٔ ذخیره‌شده را تست می‌کند.
  2. نمایه را دوباره باز کنید و روی یافتن ریزالور… کنار فهرست IP (IP list) کلیک کنید. Throne اسکن ریزالور DNS این نمایه را در IP Scanner باز می‌کند، یا اسکنی با نام «ریزالورهای» و نام نمایه (Resolvers for) می‌سازد.
  3. در زبانهٔ Targets، نشانی‌هایی را که باید امتحان شوند در Base IP list انتخاب کنید، برای مثال فهرست پیش‌فرض Iran DNS resolvers یا Russia DNS resolvers، سپس اسکن را آغاز کنید. اسکن هر نشانی را به‌عنوان تنها ریزالور نمایه امتحان می‌کند.
  4. در زبانهٔ Results، روی استفاده به‌عنوان ریزالور (Use as resolvers) کلیک کنید. فهرست نتایج اسکن، فهرست IP نمایه می‌شود. خط‌هایی که خودتان نوشته‌اید می‌مانند و اول به کار می‌روند.

اگر ویرایشگر نمایه باز باشد، فهرست به‌جای آن در ویرایشگر قرار می‌گیرد. برای ذخیرهٔ آن، همان‌جا روی تایید (OK) کلیک کنید.

برای تست‌ها و ستون‌های نتایج، اسکن ریزالورهای DNS را ببینید.

وارد کردن و اشتراک‌گذاری

Throne این قالب‌ها را از کلیپ‌بورد، پرونده‌ها، کدهای QR و اشتراک‌ها وارد می‌کند:

قالب نتیجه
لینک‌های dnst:// یک نمایهٔ DNSTT / VayDNS، یا وقتی نوع تونل در لینک masterdns باشد، یک نمایهٔ MasterDNS.
لینک‌های slipnet:// از نسخه‌های 16 تا 28 در SlipNet یک نمایهٔ DNSTT / VayDNS. نمایه‌های NoizDNS به DNSTT ساده تبدیل می‌شوند که سرورشان آن را می‌پذیرد، اما بدون روش دور زدن DPI در NoizDNS.
لینک‌های masterdns:// و stormdns:// یک نمایهٔ MasterDNS. Throne شکل v1/… همراه با پیکربندی کلاینت، شکل v1?domains=… و قالب نمایه‌های WhiteDNS و Hidden-Node را می‌خواند.
JSON در sing-box با خروجی‌های dnstt یا masterdns نمایه‌های DNSTT / VayDNS و MasterDNS.
لینک‌های vless:// با type=kcp، و JSON در Xray با شبکهٔ kcp نمایه‌های VLESS (Xray). اگر ماسک xdns در finalmask باشد، نمایهٔ XDNS هستند.
لینک‌های Throne (throne://add/…) هر کدام از این‌ها، با همهٔ تنظیمات.

نکته‌های وارد کردن:

  • یک لینک dnst:// سرویس پشت تونل را نام می‌برد: socks، ssh، shadowsocks، یا custom برای هیچ‌کدام (فقط زنجیره). MasterDNS فقط socks (SOCKS5) و custom (TCP / زنجیرهٔ سفارشی) را می‌پذیرد.
  • لینک‌های رمزشدهٔ SlipNet (slipnet-enc://، slipnet-bundle-enc://) خوانده نمی‌شوند. نمایه را بدون رمزگذاری از SlipNet استخراج کنید.
  • اگر لینک یک پروکسی هم برای اجرا روی تونل داشته باشد، Throne دربارهٔ آن هشدار می‌دهد. آن پروکسی را جداگانه وارد کنید و زیر نمایهٔ تونل DNS زنجیر کنید.
  • فهرست IP که یک لینک Throne نام می‌برد متعلق به نصب دیگری است، بنابراین Throne آن را برنمی‌دارد.

برای اشتراک‌گذاری یک نمایه، در منوی راست‌کلیک آن اشتراک گذاری (Share) را انتخاب کنید. نمایه‌های DNSTT و MasterDNS یک لینک dnst:// و نمایه‌های XDNS یک لینک vless:// می‌دهند. این لینک‌ها ریزالورها و فهرست IP شما را ندارند، و برای MasterDNS فقط دامنهٔ اول را دارند. لینک Throne همهٔ تنظیمات را به‌جز فهرست IP نگه می‌دارد. لینک‌های اشتراک‌گذاری را ببینید.

تست

تست‌های URL و تست‌های IP با نمایه‌های تونل DNS کار می‌کنند. تونل نشستش را در اولین درخواست باز می‌کند و این کار به پرس‌وجوهای کند زیادی نیاز دارد. بنابراین Throne به اولین درخواست، برای نمایه‌های DNSTT و XDNS، 30 ثانیه و برای نمایه‌های MasterDNS، 90 ثانیه زمان بیشتر می‌دهد. زنجیره‌ای با چند تونل مجموع آن‌ها را می‌گیرد. تأخیری که نشان داده می‌شود از درخواست دوم، روی نشست باز، به دست می‌آید. تست URL را ببینید.

اگر تست ناموفق بود:

  • علت را در زبانهٔ گزارش‌ها (Logs) ببینید.
  • دامنه و کلید عمومی (DNSTT) یا دامنه‌ها، رمزگذاری و کلید (MasterDNS) را با سرور مقایسه کنید.
  • ریزالورهای دیگری امتحان کنید، یا یک اسکن ریزالور اجرا کنید.

Android

Throne برای Android نوع نمایهٔ DNSTT / VayDNS یا MasterDNS ندارد، و نمایه‌های VLESS (Xray) آن شبکهٔ kcp ندارند. تونل‌های DNS و لینک‌هایشان فقط در نسخهٔ دسکتاپ کار می‌کنند.