Страница обслуживания nginx с проблемой содержимого

Ответ 1

Прости, Фрэнк Фармер, но это не сработает.

Что работает, но не так аккуратно:

И как работают запросы →

• Я использую правило # 1

  if (-f /home/shared/system/maintenance.html) {
      return 503;
  }
  

  это правило имеет поддержку именованного местоположения location @maintenance, а для общего перенаправления на /maintenance.html в root /home/shared/errors все работает.

• Эта страница содержит и изображение some.jpg - для получения этого изображения браузер запускает новый запрос, и этот новый запрос снова попадает в правило # 1

  все это было описано в начальном вопросе BUT

  Если я использую магию if, как в ответах Фрэнка Фармера, я могу указать сервер на запрашиваемый файл, но HTTP-ответ будет 503, а браузеры (все, кроме Safari, в моем тесте) вызывают ошибки в консоли отладки и отображают изображение но не обрабатывать CSS файлы в той же ситуации.

  И это важно.

• Я попытался разрешить это с помощью магии местоположения для моих новых запросов контента - это означает, что я должен:

  • НЕ return 503 для запросов контента и вообще пропустить именованное местоположение.

  • изменить root /home/shared/errors, поскольку содержание обслуживания все еще существует.

• Наконец, у меня есть следующее решение:

  • создать maintenance-static папку для всего статического содержимого и изменить пути в моем файле maintenance.html и таблицах стилей обслуживания и статических

  • Далее используйте эти правила (я считаю, что они самоописательны), которые заменяют одиночный if (-f /home/shared/system/maintenance.html) в начальном вопросе:

    set $can503 0;
    if (-f /home/shared/system/maintenance.html) {
        set $can503 1;
    }
    if ($uri ~* /maintenance-static/) {
        set $can503 0;
    }
    location /maintenance-static/ {
        root /home/shared/errors;
    }
    if ($can503 = 1) {
       return 503;
    }
    

Это решение работает без ошибок во всех браузерах и для множества страниц в папке shared/errors, например. maintenance.html, error.html, overload.html и т.д.

Это решение не совсем понятно - возможно, вы можете намекнуть мне, как я могу сделать его более аккуратным, но помня, что мы имеем дело с отдельными запросами (и отдельными процессами nginx для каждого файла/запроса в случае высокой нагрузки и т.д.) для initial html и его содержимое мы не можем использовать одно и то же правило с перенаправлением 503 для всех файлов.

Ответ 2

Я потратил два часа на поиски ответа на эту проблему и, наконец, нашел этот пост. Похоже, это должно быть более распространенным явлением. Мое решение упало где-то между Фрэнком и Виллом. Как указано в Wile, некоторые браузеры (например, Chrome) не будут отображать CSS/JS из любых файлов, которые возвращаются 503, даже если они полностью и правильно выбрали их.

Но есть исправление, которое менее хаки, чем то, что сделал Уайл. Просто верните 200!

Мое полное решение было следующим:

error_page 503 @maintenance;

location @maintenance {
    root /path_to_static_root;
    if (!-f $request_filename) {
        rewrite ^(.*)$ /rest_of_path/maintenance.html break;
    }
    return 200;
}

Работал как шарм.:)

Ответ 3

location @maintenance {
    root /home/shared/errors;
    rewrite  (some\.jpg|some2\.gif)$ /$1 break;
    rewrite ^(.*)$ /maintenance.html break;
}

Это может работать без перечисления файлов в белом списке:

location @maintenance {
    root /home/shared/errors;
    if (!-f $request_filename) {
        rewrite ^(.*)$ /maintenance.html break;
    }
}

Ответ 4

это решение работает только с одним оператором if, а также более читаемо и понятно:

upstream unicorn {
        server unix:/path/to/unicorn.sock;
}

server {
        listen 3000 default deferred;

        proxy_read_timeout 3600;
        client_max_body_size 4G;
        set_real_ip_from 0.0.0.0/0;

        root /path/to/current/public;
        try_files $uri/index.html $uri.html $uri @unicorn;

        error_page 404 /404.html;
        error_page 500 502 504 /500.html;
        error_page 503 /system/maintenance.html;

        location /404.html {
                internal;
        }

        location /500.html {
                internal;
        }

        location @unicorn {
                if (-f $document_root/system/maintenance.html) {
                        return 503;
                }

                proxy_set_header Host $http_host;
                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 $http_x_forwarded_proto;
                proxy_redirect off;
                proxy_pass http://unicorn;
        }
}

Ответ 5

server {
    listen 80;
    server_name myserv.trunk;
    autoindex off;
    access_log /var/log/nginx/sitename-access.log;

    location ^~ /static/ {
       root /home/dev/myserv-site/;
    }

    location ~ /(?P<language>en)?/? {
        uwsgi_pass unix:///tmp/uwsgi.sock;
        include uwsgi_params;
        error_page 502 @fallback;
        error_page 503 @maintenance;
        if (-f /home/dev/myserv-site/maintenance.active) {
          return 503;
        }
    }

    location @fallback {
      root /home/dev/myserv-site/;
      if ($language) {
          rewrite ^(?!\/static\/)(.*)$ /static/html/502.$language.html break;
      }
      rewrite ^(?!\/static\/)(.*)$ /static/html/502.zh.html break;
    }

    location @maintenance {
      root /home/dev/myserv-site/;
      if ($language) {
          rewrite ^(?!\/static\/)(.*)$ /static/html/503.$language.html;
      }
      rewrite ^(?!\/static\/)(.*)$ /static/html/503.zh.html break;
   }
}

Вот пример экрана страницы с переводимым обслуживанием (503) или 502. Если пользователь перейдет на http://site.com/en/, будет отображаться страница (если поддерживается файл maintenance.active). static dir находится в директории myserv-site.

Ответ 6

Я попробовал все вышеперечисленные предложения и, к сожалению, они не работают должным образом. Единственное решение, которое работает только для меня, следующее:

location / {
    if (-f /path/to/file/indicating/maintenance/mode) {
       rewrite ^(.+)$ /maintenance/$1;
    }

    #... the rest of the "normal" logic
}

location /maintenance {
    root /path/where/your/maintenance/root/is;
    rewrite ^/maintenance/(.*)$ /$1 break;
    try_files /$uri /index.html =404;
    return 200;
}

Я знаю, он создает ненужное/техническое обслуживание в обычных условиях, но вы можете представить себе другой путь к местоположению, который ваши пользователи никогда не догадываются:).