503 ошибка beget

Про location

Что это? Отличия от Apache?

Отличия:

1. У apache создается процесс на каждый клиентский запрос (либо поток, зависит от конфигурации), у nginx мастер-процесс и воркеры (каждый воркер может обслуживать тысячи соединений) которые отвлекаются только на новые события и поэтому даже при высоких нагрузках у nginx относительно равномерное потребление ресурсов
2. Apache может генерировать динамический контент, а nginx’у для этого нужен компаньон (apache или какой-либо модуль) на который он будет проксировать такие запросы (у этого есть свои плюсы, раз интерпретатор не встроен в каждого воркера то при нагрузке независимо от того как долго обрабатывается динамика, статика отдается одинакого быстро)
3. В apache есть .htaccess с одной стороны это удобно но с другой это медленнее, у nginx один конфигурационный файл
4. В apache модули подключаются на лету, для nginx нужно пересобирать ядро сервера (это считается безопаснее)
5. Apache обрабатывает запрос как путь в файловой системе к файлу который нужно обработать, а nginx обрабатывает их сначала как uri и при необходимости транслирует их в запросы к файловой системе (потому что nginx и вэб-сервер и прокси-сервер)(эта разница ярко видна в конфигах)
6. В apache все хосты работают с одной версией php (если он сконфигурирован с mod_php), в nginx все раздельно (удобнее мониторить и больше разнообразия)

(beget) Клиент просит установить модули nginx: pushstream, google pagespeed. Что делать?

Nginx собран с поддержкой этих двух модулей и многих других, но в глобальном конфиге они не подключены, потому что не нужны. Чтобы что-то включить придется проделать много работы поэтому у таких клиентов нужно узнать а так уж и нужен ли им этот модуль, если да то путь идут на выделенный сервер или впс.

Как nginx обрабатывает запрос (server_name, listen)? Изучить статью http://nginx.org/ru/docs/http/request_processing.html

Обработка запросов.Мой конспект

Какие типы location бывают?

• (none) — location интерпретируется как префикс (то есть он будет искать более длинное совпадение)
• = — при совпадении дальше искать не станет
• ~ — регистрочувствительная регулярка
• ~* — регистроНЕчувствительная регулярка
• ^~ — приоритетная регулярка
• @ — именованный location

Порядок обработки директив location.

Статья на хабре про порядок обработки location

1. Вначале будет искаться равенство (=). Оно имеет высший приоритет
2. Потом будет искаться максимальный по длине префиксный location ((   ) или (^~)), после чего будет проверено, есть ли на найденном location модификатор приоритета (^~), и если он есть, то будет возвращён этот location
3. Потом будут проверяться регулярные выражения ((~) и (~*)) сверху вниз. При совпадении будет возвращён первый location из них
4. Потом вернётся тот префиксный location, который мы нашли до этого

Также бывают вложенные location’ы, но это сложнее и описано в статье

Как сделать wildcard на nginx?

yii nginx/apply-template idud.in wildcard изменит в конфиге имя сервера на
server_name swan9250.bget.ru *.swan9250.bget.ru;
Также через customer_info можно изменить текущий шаблон
Если вручную менять конф nginx’a (дописать .domain.com в server_name) то и в конфиге apache тоже нужно будет дописать ServerAlias

Для чего нужна директива root?

Задает корневой каталог для запросов

(beget) error_page 404 = @apache

Можно указать файл,например:
erorr_page 500 502 503 504 /50x.html;
либо как в вопросе направить в именованный location для дальнейшей обработки

(beget) Таймауты ожидания для апстрима. Значения по умолчанию, как увеличить? Какую ошибку отдаст nginx по истечении таймаута?

504 Gateway Time-out

• Если апач ничего не отдает в течение 120 (таково значение proxy_read_timeout)
• Стандартное время ожидания Апача ответа от скрипта: 60 секунд. При превышении возникнет 504 ошибка
• Стандартное количество активных процессов Apache: 30 шт (на серверах 300). При превышении лимиов видим ошибку 503 (отдаётся Nginx’ом))

Изменить таймаут можно выбрав подходящий шаблон.

