Назад | Перейти на главную страницу

Отладка пропусков кеша Nginx: большое количество ошибок MISS, несмотря на высокий уровень допустимости прокси

Путь к моему прокси-кешу имеет очень большой размер 

proxy_cache_path  /var/lib/nginx/cache  levels=1:2   keys_zone=staticfilecache:180m  max_size=700m;

и используемый размер только

sudo du -sh *
14M cache
4.0K    proxy

Допустимый прокси-кеш установлен на

proxy_cache_valid 200 120d;

Я отслеживаю HIT и MISS через 

add_header X-Cache-Status $upstream_cache_status;

Несмотря на эти настройки, я вижу много ПРОБЛЕМ. И это для страниц, которые я намеренно прогревал час назад.

Как мне отладить, почему возникают эти ПРОБЛЕМЫ? Как узнать, что промах был вызван выселение, истечение срока, какой-то мошеннический заголовок и т.д? Предоставляет ли Nginx команды для этого?

редактировать: Полная конфигурация

    # at http level
    proxy_cache_path  /var/lib/nginx/cache  levels=1:2 inactive=400d keys_zone=staticfilecache:180m  max_size=700m;
    proxy_temp_path /var/lib/nginx/proxy;
    proxy_connect_timeout 30;
    proxy_read_timeout 120;
    proxy_send_timeout 120;
    #prevent header too large errors
    proxy_buffers 256 16k;
    proxy_buffer_size 32k;
    #httpoxy exploit protection
    proxy_set_header Proxy "";

    # at server level 
    add_header Cache-BYPASS-Reason $skip_reason;

    # define nginx variables
    set $do_not_cache 0;
    set $skip_reason "";
    set $bypass 0;

    # security for bypass so localhost can empty cache
    if ($remote_addr ~ "^(127.0.0.1|Web.Server.IP)$") {
        set $bypass $http_8X0;
    }

    # skip caching WordPress cookies
    if ($http_cookie ~* "comment_author_|wordpress_(?!test_cookie)|wp-postpass_" ) {
        set $do_not_cache 1;
        set $skip_reason Cookie;
    }

    # Don't cache URIs containing the following segments
    if ($request_uri ~* "/wp-admin/|/xmlrpc.php|wp-.*.php") {
        set $skip_cache 1;
        set $skip_reason URI;
    }

    # https://guides.wp-bullet.com/how-to-configure-nginx-reverse-proxy-wordpress-cache-apache/
    location / {
            proxy_pass http://127.0.0.1:8000;

            proxy_set_header X-Real-IP  $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto https;
            proxy_set_header X-Forwarded-Port 443;
            proxy_set_header Host $host;
            proxy_set_header Accept-Encoding "";

            # may need to comment out proxy_redirect if get login redirect loop
            proxy_redirect off;

            proxy_cache_key "$scheme://$host$uri";
            add_header X-Nginx-Cache-Head "$scheme://$host$uri";
            proxy_cache staticfilecache;
            proxy_cache_valid       200 301 302 100d;
            proxy_cache_valid 404 1m;


            add_header Cache-Control public;

            proxy_ignore_headers Expires;
            proxy_ignore_headers  "Cache-Control";
            proxy_ignore_headers X-Accel-Expires;

            proxy_hide_header "Cache-Control";
            proxy_hide_header Pragma;
            proxy_hide_header Server;
            proxy_hide_header Request-Context;
            proxy_hide_header X-Powered-By;
            proxy_cache_revalidate on;

            proxy_hide_header X-AspNet-Version;
            proxy_hide_header X-AspNetMvc-Version;
            #proxy_pass_header X-Accel-Expires;


            add_header X-Nginx-Cache-Status $upstream_cache_status;

            proxy_cache_use_stale  error timeout invalid_header updating http_500 http_502 http_503 http_504;
            proxy_cache_bypass $arg_nocache $do_not_cache $http_8X0;
            proxy_no_cache $do_not_cache;

    }

    location ~* \.(jpg|png|gif|jpeg|css|js|mp3|wav|swf|mov|doc|pdf|xls|ppt|docx|pptx|xlsx)$ {
            proxy_cache_valid 200 120d;
            expires 364d;
            add_header Cache-Control public;
            proxy_pass http://127.0.0.1:8000;
            proxy_cache staticfilecache;
            add_header X-Nginx-Cache-Status $upstream_cache_status;
            proxy_cache_use_stale  error timeout invalid_header updating http_500 http_502 http_503 http_504;
    }

