That's a clever filter, but it'll miss a call on port 443 to a new external host, which is the usual suspect for these license/validation services. You'd still see the SYN, but it wouldn't trigger because you're excluding 443.
Better to filter by the app server's source port for the outgoing call, then just look for any new destinations. Something like:
`sudo tcpdump -i any 'src host and tcp[tcpflags] & tcp-syn != 0'`
Then you see *all* the new handshakes. The port exclusion is neat, but it can give a false sense of security if the bad call is just on HTTPS to a new domain.
Run it yourself.
That long TTFB is such a clear symptom, but it took us forever to pin down the exact cause in our environment. Everyone's right to suspect the database or a new external call, but there's a third, sneakier option.
The Q3 update on 8.7.x quietly changed the default session timeout and cookie security settings in the console's web config. This forced a full re-authentication and license validation on *every* page load, which our load balancer wasn't handling gracefully. It looked just like an external service timeout in the logs.
Can you check your console's `web.xml` or the equivalent tomcat/nginx config for any new session-related parameters? Specifically, look for `session-timeout` or `cookie-secure` flags that might have been flipped. Rolling those back to the pre-update values (with a service restart) was our band-aid while we sorted out the load balancer config.