Апстрим некорректно разорвал TCP-сессию(например, процесс апача был убит 9-м сигналом), какую ошибку отдаст nginx? В каких логах можно найти информацию об этом?

502 — Bad Gateway
На сервере лежат логи nginx’а (в логсторадже нет), ncd переносит тебя в папку с логами.

(beget) Почему при шаблоне default на изображения не добавить водяные знаки используя php? Как это исправить?

Php работает в apache, а статика отдается nginx’ом поэтому запрос не доходит до php (водяные знаки накладываются налету, ена сервере картинки лежат без них)
Шаблон apache_js_css_watermark

(beget) Где сжатие описано в конфигах? Как его отключить? Как разрешить пользователю настраивать параметры сжатия?

По умолчанию сжатие включено, его можно отключить применив подходящий шаблон

(beget) Что надо сделать, чтобы пользователь мог настраивать заголовки (кэширования, Access-Control-Allow-Headers…)?

Направить все на apache и там в .htaccess он сможет это делать (точнее он сможет делать то что можно делать через .htaccess) (шаблон apache_all)

(beget) Поддерживается ли SNI в Бегете?

да

(beget) Зачем мы просим клиента покупать выделенный ip для установки платных SSL сертификатов?

Потому что наша инфраструктура строилась раньше чем появился SNI
Он есть просто нужно переписать много кода чтобы его включить

(beget) Поддерживается ли HTTP2 в Бегете?

да

(beget) Как включить/выключить поддержку HTTP2 для домена?

Все автоматом по http2 если есть сертификат (потому что ssl ip идет по http2)
Чтобы вернуться на http1 нужен выделенный ip (в cp есть инструкция как и что сделать)

Limit_req, limit_req_zone, burst

limit_req_zone ключ zone=название:размер rate=скорость [sync];
Задаёт параметры зоны разделяемой памяти, которая хранит состояние для разных значений ключа. Состояние в частности хранит текущее число избыточных запросов. В качестве ключа можно использовать текст, переменные и их комбинации. Запросы с пустым значением ключа не учитываются.

limit_req zone=название [burst=число] [nodelay | delay=число];
Задаёт зону разделяемой памяти (zone) и максимальный размер всплеска запросов (burst). Если скорость поступления запросов превышает описанную в зоне, то их обработка задерживается так, чтобы запросы обрабатывались с заданной скоростью. Избыточные запросы задерживаются до тех пор, пока их число не превысит максимальный размер всплеска. При превышении запрос завершается с ошибкой. По умолчанию максимальный размер всплеска равен нулю

То есть, limit_req_zone определяет зону (ключ, размер зоны, с какой скоростью в ней обрабатываются запросы), потом эта зона по имени используется в limit_req и там добавляется параметр burst в котором определяется размер всплеска запросов которые не будут отклонены а просто задержатся чтобы соответсвовать скорости указанной в limit_req_zone, при превышении допустимого всплеска лишние запросы завершаются с ошибкой (по умолчанию 503)
delay определяет начиная с какого избыточного запроса включать задержку (чтобы соответствовать значению rate в limit_req_zone, либо не использовать задержку вообще)

https://nginx.org/ru/docs/http/ngx_http_limit_req_module.html#limit_req

(beget) В каких шаблонах и при каких условиях nginx может отдавать код 503, 405?

1. default_request_rate
2. default_begetok_request_rate
3. ddos
   во всех них есть такие строки: 1 запрос в секунду, 1 запрос всплеска и они оба будут обработаны сразу, а все остальные будут отброшены с ошибкой 503 (третий запрос за секунду отбрасывается, анологично но сдругими цифрами в других шаблонах)

limit_req_zone $beget_uri zone=beget_uri_1:1007m rate=1r/s;
limit_req zone=beget_uri_1 burst=1 nodelay;

405 отдает в четырех случаях описанных в default

(beget) Описание шаблонов overloaded, ddos, cache, begetok, shellblock, viruses. Отличие их от default.

Изменения относительно дефолтного шаблона

• overloaded
  • Отключает сжатие
  • 403 на POST-запросы
  • 503 (ограничение на количество запросов в секунду)(req_limit)
  • Кэш живет дольше для раных кодов ответа (кэширование ошибок)
