وقتی Squid نمی‌تواند نام میزبان را حل کند

DNS را در جایی بررسی کنید که جست‌وجو شکست می‌خورد. اینکه لپ‌تاپ شما نامی را حل می‌کند ثابت نمی‌کند Squid، یا پراکسی بالادستی که اتصال بعدی را برقرار می‌کند، هم بتواند آن را حل کند.

گزارش کش نمونهٔ دچار خطا و تنظیمات حل‌کنندهٔ سرور را بررسی کنید. یک بررسی کمکی در سطح میزبان این است:

getent ahosts target.example

از مقصد واقعی استفاده کنید. getent سازوکار جست‌وجوی میزبان را به کار می‌گیرد؛ حل‌کنندهٔ داخلی یا کش Squid ممکن است متفاوت باشد. پیش از فرض یکسان بودن، ورودی‌های صریح dns_nameservers و hosts_file را بررسی کنید.

در Squid 6.13، فهرست صریح سرورهای نام شامل نشانی‌های IP است:

dns_nameservers 192.0.2.53

این نشانی مخصوص مستندات را با حل‌کننده‌ای تأییدشده که از سرور Squid قابل دسترسی باشد جایگزین کنید. نام‌های خصوصی ممکن است به حل‌کنندهٔ سازمان نیاز داشته باشند؛ یک حل‌کنندهٔ عمومی نامرتبط ممکن است آن‌ها را در نمای DNS خود نبیند.

نام مستعار فایل hosts لپ‌تاپ همراه درخواست نام میزبان از طریق پراکسی منتقل نمی‌شود. در ماشینی که جست‌وجو را انجام می‌دهد، تنظیم hosts_file نسخهٔ نصب‌شدهٔ Squid را مرور کنید و در صورت لزوم حل‌کنندهٔ پراکسی بالادستی را هم در نظر بگیرید. نام میزبان مورد استفاده برای هویت TLS باید با سرویس سازگار باشد.

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