Investigate outgoing connections in FW logs

[verfluchten]

I always thought that if an inbound PASS FW rule is matched, then the response will always be allowed. At least this was how my Linux router worked. It also had a settings for rules that checked NEW/ESTABLISHED etc attributes of connections which I am not seeing in OS.
Long story short, I host a number of web servers from a VM on my LAN. This and other handful of VMs are blocked from making outgoing connections by a LAN rule that is spelled as follows:

Block IPV4 protocols * source <VM's IP address> Port * Destination *

Every couple hours, the web server VM does bursts of 10x outgoing connection attempts from source port 80 to random high ports on mostly search engine destination IPs, i.e. Google bot, Microsoft, Yahoo, and a number of others whom I checked and found that they are also less famous search engines.
It occurred to me that this could be me mistaking the web server's response to an incoming request for a new outgoing connection, but when I browsed all of the hosted web sites from outside of my LAN, from elsewhere on the Internet, I did not see any new such entries in the logs. It also occurs to me that they might be GETting something that I do not get such as robots.txt, XMLRPC, etc. How can I find out for sure whether it is a web site responding to an external request and being blocked by the above rule or it is some malicious activity?
It confuses me that they always come in bursts of 10x regardless of which search engine it is. This leads me to believe that it is something coded into the web server software rather than all those search engines using the same pattern of requests. Any ideas as to what is going on?

[meyergru]

It is probably an attempt to upgrade an outgoing connection to use HTTP/3, which uses UDP during handshake. Since those packets are unsolicited, they may get blocked. Also, some web servers still send some packets when they end HTTP(S) sessions and these may get blocked because they are out-of-state.

[EricPerl]

If the source port is 80 and the destination port is random (as it would for a client), could it be for a reply to a long poll request (some form of notification)?
And the FW could be dropping the state corresponding to this connection if it's been idle for too long.

[verfluchten]

It is probably an attempt to upgrade an outgoing connection to use HTTP/3, which uses UDP during handshake. Since those packets are unsolicited, they may get blocked. Also, some web servers still send some packets when they end HTTP(S) sessions and these may get blocked because they are out-of-state.

The rule logs very short TCP packets to all of the destinations, be it Google or some obscure crawler.