• ddos = overloaded — (минус) limit_req zone=beget_ua_1 burst=1 nodelay;
• cache — запрещает кэш в /wp-admin/, нужен чтобы не отдавались куки с данными админки (это бегеток плюс location с wp-admin в котором дериктивы про заголовки)
• shell_block — по крону каждые 10 минут запускается скрипт и проверяет все запросы в access.log за последние 10 минут на предмет вирусни. Если находит то начинает мониторить запросы, если запрашивается стремный файл то запрос блокируется (снимать шаблон надо самому, а ставится он автоматически)
• viruses
  • Отдает 403 на sql инъекции
  • 403 на POST-запросы
• begetok — защищает сайт от ботов (если нет куки «begetok» то направляет на страницу где выставляется эта кука (и так до бесконечности)(кроме наших сетей, их обходит стороной))

(beget) Блокировки xmlrpc.php, sql.gz, useragent, etc. Как реализовано в конфиге? Как отключить? Как включить обратно?

В конфиге есть переменные которые переопределяются в зависимости от запроса (например если в запросе есть .sql.gz и sqldumps_disable = N, то переменная block_sql_dumps становится = 1)

map "$uri:$sqldumps_disable" $block_sql_dumps {
  "~*.sql(.gz)?:N$" 1;
}

установить «Y» в нужные переменные в конфиге, это нужно делать через yii

Ошибка 503 (ERROR Service Unavailable с англ. «Сервис временно недоступен») — это код ответа сервера, который говорит о том, что по техническим причинам сервер не в состоянии обработать текущий запрос. Простыми словами, ошибка 503 — это ответ сервера при его медленной работе, большом количестве запросов или подвисания определенных скриптов на сайте.

Логика появления сбоя следующая: все запросы обрабатываются в порядке живой очереди, при этом самые «тяжелые» из них ждут дольше всего, а простые обрабатываются в первую очередь. Но даже сама очередь всегда ограничивается определенным числом запросов: если поступающий запрос выходит за ее пределы, сервер отдает 503-й код.

Почему возникает ошибка 503

Мы подготовили 2 группы источников ошибки. Внимательно изучите каждую, и без труда найдете виновника сбоя.

Группа 1. Излишнее количество запросов, отправляемых к серверу

Здесь можно выделить как минимум пять источников ошибки.

1. Хакерские атаки. Подобная техника вывода сайта из строя характерна, например, для DDoS-атак.

Решение: установите на свой сайт CloudFlare или другой защитный экран.

2. Разобщение ресурсов. Необходимые для отображения страницы компоненты загружаются в качестве самостоятельных запросов. Вместо того чтобы загружать медиафайлы (например, изображения или анимации), JavaScript и «стили» одним файлом, все эти компоненты разрознены. И, соответственно, они отправляются по разным запросам.

Решение: удалите лишние неиспользуемые скрипты, внедрите кэширование страниц, уменьшите размер изображений, обязательно продиагностируйте CSS.

3. Внедрение скриптов или URL. Если вы пытаетесь задействовать JavaScript на чужом сайте, будьте готовы, что сервер выдаст 503-й ответ. То же самое касается попыток внедрения информеров или любых URL на изображения сайта.

Решение: установка антилич-плагина для используемой CMS или же самостоятельное прописывание такого кода в файле htaccess:

   RewriteCond %{HTTP_REFERER} !^$
   RewriteCond %{HTTP_REFERER} !^http(s)?://(www.)?ваш сайт.ru [NC]
   RewriteCond %{HTTP_REFERER} !^http(s)?://(www.)?images.yandex.ru
   [NC]RewriteCond %{HTTP_REFERER} !^http(s)?://(www.)?images.google.com [NC]
   RewriteCond %{HTTP_REFERER} !^http(s)?://(www.)?images.google.ru [NC]
   RewriteCond %{REQUEST_URI}

   !^/название_изображения_которое_будет_выводиться_на_других_сайтах.png [NC]
   RewriteRule .(gif|jpg|jpeg|png|swf)$ http://

   Ваш_сайт.ру/название_изображения_которое_будет_выводиться_на_других_сайтах.png [R,NC]


