How to see server names in QUIC (HTTP/3) traffic in a PCAP
A growing share of web traffic no longer uses TCP at all. HTTP/3 runs over QUIC, on UDP, and encrypts even the parts of the connection that TLS over TCP leaves in the open. Yet the first packet of every QUIC connection can be decrypted by anyone who captures it, and it names the server.
Upload the capture and PCAPNG Analyzer decrypts QUIC’s Initial packets for you, so HTTP/3 server names and JA4 fingerprints sit alongside TLS over TCP in one view. In Pro they also count for threat-intel matching, first-seen findings and each address’s history across captures.
Try it free on your own computer →1. Why QUIC changes the picture
Browsers use HTTP/3 wherever a server offers it, and the largest services (search, video, CDNs, social media) do. In one home-browsing capture we checked, 169 of 587 TLS connections, more than a quarter, ran over QUIC rather than TCP. Seventeen server names appeared only in QUIC.
Analysis that starts from tcp.port == 443, or a tool that only reads TCP, misses all of that. So check how much QUIC a capture contains before concluding that a host didn't contact a site.
2. Why the first packet can be read
A QUIC connection starts with an Initial packet carrying a TLS ClientHello, the same message that opens TLS over TCP, with its server name (SNI), application protocol (ALPN) and capabilities. Unlike TLS over TCP, the Initial is encrypted. But its keys are derived from the connection ID written in the packet's own header (RFC 9001). That is deliberate: it protects the handshake from tampering, not from observation. Anyone with the packet can derive the keys and read the ClientHello.
Everything after the handshake, including the server's certificate, is protected by keys that only the two endpoints know.
3. Extract server names
Current Wireshark versions decrypt Initial packets automatically, and the ClientHello appears under the same TLS fields as over TCP. List server names seen over QUIC, most frequent first:
tshark -r capture.pcapng -Y "quic && tls.handshake.type == 1" \
-T fields -e tls.handshake.extensions_server_name | sort | uniq -c | sort -rnLeave out quic && to list names from TCP and QUIC together, which is usually what you want for a complete picture. Other useful fields from the same packets:
tls.handshake.extensions_alpn_str:h3for HTTP/3. Other values show QUIC used by something other than a browser.tls.handshake.ja4: the client fingerprint, starting withqfor QUIC.quic.version:0x00000001for QUIC version 1; version 2 is0x6b3343cf.
To compare QUIC with TLS over TCP, count ClientHellos on each:
tshark -r capture.pcapng -Y "quic && tls.handshake.type == 1" | wc -l
tshark -r capture.pcapng -Y "tcp && tls.handshake.type == 1" | wc -l4. Inspect it in Wireshark
Filter quic.long.packet_type == 0 to show Initial packets. Expand one: under the decrypted payload, the CRYPTO frame holds the TLS ClientHello, with the server name extension inside. Large ClientHellos (for example, with post-quantum key shares) are split over two Initial packets, and Wireshark reassembles them.
Use Statistics → Conversations on the UDP tab to see which hosts used QUIC and how much data went where. Remember that the IP address only shows where the connection went, and one CDN address may serve thousands of sites.
5. Know what stays hidden
- Content and certificates. Paths, headers, bodies and the server's certificate are all encrypted with real session keys. Without the browser's key log (
SSLKEYLOGFILE), recorded at capture time, they stay hidden. - Encrypted ClientHello (ECH). Where ECH is used, the visible server name is the provider's public front, not the real site, and the true name is encrypted inside.
- Connections already running. After the handshake, QUIC packets use short headers that can't be decrypted. A capture that starts mid-connection shows only UDP flows.
- The first visit to a site usually uses TCP. A browser learns that a server offers HTTP/3 from that response, and switches on later connections.
Many organisations block QUIC so that browsers fall back to TLS over TCP, which their proxies can inspect. If a capture shows no QUIC at all, check whether that is policy before assuming no client uses it.
Manual method vs PCAPNG Analyzer
Manual method
- Count QUIC and TCP ClientHellos.
- Extract server names from both.
- Check ALPN, versions and JA4 fingerprints.
- Inspect suspicious Initial packets in Wireshark.
- Compare names with your threat intel.
With PCAPNG Analyzer
- Upload the capture.
- Choose See TLS analysis: server names and client fingerprints cover QUIC and TCP together.
- In Pro, QUIC names are matched against your threat-intel lists and appear in first-seen findings.
The app decrypts client Initial packets of QUIC version 1 and version 2 with keys derived from their connection IDs, exactly as the protocol allows. It reassembles ClientHellos that span two Initial packets, and reports a second ClientHello after a retry. It reads nothing beyond the handshake: no keys are imported, and the rest of the connection stays encrypted.
Don't lose a quarter of your traffic
See server names and fingerprints from QUIC and TCP in one view, on a server you control.
Start freeCompare Free and Pro