“Resolving Host in Proxy Script”-এ আটকে আছেন? PAC ফাইলটি দেখুন

স্টেটাস বার্তাটি বলে “Resolving host in proxy script,” তবু প্রক্সি সার্ভার বদলালে খুব একটা পার্থক্য হয় না। এটি একটি কাজের সূত্র: ব্রাউজার হয়তো এখনও ঠিক করছে অনুরোধটি কোথায় পাঠাবে।

একটি PAC ফাইল DNS-নির্ভর পরীক্ষা চালাতে পারে। সেই পরীক্ষাগুলো যদি একটি অগম্য রিজলভারের জন্য অপেক্ষা করে বা বারবার অপ্রয়োজনীয় প্রশ্ন করে, তবে নির্বাচিত প্রক্সি কিছু পাওয়ার আগেই পৃষ্ঠা লোডিং থেমে যেতে পারে।

1. বিরতিটি কোথায় তা চিহ্নিত করুন

একটি ক্ষতিগ্রস্ত URL-এর জন্য নির্ধারণ করুন বিলম্বটি PAC ফাইল আনার সময়, তা মূল্যায়নের সময়, নাকি ফেরত দেওয়া প্রক্সিতে সংযোগ করার সময় ঘটে। একটি খালি প্রক্সি অ্যাক্সেস লগ প্রথম দুটি পর্যায়ের সঙ্গে সঙ্গতিপূর্ণ; এটি প্রমাণ করে না যে ব্রাউজার সরাসরি পথ ব্যবহার করেছে।

তারপর দেখুন কোন নিয়মগুলোর DNS দরকার। Microsoft-এর PAC কর্মক্ষমতা নির্দেশিকা অপ্রয়োজনীয় DNS-নির্ভর কাজ এড়ানোর পরামর্শ দেয়। হোস্টনাম সমতা পরীক্ষার সেই হোস্টনাম রিজলভ করে সাবনেট যাচাই করার মতো তথ্য লাগে না।

2. অপ্রয়োজনীয় DNS কাজ সরান

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

উপরে একটি শর্তহীন DIRECT রিটার্ন যোগ করে ধীর স্ক্রিপ্ট “ঠিক” করবেন না। এটি বিলম্বের সঙ্গে রাউটিং সিদ্ধান্তটিও সরিয়ে দেয়।

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