Configurando o cabeçalho HTTP "Expires" para conteúdo estático servido do Nginx?

Eu prefiro fazer um cabeçalho de cache mais completo, além de mais algumas extensões de arquivo. O '?' prefixo é uma marca de 'não captura', o nginx não criará um $1. Ajuda a reduzir a carga desnecessária.

location ~* \.(?:ico|css|js|gif|jpe?g|png)$ {
    expires 30d;
    add_header Pragma public;
    add_header Cache-Control "public";
}

server {
    ...

    location ~* \.css$ {
       expires 30d;
    }
    ...
}

A locationdiretiva

A expiresdiretiva

Não tenho reputação suficiente para comentar por que a resposta aceita faria com que os arquivos não aparecessem mais, mas descobri e gostaria de ajudar!

Versão curta:

Certifique-se de ter um diretório raiz especificado para o seu bloco de localização nas imagens, se você não tiver um conjunto global!

Versão longa abaixo:

Em primeiro lugar, meu método de implementação desta solução foi muito semelhante a this answer , onde você escreve a regra (como na resposta aceita):

location ~* \.(?:ico|css|js|gif|jpe?g|png)$ {
    expires 30d;
    add_header Pragma public;
    add_header Cache-Control "public";
}

em um arquivo img-cache.conf

e, em seguida, inclua esse arquivo em sua server {...}diretiva.

Meu exemplo de somesite.com na minha pasta sites-available:

 #Image Caching
 include /etc/nginx/conf/img-cache.conf;

Dessa forma, você pode adicionar o bloco de localização de cache de imagem a vários sites que possa estar executando.

Em segundo lugar, eu tenho uma situação em que meu /var/www/ contém duas pastas que eu permito como public_html - segura e treinamento, então eu tenho que fazer blocos de localização específicos na diretiva do servidor do meu site, destacando essas pastas.

Como tal, não tenho um diretório raiz global definido .

Então, quando você faz seus blocos de localização de imagem, você pode não estar fornecendo a eles um diretório raiz para procurar as imagens!

Minha solução foi então:

location ~ ^/training.+\.(?:ico|css|js|gif|jpe?g|png)$ {
        root /var/www/;
        expires 7d;
        add_header Pragma public;
        add_header Cache-Control "public";
        try_files $uri 404;
}

location ~ ^/.+\.(?:ico|css|js|gif|jpe?g|png)$ {
        root /var/www/secure;
        expires 7d;
        add_header Pragma public;
        add_header Cache-Control "public";
        try_files $uri 404;
}

Você também pode definir as expirações para o máximo. Aqui está a diretiva que eu uso para css e js.

# Set css and js to expire in a very long time
location ~* ^.+\.(css|js)$ {
    access_log off;
    expires max;
}

Todas as soluções mencionadas negarão a possibilidade de ter diferentes aliases para diferentes caminhos. Além disso, para ter todas as expirações de cache diferentes em um só lugar, você deve usar o mapa nginx da seguinte maneira.

...

# Expires mappings
map $sent_http_content_type $expires {
    default                    off;
    text/html                  epoch;
    text/css                   max;
    application/javascript     7d;
    ~image/                    max;
}

...

server {
   listen ...;

   expires $expires;
   location /assets/ {
      # It is now possible to serve some resources from different path
      alias /var/www/my_other_path/
   }

   # and have them all have same expirations
   location / {
       try_files $uri $uri/ /index.html;
   }
...
}

Offdesabilita o cache, epoch(para unix epoch) resulta em recurso sempre sendo buscado novamente, maxdefine a data para o valor máximo do navegador.

O ~image/ corresponde a qualquer tipo de imagem.

Mais sobre mapas nginx em http://nginx.org/en/docs/http/ngx_http_map_module.html .

Se você tiver um lugar que abriga todos os seus arquivos estáticos, algo assim funcionará ...

 location /static {
            your/location/to/static/files/static;
            expires 30d;
            add_header Cache-Control "public";
    }

A resposta aceita fez com que o nginx não encontrasse nenhum dos meus arquivos estáticos. Não tenho certeza do porquê, mas esta é uma alternativa simples.

A maioria das respostas nesta página são extremamente desatualizadas e/ou complicadas...

Para começar, o Expirescabeçalho não é uma boa opção hoje em dia, nem o Pragmacabeçalho... idealmente, você deve desabilitar ambos os cabeçalhos em sua configuração do Nginx .

more_clear_headers "Pragma Expires";

É muito mais simples definir um único Cache-Controlcabeçalho no bloco de localização de ativos estáticos:

location ~* \.(atom|bmp|bz2|css|doc|docx|eot|gif|gz|ico|jpeg|jpg|js|mid|midi|mp4|ogg|ogv|otf|png|ppt|rar|rss|rtf|svg|svgz|tar|tgz|ttc|ttf|wav|webp|woff|woff2|xls|zip)$ {
    add_header Cache-Control "public, max-age=691200";
}

Lembre-se que para o Nginx, se você usar a expiresdiretiva como expires maxesta NÃO é apenas definir um Expirescabeçalho HTTP, também está configurando um Cache-Controlcabeçalho, então pode ficar muito confuso rapidamente.

O TLDR apenas usa Cache-Controlem seus arquivos estáticos para que CDNs como Cloudflare possam armazená-los em cache na borda e/ou navegadores podem armazená-los por um tempo.

E eu recomendo NÃO usar nenhum cabeçalho de cache para sua página/conteúdo HTML em sites dinâmicos como o WordPress, porque isso só levará a conflitos e confusão etag... 't e acho que isso faz mais sentido ao usar caches de saída agressivos como Varnish ou LS Cache da Litespeed.

As abordagens acima são o que usamos no SlickStack e funciona de maneira fantástica para desempenho e estabilidade, enquanto protege contra, por exemplo, plugins (ou pessoas) do WordPress que mexem com suas configurações.

Etapa 1: Configurando o Cache-Control e os cabeçalhos de expiração:

sudo nano /etc/nginx/sites-available/default

Adicione o seguinte acima do serverbloco:

# Expires map
map $sent_http_content_type $expires {
    default                    off;
    text/html                  epoch;
    text/css                   max;
    application/javascript     max;
    ~image/                    max;
}

E esta linha dentro do serverbloco.expires $expires;

sudo systemctl restart nginx

Fonte: Digital Ocean