Wget به نشانی پروکسی نیاز دارد، نه URL یک فایل PAC

به GNU Wget برای مقصد دانلود یک نقطه پایانی ارسال واقعی بدهید:

https_proxy=http://proxy.example:8080 wget https://downloads.example/file.zip

URL نمونه اول را با پروکسی HTTP تأییدشده و دومی را با فایل موردنظر جایگزین کنید. https_proxy درخواست‌های مربوط به مقصدهای HTTPS را انتخاب می‌کند؛ مقدار آن نام شنونده را می‌آورد، نه یک اسکریپت PAC برای ارزیابی.

نشانی‌ای مانند https://config.example/proxy.pac به داده‌های انتخاب مسیر اشاره می‌کند. قرار دادن آن در متغیر پروکسی باعث نمی‌شود Wget جاوااسکریپت اجرا کند. ورودی‌های پروکسی GNU Wget و نسخه نصب‌شده را بررسی کنید؛ ابزار دیگری با نام مشابه ممکن است رفتار متفاوتی داشته باشد.

برای URLهای مربوطه نتیجه PAC را به دست آورید. کپی کردن یک نقطه پایانی فقط زمانی مناسب است که آن مسیر در سراسر عملیات معتبر باشد. تغییرمسیرها می‌توانند میزبان را عوض کنند و مقصدهای داخلی می‌توانند مستقیم باشند. یک سیاست پیچیده به یک آداپتور پشتیبانی‌شده یا ترتیبات مدیریتی نیاز دارد که آن تصمیم‌ها را حفظ کند.

نقطه پایانی تأییدشده یا یکپارچه‌سازی خط فرمان را درخواست کنید، نه اینکه برنامه PAC را در نمایه shell بچسبانید یا اسکریپت ناشناسی را به‌عنوان کد shell بدون محدودیت اجرا کنید.