# wpad.dat vs proxy.pac: same file, different delivery

Source: https://findproxyforurl.net/articles/wpad-dat-vs-proxy-pac/ · updated 2026-10-06

A wpad.dat and a proxy.pac file contain the same thing, a PAC file with a FindProxyForURL function. The difference is how clients find the file, and that is where the risk lives.

## The file is the same

Both names hold a PAC file: JavaScript with a [`FindProxyForURL(url, host)`](https://findproxyforurl.net/findproxyforurl/)
function that returns `DIRECT` or a list of proxies ([what is a PAC file?](https://findproxyforurl.net/articles/what-is-a-pac-file/)).
You can test either one in the [PAC file tester](https://findproxyforurl.net/check/) in exactly the same way.

## Delivery is different

| | Explicit PAC URL (proxy.pac) | WPAD discovery (wpad.dat) |
|---|---|---|
| How the client finds it | URL set by group policy, MDM or by hand | DHCP option 252, or DNS lookups for a host called `wpad` |
| Transport | whatever the URL says; use HTTPS | plain HTTP ([PAC-D001](https://findproxyforurl.net/rules/pac-over-plain-http/)) |
| Who can supply the file | the server you configured | the first DHCP answer on the segment ([PAC-D008](https://findproxyforurl.net/rules/dhcp-option-252/)), or whoever answers the `wpad` name ([PAC-D007](https://findproxyforurl.net/rules/wpad-dns-discovery/)) |
| Works on unmanaged devices | only if configured | yes, that is its point |

The DNS variant is the classic trap. A client in `pc.eng.corp.example` asks for
`wpad.eng.corp.example`, then `wpad.corp.example`, then `wpad.example`. The last step leaves your
namespace. Public `wpad` names have been registered and abused, as documented in US-CERT alert
TA16-144A. The details are on the [WPAD page](https://findproxyforurl.net/wpad/).

## Which to use

- **Managed devices:** an explicit `https://` PAC URL, distributed by policy. Disable "automatically
  detect settings" where you do not need it.
- **WPAD unavoidable** (guest networks, unmanaged devices): own a `wpad` record in every internal DNS
  suffix, block `wpad.*` lookups to the internet at your resolvers, and enable DHCP snooping on
  access switches if you use option 252.
- **Either way:** serve the file as `application/x-ns-proxy-autoconfig` with an explicit
  `Cache-Control: max-age` of at most a day ([PAC-D002](https://findproxyforurl.net/rules/wrong-content-type/),
  [PAC-D003](https://findproxyforurl.net/rules/missing-cache-control/)).

## Testing a wpad.dat (a WPAD tester in three steps)

1. Fetch it as a client would: `curl -sS -D - http://wpad.corp.example/wpad.dat`.
2. Paste the body into the [tester](https://findproxyforurl.net/check/) with the URLs you care about.
3. Under **Delivery**, choose "WPAD DNS discovery" or "DHCP option 252" and paste the headers. The
   delivery is graded together with the file.

Then check from a client in each DNS suffix which `wpad` names resolve. Every answer should come from
your own DNS server, or be NXDOMAIN.


## Frequently asked questions

### Is wpad.dat different from proxy.pac?

Not in content. Both are PAC files. wpad.dat is the file name that WPAD auto-discovery requests from a host called wpad; proxy.pac is the conventional name when the URL is configured explicitly. You can serve the same file under both names.

### Which is more secure, WPAD or an explicit PAC URL?

An explicit PAC URL served over HTTPS and distributed by group policy or MDM. WPAD discovery uses plain HTTP, can walk out of your DNS namespace, and its DHCP variant is unauthenticated.

### How do I test a wpad.dat file?

Fetch it the way clients do (curl http://wpad.<domain>/wpad.dat), paste the body into an online PAC file tester such as findproxyforurl.net/check/, and paste the response headers under Delivery with "WPAD DNS discovery" selected to grade how it is served.