WPAD حل می‌شود، اما مرورگر 404 می‌گیرد

نام wpad به ماشین مورد انتظار حل می‌شود. این دلگرم‌کننده است، اما فقط آغاز کار است. مرورگر هنوز باید فایلی از آن ماشین درخواست کند و اسکریپت PAC را دریافت کند.

سرنخ مفیدی را می‌توان در گزارش دسترسی سرور وب یافت: کلاینت /wpad.dat را درخواست کرد و HTTP 404 دریافت کرد. نشانی PAC که به‌صورت دستی باز شود ممکن است از نام میزبان دیگری استفاده کند. حتی وقتی هر دو نام به یک سرور برسند، ممکن است میزبان‌های مجازی متفاوتی را انتخاب کنند.

درخواستی را که کلاینت فرستاده دنبال کنید

نشانی دقیقی را که کشف انتخاب کرده، مقدار HTTP Host، مسیر و پاسخ را بررسی کنید. باز کردن یک نشانی PAC راحت در یک زبانه معمولی مرورگر ثابت نمی‌کند که کشف خودکار همان نشانی را درخواست کرده است.

اگر هم نام‌های کوتاه و هم نام‌های کامل انتظار می‌رود، میزبان وب مورد نظر را طوری پیکربندی کنید که آن نام‌ها را آگاهانه مدیریت کند. تأیید کنید که /wpad.dat به فایل درست نگاشت می‌شود، نه به ریشه پیش‌فرض اسناد یا برنامه‌ای نامرتبط.

یک اسکریپت سرو کنید، نه صفحه خطا

بدنه پاسخ را همراه با وضعیت آن بررسی کنید. صفحه ورود، سند خطای برندشده یا تغییرمسیر هنگام مشاهده دستی ممکن است معتبر به نظر برسد، اما اسکریپت PAC مورد انتظار حل‌کننده نیست. Chromium الزامات دانلود PAC سخت‌گیرانه را مستند می‌کند، از جمله پاسخ HTTP 200.

تنها پس از تحویل موفق شود است که اشکال‌زدایی FindProxyForURL() معنا دارد. تغییر قواعد نام میزبان آن نمی‌تواند 404ی را که مانع دریافت آن توسط مرورگر شده بود جبران کند.

همچنین سرور وب PAC را از پروکسی جلوی نام‌برده‌شده در اسکریپتش جدا کنید. ممکن است یک ماشین را شریک باشند، اما یک ورودی در گزارش دسترسی یک سرویس مدرکی نیست بر اینکه سرویس دیگر درخواست مقصد کاربر را مدیریت کرده است.