Table of contents

Client logs are wonderful right up until the moment they actually show you something. But one day you hit a wall: the app spits out a laconic connection reset, the proxy stays silent in its own logs, and the target server swears everything is fine on its end. Who's lying? Nobody. You're just looking at the problem from the top floor, while the truth lives down at the packet level. And that's where you need to go.

This article is a detailed engineering guide to working with tcpdump and Wireshark when traffic goes through a proxy. We'll break down exactly what an observer sees before the proxy and after it, why inside an HTTPS tunnel you only see a CONNECT request and nothing else, and how to tell from a single dump whether the drop happened on your side or on the target server's side. This isn't about interception or HTTPS manipulation at the application level - it's about the packet level and honest drop diagnostics.

Introduction: when client logs are no longer enough

Picture a typical infrastructure. Your app reaches out to an external API through the Proxeon HTTP proxy. Usually everything works. But five percent of requests fail with an error, and you have no idea why. The app logs show only that the connection broke. The proxy logs show the tunnel was established. The target server is outside your control. You're stuck between three black boxes.

This is exactly where packet diagnostics begins. A traffic dump is a transcript of the conversation between machines, recorded word for word, without interpretation and with no right to lie. A packet either arrived or it didn't. The RST flag is either set or it isn't. TCP can't pretend. And once you learn to read this transcript, you'll stop guessing.

From this guide you'll learn: how to capture a dump with the tcpdump command without filling your disk with gigabytes; which Wireshark display filters save hours; how to read the TLS handshake even without decryption; how to identify who caused the drop by the flags; and how to legally decrypt your own traffic through the SSLKEYLOGFILE variable. At the end you'll find a ready-made checklist for contacting support and a detailed FAQ.

Fundamentals: three segments of a single connection

The first thing to get into your head: when a client works through a proxy, that's not one connection but at least two separate TCP connections. One goes from the client to the proxy. The other goes from the proxy to the target server. This is the foundation without which the rest of the analysis makes no sense.

What a dump is and how it's structured

A packet dump is a sequence of network packets captured on a specific network interface of a specific machine. The key word is specific. You always see only the traffic that physically passes through the capture point. Capturing on the client, you see the client-proxy conversation. Capturing on the proxy, you see both sides. On the target server - only the proxy-server conversation.

Each packet carries layer headers: Ethernet, IP, TCP or UDP, and the payload. For drop diagnostics we're primarily interested in the TCP layer: port numbers, sequence numbers, acknowledgments (ACK), and flags - SYN, ACK, FIN, RST, PSH.

The proxy model: two connections instead of one

Let's break down how traffic flows when working with an HTTP proxy in tunnel mode:

  • Segment A (client - proxy). The client opens a TCP connection to the proxy's IP and port. Over this channel it sends a command to establish a tunnel.
  • Segment B (proxy - target server). The proxy opens a separate TCP connection to the target server under its own name. This is already a different src-IP, a different src-port, a different state.
  • The logical tunnel. Once established, the proxy starts blindly shuffling bytes from segment A into segment B and back. It doesn't parse what's inside.

Why does this matter for diagnostics? Because the drop can happen on either of the two segments, and from the client's perspective the symptom will be identical - the connection died. But the cause, and therefore the fix, is different.

HTTP proxy, SOCKS, and tunneling

With a regular unencrypted HTTP request, the proxy sees the method, the URL, and the headers. But as soon as HTTPS comes into play, the picture changes. The client can't hand the proxy an unencrypted request - that would defeat the purpose of encryption. So tunneling kicks in: the client tells the proxy connect me to this host on this port and don't interfere any further. That command is CONNECT.

Deep dive: why only CONNECT is visible inside the tunnel

This is perhaps the most common source of confusion for engineers opening an HTTPS traffic dump through a proxy for the first time. You expect to see requests and responses, but instead you see one line and then an unreadable mess. Let's figure out why, and why this is exactly how it should be.

The anatomy of CONNECT

When the client wants to establish a secure connection through a proxy, it sends the proxy this request in the clear:

CONNECT api.example.com:443 HTTP/1.1\r\nHost: api.example.com:443\r\n\r\n

