nginx использует прокси-кеш, если сервер не работает


11

Мне нужно, чтобы прокси-сервер nginx использовал кеш, если внутренний сервер не работал:

это моя конфигурация но, похоже, nginx использует кеш без проверки бэк-сервера.

http {

  # ...

  proxy_set_header Host $host;
  proxy_set_header X-Real-IP $remote_addr;
  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  proxy_cache_path /tmp/nginx levels=1:2 keys_zone=tmpzone:10m inactive=60m;
  proxy_cache_key "$scheme$request_method$host$request_uri";


  server {
    server_name _;

    location / {
      proxy_connect_timeout 5s;
      proxy_read_timeout 5s;
      proxy_cache tmpzone;
      proxy_cache_valid      200 304 1d;
      proxy_cache_use_stale  error timeout invalid_header updating http_500 http_502 http_503 http_504;
      proxy_set_header X-Real-IP  $remote_addr;
      proxy_set_header X-Forwarded-For $remote_addr;
      proxy_set_header Host 'www.example.com';
      proxy_pass http://www.example.com;
    }
  }
}

Вопрос: как я могу обойти прокси-кеш, если бэкэнд-сервер работает? И когда сервер работает, мой прокси-сервер вообще не использует кеш.


Какой именно вопрос?
Дженни Д

Вопрос: как я могу обойти прокси-кеш, если бэкэнд-сервер работает?
sдоступна из

Одно из готовых решений может состоять в том, чтобы запустить 2 «сервера», один с кешем, один без кеша и использовать вышестоящий модуль nginx.org/en/docs/http/ngx_http_upstream_module.html ? Лучшим решением, вероятно, будет возможность использовать proxy_cache_bypass с проверкой, есть ли бэкэнд или нет ... хотя я понятия не имею, как заставить это работать ... интересный случай.
SvennD

Решения этой проблемы XY можно найти в SO
Dayo

Ответы:


8

Кажется, дубликат этого:

/programming/16756271/how-to-configure-nginx-to-serve-cached-content-only-when-backend-is-down-5xx-re

Короче говоря, используйте proxy_cache_use_stale

В качестве обновления я проверил это, и он отлично работает. Я сделал тест на моей рабочей станции, где у меня есть (для полноты):

Fedora 23 nginx 1.8.1 настроен как ssl terminator + кеш + обратный прокси-сервер Apache 2.4.18 настроен на прослушивание через порт 80

С Apache, выступающим в качестве апстрима, обслуживающим только статический файл, я сделал этот тест

  1. Apache вверх, nginx вверх, указывая браузеру на обратный прокси-URL, обслуживаемый nginx. Я вижу прокси-контент от Apache. На этом этапе nginx хранит это в кэше.
  2. Остановился апач
  3. подключаясь к nginx, я вижу кэшированный файл, который обслуживал ранее Apache.

Конфигурация nginx, которую я использовал (только интересные части):

nginx.conf:

http {
[...]
location
    proxy_cache_path        /var/lib/nginx/tmp/proxy/ levels=1:2 keys_zone=STATIC:10m inactive=24h max_size=1g;
    include /etc/nginx/conf.d/*.conf;
}

/etc/nginx/conf.d/local.conf:

upstream localhost {
    server 127.0.0.1:80;
[...]
}


server {
    listen       127.0.0.1:443 ssl;

[...]

    location /be/ {
        proxy_pass              http://localhost;
        proxy_cache             STATIC;
        proxy_cache_valid       200 1d;
        proxy_cache_use_stale   error;
}

Не работает вообще попробуйте.
sдоступна из

В случае, если вы должны сообщить об ошибке в команду nginx. Что ты пробовал кстати? В случае, если я попытаюсь воспроизвести это
Фреди

Хорошо, я сделал тест, и он работал нормально. Обновил мой ответ с подробностями теста.
Фреди

Таким образом, я прочитал оригинальный вопрос Sweb о том, что в состоянии Apache и nginx все запросы должны проходить через бэкэнд Apache. Запросы следует обслуживать только из кэша NginX, если Apache не работает
abhishekmukherg

@abhishekmukherg, ты можешь делать то, что говоришь, но почему? Когда оба работают, а файлы статичны (например, jpg / css / html), зачем переходить на бэкэнд, используя больше ресурсов network / cpu / ecc, когда у вас есть реальный интерфейс? Кстати, это вопрос другого вопроса
Фреди

0

Используйте proxy_intercept_errors и proxy 500 для сервера, на котором включено кэширование.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.