Migrating from Varnish

Andrei lagged at gmail.com
Thu Nov 23 16:24:19 UTC 2017

Hello Maxim!

On Nov 23, 2017 17:55, "Maxim Dounin" <mdounin at mdounin.ru> wrote:


On Thu, Nov 23, 2017 at 09:00:52AM -0600, Andrei wrote:

> Hi all,
> I've been using Varnish for 4 years now, but quite frankly I'm tired of
> using it for HTTP traffic and Nginx for SSL offloading when Nginx can just
> handle it all. One of the main issues I'm running into with the transition
> is related to cache purging, and setting custom expiry TTL's per
> zone/domain. My questions are:
> - Does anyone have any recent working documentation on supported
> modules/Lua scripts which can achieve wildcard purges as well as specific
> URL purges?

Cache purging is available in nginx-plus, see

I'm aware of the paid version, but I don't have  a budget for it yet, and
quite frankly this should be a core feature for any caching service. Are
there no viable options for the community release? It's a rather pertinent
feature to have in my transition

> - How should I go about defining custom cache TTL's for: frontpage,
> dynamic, and static content requests? Currently I have Varnish configured
> to set the ttl's based on request headers which are added in the config
> with regex matches against the host being accessed.

Normal nginx approach is to configure distinct server{} and
location{} blocks for different content, with appropriate cache
validity times.  For example:

    server {
        listen 80;
        server_name foo.example.com;

        location / {
            proxy_pass http://backend;
            proxy_cache one;
            proxy_cache_valid 200 5m;

        location /static/ {
            proxy_pass http://backend;
            proxy_cache one;
            proxy_cache_valid 200 24h;

Note well that by default nginx respects what is returned by the
backend in various response headers, and proxy_cache_valid time
only applies if there are no explicit cache validity time set, see

So to override the ttls set by the backend, I would have to use
proxy_ignore_headers for all headers which can directly affect the intended

Thank you for your time!

Maxim Dounin
nginx mailing list
nginx at nginx.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20171123/022ce103/attachment-0001.html>

More information about the nginx mailing list