Proxy PAC Failover Test: Verify Routing, Standby Order and DIRECT Safety

A Proxy Auto-Configuration file is executable routing policy. Its FindProxyForURL(url, host) function can send a request through a primary proxy, try a standby, or allow a direct connection. A syntax check cannot prove that the intended route is chosen, that failover preserves policy, or that a browser interprets the result as expected.

This guide describes a controlled acceptance test for PAC files used with authorized networks and proxy services. It focuses on observable route decisions, failure boundaries and safe rollout. It does not recommend WPAD on untrusted networks or silent direct fallback for traffic that must use a proxy.

Treat the PAC file as a decision table

Start by translating every branch into a row. Do not rely on comments or the apparent order of conditions.

Include HTTP and HTTPS inputs. For HTTPS, modern browsers may give the PAC function only the scheme and host rather than the full path and query. Therefore, routing decisions that depend on a secret, tenant ID or URL path are unreliable and risk exposing sensitive values in policy logic.

Build an offline evaluator first

Run the PAC function in a constrained test harness with a fixed clock and stubbed helper functions. Each case should record:

case_id
input_scheme
input_host_class
resolver_fixture
expected_directive
actual_directive
evaluation_ms
exception_class
policy_version

Test exact output, including order. PROXY primary.example:8080; PROXY standby.example:8080 is not equivalent to the reverse order. Reject unexpected DIRECT, unsupported schemes, empty strings and exceptions.

Do not place proxy credentials in a PAC file. The file may be downloaded, cached and inspected by users or processes. Authentication belongs in the client or an approved secret-delivery mechanism.

Create controlled route beacons

Use destination fixtures you own or have permission to test. Each response should reveal only safe evidence:

• a unique destination marker;
• the observed proxy route alias, not credentials;
• the observed region and address family;
• a response digest and semantic completion marker;
• timestamps sufficient to calculate connection and failover delay.

Run at low concurrency. Keep target content identical across primary, standby and direct paths so that a route change is not confused with an application change.

Verify normal routing before failover

For every decision-table row, load the controlled destination and confirm the actual network path. A correct page is insufficient evidence if it might have arrived directly.

Record PAC retrieval, PAC evaluation, DNS lookup, proxy connection, CONNECT, TLS, first byte and complete-response timing separately. Confirm that bypass rules do not match sibling domains, deceptive suffixes or user-info text.

For SOCKS workflows outside PAC, use the SOCKS5 remote DNS guide. Do not assume that PAC DNS helper behavior is the same as socks5h remote resolution.

Test ordered failover deliberately

Create four controlled conditions:

1. primary healthy and standby healthy;
2. primary refuses the TCP connection;
3. primary accepts TCP but stalls before a useful proxy response;
4. primary authenticates but the destination fixture fails.

Only the first two or three should normally trigger proxy-route failover, depending on client behavior and policy. A destination failure after a working proxy route should not automatically burn through every proxy in the list.

Measure how long the client waits before trying the standby. Excessive connection timeouts can turn a correct PAC order into an unacceptable user experience. Apply the proxy timeout budget guide so DNS, connect, TLS and application phases have explicit budgets.

Make DIRECT fallback an explicit security decision

A return value such as:

PROXY primary.example:8080; PROXY standby.example:8080; DIRECT

means that traffic may leave without the proxy if earlier routes fail. That can violate location, audit, access-control or data-handling requirements. Do not add DIRECT merely to improve apparent availability.

Maintain two policy classes:

• fail closed: regulated, authenticated or location-sensitive workloads never use DIRECT;
• fail open: only specifically approved low-risk destinations may use DIRECT, with monitoring and an expiration date for the exception.

The direct path must have its own test beacon. Alert whenever it is selected unexpectedly.

Test DNS-dependent helpers

Functions such as isResolvable() and isInNet() may cause DNS work during PAC evaluation. Test positive, negative, slow and split-horizon answers. Record whether evaluation blocks, whether answers are cached and which resolver view the client uses.

Avoid putting expensive DNS checks near the top of a rule set when cheaper hostname matches can decide the route. A correct PAC file that adds seconds to every navigation is operationally broken.

