Varnish 4 Working Config (optimized) for Wordpress (default.vcl)

Question

I have successfully set up varnish 4 on my nginx 1.6.2 it is working but as per the test on

http://www.isvarnishworking.com/

it shows

Varnish appears to be responding at that url, but the Cache-Control header's "max-age" value is less than 1, which means that Varnish will never serve content from cache at this url.

The max-age value appears to be: 0

This may be intentional, but if you want Varnish to cache this url you'll have to fix the max-age value the application is sending to Varnish.

That means it is not working but not as expected and searched for config files for it but due to huge changes in version 4 of varnish those config files are not working.

Please help me guys.

Thanks

Answer 1

Resurrecting an old post, I know, but wanted to put this here for anyone that comes across the same issue.

First you're going to want to drop cookies for users that aren't logged in. Here's a section from my vcl_recv sub:

sub vcl_recv {
    # Some wordpress URL manipulation
        if (req.url ~ "\?(utm_(campaign|medium|source|term)|adParams|client|cx|eid|fbid|feed|ref(id|src)?|v(er|iew))=") {
            set req.url = regsub(req.url, "\?.*$", "");
        }

        # Pass if the page is login, admin, preview, search or xmlrpc
        if (req.url ~ "wp-(login|admin)" || req.url ~ "preview=true" || req.url ~ "\?s=" || req.url ~ "xmlrpc.php") {
            return (pass);
        }

        # Some generic URL manipulation, useful for all templates that follow
        # First remove the Google Analytics added parameters, useless for our backend
        if (req.url ~ "(\?|&)(utm_source|utm_medium|utm_campaign|utm_content|gclid|cx|ie|cof|siteurl)=") {
            set req.url = regsuball(req.url, "&(utm_source|utm_medium|utm_campaign|utm_content|gclid|cx|ie|cof|siteurl)=([A-z0-9_\-\.%25]+)", "");
            set req.url = regsuball(req.url, "\?(utm_source|utm_medium|utm_campaign|utm_content|gclid|cx|ie|cof|siteurl)=([A-z0-9_\-\.%25]+)", "?");
            set req.url = regsub(req.url, "\?&", "?");
            set req.url = regsub(req.url, "\?$", "");
        }

        # Strip hash, server doesn't need it.
        if (req.url ~ "\#") {
            set req.url = regsub(req.url, "\#.*$", "");
        }

        # Strip a trailing ? if it exists
        if (req.url ~ "\?$") {
            set req.url = regsub(req.url, "\?$", "");
        }

        # Remove the wp-settings-1 cookie
        set req.http.Cookie = regsuball(req.http.Cookie, "wp-settings-1=[^;]+(; )?", "");

        # Remove the wp-settings-time-1 cookie
        set req.http.Cookie = regsuball(req.http.Cookie, "wp-settings-time-1=[^;]+(; )?", "");

        # Remove the wp test cookie
        set req.http.Cookie = regsuball(req.http.Cookie, "wordpress_test_cookie=[^;]+(; )?", "");

        # Remove the cloudflare cookie 
        set req.http.Cookie = regsuball(req.http.Cookie, "__cfduid=[^;]+(; )?", "");

        # Remove the PHPSESSID in members area cookie 
        set req.http.Cookie = regsuball(req.http.Cookie, "PHPSESSID=[^;]+(; )?", "");

        # Remove the Quant Capital cookies (added by some plugin, all __qca)
        set req.http.Cookie = regsuball(req.http.Cookie, "__qc.=[^;]+(; )?", "");

        # Are there cookies left with only spaces or that are empty?
        if (req.http.cookie ~ "^\s*$") {
            unset req.http.cookie;
        }

        #Drop ALL cookies sent to WordPress, except those originating from the URLs defined.
        if (!(req.url ~ "(wp-login|wp-admin|cart|my-account|checkout|addons|wordpress-social-login|wp-login\.php|forumPM|members)")) {
            unset req.http.cookie;


        }
}

Also in your backend response you want to drop cookies if you're not logged in. You also need to instruct varnish to set the TTL for the beresp so Age doesn't always show 0.

sub vcl_backend_response {

  if (!(bereq.url ~ "(wp-(login|admin)|login)")) {
    unset beresp.http.set-cookie;
  }

  set beresp.ttl = 1h;

  return (deliver);
}

That's the basics.

Answer 2

The solution to this does not lie in configuration Varnish correctly. That's a bit too strong a statement—you could fix this in Varnish. But you shouldn't.

The issue is that WordPress is sending up a header that is preventing Varnish from caching the object it's delivering. You'll need to track down where in WordPress this header is being generated, and modify, disable, or override it.

Answer 3

By default, WordPress sends every visitor a Cookie, which makes Varnish think that every visitor is unique, and therefore shouldn't be cached.

To get any benefit out of Varnish, you'll need to override this behaviour, and 'unset' or 'remove' the cookies as the HTTP request enters Varnish.

There's a lot written online about this, and plenty of Varnish VCL files and examples, one of which you can find here: https://www.varnish-cache.org/trac/wiki/VCLExampleTemplateWordpressNopurge

Good luck!