How to Audit Proxy Bypass and PAC Rules in Browser Automation

A browser can be configured with a proxy and still send part of its traffic directly. PAC rules, operating-system exclusions, NO_PROXY, extension behavior, service workers, WebSocket clients and application-specific network stacks can all create exceptions. A successful page load therefore proves only that the page loaded—not that every relevant request used the purchased proxy route.

This guide builds a bounded acceptance test for teams evaluating residential or rotating proxies for authorized data collection, market research, localization QA and ad verification.

Define the routing promise before testing

Write down what must be proxied and what may remain direct. Include the browser, automation runtime, protocols, destination groups, session mode and IP family. Separate three outcomes:

• proxied: the request uses the expected proxy exit;
• approved direct: a documented exception such as a local health endpoint;
• unexpected direct: any other request that bypasses the proxy.

Do not use “the browser uses a proxy” as an acceptance rule. It cannot tell you whether DNS, subresources, background requests or WebSockets follow the same path.

Build a controlled observation point

Use an authorized test endpoint that records the source address, request time, protocol, hostname and a random run identifier. Do not place credentials, cookies or customer data in that identifier. Capture the same fields at the automation client and proxy gateway when available.

For each run, preserve:

The observation endpoint should return a minimal response and enforce a conservative rate limit. It is a measurement instrument, not a traffic generator.

Create a route matrix

Test more than the top-level document. A useful matrix includes:

1. an HTTPS document and same-origin subresources;
2. a cross-origin image, script and API request on domains you control;
3. a WebSocket connection if the workload uses one;
4. a fresh DNS name and a previously resolved name;
5. an IPv4-only and IPv6-capable test host when both families are in scope;
6. a localhost or private endpoint that should remain direct;
7. a hostname that intentionally matches each PAC or bypass rule.

Run each cell in a clean browser profile, then repeat in a warm profile. The comparison catches service-worker, cache and persistent-connection effects that a single fresh session misses.

Inspect every bypass layer

Proxy exclusions can come from several layers. Record the effective value at runtime rather than trusting configuration files alone.

PAC decisions

List the rules in evaluation order. Test exact hosts, subdomains, uppercase and lowercase forms, trailing dots, alternate ports and internationalized hostnames used by the workload. Treat broad suffix matches carefully: an exception intended for one internal service can unintentionally cover unrelated domains.

Environment and operating system

Check proxy environment variables, operating-system network settings and automation-launch arguments. An inherited NO_PROXY value or a platform default can override an otherwise correct browser configuration.

Browser and extension behavior

Extensions may change proxy settings after startup. Service workers can initiate background fetches, while speculative connections and prefetching may appear outside the visible page flow. Test with the production extension set and disable optional prefetch features only if that matches the intended deployment.

Application libraries

Downloads, media players, native messaging helpers and external HTTP clients may not use the browser network stack. If the workflow invokes them, test them as separate clients rather than assuming browser settings propagate.

Prove the route without exposing the client IP

Use two independently controlled endpoints: one expected to receive proxied traffic and one explicit direct-route canary. Compare their observed source addresses with the known proxy exit and a sanitized client-network fingerprint. The report should state only whether the values matched; avoid retaining an operator's precise residential address.

If the direct canary is not required for production, keep it inside a controlled test environment. Never cause a real customer destination to receive surprise direct traffic merely to prove a failure.

Test rotation and sticky sessions separately

For rotating sessions, create a new documented session key and verify that all resources within one logical transaction follow the expected policy. For sticky sessions, repeat the route matrix over the promised lifetime. Record both exit changes and route-class changes.

A new proxy IP is not the same as a bypass. Classify failures separately:

• proxy exit changed but traffic stayed proxied;
• traffic switched from proxy to direct;
• one protocol bypassed while others remained proxied;
• IPv6 connected directly while IPv4 used the proxy;
• a retry changed the path after the first attempt failed.

Pair this evidence with the session stickiness test and retry budget guide.

Calculate the metrics that support a purchase decision

Report denominators and segment results by browser version, route rule, destination group, protocol and IP family.

• proxy coverage: proxied requests divided by requests required to be proxied;
• unexpected direct rate: unapproved direct requests divided by all observed requests;
• transaction integrity: transactions in which every required request used the expected route;
• PAC decision accuracy: rule cases with the expected direct or proxy result;
• route stability: sessions with no unexplained route-class change;
• evidence completeness: requests joined across client, proxy and endpoint logs.

For privacy-sensitive or location-sensitive work, one unexpected direct request can be a release blocker even if the aggregate percentage looks small.

Set an acceptance gate

A practical production gate can require:

• zero unexpected direct requests in the required route matrix;
• all approved direct routes documented with an owner and reason;
• 100% correct PAC decisions for production host patterns;
• no IPv4/IPv6 route split unless explicitly designed;
• stable behavior in clean and warm profiles;
• route evidence preserved without secrets or personal payloads;
• a rollback procedure tested after PAC or browser changes.

Use pass, conditional pass, fail and inconclusive. A conditional pass must name the permitted browser version, markets, protocols and excluded features. An inconclusive result requires better evidence, not a larger traffic volume.

Troubleshooting sequence

When the test finds a direct request:

1. identify its hostname, protocol, resource type and IP family;
2. reproduce it with one clean profile and one request;
3. evaluate the PAC result for that exact hostname;
4. inspect environment, system and browser exclusions;
5. confirm whether an extension or external helper made the request;
6. compare client, gateway and endpoint timestamps;
7. narrow the responsible rule and retest the full matrix;
8. document the fix and a regression case.

Avoid adding a blanket proxy rule until you understand legitimate local or internal traffic. A hasty change can break health checks and private services.

Buyer checklist

• Define required proxy and approved direct routes.
• Test documents, subresources, APIs and WebSockets.
• Cover clean and warm profiles.
• Exercise every PAC and bypass pattern explicitly.
• Separate IPv4 and IPv6 results.
• Detect retries that silently change the route.
• Join browser, proxy and endpoint evidence with sanitized IDs.
• Set a zero-tolerance rule where direct exposure creates material risk.
• Re-run after browser, extension, PAC or operating-system updates.
• Keep secrets, cookies and personal data out of test logs.

FAQ

Does checking the browser's public IP prove all requests are proxied?

No. It proves only that the request used for the check appeared from that address. Subresources, WebSockets, DNS behavior or external helpers may follow another path.

Should localhost always bypass the proxy?

Often, but not universally. Document the intended behavior and test exact names and address forms. Avoid broad exceptions that include production domains.

Can a PAC file create intermittent failures?

Yes. DNS-dependent rules, cached decisions, fallback directives and different hostname forms can produce inconsistent routes. Test deterministic cases and capture the effective decision.

Should failures be counted as bypasses?

Keep availability and routing as separate metrics. A connection failure is not proof of a bypass, but a retry that goes direct is an unexpected route change and must be counted.

Compliance note

Run route audits only on systems and destinations you own or are authorized to test. Follow provider contracts, destination terms, privacy requirements and rate limits. Do not use proxies to evade access controls, conceal abusive activity, misrepresent identity or manufacture traffic. Retain only the minimum sanitized routing evidence needed for engineering and purchasing decisions.