How to monitor HTTP/3 and QUIC traffic in Linux terminal

The challenge of viewing QUIC and HTTP/3 traffic

The modern internet has shifted dramatically with the transition from TCP to UDP as the foundation for web transport. The QUIC protocol, developed by Google and standardized by the IETF, brings massive speed improvements and eliminates historical bottlenecks of sluggish connections. In practice, this means the first request reaches the server much faster, even if there is packet loss along the network route. However, this architectural evolution created a major headache for system administrators and network engineers: traffic inspection.

Because QUIC encrypts not only the payload data but also most control metadata during the initial handshake, traditional TCP-based monitoring tools became effectively blind. In the past, debugging web server issues only required capturing packets and looking at port states or connection flags. Today, in Linux production environments, diagnosing a delivery failure requires mastering specialized command-line utilities. Before diving deep into packet analysis, keep in mind that infrastructure visibility also relies on other layers, such as how to monitor Linux network traffic in real time with bpfTOP to evaluate overall bandwidth consumption.

Preparing the environment and understanding tshark

Tshark is the text-mode version of classic Wireshark, the world's most famous network protocol analyzer. It runs seamlessly on Linux servers without a graphical interface, making it indispensable for cloud environments, containers, or remote dedicated servers. In practice, it acts like an ultra-precise recorder that intercepts everything passing through the network interface and outputs it to the screen or a file for later auditing. To install the utility on Debian or Ubuntu distributions, simply use the system's standard package manager.

To perform the installation without prompts regarding capture permissions for regular users, run the command below in your server terminal. It is vital to ensure your user has proper privileges or run the process with elevated permissions, since direct reading of the network interface requires administrator access.

sudo apt update && sudo apt install tshark -y

During installation, the package manager often asks if non-root users can capture packets. Allowing this configuration prevents you from always having to run the main command as root, thereby increasing the operational security of your production Linux environment.

Capturing QUIC packets on the network interface

Since QUIC relies on the UDP protocol rather than traditional TCP on port 443, the first step toward clean analysis is filtering the correct traffic on the active interface. If you attempt to capture everything passing through a busy server's network card, the terminal will be flooded by thousands of lines of irrelevant packets in fractions of a second. To avoid this noise, we instruct tshark to focus exclusively on the default port used by HTTP/3.

The following command starts a capture on the server's primary interface, filtering only UDP packets destined for or originating from port 443. In practice, this isolates the raw QUIC traffic your application is receiving from modern web browsers or compatible clients.

sudo tshark -i eth0 -f "udp port 443"

While the command runs, every captured QUIC packet appears on screen with details about size, source and destination IP addresses, and initial connection identifiers. To save this capture into a file for later analysis, simply append the writing parameter to the original command.

sudo tshark -i eth0 -f "udp port 443" -w quic_capture.pcap

Applying advanced filters to isolate HTTP/3 connections

Capturing raw packets is only the beginning; the real challenge in production environments is separating signal from noise. Tshark features an extremely powerful display filter language that lets you extract only the packets of logical interest. When we want to analyze specific HTTP/3 transactions within the sea of QUIC packets, we must use fields decoded by the program's internal engine.

To read the previously recorded file and filter only packets containing active HTTP/3, we use the read flag combined with the specific display filter. This makes auditing easier without needing to restart a live network capture. Furthermore, in complex debugging scenarios, cross-referencing this information with how to use awk to filter logs in Linux terminal helps correlate network events with application error logs.

tshark -r quic_capture.pcap -Y "http3"

If you need to investigate a specific client connection reporting slowness, you can refine the filter by specifying their source IP address. This restricts the output exclusively to packets exchanged between the server and that particular user.

tshark -r quic_capture.pcap -Y "ip.addr == 192.168.1.50 && http3"

Unlocking encryption with session keys

One of the biggest barriers when inspecting modern web traffic is end-to-end encryption, which prevents direct reading of HTTP/3 headers and transmitted payloads. Because TLS 1.3 is mandatory in QUIC, packets travel completely protected. However, you can instruct tshark to decrypt traffic at runtime if you have access to session keys generated by the web server, such as Nginx or Caddy.

To enable this engineering feat, the web application must be configured to export master encryption secrets to an environment variable or specific log file (usually via the `SSLKEYLOGFILE` directive). With this file in hand, we pass the corresponding parameter to tshark during capture file analysis.

export SSLKEYLOGFILE=/path/to/keylog.log
tshark -r quic_capture.pcap -o tls.keylog_file:$SSLKEYLOGFILE -Y "http3"

In practice, this causes tshark to use temporary secrets to decode encrypted packets, allowing you to view URL paths, HTTP status codes, and headers exchanged between client and server directly in the terminal. To explore these architectural concepts further in production, see our related technical analysis on How to test and replace SMD IC with hot air station.

Final considerations on network monitoring

Monitoring QUIC and HTTP/3 traffic via command line requires a mindset shift compared to legacy TCP-based diagnostics. Although default encryption introduces considerable challenges for network visibility, proper use of tools like tshark combined with session key logs gives total control back to the systems engineer. Mastering these commands in Linux environments guarantees fast and precise troubleshooting, allowing you to identify delivery bottlenecks before they impact end-user experience.

Keeping this inspection routine integrated into your infrastructure lifecycle ensures your web application operates with peak performance and stability. Continuous practice with display filters and understanding UDP protocol states turns the terminal into a comprehensive network engineering lab, ready to solve modern web challenges.