The proxy opens a TCP connection to api.example.com on port 443, and if all goes well, replies to the client:

HTTP/1.1 200 Connection established\r\n\r\n

From this moment on, the proxy becomes a dumb pipe. Everything the client sends next, the proxy forwards to the server byte for byte, and vice versa. And what does the client send next? The TLS ClientHello, the start of the handshake. Encrypted exchange. The proxy has no keys and physically cannot peek inside.

What this means for an observer with a dump

If you're capturing on the client or on the proxy, you'll see:

  • The TCP connection setup to the proxy (SYN, SYN-ACK, ACK).
  • The plaintext CONNECT request with the target hostname and port.
  • The proxy's response about the tunnel establishment status.
  • And then - only TLS records, an encrypted stream where the naked eye can only read handshake metadata.

Here's the key insight: the target hostname is always visible in the dump - in the CONNECT line. Even with zero decrypted bytes, you know exactly where the client was trying to go. This is invaluable for diagnostics: it immediately rules out the question of was the request even going to the right place.

TLS SNI: a second source of the hostname

Even if there were no CONNECT (say, with a direct connection without a proxy), the hostname is often visible in the SNI field inside ClientHello. Server Name Indication is transmitted in the clear at the start of the handshake. Wireshark displays it perfectly. In modern networks, Encrypted Client Hello is gaining traction, hiding SNI, but when working through a CONNECT tunnel this doesn't hinder diagnostics - the hostname has already been named in the CONNECT itself.

tcpdump in practice: capturing a dump without gigabytes

Time to get hands-on. tcpdump is a command-line packet capture utility available on almost any Unix-like system. It's powerful, lightweight, and indispensable on servers without a GUI. Let's walk through the key scenarios.

Basic capture on the right interface

First, list the interfaces:

tcpdump -D

Capture on a specific interface with output to the screen:

tcpdump -i eth0 -n

The -n flag disables name resolution so tcpdump doesn't lag on DNS lookups and shows clean IPs. This matters: real-time resolving distorts the picture and slows down the capture.

Filtering by host and port

Capturing all interface traffic on a loaded server is a surefire path to gigabytes of junk. Filter from the start. Capturing traffic to a specific proxy by IP and port:

tcpdump -i eth0 -n host 203.0.113.10 and port 8080

Capturing only to the target server (useful on the proxy side):

tcpdump -i eth0 -n host api.example.com and port 443

Combining: traffic to the proxy OR to the target server:

tcpdump -i eth0 -n "(host 203.0.113.10 and port 8080) or (host 198.51.100.5 and port 443)"

Watch the quotes: when the expression contains parentheses and logical operators, wrap the filter in quotes so the shell doesn't interpret the special characters.

Writing to a file and the correct format

For subsequent analysis in Wireshark you need a file in pcap format. The -w flag writes raw packets to a file:

tcpdump -i eth0 -n host 203.0.113.10 and port 8080 -w dump.pcap

A critically important point: -s 0 or the modern default captures the entire packet (snaplen). Old versions truncated packets. If you need complete data, make sure the snaplen is sufficient:

tcpdump -i eth0 -n -s 0 host 203.0.113.10 and port 8080 -w dump.pcap

If you only need headers for drop diagnostics (flags, seq, ack) and not the content, limit the snaplen to keep the file compact:

tcpdump -i eth0 -n -s 96 host 203.0.113.10 and port 8080 -w headers.pcap

File rotation: how not to fill your disk

During long diagnostics of an intermittent problem, the capture can run for hours. To avoid one monstrous file, use rotation by size and count. The -C flag sets the file size in megabytes, -W sets the number of files in the ring buffer:

tcpdump -i eth0 -n host 203.0.113.10 and port 8080 -w dump-%Y%m%d-%H%M%S.pcap -C 100 -W 10

This command creates up to ten files of one hundred megabytes each. When the tenth fills up, tcpdump starts overwriting the first. So you always keep roughly the last gigabyte of traffic and never overflow your disk. The time pattern in the filename makes the archive readable.

An alternative is time-based rotation. The -G flag sets the interval in seconds after which a new file is created:

