What this article covers

The Web Application Daemon (WAD) handles proxy inspection, explicit web proxy, authentication, and external threat feed pattern evaluation. Under heavy SSL inspection or when ingesting large threat feeds, WAD worker processes can experience exponential memory growth. This runbook details surgical worker isolation, non-disruptive recycling, and worker capping per VDOM.

Scope & Firmware Matrix FortiGate units running FortiOS 7.0 through 8.0 configured with proxy-based security profiles, SSL deep inspection, or external threat feeds (STIX/TAXII or plain IP lists).

Before using the CLI

Inspection Mode Audit Verify whether policies are configured for Flow-based or Proxy-based inspection. Flow-based policies avoid WAD worker memory footprints for standard antivirus and web filtering.
External Threat Feed Scale Confirm total entry count of configured threat feeds. Feeds exceeding 100,000 uncompressed regex entries cause WAD type=algo(3) memory exhaustion.
User Dataplane Safety Confirm that recycling WAD workers triggers immediate kernel respawn without resetting active NP6/NP7 fastpath firewall sessions.

Troubleshooting workflow

01

Audit top WAD worker memory consumption & core affinity

Query top memory consumers, examine memory allocated per WAD worker PID, and use diagnose sys top with Shift+M (sort RAM) to inspect CPU core affinity pinning.

diagnose sys top-mem 20
diagnose sys top 2 50
diagnose test application wad 1000
02

Distinguish proxy workers from threat feed algo workers

Check if memory is consumed by standard traffic workers or type=algo(3) pattern evaluation engines handling external blocklists.

diagnose test application wad 2500
diagnose test application wad 1000 | grep -E "type=|mem="
03

Inspect IPS engine worker memory & crash counters

Verify whether the IPS monitor or individual IPS engines are suffering from signature compilation leaks or engine crashes.

diagnose test application ipsmonitor 1
diagnose test application ipsmonitor 99
diagnose debug crashlog read | grep ips
04

Perform surgical worker recycling via graceful SIGTERM (Signal 15)

Do NOT issue brute force killall (SIGKILL 9), which abruptly severs sockets and risks shared memory corruption. Target the leaking worker PID with graceful SIGTERM: diagnose sys kill 15 <pid>. This allows the worker to flush log queues, release IPC shared memory locks, and close TLS sessions cleanly before supervisor respawn.

# Identify runaway worker PID, then gracefully recycle:
diagnose sys kill 15 <pid>
# Fallback zero-downtime respawn only if process is frozen in D-state:
fnsysctl killall wad
05

Cap WAD worker count per core & VDOM

On appliances with limited RAM, restrict maximum concurrent WAD workers to prevent memory overshoot during peak traffic spikes.

config system global
    set wad-worker-count 2
end
06

Optimize external threat feed pattern compression

Convert granular /32 IP entries in threat feeds to CIDR aggregates or wildcards to drastically compress the WAD algo worker pattern tree.

config system external-resource
    edit "Malicious_IP_Feed"
        set refresh-rate 1440
    next
end

Operational caution

Review before applying: Restarting WAD via fnsysctl killall wad terminates active proxy-inspected TCP handshakes (forcing clients to re-negotiate HTTP/S sessions), but does not interrupt hardware-forwarded or flow-based firewall traffic. Perform during a scheduled maintenance window if handling mission-critical explicit proxy traffic.
Next step

Continue the evidence path

If the increase occurs specifically during signature updates, use the FortiGuard update article.

Explore Ferrite workflows Browse related articles