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

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?

share|improve this question

migrated from Jan 21 '11 at 9:03

This question came from our site for professional and enthusiast programmers.

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
share|improve this answer

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.

share|improve this answer

Your Answer


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