Solution | HAR shows the browser’s request timings. WAD shows proxy processing. Packet captures show network timing on the separate client and server TCP connections. Browser "Waiting" time alone does not identify which device caused the delay.
Record client IP, URL and timezone align clocks. In the browser, go to Developer Tools -> Network, enable Preserve log, reproduce once and export HAR. Note the slow request’s time, method, URL and status. In parallel, collect a short client-filtered WAD trace. Coordinate with other administrators before resetting diagnostics:
diagnose debug reset
diagnose debug console timestamp enable
diagnose wad debug clear
diagnose wad filter clear
diagnose wad filter src <client-IP>
diagnose wad debug enable category all
diagnose wad debug enable level verbose
diagnose debug enable
Capture both sides in the GUI or use a separate CLI session (Ctrl+C to stop):
diagnose sniffer packet any 'host <client-IP> or host <server-IP>' 4 0 l
Immediately after reproduction stop and clear debug:
diagnose debug disable
diagnose wad debug clear
diagnose wad filter clear
diagnose debug reset
diagnose debug console timestamp disable
Match URL, method, time and WAD identifiers to each TCP connection. Client-side and server-side TCP sequence numbers differ.
Before outbound connection: Check WAD for authentication, DNS or policy delays. Slow SYN/SYN-ACK or TLS exchange: Check the affected peer and network path. Request forwarded, response delayed: Investigate the upstream processing and network. Response received promptly but delivered late: Inspect proxy buffering, resource use and client-side flow control.
Correct the identified cause, repeat the same request and compare timings.
Note: HTTPS PCAPs usually hide HTTP content; HAR/WAD provide request context. Remove credentials, cookies and tokens before sharing.
|
