Файли PAC: коли запит використовує проксі або йде напряму

Читайте результат PAC як рішення про маршрут до конкретної цілі та враховуйте вплив резерву DIRECT на спостережувану вихідну адресу.

Сторінка перевірки IP може показувати пряму адресу, хоча файл PAC правильно спрямовує інший сайт через проксі. Перевірте, яка гілка керує самою сторінкою перевірки:

function FindProxyForURL(url, host) {
  if (host === "example.com") {
    return "PROXY 203.0.113.10:8080; DIRECT";
  }
  return "DIRECT";
}

Скрипт пропонує example.com HTTP-проксі, а потім DIRECT. Усі інші хости явно прямі, тому перевірка IP на іншому домені ніколи не тестує гілку проксі. Перед використанням замініть документаційну точку потрібним HTTP-проксі; список HTTP-проксі дає кандидатів, коли публічні проксі відповідають політиці.

Крапки з комою відділяють маршрути-кандидати. DIRECT дозволяє з’єднання без проксі; за його вибору ціль може бачити вихід прямого маршруту. Політика обов’язкового проксі не може спиратися на правило, що навмисно дозволяє цей резерв за недоступного проксі.

Браузер вирішує, як обробляти збої кандидатів, і може пам’ятати непрацездатні проксі. HTTP-помилка сайту не означає автоматично недоступний проксі. Тому перший кандидат скрипта сам собою не визначає використаний маршрут.

PROXY IP:port позначає звичайний HTTP-слухач. За підтримки він може переносити HTTPS через CONNECT; окрема точка не потрібна лише тому, що сайт HTTPS. Використовуйте тільки дані URL, які дає браузер: шлях HTTPS і частина запиту можуть бути видалені до оцінювання PAC.

Оцініть результат для потрібної цілі, потім зробіть новий запит під тим самим правилом. Перед вибором виправлення розрізніть помилковий збіг, недоступну точку й дозволений прямий резерв.

Схожі статті