tcpdump -i eth0 -n host 203.0.113.10 and port 8080 -G 3600 -w dump-%Y%m%d-%H%M%S.pcap

A new file every hour. Handy when you later need to quickly find the interval around the incident time.

Capturing around an event: catching a rare drop

The nastiest situation is a problem that reproduces once an hour, unpredictably. You start a ring buffer and wait. As soon as the app records an error, you note the exact time and stop the capture. Then in the analysis you jump to that second. A practical trick: have the app write the exact timestamp with milliseconds to the log on error - that's your anchor in the dump.

Filtering by TCP flags right in tcpdump

Sometimes it's useful to capture only packets with specific flags. For example, only packets with the RST flag, to immediately understand whether resets are flying around:

tcpdump -i eth0 -n "tcp[tcpflags] & tcp-rst != 0"

Only SYN packets - handy for tracking connection attempts:

tcpdump -i eth0 -n "tcp[tcpflags] & tcp-syn != 0"

A combination of RST or FIN for monitoring connection terminations to the proxy:

tcpdump -i eth0 -n "host 203.0.113.10 and (tcp[tcpflags] & (tcp-rst|tcp-fin) != 0)"

Wireshark: reading a dump like an open book

tcpdump catches, Wireshark reads. It's a graphical analyzer with a rich system of display filters and protocol decoders. You open the saved pcap file and begin the investigation. Let's go over the tools that really matter for our task.

Display filters versus capture filters

Don't confuse the two. A capture filter (the one in tcpdump) discards packets before they're written - what wasn't caught doesn't exist. A Wireshark display filter is a lens: it only hides the irrelevant from an already-loaded file without deleting anything. Their syntax differs. Below are display filters specifically.

Basic display filters

Show only traffic to a specific IP:

ip.addr == 203.0.113.10

Only the proxy TCP port:

tcp.port == 8080

A combination of host and port:

ip.addr == 203.0.113.10 && tcp.port == 8080

Show only packets with the RST flag - all connection resets become instantly visible:

tcp.flags.reset == 1

Only FIN packets:

tcp.flags.fin == 1

Only SYN without ACK - connection opening attempts:

tcp.flags.syn == 1 && tcp.flags.ack == 0

Finding CONNECT and HTTP headers

To find the CONNECT request itself in the dump:

http.request.method == "CONNECT"

The proxy's response about tunnel establishment appears as an HTTP response. Filter all HTTP requests:

http.request

All HTTP responses with status codes:

http.response

Follow TCP Stream: assembling the conversation as a whole

This is possibly the single most valuable Wireshark feature for our task. Right-click on any packet of a connection, then Follow, then TCP Stream. Wireshark will assemble the entire bidirectional exchange in one window, with client and server data shown in different colors. For unencrypted traffic you'll see plain text: the CONNECT request, the proxy's response, and then the unreadable TLS bytes.

It's precisely in Follow Stream that you visually see the break at CONNECT. The first lines read as human text, then the encrypted region begins. This confirms: the tunnel was established, encryption follows, and without keys you can't see any deeper - which is entirely normal.

Reading the TLS handshake without decryption

Even without keys, the TLS handshake tells you a lot. Filter the handshake records:

tls.handshake

Find ClientHello, where the client introduces itself to the server:

tls.handshake.type == 1

Find ServerHello, the server's response:

tls.handshake.type == 2

What does this pair tell you? If you see ClientHello but never see ServerHello - the server didn't respond to the handshake. The cause: either the target server is unreachable behind the proxy, or the drop happened before the response. If you see both but then a drop - the problem is deeper, in the encrypted exchange or at the application level.

Inside ClientHello you can read the SNI field without any decryption - the hostname being addressed:

tls.handshake.extensions_server_name == "api.example.com"

You also see the offered TLS versions and cipher suites. If the server responds with an Alert instead of ServerHello, the handshake was rejected - for example, a version or cipher mismatch. Filter for alerts:

tls.alert_message

Dump-based diagnostics: who exactly tore the connection down

We've reached the heart of the article. The connection dropped - the question is who broke it and why. TCP leaves evidence, and from that evidence you can render a verdict. Let's go over the key signals.

Normal termination: FIN

