কেন Firefox এখনও আপনার বাইপাস সাবনেটের একটি ইন্ট্রানেট হোস্ট প্রক্সি করে
লিটারাল IP ঠিকানার জন্য একটি বাইপাস রেঞ্জ সেই রেঞ্জে রিজলভ হওয়া একটি হোস্টনামকে অপরিহার্যভাবে ছাড় দেয় না।
আপনি Firefox-এর “কোনও প্রক্সি নয়” তালিকা-এ 192.168.0.0/16 রেখেছেন। http://192.168.1.20/ খুললে সরাসরি যায়, কিন্তু http://wiki.office.example/ এখনও প্রক্সিতে পৌঁছায়। দুটি URL একই সার্ভারকে নির্দেশ করতে পারে।
গুরুত্বপূর্ণ পার্থক্য হল Firefox যে গন্তব্য স্ট্রিংয়ের সঙ্গে মিল করে। IP-রেঞ্জ ব্যতিক্রম ও হোস্টনাম ব্যতিক্রম পরস্পর বিনিময়যোগ্য নয়। ঠিকানা-রেঞ্জ নিয়ম প্রযোজ্য কিনা তা ঠিক করার আগে ধরে নেবেন না যে ম্যানুয়াল বাইপাস তালিকা প্রতিটি হোস্টনাম রিজলভ করে।
| প্রবেশ করানো URL | মিল করার জন্য উপলব্ধ তথ্য |
|---|---|
| http://192.168.1.20/ | একটি লিটারাল IP ঠিকানা |
| http://wiki.office.example/ | একটি হোস্টনাম |
ইন্ট্রানেটের নিজস্ব ডোমেইন থাকলে, নামগুলো যে ঠিকানায় রিজলভ হতে পারে তা অনুমান করার বদলে উপযুক্ত হোস্টনাম বা ডোমেইন ব্যতিক্রম ব্যবহার করুন। অসম্পর্কিত পাবলিক পরিষেবাগুলো ওই ব্যতিক্রমের বাইরে রাখুন। একটি ডোমেইনে অভ্যন্তরীণ ও বাইরে হোস্ট করা—দুই ধরনের অ্যাপ্লিকেশনই থাকতে পারে।
Mozilla-র মূল ব্যাখ্যা লিটারাল IP মিলানো ও সেই IP-তে রিজলভ হওয়া নামের মধ্যে স্পষ্ট পার্থক্য করে। ওই নথিটি ঐতিহাসিক, তাই এর প্রতিটি সিনট্যাক্স উদাহরণ কপি করার আগে বর্তমান ক্লায়েন্টের আচরণ ও নীতি ইন্টারফেস যাচাই করুন।
যখন নীতির DNS দরকার
একটি PAC ফাইল DNS-সচেতন সিদ্ধান্তের জন্য আলাদা, স্পষ্ট জায়গা দেয়। এটি স্ক্রিপ্ট বিতরণ, সম্পাদন ও রিজলিউশন ব্যর্থতার ধরনও নিয়ে আসে। দীর্ঘ বাইপাস তালিকাকে ছোট দেখানোর জন্য নয়, বরং রাউটিংয়ের প্রয়োজন সেই যুক্তি চাওয়ার কারণেই এটি ব্যবহার করুন।
পরিচালিত ইনস্টলেশনে Firefox-এর কার্যকর নীতি-ও পরীক্ষা করুন। লক করা প্রক্সি নীতি ব্যাখ্যা করতে পারে কেন স্থানীয় সম্পাদনা পথ নির্ধারণ করে না।
সমস্যা সমাধানের জন্য আপনি যে লিটারাল URL প্রবেশ করিয়েছেন তা লিপিবদ্ধ করুন, কেবল সার্ভারের চূড়ান্ত IP নয়। হোস্টনাম URL-এর সঙ্গে লিটারাল-ঠিকানা URL তুলনা করলে বাইপাস সিদ্ধান্তের জন্য উপলব্ধ তথ্য বদলে যায়, এবং সে কারণেই দুটি অনুরোধ ভিন্ন পথে যেতে পারে।