Reading TLS handshakes without a debugger
A packet capture is often enough to tell whether two endpoints are speaking the protocol you think they are. The interesting part is knowing which bytes to ignore.
Every TLS 1.3 connection starts with a small, highly structured conversation. The client sends a ClientHello; the server answers with a ServerHello, certificate, and finished message. Most of this is encrypted, but the framing is not. That framing is a surprisingly reliable fingerprint.
Look at the record layer first
The first byte of each record is the content type. A value of 22 means handshake. The next two bytes are the legacy version, and the final two are the record length. If you see something other than a handshake record at the start of a connection, you are probably not looking at TLS at all.
ALPN is a contract
The Application-Layer Protocol Negotiation extension tells the server which protocols the
client understands. A browser usually offers h2 and http/1.1. A
server that only answers http/1.1 is not necessarily suspicious, but it is
worth noticing when the same server presents an otherwise modern configuration.
What this is good for
Mostly, it shortens the distance between "the request failed" and "the request never reached an HTTP implementation." Once you can see the difference, the rest of the debugging is ordinary application work.