A graceful connection close happens through the exchange of FIN packets. One side says I'm done sending, the other acknowledges and also sends FIN. This is a polite goodbye. If in the dump you see a tidy FIN-ACK-FIN-ACK exchange, the connection closed correctly. The only question is whether your client expected that close. If the server sent FIN after delivering the full response, all is well. If FIN arrived in the middle of expected data - the server closed early.

Abrupt termination: RST

The RST flag is a rude cutoff. Not a goodbye, but a door slam. RST means: this connection is invalid, forget about it immediately. The causes vary:

  • The port is closed - nobody is listening on the other side. RST arrives almost immediately after SYN.
  • The application on the other side closed the socket abruptly.
  • An intermediary device (firewall, load balancer, the proxy itself) forcibly reset the connection due to a timeout or policy.
  • One of the sides received a packet for a connection it had already forgotten about.

The key to solving it is who sent the RST. Look at the source IP of the packet with RST. If the RST came from the proxy's IP - the proxy or something between the proxy and you tore it down. If from the target server's IP - then the proxy-server segment reached the server, and the server or a device next to it dropped it.

But remember the two segments. Capturing on the client, you'll only see RST from the proxy's IP, because you don't talk to the server directly - the proxy sits between you. To understand what's happening in segment B, you need a dump on the proxy side. We'll cover that in the checklist section.

Retransmissions

Wireshark automatically marks retransmissions. Filter:

tcp.analysis.retransmission

A retransmission means the sender didn't receive an ACK for a sent segment in time and is sending it again. Occasional retransmissions are normal for the internet. But an avalanche of retransmissions is a symptom of packet loss along the path. Particularly characteristic of mobile and unstable networks.

Related useful filters. Duplicate ACKs, signalling a missing segment:

tcp.analysis.duplicate_ack

All problem events Wireshark managed to recognize:

tcp.analysis.flags

If you see a series of retransmissions followed by RST, the picture comes together: packets were getting lost, one side got tired of waiting and tore down the connection. This is a classic story for a bad channel.

Zero Window: the receiver choked

TCP has a flow control mechanism via the receive window. If the receiver can't keep up with processing data, it announces zero window - buffer full, slow down. Filter:

tcp.analysis.zero_window

Zero window is not packet loss, but a signal that the receiving application is slow to read from the socket. For example, your client receives a large response but processes it on a single thread and can't keep up. The sender waits, the window doesn't open, and eventually a timeout may trigger. If a window update follows zero window, everything normalized. If zero window is followed by silence and then RST - the receiver hung or crashed.

A related signal is window full, when the sender has bumped against the announced window and can't send further:

tcp.analysis.window_full

Verdict matrix

Let's assemble the logic into a practical framework. Look at the last packets of the live connection before the drop:

  • SYN present, no SYN-ACK, then RST or silence. The connection didn't establish. The target point is unreachable or the port is closed. When working through a proxy, RST comes from the proxy if the server behind it is unreachable.
  • Setup succeeded, CONNECT sent, no response. The proxy accepted the command but couldn't reach the target server, or the server is silent. Expect a timeout.
  • ClientHello present, no ServerHello. The target server didn't respond to the handshake. The problem is in the proxy-server segment.
  • Data flowed, then RST from the server. The server abruptly closed the connection - overload, application error, timeout on its side.
  • Data flowed, then FIN from the server in the middle of the response. The server closed gracefully but earlier than the client expected - likely a response size limit or a request timeout.
  • Avalanche of retransmissions, then RST. Channel loss. Look for the problem in the network - mobile connection, congested route.
  • Zero window, then silence. Your client wasn't reading data fast enough. The problem is on your side in the processing.

Decrypting your own traffic via SSLKEYLOGFILE

Sometimes metadata alone isn't enough - you need to see the contents of the encrypted exchange. This is legal and proper only when the traffic is your own: your client, your keys, your app. We don't intercept anyone else's data or swap certificates. We ask our own client to kindly write session keys to a file, so we can then feed them to Wireshark.

How it works

Many client TLS libraries support the SSLKEYLOGFILE environment variable. If it's set, the library appends session secrets to the specified file in a standard format. Wireshark can read that file and decrypt the corresponding sessions in the dump. No magic and no hacking - the client voluntarily hands over its keys, because you, the client's owner, decided so.

