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 ফাইলের উপনাম প্রক্সির মাধ্যমে পাঠানো হোস্টনেম অনুরোধের সঙ্গে যায় না। অনুসন্ধানকারী মেশিনে ইনস্টল করা Squid সংস্করণের hosts_file সেটিং দেখুন এবং প্রযোজ্য হলে প্যারেন্ট প্রক্সির রেজলভারও বিবেচনা করুন। TLS পরিচয়ের জন্য ব্যবহৃত হোস্টনেম পরিষেবার সঙ্গে মিলিয়ে রাখুন।

একটি নিয়ন্ত্রিত কনফিগারেশন পরিবর্তনের পর সিনট্যাক্স পরীক্ষা করে নির্দিষ্ট ইনস্ট্যান্সের কনফিগারেশন পুনরায় লোড করুন, একই অনুরোধ আবার পাঠিয়ে তার প্রমাণ দেখুন। ক্যাশে থাকা ইতিবাচক ও নেতিবাচক উত্তর বারবার পরীক্ষায় প্রভাব ফেলতে পারে। সফল অনুসন্ধানের পর সংযোগের সময়সীমা পেরিয়ে যাওয়া পরবর্তী ধাপের রুট বা অনুমতির ব্যর্থতা; সেটি সারাতে DNS বদলাতে থাকবেন না। সার্ভারের পরিবর্তন মূল্যায়নের সময় ক্লায়েন্টের DNS, প্যারেন্ট রাউটিং ও প্রক্সি প্রোটোকল অপরিবর্তিত রাখুন।