시간 기반 PAC 규칙이 프록시를 선택할 때

아침에는 한 프록시를, 나중에는 다른 프록시를 반환하는 PAC 규칙을 작성할 수 있습니다. 그러나 그 규칙에서 모든 기존 브라우저 연결이 정오에 출구를 바꾼다고 추론할 수는 없습니다.

timeRange() 같은 함수는 라우팅 결정에 참여합니다. 터널을 닫거나 소켓을 이전하거나 프록시 제공업체에 공용 IP 회전을 요청하는 백그라운드 스케줄러가 아닙니다.

세 가지 사건을 구분하세요:

1. 브라우저가 PAC를 평가하고 경로를 얻습니다.
2. 클라이언트가 자체 네트워크 규칙에 따라 연결을 설정하거나 재사용합니다.
3. 선택된 서비스가 이후 연결에 사용할 공용 주소를 고릅니다.

시간 조건은 첫 번째 사건에 직접 관련됩니다. 이미 진행 중인 다운로드나 장기 연결은 다른 문제입니다. 클라이언트 캐싱과 연결 재사용은 '스크립트에 시계 확인이 있다'는 것이 정확한 전환 일정의 충분한 증거가 아님을 뜻하기도 합니다.

작업에 세션, 요청 또는 시간 창마다 새 출구가 필요하다면 그 요구에 맞게 설계된 인터페이스를 사용하고 문서화된 동작을 확인하세요. PAC는 엔드포인트 중에서 선택할 수 있지만, 그 엔드포인트가 자체 출구 주소로 무엇을 하는지는 정의하지 않습니다.

시간 기반 라우팅은 의도적인 네트워크 정책에 여전히 유용할 수 있습니다. 평가 시점에 경로를 선택하는 것으로 설명하고, 보장된 IP 회전 메커니즘으로 설명하지 마세요.