Example for the command line and browsers on supporting engines

Setting the variable before launching the app on a Unix-like system:

export SSLKEYLOGFILE=/home/user/tls-keys.log

Launching a client such as curl that supports this variable when built with a suitable library:

SSLKEYLOGFILE=/home/user/tls-keys.log curl -x http://203.0.113.10:8080 https://api.example.com/status

Here the -x flag sets the Proxeon proxy, and SSLKEYLOGFILE forces the session keys to be written. In parallel, you capture a dump via tcpdump. After that you have both the pcap and the key file.

Connecting keys in Wireshark

In Wireshark, open the settings, find the TLS protocol section, and specify the path to the key file in the pre-master-secret log file field. Then re-read the dump. The previously unreadable TLS records become decrypted: you'll see the actual HTTP requests and responses inside the tunnel. Now Follow TLS Stream shows the full application-level exchange.

Important limits of applicability

  • Only traffic whose keys landed in the file gets decrypted. Other people's sessions stay encrypted - and rightly so.
  • The keys are sensitive. The tls-keys.log file effectively opens up the contents of your sessions. Treat it as a secret, delete it after debugging.
  • The method is intended for debugging your own applications, not for observing someone else's traffic. This is a fundamental ethical and legal boundary.

Typical drop scenarios and how to read them

Theory without recognizable patterns evaporates quickly. Let's go over several characteristic scenarios you'll encounter again and again. Learn to recognize them at a glance.

Connect timeout: the server behind the proxy is unreachable

The picture in the dump on the client: TCP to the proxy established normally, the client sent CONNECT, and then silence. There's no 200 response from the proxy. After a while either RST comes from the proxy, or the app closes the connection by its own timeout.

What this means: the proxy accepted your command, tried to open segment B to the target server, but it didn't respond. The target server is down, the port is closed, or the route to it is broken. Your side and the proxy are working fine. Action: check the reachability of the target host, and if needed capture on the proxy side to see segment B.

Drop in the middle of a response

The picture: the tunnel is established, TLS completed, data started flowing, part of the response was received, and then suddenly FIN or RST from the server side. The client got an incomplete response and is complaining about truncated content.

If it's FIN, the server closed gracefully but prematurely - perhaps a response generation time limit or a size restriction on its side kicked in. If it's RST, the server or a device next to it dropped it abruptly. Action: if the problem repeats on large responses - look for timeouts and limits. Decrypting your own traffic through SSLKEYLOGFILE will help you see whether the HTTP header was received and how much of the body made it.

Loss in a mobile network

The picture: many packets marked as retransmission, duplicate ACKs appear, noticeable time gaps between packets. The connection is either painfully slow or eventually dies by timeout.

This is a classic of an unstable radio channel. Packets get lost, TCP resends them, speed drops. Mobile networks also tend to break long-idle connections via NAT timeouts on the carrier's intermediary gear: in the middle of silence an RST suddenly flies in when one side tries to resume the exchange on a connection the carrier has already forgotten. Action: set sensible keep-alives and timeouts, application-level retries, and don't hold long-idle connections.

The proxy is unreachable entirely

The picture: the client sends SYN to the proxy's IP and port but doesn't get a SYN-ACK. Either silence with SYN retransmissions, or an immediate RST. If silence - something between you and the proxy is filtering packets, or the proxy isn't listening. If an immediate RST - nobody is responding on that port. Action: verify the proxy address and port, network reachability, and configuration correctness.

Slow client: zero window

The picture: the exchange is going, but periodically the client announces zero window, the sender pauses, then a window update resumes the flow. If this repeats often, your app is reading from the socket slower than the server delivers. Action: optimize response processing, read the stream on a separate thread, increase buffers.

Common mistakes when capturing and reading a dump

