A PAC result names both a proxy and a protocol. If your Firefox deployment needs SOCKS5, say so in the returned value:

return "SOCKS5 proxy.example:1080";

If the PAC policy uses public endpoints, select candidates from the SOCKS5 proxy list and keep the explicit SOCKS5 result. The generic SOCKS token has compatibility history. It is not a portable instruction that every browser must interpret as the newest SOCKS version.

In the Firefox implementation examined here, the PAC parser maps explicit SOCKS5 to the version-5 socket provider and requests server-side destination hostname resolution. Manual proxy configuration follows a separate settings path. A preference name from a manual setup therefore should not be treated as a universal explanation of every PAC result.

Keep the exact browser version, loaded PAC script, and returned token in the record. A script you edited is not necessarily the script the client fetched, and a different route returned for one host can change the observation.

This concerns the destination name associated with the selected SOCKS route. The client still needs to reach the proxy endpoint, and other applications keep their own DNS behavior. Do not turn one correct PAC result into a claim that all device-wide lookups now travel remotely.

When the configuration must support several browsers, check their documented PAC token support rather than transferring a Firefox source-level detail into another implementation.

Related articles