IPv6 requires explicit cases. Validate IPv6-only hosts, dual-stack hosts, literals where supported and address-family changes after network handoff. Pair the results with the curl Happy Eyeballs proxy test.

Validate caching and updates

PAC files and auto-discovery results can be cached. Publish each test build with an internal policy version and record the version actually executed by every client. Then test:

• fresh profile versus warm profile;
• browser restart and operating-system restart;
• unchanged URL with changed content;
• changed PAC URL;
• temporary PAC server failure;
• rollback to the previous known-good policy.

Never assume a successful upload means every client has adopted the new rules. A mixed fleet can route identical requests differently for hours.

Compare real clients

Run the same matrix in every supported browser and in non-browser runtimes that claim to consume system proxy settings. Browser PAC, WinHTTP, command-line tools and automation frameworks do not necessarily share discovery, caching or failover behavior. Microsoft documents, for example, that WinHTTP applications may need to implement iteration through multiple returned proxies themselves.

Record client name, exact build, operating system, management policy, PAC source and result. Do not infer one client's behavior from another.

For browser automation, run a visible canary before scaling workers. Use the browser proxy concurrency plan to prevent a faulty PAC update from creating a synchronized connection surge.

Failure taxonomy

Use stable labels:

• PAC_FETCH: configuration could not be retrieved;
• PAC_PARSE: syntax or runtime exception;
• PAC_DECISION: output differs from the decision table;
• DNS_HELPER: resolver-dependent rule failed or stalled;
• PRIMARY_CONNECT: selected primary was unreachable;
• STANDBY_NOT_TRIED: client did not advance as expected;
• DIRECT_UNEXPECTED: traffic bypassed the proxy without approval;
• CACHE_STALE: old policy remained active;
• CLIENT_VARIANCE: supported clients chose different routes;
• DESTINATION: route worked but the owned endpoint failed.

Quarantine a policy version, not an entire proxy pool, when the evidence points to evaluation or caching. Use the proxy pool quarantine and recovery guide only for repeated route-specific faults.

Acceptance gates

A PAC rollout is ready when:

• every decision-table case returns the expected ordered directive;
• no secret or credential appears in the file or logs;
• primary, standby and approved direct paths are independently observable;
• failover completes within the workload's time budget;
• destination errors do not cause uncontrolled route cycling;
• DIRECT is absent from fail-closed classes;
• DNS helpers meet latency and correctness limits;
• policy update and rollback work with warm caches;
• all supported clients pass the same business rules;
• canary monitoring can identify the executed policy version.

Checklist

• [ ] Every branch has a positive, negative and boundary case.
• [ ] Directive order is asserted exactly.
• [ ] Primary and standby failures are controlled independently.
• [ ] Direct fallback has explicit approval and monitoring.
• [ ] HTTPS rules do not depend on paths or query strings.
• [ ] PAC code and logs contain no credentials or tokens.
• [ ] Slow, failed and split-horizon DNS are tested.
• [ ] IPv4, IPv6 and dual-stack cases are included.
• [ ] Cold and warm cache behavior is verified.
• [ ] Rollback is tested before broad deployment.
• [ ] Each supported browser and runtime has evidence.
• [ ] Tests use only owned or authorized destinations.

FAQ

Does listing two proxies guarantee automatic failover?

No. Interpretation and retry behavior vary by client. Test the exact browser or runtime and the failure type you expect.

Should every PAC result end with DIRECT?

No. DIRECT can bypass location and security controls. Use it only for explicitly approved fail-open traffic.

Can a PAC rule match an HTTPS path?

Do not design policy around it. Browsers commonly strip the path and query before PAC evaluation for HTTPS URLs.

Is WPAD safe on public networks?

Automatic discovery expands the trust boundary. Prefer an explicitly managed PAC URL and authenticated configuration distribution where policy permits.

Compliance note

Deploy PAC and WPAD only on networks you administer or are authorized to test. Treat the PAC file as executable policy, protect its distribution, minimize logging, and never use routing rules to bypass access controls or regional restrictions. Record and review every DIRECT exception.