Experience is a collection of bumps and bruises. Let's gather the most common mistakes so you don't repeat them.

  • Capturing in the wrong place. You're hunting a drop in the proxy-server segment, but captured on the client, where that segment isn't visible at all. Always think about which segment you need and capture at the right point.
  • Capturing everything indiscriminately. Without a filter on a loaded server you'll get gigabytes and drown in them. Filter by host and port from the start.
  • Truncated snaplen where you need data. If you want to see content but set a short snaplen, the payload gets truncated and Follow Stream shows fragments.
  • Name resolution enabled. You forgot the -n flag, and tcpdump lags on DNS, distorting timings. Always -n when capturing.
  • Ignoring the direction of RST. Someone sees RST and draws a conclusion without checking who sent it. The source IP of the RST packet is half the answer.
  • Confusing a normal FIN with a failure. FIN is a normal close. You should panic not at the FIN itself but at a FIN that arrived before the expected end of data.
  • Forgetting time zones and exact time. App logs and the dump must be time-synchronized, otherwise you won't find the right moment. Keep NTP in order.
  • Keeping the SSLKEYLOGFILE. After debugging it must be deleted. It's a secret that exposes the contents of your sessions.
  • Drawing conclusions from a single connection. Intermittent problems require statistics. One failed request may be a coincidence, a pattern of a dozen is a diagnosis.

Engineer's tools and resources

Let's assemble the arsenal worth having at hand when working with proxy traffic.

Capture

  • tcpdump - the primary capture tool on servers and in the console. Lightweight, always available, flexible filtering.
  • dumpcap - the console utility from the Wireshark suite, purpose-built for efficient capture with rotation.
  • tshark - the console Wireshark. Lets you apply display filters without a GUI, handy for scripts and remote servers.

Analysis

  • Wireshark - the graphical analyzer, decoders for hundreds of protocols, a powerful filter system, Follow Stream, connection statistics.
  • Wireshark's Expert Information - a built-in panel highlighting anomalies: retransmissions, resets, zero window. Start your investigation right there.
  • Conversation statistics - a table of all TCP connections in the dump with bytes and duration. You quickly spot which connection is anomalously short.

Handy command-line techniques

Quickly peek at a pcap's contents in the console via tshark with a display filter:

tshark -r dump.pcap -Y "tcp.flags.reset == 1"

Output only CONNECT requests from a file:

tshark -r dump.pcap -Y "http.request.method == \"CONNECT\""

Show all retransmissions:

tshark -r dump.pcap -Y "tcp.analysis.retransmission"

These commands are invaluable when there's no GUI but you have to figure things out here and now, over ssh.

Cases and results in practice

Nothing convinces better than real stories. Here are composite cases reflecting real engineering practice in diagnosing proxy traffic.

Case 1: five percent of requests fail at night

The integration team complained: about five percent of requests to an external API through the proxy failed with a truncated response, mostly at night. App logs showed incomplete content. Proxy logs showed established tunnels with no errors.

They captured on the client with ring rotation for several hours and the exact error marker from the log. At the moment of the incident they saw: the tunnel established, TLS completed, part of the response body arrived, then FIN from the proxy. Decrypting their own traffic through SSLKEYLOGFILE showed the correct HTTP header with the body size, but the body was cut off in the middle. Conclusion: the target server was closing the connection due to its own generation timeout for large nightly reports. The fix on the integration side - request data paginated in smaller chunks. The problem disappeared entirely.

Case 2: a mysterious instant RST

Another engineer got an instant reset right after sending CONNECT for one specific host, while everything worked for other hosts. The first suspicion fell on the proxy.

The dump on the client showed: CONNECT went out, and almost instantly an RST came back from the proxy's IP. But the instantaneity was suspicious - usually an unreachable server yields a timeout, not an instant reset. They captured on the proxy side and saw segment B: the proxy was opening a connection to the target host on the required port, and the target server was responding with RST to SYN - the port was closed. The proxy honestly relayed that refusal to the client. It turned out the target service had recently changed its port. Conclusion: an instant RST is most often a closed port, not a proxy problem. The correct port restored the work.

Case 3: degradation in the mobile segment

An app on mobile devices working through a proxy regularly lost its connection for some users. The dump from the device in a spotty coverage area showed the classic picture: series of retransmissions, duplicate ACKs, growing intervals, and finally RST after a long idle - the result of the carrier's NAT timeout.

