Maneira correta de usar o nginx como cache da web

Maneira correta de usar o nginx como cache da web

Estou tentando usar o nginx como cache da web (e não consigo).

Meu sistema é um servidor Ubuntu 16.04 onde nginx é um proxy reverso para um servidor web gunicorn (é um aplicativo Django).

Para configurar o cache da web, adicionei as seguintes linhas no topo do meu virtual hostarquivo (aquele em sites-available):

proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=static_cache:10m max_size=90m;
proxy_cache_key "$scheme$request_method$host$request_uri$is_args$args";
proxy_cache_valid 200 302 10m;
proxy_cache_valid 404 1m;

A seguir, dentro do serverescopo principal, tenho o seguinte trecho (onde injetei as diretivas de cache):

location @https_proxy_to_app {
    proxy_cache static_cache;
    proxy_cache_bypass $http_cache_control;
    add_header X-Proxy-Cache $upstream_cache_status;

    proxy_set_header X-Forwarded-Proto https;
    # additional proxy parameters
    include proxy_params;

    proxy_redirect off;
    proxy_pass http://app_server;
}

Isso não gera HITS ou MISSES no cache quando tento enrolar uris de ativos estáticos (que é a única maneira de testar se o cache está funcionando ou não). Portanto, o cache não está operacional. Aqui está o que quero dizer:

Tentando curl -X GET -I https://example.com/static/css/my_app.cssrendimentos:

HTTP/1.1 200 OK
Server: nginx
Date: Wed, 22 Jan 2020 08:05:37 GMT
Content-Type: text/css
Content-Length: 26597
Last-Modified: Fri, 03 Jan 2020 14:23:59 GMT
Connection: keep-alive
Vary: Accept-Encoding
ETag: "5e0f4e7f-67e5"
Expires: Thu, 31 Dec 2037 23:55:55 GMT
Cache-Control: max-age=315360000
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
X-Frame-Options: SAMEORIGIN
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Accept-Ranges: bytes

Isso é problemático porque deveria incluir X-Proxy-Cache: HITou X-Proxy-Cache: MISS. Por favor, ajude-me a diagnosticar o problema.


A seguir estão todos os meus locationblocos (em ordem de aparição):

location ~* \.(?:ico|css|js|gif|jpg|jpeg|png|svg|woff|ttf|eot)$ {

    root /home/ubuntu/app/myproj/;
    access_log off;
    error_log off;

}

# shows number of connections at https://example.com/status_nginx
location /status_nginx {
    stub_status on;
    allow 127.0.0.1;
    deny all;
}

location / {

    limit_conn conn_limit_per_ip 20;
    limit_req zone=req_limit_per_ip burst=10 nodelay;

    limit_req_log_level warn;

    #proxy_pass_request_headers on;
    proxy_buffering on;
    proxy_buffers 24 4k;
    proxy_buffer_size 2k;
    proxy_busy_buffers_size 8k;

    try_files $uri @https_proxy_to_app;
}

location @https_proxy_to_app {

    proxy_cache static_cache;
    proxy_cache_bypass $http_cache_control;
    add_header X-Proxy-Cache $upstream_cache_status;

    proxy_set_header X-Forwarded-Proto https;
    # additional proxy parameters
    include proxy_params;

    proxy_redirect off;
    proxy_pass http://app_server;
}

Responder1

Seu .cssarquivo é servido usando o seguinte bloco em sua configuração:

location ~* \.(?:ico|css|js|gif|jpg|jpeg|png|svg|woff|ttf|eot)$
    root /home/ubuntu/app/myproj/;
    access_log off;
    error_log off;
}

Isso significa que o nginx está enviando o arquivo diretamente, sem usar o servidor upstream para processar a solicitação. Isso significa que não há cache executado.

Se você remover .cssa extensão da lista E se rootnão apontar para o diretório onde este arquivo CSS pode ser encontrado, a solicitação será enviada proxy_passpara o servidor upstream.

Em seguida, a resposta será armazenada em cache, desde que o servidor upstream defina cabeçalhos de cache HTTP adequados.

informação relacionada