A PAC file decides which path a request takes: direct, through the Zscaler tunnel, or elsewhere. At its core it is a JavaScript function, and in many teams exactly one person feels confident with it. PAC-Lens reads the file that is actually active in your tenant, checks its syntax, and shows which line applies to a specific case when you enter a test URL. Silent guesswork turns into a line you can point at. Even a clean acquittal of the PAC file saves time, because the search then continues elsewhere on purpose.
The component checked last
Few building blocks in Zscaler operations decide as much and get examined as rarely as the PAC file. It determines which path a connection takes, and it does so quietly in the background. When a request behaves oddly, suspicion usually falls first on the policy or the network. The PAC file gets its turn once everything else has been ruled out.
The reason is rarely carelessness. PAC files are proxy auto-config scripts, JavaScript functions with a grammar of their own. Anyone who does not touch them regularly reads them slowly. If the one colleague who feels confident is away, the file becomes a black box: nobody changes anything, for fear of breaking something more important.
That caution is justified. A PAC file is evaluated on every connection attempt, for every user, at every location. A mistake in it takes effect immediately and broadly. The result is a state many organisations know well: the file works, nobody fully understands it, and everyone hopes it will not need to change.
What PAC-Lens does
PAC-Lens retrieves the PAC file that is actually active in your tenant, checks its syntax, and answers the one question that matters day to day: which line applies to this particular address?
You enter a test URL and see the matching rule highlighted in the code, together with the path it prescribes. The difference from the previous approach is not speed alone but the kind of result: an assumption becomes a finding.
The word "active" matters here. What gets checked is not a copy from a file share that may be three revisions old, but the version actually served in the tenant. In troubleshooting, that distinction is often the decisive one.
A case from everyday work
A user reports that an internal application is unreachable at the office but works from home. Three explanations are plausible: the policy, the network, or the PAC file. Without a tool this turns into a chain of follow-up questions, often across several levels and several days.
With PAC-Lens you test the affected address directly and see which PAC rule applies and where it sends the request. If the file routes the request past the tunnel, you have found the cause. If it does not, the PAC file is cleanly ruled out.
The conversation that follows has a different quality. It starts with a finding rather than a hunch, and it can point at a line everyone involved sees the same way.
Why an acquittal is worth just as much
In troubleshooting, what matters is not only where the problem is, but also where it definitely is not. A suspicion cleanly ruled out shortens every subsequent round, because it stops the same lead being followed twice.
In practice this is the more common case: the PAC file is usually fine. It is just that nobody knows this for certain beforehand, and that uncertainty costs time in every incident anew.
If you are working on the PAC file anyway
PAC-Lens reads and explains. For building new rules there is PAC Configuration Studio: a guided rule builder that requires no JavaScript knowledge and uses the same trace engine as PAC-Lens. A test result there is therefore just as dependable as a live finding here.
The studio creates, tests and exports the finished PAC file for upload to Zscaler. It does not write into the tenant by itself. The finished file stays in your hands, and the upload follows your usual route.
PAC-Lens reads and explains. It writes nothing back into your tenant. Changes to the PAC file remain your own deliberate step.
What the endpoint can contribute
PAC-Lens answers which rule should apply. A second question remains: which path does a particular device actually take? Where the CentaurNexusAgent is installed, that view is added. It measures the path regularly and detects whether a request runs through Zscaler. Alongside the rule, you get the observation from the workplace.
Together they make diagnosis more dependable: the rule says what should apply, the measurement what actually arrives. Where the two diverge, that divergence is itself the finding.
The agent explicitly collects no visited addresses, no host names and no page content. What is transmitted are status values, not content.
Frequently asked questions
What is a PAC file?
A proxy auto-config file is a JavaScript function that tells the browser, for every address, which path a request should take: direct, via a proxy, or through the Zscaler tunnel. It is evaluated on every connection attempt.
Why is a PAC file so hard to check?
Because it is program code rather than a rule list. To know which line applies to a given address, you have to run the function in your head. That is slow and error-prone.
Does PAC-Lens require Zscaler administrator rights?
PAC-Lens is role-controlled and reads the active PAC file through the existing connection. Who may use which view is set through roles, without handing out administrator rights broadly.
Can I build new PAC rules with it?
That is what PAC Configuration Studio is for. It creates and tests new rules through a guided builder and uses the same trace engine as PAC-Lens. The finished file is exported for upload.
Does PAC-Lens change my configuration?
No. PAC-Lens reads the active file and evaluates it. It writes nothing back into the tenant.
Sources
See the workflow in context
Pick the matching role in the demo launcher. The demo uses prepared sample data.
Open demo launcher