Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

If I use this filter in Wireshark: http.request.method == "POST" and use the vote buttons to vote for a stack exchange question, then Wireshark captures the corresponding POST request. I can also see in Chromes debugger that the request is a POST.

However, on another site that I'm trying to examine, when I click on a form button that triggers a POST (and Chromes debugger confirms that it is a POST) then Wireshark captures nothing.

Why might this be?

Thanks for all the tips. Utimately, I did get to examine a POST sent from my webserver using Fiddler, and it did help me out. I didn't mention it, but my webserver is Jetty running locally on Ubuntu, and I'm using Apache HttpClient for handling requests. For Java, if your not using HttpClient, this question is helpful. If you are, then check this question out.

In either case, Fiddler still needs to be setup to monitor HTTPS connections by checking the option at Tools --> Fiddler Options --> HTTPS --> Capture HTTPS CONNECTs

share|improve this question
up vote 8 down vote accepted

HTTPS encrypts the contents of the message from anyone snooping on the wire - which is exactly what you are doing - so it's working as intended. Anyone doing packet captures anywhere between the browser and webserver just see encrypted traffic.

Wireshark isn't the best tool for analysing HTTPS traffic. For that, you can use the debugger built into the browser, or something like Fiddler, which runs as a proxy server on your machine and decrypts HTTPS traffic.

Fiddler does this by sitting in the middle - the webserver is having an HTTPS conversation with Fiddler, and your browser is having an HTTPS conversation with Fiddler. But Fiddler is able to decrypt both connections. This will of course throw up scary invalid certificate warnings unless you add Fiddler's CA certificate to your browser/OS.

Wireshark WILL work if you have the SSL private key file. So if you are on the webserver end of things, load your SSL private key into Wireshark and it will decrypt the traffic for you. This only works if you have access to the private key - you won't be able to decrypt traffic to/from stackexchange this way, but you can use it for web servers you control.

Now that you've clarified the traffic is from your webserver to a third party, I have another option for you, if you are on Linux or Mac: mitmproxy

Either fiddler or mitmproxy should be able to do the man in the middle decryption for you. The tricky part is getting the data to pass through the proxy. On linux this is relatively easy using iptables - the mitmproxy gives setup instructions for that. On both windows and linux you should be able to use Apache's mod_proxy ProxyRemote settings to direct traffic to your proxy server.

share|improve this answer
Is it possible to configure Fiddler to intercept requests sent from a webserver running on my machine, or does it only work with requests from browsers? – RTF Aug 13 '14 at 18:28
@RTF added advice if you are on the webserver side of things. – Grant Aug 13 '14 at 18:37
The request that I want to debug is actually being sent from a webserver that I do own to a HTTPS server that I don't own. Does that mean that the traffic is encrypted using the destination servers public key, and since I don't have their private key, I can't use Wireshark? – RTF Aug 13 '14 at 18:44
@RTF more options added. – Grant Aug 13 '14 at 19:14
And with the proxy approach, one should disable certificate checking in the client that makes the HTTPS connection to the server, otherwise the connection won't work at all. – Tero Kilkanen Aug 13 '14 at 19:53

It might be because the other side is using HTTPS.

share|improve this answer
It is using HTTPS, I just realized that. It seems I can't analyse the POST request then because I don't own the HTTPS server – RTF Aug 13 '14 at 18:17

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.