Кеширование:

Вы включаете proxy_cache в твоем location или server блок?

Например, несколько настроек в location / блок от Документы Nginx.

proxy_cache_path  /var/lib/nginx/cache  levels=1:2   keys_zone=staticfilecache:180m  max_size=700m;


server {
    # ...
    location / {
        proxy_cache my_cache;
        proxy_cache_revalidate on;
        proxy_cache_min_uses 3;
        proxy_cache_use_stale error timeout updating http_500 http_502
                              http_503 http_504;
        proxy_cache_background_update on;
        proxy_cache_lock on;
    # ...
    }

Для работы кеша необходимы как минимум две обязательные настройки:

Если вы установите его в location блок, вы уверены, что хотите кэшировать именно его?

Анализируя

Если вы хотите анализировать попадания, вы можете создать для этого специальный журнал:

log_format cache_st '$remote_addr - $upstream_cache_status [$time_local]  '
                    '"$request" $status $body_bytes_sent '
                    '"$http_referer" "$http_user_agent"';

И в том же server или location блок, вы можете добавить его как дополнительный журнал, чтобы не пропустить другие вещи:

access_log   /var/log/nginx/domain.com.access.log;
access_log   /var/log/nginx/domain.com.cache.log cache_st;

Затем вы можете проверить некоторую статистику:

HIT vs MISS vs BYPASS vs EXPIRED

awk '{print $3}' cache.log | sort | uniq -c | sort -r

MISS URL:

awk '($3 ~ /MISS/)' cache.log | awk '{print $7}' | sort | uniq -c | sort -r

BYPASS URL:

awk '($3 ~ /BYPASS/)' cache.log | awk '{print $7}' | sort | uniq -c | sort -r

MISS против BYPASS

  • МИСС происходит, когда шаблон настроен для кеширования, но на момент запроса не был кэширован. В правильной конфигурации последующие запросы будут обслуживаться из кеша в зависимости от продолжительности кэширования других параметров.
  • БАЙПАС возникает, когда шаблон был явно настроен НЕ для использования кеша. например пропуск кеширования для вошедшего в систему пользователя. Последующие запросы также будут игнорироваться.

Источник анализа: - https://easyengine.io/tutorials/nginx/upstream-cache-status-in-access-log/

Другой вариант анализа на лету через консоль - использовать GoAccess, действительно хороший анализатор веб-журналов в реальном времени, который требует только ncurses работать: https://goaccess.io/

Возможно, вам потребуется установить inactive параметр на proxy_cache_path к чему-то большему, чем 120d (или как вы хотите, чтобы ваше максимальное время кеширования действительно было). В по умолчанию для неактивного состояния установлено 10 минут.. Пока к кэшируемому URL-адресу осуществляется доступ в течение периода времени неактивного параметра, ваш кеш действителен, но если к нему не обращаются в течение этого периода времени, он выпадет из кеша. Видеть Понимание директивы nginx proxy_cache_path Чтобы получить больше информации.

Я считаю, что это выходит за рамки типичная отладка в стиле $ upstream_cache_status потому что очистка кеша не происходит в цикле запроса / ответа. AFAIK рабочий процесс nginx выполняет очистку кеша как задачу с низким приоритетом, если он больше ничего не делает. Я не уверен, где эта активность будет отображаться в журналах, но, скорее всего, она появится только при сборке с включенной отладкой.

Что пытаетесь кешировать? CMS? Статическая страница? Обычно, если поддерживается отправка без кеширования, срок действия -1 или частный кеш, вы получите промахи. В случае cookie вы также будете попадать в цель.