From a PAC Test Result to the Browser's Actual Route
Separate a PAC function's returned route from file delivery, browser adoption, proxy reachability, and the request's final path.
A PAC tester returns PROXY proxy.example:8080. Useful result. Now there are several other questions to answer before calling the browser configuration verified.
| Question | What to examine |
|---|---|
| What does this script return for this input? | The evaluator, input URL, and helper results |
| Did the browser obtain this copy? | The configured PAC URL and delivery/cache evidence |
| Did the browser use the returned route? | The browser's proxy-resolution and connection diagnostics |
| Could that route carry the request? | The selected endpoint's connection and proxy exchange |
A tool such as pacparser evaluates PAC logic with its own supported helpers. It is not running the target browser's complete configuration discovery, policy, caching, and connection machinery.
Keep inputs comparable. A different URL scheme, hostname spelling, DNS answer, or supplied client address can change a legitimate result. A test run on another network may exercise a different branch without any script bug.
Browser policy can also select another PAC URL or a fixed proxy. Editing the file on disk does not establish that the browser fetched it again. For Chrome, refreshing PAC differs from clearing remembered bad proxies. Capture the exact file revision and relevant consumer settings with the result.
Use offline evaluation to narrow a logic problem. Use the real client's diagnostics to establish adoption and routing. If the script result is right but the proxy sees no transaction, investigate that gap before rewriting a working rule.