Когда PAC-правила, основанные на времени, выбирают прокси
Правило времени в PAC выбирает прокси при оценке маршрутизации. Оно не обещает перенести существующее соединение на новый выход в точную секунду.
Вы можете написать правило PAC, которое утром возвращает один прокси, а позже другой. Но из этого правила нельзя заключить, что каждое существующее соединение браузера меняет выход в полдень.
Функции вроде timeRange() участвуют в решении о маршрутизации. Это не фоновый планировщик, который закрывает туннели, переносит сокеты или просит провайдера прокси сменить его публичный IP.
Держите три события раздельно:
- Браузер оценивает PAC и получает маршрут.
- Клиент устанавливает или повторно использует соединение по своим сетевым правилам.
- Выбранный сервис выбирает публичный адрес для своего дальнейшего соединения.
Условие времени напрямую касается первого события. Уже активная загрузка или длительное соединение — это другое. Кэширование на стороне клиента и повторное использование соединений также означают, что «в скрипте есть проверка часов» не является достаточным доказательством точного графика переключения.
Если задаче нужен новый выход на каждую сессию, запрос или временное окно, используйте интерфейс, предназначенный для этого требования, и проверьте его документированное поведение. PAC может выбирать среди конечных точек, но не определяет, что эти конечные точки делают со своими выходными адресами.
Маршрутизация на основе времени всё ещё может быть полезна для намеренной сетевой политики. Описывайте её как выбор маршрута в момент оценки, а не как гарантированный механизм смены IP.