We have Varnish as our load balancer and reverse proxy cache for normal HTTP traffic. For HTTPS traffic, we use Pound proxy to unwrap the SSL and forward to Varnish, which then forwards to the back-end servers. This is used for our "checkout" process to encrypt credit card info in transition. However, on the last stage of checkout, users are always getting an HTTP 500 (Internal Server) error. It doesn't seem to be due to our back-end app server, by all tests I've tried. Does anyone know anything about how that transition works-- the transition back from HTTPS to HTTP and the interaction between Pound and Varnish-- and why it might cause 500 errors?


The first thing to do is to see if Varnish sees the 500. If it does, it's either Varnish's fault or the fault of your backend. If it doesn't, you can concentrate on troubleshooting Pound.

To see what Varnish is doing when you're getting 500s, use varnishlog:

varnishlog -co TxStatus 500

What does the pound log indicate when you get the 500?

Are you using cookies for the checkout, and do you know how much data is being saved in the cookie? Can you check if the cookie is being truncated when you receive the 500, because pound is strict about the maximum size of cookies allowed, although this has varied according to the version of pound. You may want to check for the cookie size easily by simply not using the proxies.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy