چرا فایل PAC شما آداپتور شبکه اشتباه را انتخاب می‌کند
یک لپ‌تاپ می‌تواند چندین نشانی محلی داشته باشد. قاعده PAC مبتنی بر myIpAddress() ممکن است رابطی متفاوت از آنچه انتظار داشتید را تشخیص دهد.
لپ‌تاپ به Wi-Fi اداری متصل است، کابل اترنت وصل است و آداپتور VPN هنوز وجود دارد. فایل PAC شما از myIpAddress() می‌پرسد که روی کدام شبکه است. این معقول به نظر می‌رسد تا زمانی که نشانی‌ای متعلق به آداپتور اشتباه دریافت کند.
جزئیات گمشده این است که تابع فقط یک نشانی برمی‌گرداند. این تابع فهرستی از همه رابط‌ها نیست و برای کشف IP عمومی شما با هیچ وب‌سایتی تماس نمی‌گیرد. یک نشانی خصوصی، یا حتی یک loopback جایگزین، به شما نمی‌گوید درخواست عبوری از پروکسی از کدام نشانی خروجی استفاده خواهد کرد.
یک پاسخ برای دستگاهی با چند نشانی
انتخاب رابط شبکه به پیاده‌سازی PAC مربوط است. توصیه قدیمی مرتب‌کردن دوباره آداپتورهای Windows ممکن است نسخه خاصی از مرورگر و سیستم‌عامل را توصیف کند، اما اصلاحی عمومی و ضعیف است. Chromium الگوریتم انتخاب و محدودیت‌های چندشبکه‌ای خود را مستند کرده است؛ کلاینت دیگر لازم نیست همان انتخاب را انجام دهد.
با شناسایی مقداری که مرورگر آسیب‌دیده واقعاً ارائه کرده شروع کنید، سپس آن را با بررسی‌های زیرشبکه در اسکریپت خود مقایسه کنید. این کار را جداگانه روی Wi-Fi، اترنت و اتصال VPN تأییدشده انجام دهید. نشانی‌ای که عجیب به نظر می‌رسد هنوز هم می‌تواند قواعد پیاده‌سازی را برآورده کند.
تصمیم را به حدس کمتری وابسته کنید
در جایی که عملی است، پروکسی را بر اساس نام میزبان مقصد انتخاب کنید، نه بر اساس رابط فرضی کلاینت. اگر تشخیص شبکه لازم است، از یک نشانه عامدانه و مستندشده استفاده کنید که سازمان شما آن را کنترل می‌کند. تشخیص مبتنی بر DNS نیز حالت‌های شکست دارد، بنابراین تعریف کنید وقتی آن نشانه در دسترس نیست چه اتفاقی می‌افتد.
برخی پیاده‌سازی‌ها myIpAddressEx() را ارائه می‌دهند. پیش از پذیرش آن، پشتیبانی و قالب بازگشتی‌اش را بررسی کنید؛ این جایگزین مستقیم یک رشته IPv4 نیست. در نهایت، مسیر درخواست حاصل را به‌طور مستقل بررسی کنید. تشخیص درست زیرشبکه اداری و رسیدن به پروکسی مورد نظر دو نتیجه جداگانه هستند.