আপনি PAC ফাইলটি সম্পাদনা করেছেন। ব্রাউজার কি এটি আবার এনেছে?
এর সার্ভারে একটি প্রক্সি স্ক্রিপ্ট সংরক্ষণ করা প্রমাণ করে না যে ব্রাউজার তার ক্যাশে করা কনফিগারেশন প্রতিস্থাপন করেছে। নতুন নিয়ম ডিবাগ করার আগে পুনরুদ্ধার যাচাই করুন।
আপনি PAC ফাইলটি প্রক্সি A থেকে প্রক্সি B-তে পরিবর্তন করে সংরক্ষণ করেন এবং একটি ওয়েবসাইট পুনরায় লোড করেন। ওয়েবসাইটটি এখনও প্রক্সি A দেখে। নিয়মটি আবার পরিবর্তন করার আগে ব্রাউজারটি নতুন স্ক্রিপ্টটি আদৌ পেয়েছে কি না তা যাচাই করুন।
পৃষ্ঠা পুনরায় লোড করা এবং PAC ডাউনলোড করা দুটি ভিন্ন কাজ। ক্লায়েন্ট যে পৃষ্ঠা দেখা হচ্ছে তা থেকে স্বাধীনভাবে একটি স্ক্রিপ্ট ধরে রাখতে পারে। ইতিমধ্যে প্রতিষ্ঠিত একটি সংযোগ আরেকটি কারণ যোগ করে যে পরবর্তী দৃশ্যমান কার্যক্রম একটি নতুন রাউটিং সিদ্ধান্ত দেখাতে নাও পারে।
PAC অনুরোধ খুঁজুন
কনফিগারেশন সার্ভারের অ্যাক্সেস লগ এবং ক্লায়েন্টের উপলব্ধ নেটওয়ার্ক ডায়াগনস্টিক্স ব্যবহার করুন। সঠিক PAC URL, প্রতিক্রিয়া এবং সরবরাহকৃত স্ক্রিপ্টের সংস্করণ চিহ্নিত করুন। একটি ডিরেক্টরিতে সম্পাদিত ফাইল সক্রিয় ওয়েব হোস্ট দ্বারা পরিবেশিত ভিন্ন একটি ফাইলের সাথে coexist করতে পারে।
Chromium তার নিজস্ব PAC ক্যাশিং এবং পুনরায় আনার আচরণ নথিভুক্ত করে। অন্যান্য ক্লায়েন্টের নিজস্ব নিয়ম রয়েছে। পুরনো “ব্রাউজার পুনরায় চালু করুন” উপকথাটিকে সর্বজনীন রিফ্রেশ ব্যবধানে রূপান্তর করা এড়িয়ে চলুন।
তুলনাটিকে অর্থবহ করুন
যদি একটি নিয়ন্ত্রিত নতুন ব্রাউজার সেশন উপযুক্ত হয়, সমর্থিত কনফিগারেশন পদ্ধতি ব্যবহার করুন এবং কেবল সেটিংস স্ক্রিনের উপর নির্ভর না করে পুনরুদ্ধার নিশ্চিত করুন। সচেতন থাকুন যে একটি উইন্ডো বন্ধ করা সর্বদা প্রতিটি ব্রাউজার প্রক্রিয়া বন্ধ করে না।
নতুন স্ক্রিপ্টটি লোড হয়েছে জানার পরে গন্তব্যের জন্য এর ফলাফল পরীক্ষা করুন। কেবল তারপরেই সংযোগ পুনঃব্যবহার বা প্রক্সি পরিষেবার প্রস্থান ঠিকানা তদন্ত করুন। সেই পরবর্তী ধাপগুলি ক্লায়েন্ট কখনও পায়নি এমন একটি PAC সম্পাদনা ব্যাখ্যা করতে পারে না।