client → local forward proxy → HTTP parent → website

সব DNS “প্রক্সির” বলে দাবি করার বদলে ব্যর্থ হওয়া নামটি দিয়ে শুরু করুন:

প্রয়োজনীয় নামযে হপকে এটিতে পৌঁছতে হবে
লোকাল প্রক্সি এন্ডপয়েন্টক্লায়েন্ট
HTTP প্যারেন্ট এন্ডপয়েন্টলোকাল ফরওয়ার্ড প্রক্সি
ওয়েবসাইট এন্ডপয়েন্টপ্যারেন্ট যখন চূড়ান্ত সংযোগ খোলে

এন্ডপয়েন্টগুলো হোস্টনেম হলে ওই হপগুলো ভিন্ন রিজলভার ব্যবহার করতে পারে। HTTPS-এর ক্ষেত্রে একটি ফরওয়ার্ড প্রক্সি CONNECT-এর গন্তব্য হোস্ট ও পোর্ট প্যারেন্টকে পাঠাতে পারে, এবং প্যারেন্টই চূড়ান্ত সংযোগ করে। মূল ক্লায়েন্টকে আগে ওয়েবসাইট রিজলভ করতে হয় না। সাধারণ HTTP ফরওয়ার্ডিংও গন্তব্যের তথ্য সামনে বহন করে।

এটি কোনো প্রতিশ্রুতি নয় যে প্রতিটি নামের জন্য ঠিক একটি মেশিন কোয়েরি করে। ACL মূল্যায়ন, ক্যাশিং, নীতি এবং বাস্তায়নের বিবরণ অতিরিক্ত লুকআপ ঘটাতে পারে।

প্যারেন্ট উপলব্ধ না থাকলে ফলব্যাক নীতি যাচাই করুন। সরাসরি অ্যাক্সেস অনুমোদিত হলে লোকাল প্রক্সিই ওয়েবসাইটমুখী হপ হতে পারে, নিজের রিজলভার ও সোর্স-ঠিকানা সিদ্ধান্ত নিয়ে। শুধু প্যারেন্ট কনফিগার করলেই প্রতিটি অনুরোধ তা ব্যবহার করেছে বলে প্রমাণ হয় না।

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

সম্পর্কিত নিবন্ধ