Файлы 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.

Оцените результат для нужной цели, затем сделайте новый запрос под тем же правилом. Перед выбором исправления различите ошибочное совпадение, недоступный узел и разрешённый прямой резерв.

Похожие статьи