Drupal 7 can be used with Varnish and other reverse proxy servers if configured correctly. This blog post highlights how you can control your cache with Drupal, the Varnish module and the Cache Actions module.
Using a reverse proxy cache is an efficient way to cache your web site in order to get faster response times. Drupal 7 works with reverse proxy cache servers like Varnish out of the box and the integration can be extended by using the Varnish module. I'm going to show you how the integration works in this blog post.

We put almost all of our Drupal sites behind the excellent Varnish HTTP accelerator, and it gives us a massive performance boost for most site visitors. However it seems to have a tendency to crash without warning and occasionally just dies, leaving our sites down.

We workaround this issue by using another piece of useful kit, called Monit, that keeps an eye on processes on your server and restarts them if necessary.

Installing and configuring Monit is really simple (these instructions are for a Debian based server):

There are a lot of places, where you need client's IP address in Drupal (or any other CMS/web app of course). The problem arises, when you use a reverse proxy server (like Varnish), since every request to web server will be done by the latter. We will have every single visitor of our website coming from a single IP (reverse proxy), as a result.

Drupal is smart enough to overcome that. Reverse proxy servers can be configured to forward original client IP in a request header (usually X-Forwarded-For). This value can be used on web server to know where our visitory come from. In Drupal we have function ip_address(), which will read and return client's IP. If we take a look at this function's code, we can see that it already has support for situations, where reverse proxy is used. This function will still return Varnish's IP address by default, though.

Varnish is an amazing and incredibly efficient tool for serving up common resources from your site to end-users. Besides simply making your site faster, it also can add additional redundancy to your setup by acting as a full backup if the web servers fail. In order to make Varnish both serve as an effective backup and efficient caching layer, it needs to clean up incoming headers from the browser, strip down cookies, and consolidate the "Accept-Encoding" header.
After such extensive explanations it's easy to get overwhelmed, but the good news is that the VCL file provided here can quickly be deployed to almost any Drupal site and start working immediately. For most sites no further customization is needed, and sites that need to tweak it will have a good head start towards huge reductions in server load. On our sites, Varnish is usually able to handle about 85% of the traffic without ever touching the web servers. Even during peak times with hundreds of thousands of requests coming in per hour, Varnish can hum along at less than 5% CPU usage of an average 4-core server. Instead of scaling out your web servers horizontally, adding a few Varnish machines in front of them can save a huge amount of processing and speed up your site at the same time.
If you haven't already, grab the actual default.vcl file that we use on our sites and read it through start to finish. Now with all of the individual pieces explained in-depth above, we hope you can use it as a starting point for your own VCL configuration. Happy caching!

The default Varnish config for Pressflow by Four Kitchens is an excellent starting point and gets you up and running with relatively little pain and effort. Having done a fair amount of Varnish tweaking for my personal and work websites, I came across a couple of varnish tweaks that resulted in a phenominal improvement in Varnish Hit rate.