☰

Правильный способ использования nginx в качестве веб-кэша

tag-icon • tag-icon nginx
Правильный способ использования nginx в качестве веб-кэша

Я пытаюсь использовать nginx в качестве веб-кэша (и у меня это не получается).

Моя система представляет собой сервер Ubuntu 16.04, где nginx является обратным прокси-сервером для веб-сервера gunicorn (это приложение Django).

Чтобы настроить веб-кэширование, я добавил следующие строки в верхнюю часть своего virtual hostфайла (тот, что в 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;

Далее, внутри основной serverобласти видимости, у меня есть следующий фрагмент (где я внедрил директивы кэширования):

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;
}

Это не дает кэш-ПОПАДАНИЙ или ПРОМАХОВ, когда я пытаюсь curl статические URI активов (что является единственным способом проверить, работает кэш или нет). Следовательно, кэширование не работает. Вот что я имею в виду:

Попытка curl -X GET -I https://example.com/static/css/my_app.cssдает:

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

Это проблематично, поскольку предполагалось включить X-Proxy-Cache: HITили X-Proxy-Cache: MISS. Пожалуйста, помогите мне в диагностике проблемы.

Ниже приведены все мои locationблоки (в порядке появления):

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;
}

решение1

Ваш .cssфайл обслуживается с использованием следующего блока в вашей конфигурации:

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

Это означает, что nginx отправляет файл напрямую, не используя сервер upstream для обработки запроса. Это означает, что кэширование не выполняется.

Если вы удалите .cssрасширение из списка И не rootукажете каталог, в котором находится этот CSS-файл, то запрос будет отправлен proxy_passна вышестоящий сервер.

Затем ответ будет кэшироваться при условии, что вышестоящий сервер установит соответствующие заголовки HTTP-кеша.

Связанный контент