DNS بخشی از پیکربندی Clash است که بیشترین مشکلهای مرموز را میسازد. مسیریابی نادقیق، پخش آنلاینی که باز نمیشود، سرویسهای داخلی که از کار میافتند — هشت بار از ده بار ردش به همینجا میرسد.
اول، اصلاً چرا یک کلاینت پروکسی سراغ DNS میرود
در حالت عادی سیستم نامها را حل میکند و بعد برنامه به IP حاصل وصل میشود.
زیر پروکسی یک تعارض هست: قواعد بر پایهٔ دامنه نوشته شدهاند، ولی وقتی ترافیک به هسته میرسد ممکن است چیزی جز یک IP باقی نمانده باشد.
پس هسته باید خودش DNS را دست بگیرد. دو راه برای این کار هست.
redir-host: واقعی حل کن
هسته پرسوجو را میگیرد، نام را واقعاً حل میکند، IP واقعی را به برنامه برمیگرداند و درون خودش یادداشت میکند «این IP متعلق به آن دامنه است».
مزیت: IP واقعی برگردانده میشود، پس سازگاری در بهترین حالت است — سرویسهای داخلی و دستگاههای شبکهٔ محلی درست رفتار میکنند.
عیبها:
- هر جستوجو منتظر بالادست میماند که کند است
- اگر حل یک نام خارجی مسموم شده باشد IP غلط میگیرید
- پاسخ ممکن است نشانی یک CDN درونمنطقهای باشد که تصمیم قواعد را کج میکند
fake-ip: یک نشانی قلابی بده
هسته پرسوجو را میگیرد و اصلاً حلش نمیکند. یک نشانی ساختگی از بازهٔ رزروشدهای مثل 198.18.0.0/16 میدهد و ثبت میکند «این IP ساختگی = آن دامنه».
برنامه به نشانی ساختگی وصل میشود، هسته آن را میشناسد، دامنه را برعکس پیدا میکند، قواعد را بر پایهٔ دامنه تطبیق میدهد، و حل واقعی را به گرهٔ خروجی میسپارد.
مزیتها:
- پاسخ DNS عملاً آنی است (چیزی برای انتظار نیست)
- مسمومسازی از ریشه حذف میشود
- اطلاعات دامنه کامل حفظ میشود، پس تطبیق قواعد در بالاترین دقت است
- حل شدن روی گرهٔ خروجی، تشخیص منطقه توسط سرویسهای پخش را قابلاتکاتر میکند
عیبها:
- نشانی برگشتی ساختگی است، پس هر چیزی که به IP واقعی وابسته است میشکند
ping example.comعدد198.18.x.xنشان میدهد که عجیب به نظر میرسد (در عمل بیآزار)- نامهای داخلی باید در
fake-ip-filterبروند وگرنه حل نمیشوند
نتیجه: تقریباً همیشه fake-ip
یک پیکربندی DNS که کار میکند
dns:
enable: true
listen: 0.0.0.0:1053
ipv6: false
prefer-h3: false
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
fake-ip-filter:
- "*.lan"
- "*.local"
- "*.localdomain"
- "+.internal"
- "+.home.arpa"
- "+.pool.ntp.org"
- "time.*.com"
- "ntp.*.com"
- "+.market.xiaomi.com"
- "localhost.ptlogin2.qq.com"
- "+.msftconnecttest.com"
- "+.msftncsi.com"
# برای حل کردن نام خود سرورهای DoH/DoT پایین به کار میرود
default-nameserver:
- 223.5.5.5
- 119.29.29.29
# DNS اصلی: نامهای درونمنطقهای را حل میکند
nameserver:
- https://doh.pub/dns-query
- https://dns.alidns.com/dns-query
# DNS پشتیبان: نامهای خارجی را حل میکند
fallback:
- https://1.1.1.1/dns-query
- tls://8.8.4.4:853
# کِی پاسخ fallback را بگیریم
fallback-filter:
geoip: true
geoip-code: CN
ipcidr:
- 240.0.0.0/4
- 0.0.0.0/32
# نامهای مشخص را به حلکنندههای مشخص بفرست
nameserver-policy:
"geosite:cn": [223.5.5.5, 119.29.29.29]
"+.mycompany.com": "10.10.0.53"هرکدام از این چهار فیلد چه میکنند
fallback-filter چطور تصمیم میگیرد
همزمان از nameserver و fallback میپرسد، بعد:
- نشانی
nameserverدرون منطقه است ← همان را بگیر (پس این نام محلی است) - نشانی
nameserverبیرون منطقه است ← پاسخfallbackرا بگیر (نام خارجی، جایی که حلکنندهٔ محلی ممکن است مسموم باشد)
این چیدمان نامهای محلی را به حلکنندههای محلی میفرستد (سریع، و CDN نزدیک مینشیند) و نامهای خارجی را به حلکنندههای خارجی (دقیق و بدون مسمومسازی).
نشت DNS واقعاً چیست
«نشت DNS» یعنی: شما فکر میکنید ترافیکتان از پروکسی میرود، ولی حل نام هنوز به حلکنندهٔ اپراتور شما میرود. نتیجه این است که اپراتور میبیند به چه دامنههایی سر میزنید.
DoH توکار مرورگر رایجترین منبع نشت فراموششده است: کروم و فایرفاکس ممکن است بهطور پیشفرض DNS رمزنگاریشدهٔ خودشان را روشن کنند و هم سیستم را دور بزنند هم هسته را.
- Chrome/Edge: Settings ← Privacy and security ← Security ← گزینهٔ «Use secure DNS» را خاموش کنید
- Firefox: Settings ← Privacy & Security ← در پایینترین بخش «DNS over HTTPS» ← خاموش
جدول خرابیهای رایج
| نشانه | علت | راهحل |
|---|---|---|
| نامهای داخلی حل نمیشوند | fake-ip گرفتشان | به fake-ip-filter اضافه کنید |
ping example.com عدد 198.18.x.x میدهد | رفتار مورد انتظار | fake-ip همین کار را میکند؛ بیآزار |
| با نام به دستگاه شبکهٔ محلی (NAS) نمیرسید | نام .local / .lan از fake-ip گذشت | مقادیر "*.lan" و "*.local" را اضافه کنید |
| برنامهای بیپایان میچرخد | حلکنندهٔ خودش را دارد و رهگیری شده | زیر TUN گزینهٔ dns-hijack را بررسی کنید |
| سایتهای محلی کندتر شدند | حلکنندهٔ خارجی CDN را به جای دوری فرستاد | با nameserver-policy نامهای محلی را روی حلکنندهٔ محلی نگه دارید |
| پخش آنلاین منطقه را اشتباه تشخیص میدهد | حل بهصورت محلی انجام شد | از fake-ip استفاده کنید تا گرهٔ خروجی حل کند |
| همگامسازی ساعت شکست میخورد | نامهای NTP از fake-ip گذشتند | مقادیر "+.pool.ntp.org" و "time.*.com" را اضافه کنید |
| پیامرسانی وارد نمیشود | نام خاصی به IP واقعی نیاز دارد | مقدار "localhost.ptlogin2.qq.com" را اضافه کنید |
چه چیزی در fake-ip-filter جا دارد
اصلش: هر نامی که برای کار کردن به IP واقعی نیاز دارد باید داخلش برود.
بررسی اینکه پیکربندی اثر کرده
آیا fake-ip کار میکند؟
nslookup google.com 127.0.0.1برگشتن 198.18.x.x یعنی fake-ip در حال کار است.
آیا نامهای داخلی به حلکنندهٔ درست میروند؟
nslookup gitlab.mycompany.com 127.0.0.1باید IP واقعی داخلی برگردد نه 198.18.x.x. نشانی ساختگی یعنی fake-ip-filter اشتباه است.
جستوجوها چقدر طول میکشند؟
سطح لاگ را روی debug بگذارید تا مدت و سرور بهکاررفتهٔ هر پرسوجو را ببینید. تعداد زیاد پرسوجوهای بالای ۲۰۰ میلیثانیه یعنی حلکنندههای بالادستیتان بد انتخاب شدهاند.
خلاصه
- بهطور پیشفرض fake-ip را به کار ببرید؛ سریعتر و دقیقتر و مصون از مسمومسازی است
fake-ip-filterباید نگهداری شود: نامهای داخلی و NTP و بررسی اتصال همه اجباریاندnameserver-policyبالاترین اولویت را دارد — برای مسیریابی دقیق DNS از آن استفاده کنید- DoH خودِ مرورگر را خاموش کنید، وگرنه همهٔ بالاییها هدر میرود
default-nameserverفقط IP ساده میگیرد
بیشتر بخوانید: درون TUN و تونل تفکیکی در عمل.
مستندات مرتبط
حالت TUN از دید یک بسته چه میکند: ساختن کارت مجازی، بازنویسی جدول مسیریابی، ربودن پورت ۵۳، و انتخاب میان پشتههای gvisor و system و mixed.
چه چیزی ترافیک بازی را متفاوت میکند: چرا UDP به TUN نیاز دارد، نوع NAT واقعاً یعنی چه، چرا از دست رفتن بسته از تأخیر بدتر است، و فهرستی از تنظیمها با هدف تأخیر کم.
هر ستون چه معنایی دارد و چطور به کارش ببریم: یافتن برنامهای که ترافیک را میخورد، علت انفجار تعداد اتصال، گلوگاه گذردهی کجاست، و پایش پیوسته از راه API.