When Time-Based PAC Rules Choose a Proxy
A PAC time rule chooses a proxy when routing is evaluated. It does not promise to move an existing connection to a new exit at a precise second.
You can write a PAC rule that returns one proxy in the morning and another later. You cannot infer from that rule that every existing browser connection switches exits at noon.
Functions such as timeRange() participate in a routing decision. They are not a background scheduler that closes tunnels, migrates sockets, or asks a proxy provider to rotate its public IP.
Keep three events separate:
- The browser evaluates the PAC and obtains a route.
- The client establishes or reuses a connection using its networking rules.
- The selected service chooses the public address for its onward connection.
A time condition directly concerns the first event. An already active download or long-lived connection is another matter. Client caching and connection reuse also mean that “the script contains a clock check” is insufficient evidence of a precise switching schedule.
If a task needs a new exit per session, request, or time window, use an interface designed for that requirement and verify its documented behavior. A PAC can select among endpoints, but it does not define what those endpoints do with their own exit addresses.
Time-based routing can still be useful for an intentional network policy. Describe it as choosing a route at evaluation time, not as a guaranteed IP-rotation mechanism.