Вам понадобится кастомизировать этот код под свои нужды. Например, так:

   RewriteCond %{HTTP_REFERER} !^$
   RewriteCond %{HTTP_REFERER} !^http(s)?://(www.)?http://ваш_сайт.ru [NC]
   RewriteCond %{HTTP_REFERER} !^http(s)?://(www.)?images.yandex.ru [NC]
   RewriteCond %{HTTP_REFERER} !^http(s)?://(www.)?images.google.com [NC]
   RewriteCond %{HTTP_REFERER} !^http(s)?://(www.)?images.google.ru [NC]
   RewriteCond %{REQUEST_URI} !^/antipic.jpg [NC]
   RewriteRule .(gif|jpg|jpeg|png|swf)$ http:/ваш_сайт.ru/antipic.png [R,NC]

4. Определенный компонент сайта постоянно отправляет запросы на веб-сервер. Это вредно, бесполезно и ухудшает быстродействие сервера + увеличивает скорость загрузки вашего сайта. В качестве такого компонента могут выступать разные элементы: виджет, установленная тема или какой-либо плагин. Допустим, вы захотели внедрить на коммерческую страницу окно с чатом. Если оно создано на базе AJAX — а это весьма распространенный сценарий — готовьтесь к бесконечному количеству запросов и увеличению нагрузки на сервер.

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

5. Нагрузка, создаваемая краулерами поисковых систем или других сервисов. Пауки «Гугла», «Яндекса» и других поисковых систем автоматически обходят все сайты в интернете. Да, вы можете добавить рекомендательные директивы в файл robots.txt, но чаще всего краулеры их не соблюдают. Еще более серьезную нагрузку могут создавать пауки сторонних сервисов, например, краулеры Netpeak, Megaindex, Serpstat.



Решение: в robots.txt укажите конкретных user-agent’ов, которые создают серьезную нагрузку на сайт. Если это не помогло, попробуйте заблокировать конкретные IP-адреса. В случае с краулерами такой подход чаще всего не сработает: у них обычно не статические IP.

6. Плагины вCMS. Если вы вебмастер и проблема возникает на вашем сайте, обращайте внимание на установленные в CMS плагины: часто они конфликтуют друг с другом или, например, с темой сайта.

Решение: Попробуйте отключить те плагины, которые вы устанавливали недавно и понаблюдайте за проблемной страницей. Если она открылась, значит причина была именно в каком-то из плагинов, а точнее — внутренних ошибках, которые создавал такой плагин. Если вы не знаете, какой именно плагин является причиной ошибки, отключите их все. Затем начните включать поэтапно, а затем проверяйте доступность проблемной страницы. Если дело было в плагине, рано или поздно страница откроется без ошибки. После нахождения плагина-виновника удалите его через административную панель вашей CMS или замените другим с аналогичным функционалом.

7. Отключение сервера. Еще одна причина, о которой мы не сказали выше — временное отключение сервера (например, при возникновении хакерских атак на хостинг или на время выполнения регламентных работ по обслуживанию машин).

Решение: Диагностировать эту причину можно, задав соответствующий вопрос в саппорт хостинга. Специалист технической поддержки сообщит о перебоях в работе сервера.

Группа 2. Негативное воздействие одного или нескольких скриптов

В этой группе можно выделить 5 причин появления сбоя.

1. «Тяжелые» запросы, отправляемые к базе данных MySQL. Если число таких запросов велико, ошибка может появляться время от времени. Решение для вебмастера — глобальная оптимизация запросов, отправляемых в SQL.

Решение: индексация таблицы базы данных непосредственно по колонкам из выборки. MySQL хорош тем, что все «тяжелые» запросы автоматически фиксируются в папке logs:



Вы без проблем найдете все «медленные» запросы и сможете оптимизировать их в дальнейшем, либо просто заменить.

Помочь также может внедрение кэширования страниц, изменение темы сайта (эта причина обнаруживается чаще, чем другие), отключение неоптимизированных плагинов. Иногда проблем настолько много, что решить их сразу может только переезд на другую систему управления контентом.

