Install Varnish Proxy Server in cPanel/WHM

Varnish is a forward-proxy caching solution for dedicated servers. It sits in front of the main webserver Apache and handles all incoming requests first.

If a new request comes in, it passes it to the Apache web server, waits for the code to be processed, and then both serves the content as well as caches it.

If the request has already been cached, the content is served without the passing any data to the backend, saving a huge amount of CPU and a moderate amount of RAM.

You can follow below steps to install and setup Varnish Cache as a frontend reverse proxy to your webserver.

# yum -y install epel-release;
# rpm -ivh http://repo.varnish-cache.org/redhat/varnish-4.0.el6.rpm [CentOS/RHEL 6]
# rpm -ivh http://repo.varnish-cache.org/redhat/varnish-4.0.el7.rpm [CentOS/RHEL 7]
# yum -y install varnish;

Make sure to enable varnish service to start at boot.

# chkconfig varnish on [CentOS/RHEL 6]
# systemctl enable varnish [CentOS/RHEL 7]

Set the Varnish port in /etc/sysconfig/varnish:

Set the backend port in /etc/varnish/default.vcl. If you are using just Varnish+Apache, this is the Apache port. If you are using Varnish+Apache, this is the Nginx port.

backend default {
.host = "127.0.0.1";
.port = "81";
}

Set the Apache port in /var/cpanel/cpanel.config. If you are using just Varnish+Apache, this would be 8080. If you are using Varnish+Nginx+Apache, this would be 81.

Update settings and restart services:

# /usr/local/cpanel/scripts/restartsrv_cpsrvd
# /etc/init.d/httpd restart [CentOS/RHEL 6]
# systemctl restart httpd.service [CentOS/RHEL 7]
# /etc/init.d/varnish restart [CentOS/RHEL 6]
# systemctl restart varnish.service [CentOS/RHEL 7]

There are many additional settings to define in /etc/varnish/default.vcl beyond what you already added but these can be very custom depending on the CMS so try Googling around for your Drupal-specific optimized VCLs – Be sure to include the Varnish version or the syntax won’t work!

You’re almost done. If you plan on using multiple dedicated IPs, now is the point where you add every additional backend to /etc/varnish/default.vcl. Copy the same block from before and change the IP from 127.0.0.1 to each IP on the server you need. Restart the service again when finished.
Troubleshooting

Here are a few tools and one-liners for logging, statistics, and a good direction when your setup won’t start up.

# varnishlog

Live feed of the Varnish log. What you are watching for here is ‘c’ vs. ‘b’ in the third column, which each stand for ‘cache’ and ‘backend’, respectively. Mash F5 and you should see consistent ‘c’ hits. Add some nonsense in the site’s search bar, for example, and you should see ‘b’ hits included in the output. Useful for ensuring both are being routed.

# varnishstat

Very useful tool for analyzing how efficinet the cache is. Similar to the MySQL tuner/primer, this shows hit/miss percentages and many other statistics for optimization.

# varnishd -C -f /etc/varnish/default.vcl 

Syntax check. If this outputs several hundred lines of C code, you know you’re okay. Otherwise, this will give you the specific line that errors out.

# varnishadm "ban req.url ~ /"

This clears the cache so the next reload of the page should show nothing but ‘b’ hits. In the VCL syntax, ‘ban’ is synonymous with discarding the cache. So basically it’s the regex for “Kill everything that matches /”.

# varnishtop -i txurl 

Sort of a “top -c” live feed to see the top hits to the frontend. Not a hugely universal tool but potentially useful.