WPAD সমাধান হয়, কিন্তু ব্রাউজার 404 পায়

wpad নামটি প্রত্যাশিত মেশিনে সমাধান হয়। এটি আশাব্যঞ্জক, কিন্তু এটি কেবল শুরু। ব্রাউজারকে এখনও সেই মেশিন থেকে ফাইল চেয়ে PAC স্ক্রিপ্ট পেতে হবে।

ওয়েব সার্ভারের অ্যাক্সেস লগে একটি সহায়ক সূত্র পাওয়া যায়: ক্লায়েন্ট /wpad.dat চেয়ে HTTP 404 পেয়েছে। হাতে খোলা PAC URL ভিন্ন হোস্টনেম ব্যবহার করতে পারে। এমনকি দুই নাম একই সার্ভারে পৌঁছালেও তারা ভিন্ন ভার্চুয়াল হোস্ট বেছে নিতে পারে।

ক্লায়েন্ট যে অনুরোধ করেছে তা অনুসরণ করুন

আবিষ্কার যে সঠিক URL বেছেছে, HTTP Host মান, পাথ এবং প্রতিক্রিয়া যাচাই করুন। সাধারণ ব্রাউজার ট্যাবে সুবিধাজনক PAC URL খুললে প্রমাণ হয় না যে স্বয়ংক্রিয় আবিষ্কার সেই URL চেয়েছিল।

যদি সংক্ষিপ্ত ও সম্পূর্ণ যোগ্যতাসম্পন্ন উভয় নামই প্রত্যাশিত হয়, তবে লক্ষ্য ওয়েব হোস্টকে সেই নামগুলো ইচ্ছাকৃতভাবে সামলাতে কনফিগার করুন। নিশ্চিত করুন যে /wpad.dat সঠিক ফাইলে ম্যাপ হয়, ডিফল্ট ডকুমেন্ট রুট বা অসম্পর্কিত অ্যাপ্লিকেশনে নয়।

স্ক্রিপ্ট দিন, ত্রুটি পাতা নয়

প্রতিক্রিয়ার স্ট্যাটাসের পাশাপাশি তার বডিও যাচাই করুন। সাইন-ইন পাতা, ব্র্যান্ডেড ত্রুটি নথি বা রিডাইরেক্ট হাতে দেখলে বিশ্বাসযোগ্য মনে হতে পারে, কিন্তু সেটি রিজলভার যে PAC স্ক্রিপ্ট প্রত্যাশা করে তা নয়। Chromium কঠোর PAC ডাউনলোডের শর্ত নথিভুক্ত করে, যার মধ্যে HTTP 200 প্রতিক্রিয়াও আছে।

ডেলিভারি সফল হলে হওয়ার পরেই FindProxyForURL() ডিবাগ করা অর্থপূর্ণ। এর হোস্টনেম নিয়ম বদলে সেই 404 ঠিক করা যায় না যা ব্রাউজারকে এটি পেতে বাধা দিয়েছিল।

PAC ওয়েব সার্ভারকে তার স্ক্রিপ্টে উল্লিখিত ফরওয়ার্ড প্রক্সি থেকেও আলাদা করুন। তারা একটি মেশিন ভাগ করতে পারে, কিন্তু একটি সেবার অ্যাক্সেস লগের এন্ট্রি প্রমাণ নয় যে অন্য সেবাটি ব্যবহারকারীর গন্তব্য অনুরোধ সামলেছে।