Обязательно убедитесь, что проблемная страница может установить соединение с БД MySQL. В противном случае и будет возникать 503 ответ сервера.

2. Слишком «тяжелые» скрипты. Даже 1-2 плохо оптимизированных скрипта могут создавать колоссальную нагрузку на сервер.

Решение: ресурсоемкие сценарии должны быть отключены или заменены на те, которые не создают высокой статической нагрузки.



3. Передача файлов большого размера непосредственно через PHP. Этот источник сбоя возникает при попытке передать статичные файлы через какие-либо скрипты, например, при помощи средств того же PHP. Это некорректный подход.

Решение: перестать передавать статичные файлы больших размеров через скрипты. Если вам нужно отправить очень тяжелый файл, лучше делайте это через FTP. Статичные файлы серьезного размера должны передаваться исключительно прямым образом, без участия скриптов.

При прямой передаче статичных файлов используется отдельный процесс, поддерживающий большое количество потоков. Такой процесс в состоянии работать сразу с несколькими запросами и без влияния на скорость подгрузки компонентов страницы.

4. Регулярное использование почтовых сервисов. Каждый раз, когда скрипт e-mail-рассылки инициализируется, возрастает нагрузка на сервер.

Решение: изучайте лимиты по суммарному числу емейлов, которые допустимо отправлять через используемый вами хостинг.

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

Настраивайте расписание самой рассылки через функцию крон в административной панели выбранного хостинга, а не сторонними способами, например, через плагины для CMS.



5. Взаимодействия с программным сервером. Самый частый сценарий — подключение к удаленному серверу. Это сулит дополнительные сложности: совершение ненужных HTTP-запросов, появление тайм-аутов, обрывы связи, излишнее ожидание ответа.

Решение: соединение с таким веб-сервером нужно минимизировать, а лучше вообще избавиться от него.

Как еще исправить ошибку 503: дополнительные советы пользователю

1. Напишите в саппорт сайта и уточните, почему не открывается страница. Обычно email для технических вопросов вынесен отдельно на странице контактов.



2. Отключите сетевое оборудование (например, Wi-Fi роутер) примерно на 2-3 минуты. Это поможет, если ошибка возникает на уровне IP-адреса. При перезагрузке сетевого оборудования вашему устройству будет присвоен новый IP, а проблемы с открытием страницы будут решены. Этот способ сработает только в том случае, если ваш интернет-провайдер присваивает вам динамический, а не статический адрес.
3. Обновите проблемную страницу с очисткой кэша. Для этого используйте сочетание горячих клавиш Control + F5. Полезно также целиком очистить все временные файлы в используемом браузере.



При такой очистке вы автоматически выйдете из всех аккаунтов (на всех сайтах), где прошли авторизацию ранее.

4. Откройте проблемную страницу через другой браузер. В очень редких случаях браузер может идентифицировать 503-й ответ сервер ошибочно. Изменение браузера поможет диагностировать этот источник ошибки. Вы также можете просто закрыть браузер и запустить его заново. Если причина возникновения ошибки связана только с текущей сессией, перезагрузка браузера также решит эту проблему.
5. Перезагрузите систему. В редких случаях причиной ошибки может быть сбой ОС. Он может возникать как на уровне системного, так и стороннего ПО. Перезагрузка системы в вышеуказанных сценариях станет решением.

Резюме

Мы убедились, 503 ошибка чаще всего появляется на стороне вебмастера. Среди самых частых сценариев можно назвать некорректные параметры на уровне сайта или внутри самого хостинга. Проверяйте их в первую очередь, и лишь потом разбирайте второстепенные варианты, описанные нами выше.

• Здравствуйте, Гость! Предложение любых услуг в данном разделе запрещено! Все подобные темы будут незамедлительно удаляться.

503 Service Temporarily Unavailable

The server is temporarily unable to service your request due to 
maintenance downtime or capacity problems. Please try again later.

Additionally, a 503 Service Temporarily Unavailable error was encountered
while trying to use an ErrorDocument to handle the request.

Apache Server at www.example.com Port 80

Научитесь: Профессия Python-разработчик
Узнать больше