If you're seeing an abnormal spike in requests for /wpad.dat targeting your catch-all vhost, you're experiencing a common (yet poorly documented) issue related to Web Proxy Auto-Discovery Protocol (WPAD). This isn't necessarily an attack, but rather misconfigured clients searching for proxy configurations.

The key detail in your case is that the requests target cluster.atlascms.se, which serves as your DNS failover host. The WPAD protocol works through DNS resolution in this order:

1. Client checks http://wpad.[yourdomain]/wpad.dat
2. Falls back to http://wpad/wpad.dat
3. Finally attempts parent domains

Since your failover domain is likely configured as a wildcard or default DNS entry, it's catching all these WPAD discovery attempts.

Here are three approaches to handle this:

# Option 1: Return 204 No Content (silent fail)
<LocationMatch "^/wpad\.dat$">
    Redirect 204 /
</LocationMatch>

# Option 2: Serve empty valid wpad.dat (stops retries)
Alias /wpad.dat /var/www/empty_wpad.dat
# Then create empty_wpad.dat with:
# function FindProxyForURL(url, host) { return "DIRECT"; }

# Option 3: Block at vhost level (if no legitimate use)
<VirtualHost *:80>
    ServerName cluster.atlascms.se
    Redirect 403 /
    # Or more granular:
    <Files "wpad.dat">
        Order allow,deny
        Deny from all
    </Files>
</VirtualHost>

For a more permanent solution at the DNS level:

; BIND configuration example
zone "atlascms.se" {
    type master;
    file "db.atlascms.se";
    // Explicitly define WPAD behavior
    wpad no;
};

# Or via RPZ (Response Policy Zones) if using BIND 9.8+
zone "rpz" {
    type master;
    file "db.rpz";
    allow-query { none; };
};

# In db.rpz:
wpad.atlascms.se CNAME .
*.wpad.atlascms.se CNAME .

To prevent log bloat from these requests:

# In httpd.conf
SetEnvIf Request_URI "^/wpad\.dat$" dontlog
CustomLog logs/access.log combined env=!dontlog

# For mod_security users:
SecRule REQUEST_URI "@streq /wpad.dat" "id:1001,phase:1,nolog,pass,ctl:ruleEngine=Off"

Verify the effectiveness with this real-time monitoring command:

tail -f /var/log/apache2/access.log | grep -v "wpad.dat" | \
awk '{print $1}' | sort | uniq -c | sort -nr

This gives you clean traffic analysis while filtering out the WPAD noise.

When my Apache logs ballooned to 12GB overnight, I discovered thousands of legitimate hosts hammering /wpad.dat requests against my catch-all vhost. This wasn't a DDoS attack - but rather misconfigured clients searching for proxy settings through the Web Proxy Auto-Discovery Protocol (WPAD).

The key insight emerged when I noticed all requests targeted cluster.atlascms.se, my DNS failover host. Modern systems attempt WPAD resolution through DNS in this order:

1. http://wpad.[current-domain]/wpad.dat
2. http://wpad.[parent-domain]/wpad.dat
3. Repeat upward through domain hierarchy

Since clients used subdomains pointing to my failover host, their WPAD queries inevitably hit cluster.atlascms.se.

For immediate relief, implement these Apache directives:

# Return 404 for WPAD requests
RewriteEngine On
RewriteCond %{REQUEST_URI} ^/wpad\.dat$ [NC]
RewriteRule .* - [R=404,L]

# Alternative: Serve empty PAC file
<Location "/wpad.dat">
    ForceType application/x-ns-proxy-autoconfig
    ErrorDocument 200 "function FindProxyForURL(url, host) { return 'DIRECT'; }"
</Location>

Prevent resolution attempts at the source:

; BIND zone file addition
wpad    IN      CNAME   .
cluster IN      A       192.0.2.1

Or for Windows DNS:

Add-DnsServerResourceRecord -ZoneName "atlascms.se" -Name "wpad" -CName -HostNameAlias "."

Use this GoAccess command to verify effectiveness:

goaccess access.log --log-format=COMBINED --html-report-title="WPAD Traffic Analysis" -o report.html

Key metrics to watch:

• HTTP 404/200 responses for /wpad.dat
• DNS query volume for wpad.atlascms.se
• CPU load during previous peak hours