Conclusion: the network, not the proxy and not the server. The fix was at the application level - adaptive retries, sensible keep-alives, and graceful handling of breaks with connection re-establishment. The number of user-visible errors dropped severalfold, even though the radio channel itself stayed the same. The packet dump let them avoid wasting time on false hypotheses about the proxy and focus on the real cause.

The common insight from the cases

In all three stories the dump saved weeks of back-and-forth and mutual accusations between teams. Packets don't lie. As soon as a dump appears on the table with the direction of RST, the presence or absence of ServerHello, and the retransmission picture, the argument about who's to blame wraps up in minutes. That's the core value of the method: it moves diagnostics from the plane of opinions to the plane of facts.

Checklist for capturing a dump to submit to support

When you contact support - whether it's the Proxeon proxy provider or the owner of the target API - a competently captured dump speeds up resolution severalfold. Here's a checklist to complete before reaching out.

Before capture

  • Note the exact start time of diagnostics and sync the clocks via NTP on all machines involved.
  • Determine your capture points: at minimum on the client, and if possible on any side where you have access.
  • Gather the inputs: proxy IP and port, target hostname and port, expected versus actual behavior.

During capture

  • Launch tcpdump with a filter by proxy host and target port, with full snaplen and rotation: 
    tcpdump -i eth0 -n -s 0 "host 203.0.113.10 and port 8080" -w support-%Y%m%d-%H%M%S.pcap -C 100 -W 10
  • Reproduce the problem and record the exact incident time with milliseconds from the app log.
  • Don't forget to save the app logs for the same interval.

What to attach to your request

  • The pcap file itself, trimmed to the relevant time interval so you don't send gigabytes.
  • Exact incident timestamps and the time zone.
  • Proxy IP and port, target hostname and port, scenario description.
  • The fragment of app logs with the error.
  • Your preliminary analysis: who sent RST or FIN, whether ServerHello was present, whether retransmissions were observed. This shows you did your homework.

How to trim a pcap to the right interval

A huge file can be sliced by time via tshark or editcap. Example of cutting by packet number or by filter:

tshark -r big.pcap -Y "frame.time >= \"2026-01-01 03:00:00\" && frame.time <= \"2026-01-01 03:05:00\"" -w small.pcap

Support will process such a tidy, focused dump quickly, because it won't have to search for a needle in a haystack.

FAQ: common questions about dumps through a proxy

Why do I only see CONNECT in a dump of HTTPS traffic through a proxy, and then unreadable data?

Because after the tunnel is established, the proxy merely forwards encrypted TLS bytes without having the keys. Only the CONNECT command with the hostname and the proxy's response about establishment go in the clear. Everything else is protected by encryption - which is exactly why HTTPS exists. To see the contents of your own traffic, use SSLKEYLOGFILE.

How can I tell that the target server dropped the connection, not the proxy?

Look at the source IP of the packet with RST or FIN. But remember the two segments: on a client-side dump you only see the proxy's IP, because you don't talk to the server directly. To definitively attribute the drop to the target server, you need a dump on the proxy side, where the proxy-server segment is visible. If the RST in segment B arrives from the server's IP - the server dropped it.

How does retransmission differ from RST in diagnostic meaning?

A retransmission is a resend of an unacknowledged segment, a sign of packet loss in the channel, but the connection is still alive and fighting. RST is termination, an order to forget the connection. An avalanche of retransmissions transitioning into RST reads as: the channel was losing packets, the side got tired of waiting and tore the connection down. Occasional retransmissions are normal for the internet.

What does zero window mean, and is the proxy to blame?

Zero window is announced by the receiver whose receive buffer is overflowing, because the application is too slow

About the Author

Andrey Kokh

Andrey Kokh

Leading Expert and Business Consultant

Work Experience: Leading expert with 12 years of experience. Consults Forbes-listed companies, author of 3 books. Teaches at HSE and SKOLKOVO. His methodologies are used by hundreds of companies across Russia. RBC and Forbes expert on strategic development and digital transformation.
Education: Higher School of Economics. Faculty of Economics, Master's Program
Expertise:
Strategic Consulting Digital Transformation Change Management Business Strategy Innovation Management Organizational Development Lean Management Agile Transformation

Share this article: