Fgn cdn serverable com ошибка

Error: panicked at 'called `Result::unwrap()` on an `Err` value: JsValue(TypeError: Failed to fetch
TypeError: Failed to fetch)', web/src/navigator.rs:210:18
    at a.wbg.__wbg_new_df6e6ab7a65c4c4d (https://fgn.cdn.serverable.com/common/flashes/js/ruffle210214/ruffle.js:1:6799)
    at std::sync::once::Once::call_once::{{closure}}::hce6501f6f20767e4 (https://fgn.cdn.serverable.com/common/flashes/js/ruffle210214/4d640ad5aa95d1360f7c8c38e9c8b0d8.wasm:wasm-function[1327]:0x26ba91)
    at std::sync::once::Once::call_inner::hd3d269a4946f2df2 (https://fgn.cdn.serverable.com/common/flashes/js/ruffle210214/4d640ad5aa95d1360f7c8c38e9c8b0d8.wasm:wasm-function[1604]:0x29efac)
    at core::ops::function::FnOnce::call_once{{vtable.shim}}::h6ed7686ed76cb258 (https://fgn.cdn.serverable.com/common/flashes/js/ruffle210214/4d640ad5aa95d1360f7c8c38e9c8b0d8.wasm:wasm-function[4639]:0x3823e3)
    at std::panicking::rust_panic_with_hook::h4f753dc70b771d8e (https://fgn.cdn.serverable.com/common/flashes/js/ruffle210214/4d640ad5aa95d1360f7c8c38e9c8b0d8.wasm:wasm-function[3509]:0x357cb7)
    at std::panicking::begin_panic_handler::{{closure}}::h5c9fc29957309ae8 (https://fgn.cdn.serverable.com/common/flashes/js/ruffle210214/4d640ad5aa95d1360f7c8c38e9c8b0d8.wasm:wasm-function[4146]:0x37594f)
    at std::sys_common::backtrace::__rust_end_short_backtrace::h92808941d97e9b21 (https://fgn.cdn.serverable.com/common/flashes/js/ruffle210214/4d640ad5aa95d1360f7c8c38e9c8b0d8.wasm:wasm-function[4985]:0x387ab4)
    at rust_begin_unwind (https://fgn.cdn.serverable.com/common/flashes/js/ruffle210214/4d640ad5aa95d1360f7c8c38e9c8b0d8.wasm:wasm-function[4870]:0x3863b1)
    at core::panicking::panic_fmt::hbd8a975261a5f466 (https://fgn.cdn.serverable.com/common/flashes/js/ruffle210214/4d640ad5aa95d1360f7c8c38e9c8b0d8.wasm:wasm-function[4986]:0x387aea)
    at core::option::expect_none_failed::hbea1e2e5b59d80cc (https://fgn.cdn.serverable.com/common/flashes/js/ruffle210214/4d640ad5aa95d1360f7c8c38e9c8b0d8.wasm:wasm-function[4244]:0x378a28)

Error: panicked at 'assertion failed: `(left == right)`
  left: `true`,
 right: `false`: cannot recursively acquire mutex', /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/std/src/sys/wasm/../unsupported/locks/mutex.rs:24:9
    at W.n.wbg.__wbg_new_df6e6ab7a65c4c4d (https://fgn.cdn.serverable.com/common/flashes/js/ruffle221013/core.ruffle.c6fbe1d7464df286fdfb.js:1:6847)
    at std::sync::once::Once::call_once::{{closure}}::hf9ee3cf8881ab9cc (wasm://wasm/01803f76:wasm-function[1029]:0x2a2c96)
    at std::sync::once::Once::call_inner::hb30cfbde5209eed0 (wasm://wasm/01803f76:wasm-function[1493]:0x3285d3)
    at core::ops::function::FnOnce::call_once{{vtable.shim}}::h9e53a26a8ce616de (wasm://wasm/01803f76:wasm-function[4921]:0x4875eb)
    at std::panicking::rust_panic_with_hook::hb09154fa23e06c37 (wasm://wasm/01803f76:wasm-function[3619]:0x4454f1)
    at core::panicking::panic_fmt::h9e229748e3ae9f9d (wasm://wasm/01803f76:wasm-function[5112]:0x48b363)
    at core::panicking::assert_failed_inner::hfbd38b17d5176c0e (wasm://wasm/01803f76:wasm-function[2283]:0x3c65b1)
    at core::panicking::assert_failed::hef9057a88b6b4752 (wasm://wasm/01803f76:wasm-function[4687]:0x47ef34)
    at ruffle_core::loader::Loader::movie_loader_data::h751adc6d3f6065d3 (wasm://wasm/01803f76:wasm-function[1481]:0x32648e)
    at <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll::h90c6217ad768e9a6 (wasm://wasm/01803f76:wasm-function[503]:0x1a1a35)

Определите причину проблемы: источник или CDN-ресурс

Проверьте настройки CDN

• Конфигурация персонального домена

• Заголовок Host

• Протокол взаимодействия с источником

• SSL

• Опции кеширования

• Очистка кеша

После интеграции с CDN контент вашего сайта не загружается или загружается неправильно? Эта инструкция поможет быстро решить часто возникающие проблемы.

Выберите любой файл, который раздаётся через CDN. Запросите его с источника напрямую и проверьте код ответа.

Например:

• example.com — домен вашего сайта-источника.

• http или https — зависит от протокола, по которому отвечает источник.

• /image.png — путь до файла, который вы запрашиваете.

Запрос будет выглядеть так:

http(s)://example.com/image.png

Если файл загружается корректно и отвечает кодом HTTP 200, значит, проблема не связана с источником. В таком случае проверьте настройки CDN, следуя инструкции ниже. Если файл загружается с ошибками и отвечает кодом HTTP 4xx или 5xx, значит, сложность на стороне источника, а не на стороне CDN.

Проверьте настройки CDN

Проверьте конфигурацию персонального домена

Контент будет раздаваться с вашего источника, а не через CDN, если CNAME-запись персонального домена не настроена. Проверьте её:

1. Перейдите в Настройки ресурса и посмотрите на кнопку Инструкция по настройке. Откройте её, если вы видите уведомление «Осталось Х шагов». Перейдите к следующему разделу этой инструкции, если уведомления нет.

2. Нажмите на кнопку Проверить статус настройки DNS.

Появится такое уведомление, если CNAME-запись не настроена:

Если вы видите уведомление «DNS-запись успешно настроена», значит, CNAME-запись настроена верно — откройте следующий раздел этой инструкции.

3. Откройте Набор инструментов администратора Google, выберите вкладку CNAME и введите персональный домен вашего CDN-ресурса. На скриншоте выше это cdn.example.com. Нажмите Enter.

Далее возможны два варианта:

1) В секции TARGET появится значение CNAME-записи из Инструкции по настройке.

Это значит, что CNAME-запись настроена корректно. Проверьте статус настройки DNS снова (повторите шаг №2). В Инструкции по настройке должно появиться уведомление о том, что запись настроена.

Обратите внимание: DNS-записи обновляются в течение 24 часов.

2) В нижней секции появилось сообщение «Record not found!». В этом случае добавьте CNAME-запись по инструкции «Задать доменное имя для доставки контента через CDN».

4. Дождитесь обновления DNS-записи, очистите кеш браузера и попробуйте запросить контент через CDN снова. Если проблема заключалась в некорректных настройках CNAME-записи, сложность с загрузкой контента больше не повторится.

Проверьте опцию Заголовок Host

Ваш источник не сможет обрабатывать запросы от CDN, если значение опции Заголовок Host не будет совпадать с доменом источника. Проверьте, правильно ли настроена опция:

1. Перейдите в Настройки ресурса → HTTP-заголовки → Заголовок Host.

2. Скопируйте значение заголовка Host из опции.

3. Выполните команду в терминале или консоли:

curl -H "Host: example.com" -I http(s)://10.0.0.1/image.png

где:

• example.com — значение заголовка Host.

• http или https — зависит от протокола, по которому отвечает источник.

• 10.0.0.1 — IP-адрес источника.

• /image.png — путь до файла, который вы запрашиваете.

4. Если в ответе вы получили код HTTP 2xx, проблема не связана с заголовком Host. В таком случае перейдите к следующему разделу этой инструкции.

Опция Заголовок Host настроена неверно, если вам вернулся ответ с кодом HTTP 4xx или 5xx. Чтобы это исправить:

• Впишите домен вашего источника в значение опции Заголовок Host, если с CDN интегрирован только один сайт. Затем очистите кеш CDN и подождите 15 минут, чтобы новые настройки вступили в силу.

• Если вы добавили несколько источников в группу источников, каждый из них должен корректно обрабатывать домен, который указан в опции Заголовок Host. Настройте источники, чтобы они обрабатывали значение заголовка. Затем очистите кеш CDN и подождите 15 минут, чтобы новые настройки вступили в силу.

Проверьте опцию Протокол взаимодействия с источником

CDN ответит ошибкой или перенаправит запрос на источник, если вы выберите неверное значение опции Протокол взаимодействия с источником. Чтобы проверить, верный ли выбран протокол:

1. Определите, какой протокол использует ваш сайт. Для этого откройте сайт в браузере и посмотрите на адресную строку. Если слева от доменного имени стоит иконка замка, значит, ваш сайт работает по протоколу HTTPS.

Так, когда вы скопируете значение адресной строки, получите: https://example.com. Вместо example.com — ваш домен.

Если видите надпись «Не защищено» или Not secure, значит, сайт работает по HTTP. После копирования значения адресной строки, получите: http://example.com. Вместо example.com — ваш домен.

Возможно, ваш источник доступен и по протоколу HTTP, и по протоколу HTTPS. Чтобы это проверить, откройте ваш сайт по обоим протоколам: http://example.com и https://example.com.

2. Перейдите в Настройки ресурса → Общие → Протокол взаимодействия с источником. Вы увидите, какой протокол выбран для CDN-ресурса.

3. Сравните протокол из шага №1 со значением опции из шага №2. Если они совпадают: например, сайт работает по протоколу HTTP, и в значении опции выбран протокол HTTP, значит, проблема не связана с протоколом. Тогда перейдите к следующему разделу этой инструкции.

Если протоколы отличаются, перейдите к следующему шагу этой инструкции.

4. Измените значение опции Протокол взаимодействия с источником в соответствии с инструкцией «Источник. Указать источник контента и протокол взаимодействия с источником». Выберите тип протокола, который использует ваш сайт. Сохраните настройки и очистите кеш CDN.

Проверьте опцию SSL

Если вы активировали опцию SSL, но сертификат для вашего персонального домена не добавился или добавился с ошибкой, контент будет недоступен через CDN, или вы увидите надпись «Не защищено» (Not secure) в браузере.

Проверьте настройки SSL-сертификата. Для этого перейдите в Настройки ресурса → SSL → SSL и убедитесь, что ползунок «Поддержка HTTPS» активен.

Опция предложит две конфигурации: «Выписать бесплатный сертификат Let’s Encrypt» и «Добавить или выбрать собственный SSL-сертификат». В обоих случаях дождитесь, когда SSL-сертификат применится к CDN-ресурсу.

Процесс решения проблемы зависит от конфигурации SSL, которую вы выбрали.

Бесплатный сертификат Let’s Encrypt

1. Вернитесь к разделу о проверке персонального домена и убедитесь, что для него создана CNAME-запись. Без неё сертификат Let’s Encrypt не выпишется. Перейдите к следующему шагу этой инструкции, если CNAME-запись существует.

2. Перейдите в Настройки ресурса → Правила.

3. Убедитесь, что на CDN-ресурсе нет правил, которые бы помешали выписке сертификата. Чтобы выявить их, проверьте поле «Шаблон правила» каждого правила. Убедитесь, что это поле не содержит следующие значения:

• /*

• ((?!(jpeg|gif|png|pdf|jpg|css|js|woff|woff2|ttf)).)*$

• /.well-known/acme-challenge/

Первое и второе значения охватывают все запросы, которые приходят на CDN. Третье значение совпадает со значением, которое мы используем для выписки сертификата. Поэтому при наличии любого из приведённых выше значений, сертификат Let’s Encrypt не выпишется.

Если вы нашли правило с таким значением, удалите или измените его. В следующий раз, когда Let’s Encrypt попытается выписать сертификат, попытка будет успешной.

В случае если на CDN-ресурсе ещё не добавлены правила, перейдите к следующему разделу этой инструкции.

Собственный SSL-сертификат

1. Выполните команду в терминале или консоли:

curl -I https://cdn.example.com/image.png

где:

• cdn.example.com — персональный домен,

• /image.png — путь до файла, который вы запрашиваете.

Если в ответе вы получили код HTTP 2xx, перейдите к следующему шагу этой инструкции. Если в ответе ошибка

curl: (77) schannel: next InitializeSecurityContext failed: SEC_E_UNTRUSTED_ROOT (0x80090325)

значит, используется самоподписанный сертификат. Такие сертификаты не подходят для доставки контента. В этом случае выпишите новый сертификат с помощью Центра Сертификации и добавьте его в соответствии с инструкцией «Добавить SSL-сертификат к ресурсу для передачи контента по HTTPS».

2. Откройте ваш сайт и запросите любой файл, который доставляется через CDN. Нажмите на иконку замка и перейдите к информации о сертификате. Проверьте следующие значения:

• На какой домен распространяется сертификат

• Срок действия сертификата

Проверка займёт несколько минут. Если она не выявит проблем с цепочками сертификата или установит рейтинг «A+», значит, проблема не связана с SSL. В таком случае перейдите к следующему разделу этой инструкции.

Если проверка выявит проблему с цепочками сертификата или установит рейтинг «B», значит цепочка сертификата неполная или добавлена неверно. Перейдите в раздел SSL-сертификаты в личном кабинете. Удалите некорректный сертификат и добавьте его снова в соответствии с инструкцией «Добавить SSL-сертификат к ресурсу для передачи контента по HTTPS».

Проверьте опции кеширования

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

1. Перейдите на страницу Дашборда и нажмите на Общий трафик.

2. Установите фильтр «Кешированный трафик», выберите CDN-ресурс и временной диапазон. Если процент кешированного трафика менее 60%, значит, на CDN кешируется малая часть контента.

В этом случае проверьте, когда вы создали CDN-ресурс. О проблеме с кешированием можно судить спустя два дня использования CDN, так как за это время прогревается его кеш. На процент кешированного трафика также влияет количество запросов на контент от конечных пользователей. Увеличьте количество запросов, а если это не поможет, перейдите к следующему шагу этой инструкции.

Внимание: если контент не запрашивается, он удалится из кеша CDN через 36 часов независимо от настроек кеширования.

3. Выберите любой файл, который доставляется через CDN, запросите его с помощью браузера, консоли или терминала и найдите HTTP-заголовки Cache и Cache Control. Если в ответе вы видите одно из значений ниже, значит, есть проблема с настройками кеширования:

• Cache-Control: max-age=0,

• Cache-Control: private,

• Cache-Control: no-cache,

• Cache: MISS.

Перейдите к следующему шагу этой инструкции, если одно из значений выше совпало с вашим ответом. Если совпадений нет — перейдите к шагу №5 этой инструкции.

4. Перейдите в Настройки ресурса → Кеширование → Кеширование на CDN. Настройте опцию в соответствии с инструкцией «Настроить и проверить параметры кеширования на CDN-серверах».

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

Проверьте опцию Очистка

Как понять, что опция Очистка не сработала:

• CDN возвращает устаревший файл.

• Файл в кеше CDN и тот же файл на источнике не совпадают.

Как исправить ошибку:

1. Подождите 15 минут, чтобы кеш очистился на всех CDN-серверах.

2. Выполните приведённые ниже команды в терминале или консоли. Так вы запросите один и тот же файл и с источника, и с CDN:

curl -I cdn.example.com/image.png

curl -H "Host: example.com" -I http(s)://10.0.0.1/image.png

где:

• cdn.example.com — персональный домен CDN-ресурса.

• /image.png — путь до файла, который вы запрашиваете.

• http или https — зависит от протокола, по которому отвечает источник.

• example.com — значение заголовка Host.

• 10.0.0.1 — IP-адрес источника.

3. Сравните ответы команд и обратите внимание на значения заголовков:

• Content-Length — размер объекта в байтах.

• ETag — набор символов, по которому CDN определяет, изменился ли файл.

• X-Cached-Since — время в формате UTC, когда файл был закеширован на CDN.

В случае если у двух файлов не совпадают значения заголовков Etag и Content—Length, или время в значении заголовка X-Cached-Since устарело, значит, во время очистки кеша произошла ошибка. Тогда перейдите к следующему шагу этой инструкции.

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

4. Попробуйте повторить очистку кеша в соответствии с инструкцией «Очистка: выборочно или полностью очистить кеш CDN-ресурса». При выборе Очистки по шаблону обратите внимание на шаблон пути. Мы советуем проверять его, используя сервис регулярных выражений. Для этого введите шаблон пути для очистки кеша в строку в верхней части страницы, а в нижней части — URL файла. Если появится надпись no match, в шаблоне пути есть ошибка. Исправьте её и повторите очистку кеша.

Если вы прошли все шаги этой инструкции, но всё ещё наблюдаете проблемы, свяжитесь с нашей техподдержкой в чате или по почте support@edgecenter.ru. Будем рады помочь!

В статье мы расскажем, как исправить ошибку (код состояния) 500 со стороны пользователя и администратора сайта, а также подробно разберём, что такое ошибка запроса 500.

Что такое внутренняя ошибка сервера 500

Код ошибки 5хх говорит о том, что браузер отправил запрос корректно, но сервер не смог его обработать. Что значит ошибка 500? Это проблема сервера, причину которой он не может распознать.

Сообщение об ошибке сопровождается описанием. Самые популярные варианты:

• Внутренняя ошибка сервера 500,
• Ошибка 500 Internal Server Error,
• Временная ошибка (500),
• Внутренняя ошибка сервера,
• 500 ошибка сервера,
• Внутренняя ошибка HTTP 500,
• Произошла непредвиденная ошибка,
• Ошибка 500,
• HTTP status 500 internal server error (перевод ― HTTP статус 500 внутренняя ошибка сервера).

Дизайн и описание ошибки 500 может быть любым, так как каждый владелец сайта может создать свою версию страницы. Например, так выглядит страница с ошибкой на REG.RU:

Как ошибка 500 влияет на SEO-продвижение

Для продвижения сайта в поисковых системах используются поисковые роботы. Они сканируют страницы сайта, проверяя их доступность. Если страница работает корректно, роботы анализируют её содержимое. После этого формируются поисковые запросы, по которым можно найти ресурс в поиске.

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

Проверить, осталась ли страница на прежних позициях, можно с помощью Google Search Console. Если робот исключил страницу из поисковой выдачи, её можно добавить снова.

Код ошибки 500: причины

Если сервер вернул ошибку 500, это могло случиться из-за настроек на web-хостинге или проблем с кодом сайта. Самые распространённые причины:

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

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

Что делать, если вы пользователь

Если на определённом ресурсе часто возникает ошибка 500, вы можете связаться с владельцем сайта по инструкции.

Перезагрузите страницу

Удаленный сервер возвращает ошибку не только из-за серьёзных проблем на сервере. Иногда 500 ошибка сервера может быть вызвана небольшими перегрузками сайта.

Чтобы устранить ошибку, перезагрузите страницу с помощью сочетания клавиш:

• на ПК — F5,
• на ноутбуке — Fn + F5,
• на устройствах от Apple — Cmd + R.

Обратите внимание! Если вы приобретаете товары в интернет-магазине и при оформлении заказа появляется 500 Internal Server Error (перевод — внутренняя ошибка сервера), при перезагрузке страницы может создаться несколько заказов. Поэтому сначала проверьте, оформился ли ваш предыдущий заказ. Если нет, попробуйте оформить заказ заново.

Очистите кэш и cookies браузера

Кэш и cookies сохраняют данные посещаемых сайтов и данные аутентификаций, чтобы в будущем загружать веб-ресурсы быстрее. Если на ресурсе уже был статус ошибки 500, при повторном входе на сайт может загружаться старая версия страницы с ошибкой из кэша, хотя на самом деле страница уже работает. Очистить кэш и куки браузера вам поможет инструкция.

Если ни одно из этих действий не решило проблему, значит, некорректно работает сам сервер сайта. Вернитесь на страницу позже, как только владелец решит проблему.

Что делать, если вы владелец сайта

В большинстве случаев устранить проблему может только владелец сайта. Как правило, ошибка связана с проблемами в коде. Реже проблемы могут быть на физическом сервере хостинг-провайдера.

Ниже рассмотрим самые популярные причины и способы решения.

Ошибки в файле .htaccess

Неверные правила в файле .htaccess — частая причина возникновения ошибки. Чтобы это проверить, найдите .htaccess в файлах сайта и переименуйте его (например, в test). Так директивы, прописанные в файле, не повлияют на работу сервера. Если сайт заработал, переименуйте файл обратно в .htaccess и найдите ошибку в директивах. Если вы самостоятельно вносили изменения в .htaccess, закомментируйте новые строки и проверьте доступность сайта.Также может помочь замена текущего файла .htaccess на стандартный в зависимости от CMS.

Найти директиву с ошибкой можно с помощью онлайн-тестировщика. Введите содержимое .htaccess и ссылку на сайт, начиная с https://. Затем нажмите Test:

Произошла непредвиденная ошибка

На экране появится отчёт. Если в .htaccess есть ошибки, они будут выделены красным цветом:

500 ошибка nginx

Активирована устаревшая версия PHP

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

Установлены некорректные права на файлы и каталоги сайта

В большинстве случаев корректными правами для каталогов являются «755», для файлов — «644». Проверьте, правильно ли они установлены, и при необходимости измените права на файлы и папки.

Запущено максимальное количество процессов

На тарифах виртуального хостинга REG.RU установлены ограничения на количество одновременно запущенных процессов. Например, на тарифах линейки «Эконом» установлено ограничение в 18 одновременно запущенных процессов, на тарифах «+Мощность» ― 48 процессов. Если лимит превышен, новый процесс не запускается и возникает системная ошибка 500.

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

Чтобы проверить количество процессов, подключитесь по SSH. Выполните команду:

ps aux | grep [u]1234567 |wc -l

Вместо u1234567 укажите ваш логин хостинга: Как узнать логин хостинга.

Чтобы посмотреть, какие процессы запущены, введите команду:

Вместо u1234567 укажите логин услуги хостинга.

Командная строка отобразит запущенные процессы:

Код ошибки 500

Где:

• u1234567 — логин услуги хостинга,
• 40522 — PID процесса,
• S — приоритет процесса,
• /usr/libexec/sftp-server — название процесса.

Процесс можно завершить командой kill, например:

Вместо 40522 укажите PID процесса.

Чтобы решить проблему, вы также можете:

• увеличить интервал запуска заданий CRON,
• ограничить количество IMAP-соединений в настройках почтового клиента. Подробнее в статье Ограничение IMAP-соединений,
• проанализировать запущенные процессы самостоятельно или обратившись за помощью к разработчикам сайта.

Если вам не удалось самостоятельно устранить ошибку 500, обратитесь в техподдержку.

Скрипты работают слишком медленно

На каждом виртуальном хостинге есть ограничения на время выполнения скрипта. Если за установленное время скрипт не успевает выполниться, возникает ошибка сервера 500. Для решения проблемы обратитесь к разработчику сайта и оптимизируйте скрипты. Если оптимизировать нельзя, перейдите на более мощный вид сервера.

У пользователей VPS есть возможность увеличить максимальное использование оперативной памяти на процесс, но лучше делать скрипты меньшего размера.

Ошибка 500 на сайте, созданном на WordPress

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

Для начала проверьте, нужно ли обновить плагины. Часто устаревшие плагины перестают работать и вызывают проблемы работы сайта. Если все плагины обновлены, но 500 Internal Server Error остаётся, отключите все плагины, чтобы убедиться, что именно они мешают работе сайта. Как только станет понятно, что виноват один из плагинов, отключайте их по очереди, пока не найдёте тот, который нарушает работу сервера.

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

Умные люди придумали коды, по которым можно определить, что произошло с HTTP-запросом. Успешен ли он, произошло ли перенаправление. Или же все закончилось ошибкой. Как раз об ошибках и будем говорить в этой статье. Вкратце расскажу, какие они бывают и с чем связаны. 

А еще тут будет парочка забавных (и не очень) пикч и анимаций на тему описанных ошибок. Хоть какое-то развлечение.

Ошибки со стороны клиента (4xx)

Для начала перечислим коды ошибок на стороне клиента. Вина за их появление ложится на плечи обоих участников соединения.

400 Bad Request

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

401 Unauthorized

Код 401 возникает при попытке клиента получить доступ к серверу, используя неправильные данные для авторизации. По сути, используется, когда пользователь вводит неправильный логин и пароль на ресурсе, где требуется эта информация для входа. Читайте: Как исправить ошибку 401

402 Payment Required

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

Все еще считается, что код существует с расчетом на будущее. Сейчас почти не используется и поддерживается не всеми браузерами.

403 Forbidden

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

Творчество на тему знаменитой киносаги

404 Not Found

Легендарная ошибка, ставшая популярным мемом. 404 оповещает клиента о том, что его запрос ведет в никуда. Код возникает, когда пользователь пытается попасть на страницу, которой не существует. Например, когда случайно ошибается при вводе ссылки и вводит ее с опечаткой. Или же пытается получить доступ к странице, которой на сайте уже нет. 

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

И таких вариаций тысячи. Каждый пытается добавить в оформление что-то свое.

405 Method Not Allowed

405 сообщает клиенту о том, что метод, используемый при запросе, не разрешен. В качестве примера можно привести попытку со стороны клиента ввести данные в форму с помощью GET, когда она работает только с POST. Ну и в таком же духе. 

406 Not Acceptable

Ошибка 406 сообщает о том, что страница передает контент, который не может быть распознан клиентом. Возможно, проблема в методе сжатия или в формате страницы. Иногда сюда же приплетают неправильные настройки кодировки.

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

407 Proxy Authentication Required

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

408 Request Timeout

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

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

В Мистере Роботе частенько называли серии в честь ошибок HTTP (весь четвертый сезон в нумерации 4хх). В честь 408, например, назвали восьмую серию четвертого сезона

409 Conflict

Сообщение о конфликте возникает, когда запрос со стороны клиента не соответствует тому, чего ожидает сервер. В качестве примера приводят проблемы при проверки версий, когда пользователь пытается с помощью метода PUT загрузить на сервер новый файл, но там уже имеется более новая версия того же файла. Конфликта версий можно легко избежать, загрузив корректную версию.

410 Gone

Своего рода аналог 404. Разница лишь в том, что 410 намекает на перманентность отсутствия страницы. Так что этот код стоит использовать, когда на 100% уверен, что страница ушла в небытие (ну или с текущего адреса) навсегда. В любом другом случае есть универсальный 404. 

411 Length Required

411 оповещает пользователя о том, что сервер не желает принимать запрос со стороны клиента, потому что в нем не определен заголовок Content-Length. Да, это первый код в подборке, который смогут понять только люди, сведущие в настройке серверов. По-простому уложить сущность HTML-заголовков в этот материал не получится.

412 Precondition Failed

Еще один код, сообщающий о том, что сервер отклонил запрос пользователя и не разрешает доступ к выбранному ресурсу. Проблемы возникают при неправильной настройке работы методов, отличающихся от GET и HEAD. 

413 Payload Too Large/Request Entity Too Large

Код 413 говорит нам, что запрос, который посылает клиент на сервер, слишком большой. Поэтому сервер отказывается его обрабатывать и разрывает соединение. Обычно это происходит при попытке загрузить на ресурс какой-то файл, превышающий ограничение, выставленное в настройках сервера. Соответственно, решается проблема изменением настроек сервера. 

414 URI Too Long

Чем-то этот код похож на предыдущий. Здесь тоже идет речь о превышение лимита. Только теперь это касается не запроса со стороны клиента, а длины URI. То есть ссылки. Выходит, что адрес, используемый клиентом, больше, чем тот, что может обработать сервер. Как-то так. 

Такая ошибка иногда выскакивает при попытке взломать ресурс. Сайт так реагирует на слишком частые попытки воспользоваться потенциальными дырами в безопасности.

415 Unsupported Media Type

Ошибка 415 возникает, когда клиент пытается загрузить на сервер данные в неподходящем формате. В таком случае сервер просто отказывается принимать посылаемые файлы и разрывает соединение. Как и в случае с 413. 

416 Range Not Satisfiable

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

417 Expectation Failed

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

418 I’m a teapot

Код 418 можно увидеть, если сервер откажется варить кофе, потому что он чайник. Это первоапрельская шутка. Естественно, 418 не используется нигде всерьез и просто существует как дань памяти программистам-юмористам, придумавшим это в 1998 году.

У Google получился такой симпатичный чайник

421 Misdirected Request

Появляется когда запрос клиента переправляется на сервер, который не может дать на него адекватный ответ. Например, если запрос был отправлен на ресурс, который вообще не настроен обрабатывать запросы извне. 

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

422 Unprocessable Entity

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

423 Locked

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

424 Failed Dependency

424 сообщает о том, что для выполнения запроса со стороны клиента успешно должна завершиться еще одна или несколько параллельных операций. Если какая-то из них «провалится», то «помрет» все соединение сразу, и обработать запрос до конца не получится. Аналогичное происходит, если некорректно был обработан один из предыдущих запросов.

425 Too Early

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

426 Upgrade Required

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

428 Precondition Required

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

429 Too Many Requests

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

431 Request Header Fields Too Large

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

444 No Response

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

449 Retry With

Код используется в расширениях компании Microsoft. Он сигнализирует о том, что запрос от клиента не может быть принят сервером. Причиной становятся неверно указанные параметры. Сама 449 ошибка говорит о необходимости скорректировать запрос и повторить его снова, подготовив к работе с сервером.

450 Blocked by Windows Parental Controls

450 код увидят дети, попавшие под действие системы «Родительский контроль» компании Microsoft. По сути, ошибка говорит о том, что с компьютера попытались зайти на заблокированный ресурс. Избежать этой ошибки можно изменением параметров родительского контроля.

451 Unavailable For Legal Reasons

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

Список ошибок на стороне сервера (5xx)

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

500 Internal Server Error

Этот код возникает, когда сервер сталкивается с непредвиденными обстоятельствами. Такими, которые и сам не может пояснить. Как, собственно, и завершить запрос со стороны пользователя. По факту, эта ошибка говорит нам что-то вроде «Я не могу подобрать более подходящий код ошибки, поэтому лови 500 и делай с этим, что хочешь». Мы писали о нем чуть подробнее тут.

Дело не в тебе, дело во мне (С)

501 Not Implemented

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

Иногда в теле ошибки еще пишут что-то в духе «Приходите попозже, возможно, в будущем нужная функция появится».

502 Bad Getaway

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

503 Service Unavailable

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

1. Слишком много пользователей в текущий момент пытаются отправить запросы, и у сервера не остается ресурсов, чтобы ответить кому-либо еще.
2. На сервере ведутся технические работы, временно блокирующие его работу.

Обычно ошибка 503 носит временный характер, и для ее решения достаточно немного подождать. 

504 Gateway Timeout

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

505 HTTP Version Not Supported

Этот код похож на 426. Он тоже связан с неподходящей версией протокола HTTP. В этом случае нужно обеспечить и клиента, и сервер единой версией. Она, как правило, указывается в запросе со стороны пользователя. 

506 Variant Also Negotiates

Обычно с такой ошибкой сталкиваются только в том случае, если сервер изначально настроен неправильно. То есть это не сиюминутная проблема, а что-то серьезное на уровне базовой конфигурации. Тут придется потрудиться разработчикам. Выявить проблему и разрешить ее.

507 Insufficient Storage

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

508 Loop Detected

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

509 Bandwidth Limit Exceeded

Возникает, если сервер начинает потреблять больше трафика, чем ему позволено. 

510 Not Extended

Появляется, если клиент посылает запрос на использование какого-либо расширения, отсутствующего на сервере. Чтобы исправить проблему, надо убрать декларирование неподдерживаемого расширения из запроса или добавить поддержку на сервер.

511 Network Authentication Required

511 код говорит о том, что перед тем как выйти в сеть, надо авторизоваться (ввести логин и пароль). Можно воспринимать это неким PPPoE подключением, когда от клиента требуются данные для авторизации.

Заключение

Закончили. Это все ошибки, которыми отзывается HTTP, если на стороне сервера или клиента что-то пошло не так. Наткнуться на большую их часть довольно тяжело. Особенно, если вы раньше только серфили в интернете, а не занимались разработкой сайтов. А тем, кто входит в эту стезю, полезно знать основные ошибки, так как, скорее всего, придется не раз их исправлять. 

Определите причину проблемы: источник или CDN-ресурс

Проверьте настройки CDN

• Конфигурация персонального домена

• Заголовок Host

• Протокол взаимодействия с источником

• SSL

• Опции кеширования

• Очистка кеша

После интеграции с CDN контент вашего сайта не загружается или загружается неправильно? Эта инструкция поможет быстро решить часто возникающие проблемы.

Определите причину проблемы: источник или CDN-ресурс

Выберите любой файл, который раздаётся через CDN. Запросите его с источника напрямую и проверьте код ответа.

Например:

• example.com — домен вашего сайта-источника

• http или https — зависит от протокола, по которому отвечает источник

• /image.png — путь до файла, который вы запрашиваете

Запрос будет выглядеть так:

http(s)://example.com/image.png

Если файл загружается корректно и отвечает кодом HTTP 200, значит, проблема не связана с источником. В таком случае проверьте настройки CDN, следуя инструкции ниже. Если файл загружается с ошибками и отвечает кодом HTTP 4xx или 5xx, значит, сложность на стороне источника, а не на стороне CDN.

Проверьте настройки CDN

Проверьте конфигурацию персонального домена

Контент будет раздаваться с вашего источника, а не через CDN, если CNAME-запись персонального домена не настроена. Проверьте её:

1. Перейдите в Настройки ресурса и посмотрите на кнопку Инструкция по настройке. Откройте её, если вы видите уведомление «Осталось Х шагов». Перейдите к следующему разделу этой инструкции, если уведомления нет.

2. Нажмите на кнопку Проверить статус настройки DNS.

Появится такое уведомление, если CNAME-запись не настроена:

Если вы видите уведомление «DNS-запись успешно настроена», значит, CNAME-запись настроена верно — откройте следующий раздел этой инструкции.

3. Откройте Набор инструментов администратора Google, выберите вкладку CNAME и введите персональный домен вашего CDN-ресурса. На скриншоте выше это cdn.yourname.com. Нажмите Enter.

Далее возможны два варианта:

1) В секции TARGET появится значение CNAME-записи из Инструкции по настройке. 

Это значит, что CNAME-запись настроена корректно. Проверьте статус настройки DNS снова (повторите шаг №2). В Инструкции по настройке должно появиться уведомление о том, что запись настроена.

Обратите внимание: DNS-записи обновляются в течение 24 часов.

2) В нижней секции появилось сообщение «Record not found!». В этом случае добавьте CNAME-запись по инструкции «Настроить CNAME-записи в DNS».

4. Дождитесь обновления DNS-записи, очистите кеш браузера и попробуйте запросить контент через CDN снова. Если проблема заключалась в некорректных настройках CNAME-записи, сложность с загрузкой контента больше не повторится.

Проверьте опцию Заголовок Host

Ваш источник не сможет обрабатывать запросы от CDN, если значение опции Заголовок Host не будет совпадать с доменом источника. Проверьте, правильно ли настроена опция:

1. Перейдите в Настройки ресурса → HTTP-заголовки → Заголовок Host.

2. Скопируйте значение заголовка Host из опции.

3. Выполните команду в терминале или консоли:

curl -H "Host: example.com" -I http(s)://10.0.0.1/image.png

где:

• example.com — значение заголовка Host

• http или https — зависит от протокола, по которому отвечает источник

• 10.0.0.1 — IP-адрес источника

• /image.png — путь до файла, который вы запрашиваете

4. Если в ответе вы получили код HTTP 2xx, проблема не связана с заголовком Host. В таком случае перейдите к следующему разделу этой инструкции.

Опция Заголовок Host настроена неверно, если вам вернулся ответ с кодом HTTP 4xx или 5xx. Чтобы это исправить:

• Впишите домен или IP-адрес вашего источника в значение опции Заголовок Host, если с CDN интегрирован только один сайт или приложение. Затем очистите кеш CDN и подождите 15 минут, чтобы новые настройки вступили в силу.

• Если вы добавили несколько источников в группу источников, каждый из них должен корректно обрабатывать домен или IP-адрес, который указан в опции Заголовок Host. Настройте источники, чтобы они обрабатывали значение заголовка. Затем очистите кеш CDN и подождите 15 минут, чтобы новые настройки вступили в силу.

Проверьте опцию Протокол взаимодействия с источником

CDN ответит ошибкой или перенаправит запрос на источник, если вы выберите неверное значение опции Протокол взаимодействия с источником. Чтобы проверить, верный ли выбран протокол:

1. Определите, какой протокол использует ваш сайт. Для этого откройте сайт в браузере и посмотрите на адресную строку. Если слева от доменного имени стоит иконка замка, значит, ваш сайт работает по протоколу HTTPS.

Так, когда вы скопируете значение адресной строки, получите: https://example.com. Вместо example.com — ваш домен.

Если видите надпись «Не защищено» или Not secure, значит, сайт работает по HTTP. После копирования значения адресной строки, получите: http://example.com. Вместо example.com — ваш домен.

Возможно, ваш источник доступен и по протоколу HTTP, и по протоколу HTTPS. Чтобы это проверить, откройте ваш сайт по обоим протоколам: http://example.com и https://example.com.

2. Перейдите в Настройки ресурса → Общие → Протокол взаимодействия с источником. Вы увидите, какой протокол выбран для CDN-ресурса.

3. Сравните протокол из шага №1 со значением опции из шага №2. Если они совпадают: например, сайт работает по протоколу HTTP, и в значении опции выбран протокол HTTP, значит, проблема не связана с протоколом. Тогда перейдите к следующему разделу этой инструкции.

Если протоколы отличаются, перейдите к следующему шагу этой инструкции.

4. Измените значение опции Протокол взаимодействия с источником в соответствии с инструкцией «Источник. Указать источник контента и протокол взаимодействия с источником». Выберите тип протокола, который использует ваш сайт. Сохраните настройки и очистите кеш CDN.

Проверьте опцию SSL

Если вы активировали опцию SSL, но сертификат для вашего персонального домена не добавился или добавился с ошибкой, контент будет недоступен через CDN, или вы увидите надпись «Не защищено» (Not secure) в браузере.

Проверьте настройки SSL-сертификата. Для этого перейдите в Настройки ресурса → SSL → SSL и убедитесь, что ползунок «Поддержка HTTPS» активен.

Опция предложит две конфигурации: «Выписать бесплатный сертификат Let’s Encrypt» и «Добавить или выбрать собственный SSL-сертификат». В обоих случаях дождитесь, когда SSL-сертификат применится к CDN-ресурсу.

Процесс решения проблемы зависит от конфигурации SSL, которую вы выбрали.

Бесплатный сертификат Let’s Encrypt

1. Вернитесь к разделу о проверке персонального домена и убедитесь, что для него создана CNAME-запись. Без неё сертификат Let’s Encrypt не выпишется. Перейдите к следующему шагу этой инструкции, если CNAME-запись существует.

2. Перейдите в Настройки ресурса → Правила.

3. Убедитесь, что на CDN-ресурсе нет правил, которые бы помешали выписке сертификата. Чтобы выявить их, проверьте поле «Шаблон правила» каждого правила. Убедитесь, что это поле не содержит следующие значения:

• /*

• ((?!(jpeg|gif|png|pdf|jpg|css|js|woff|woff2|ttf)).)*$

• /.well-known/acme-challenge/

Первое и второе значения охватывают все запросы, которые приходят на CDN. Третье значение совпадает со значением, которое мы используем для выписки сертификата. Поэтому при наличии любого из приведённых выше значений, сертификат Let’s Encrypt не выпишется.

Если вы нашли правило с таким значением, удалите или измените его. В следующий раз, когда Let’s Encrypt попытается выписать сертификат, попытка будет успешной.

В случае если на CDN-ресурсе ещё не добавлены правила, перейдите к следующему разделу этой инструкции.

Собственный SSL-сертификат

1. Выполните команду в терминале или консоли:

curl -I https://cdn.example.com/image.png

где:

• cdn.example.com — персональный домен

• /image.png — путь до файла, который вы запрашиваете

Если в ответе вы получили код HTTP 2xx, перейдите к следующему шагу этой инструкции. Если в ответе ошибка

curl: (77) schannel: next InitializeSecurityContext failed: SEC_E_UNTRUSTED_ROOT (0x80090325)

значит, используется самоподписанный сертификат. Такие сертификаты не подходят для доставки контента. В этом случае выпишите новый сертификат с помощью Центра Сертификации и добавьте его в соответствии с инструкцией «Добавить SSL-сертификат к ресурсу для передачи контента по HTTPS».

2. Откройте ваш сайт и запросите любой файл, который доставляется через CDN. Нажмите на иконку замка и перейдите к информации о сертификате. Проверьте следующие значения:

• На какой домен распространяется сертификат

• Срок действия сертификата

Проверка займёт несколько минут. Если она не выявит проблем с цепочками сертификата или установит рейтинг «A+», значит, проблема не связана с SSL. В таком случае перейдите к следующему разделу этой инструкции.

Если проверка выявит проблему с цепочками сертификата или установит рейтинг «B», значит цепочка сертификата неполная или добавлена неверно. Перейдите в раздел SSL-сертификаты в личном кабинете. Удалите некорректный сертификат и добавьте его снова в соответствии с инструкцией «Добавить SSL-сертификат к ресурсу для передачи контента по HTTPS».

Проверьте опции кеширования

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

1. Перейдите на страницу Дашборда и нажмите на Общий трафик.

2. Установите фильтр «Кешированный трафик», выберите CDN-ресурс и временной диапазон. Если процент кешированного трафика менее 60%, значит, на CDN кешируется малая часть контента.

В этом случае проверьте, когда вы создали CDN-ресурс. О проблеме с кешированием можно судить спустя два дня использования CDN, так как за это время прогревается его кеш. На процент кешированного трафика также влияет количество запросов на контент от конечных пользователей. Увеличьте количество запросов, а если это не поможет, перейдите к следующему шагу этой инструкции.

Внимание: если контент не запрашивается, он удалится из кеша CDN через 36 часов независимо от настроек кеширования.

3. Выберите любой файл, который доставляется через CDN, запросите его с помощью браузера, консоли или терминала и найдите HTTP-заголовки Cache и Cache Control. Если в ответе вы видите одно из значений ниже, значит, есть проблема с настройками кеширования:

• Cache-Control: max-age=0

• Cache-Control: private

• Cache-Control: no-cache

• Cache: MISS

Перейдите к следующему шагу этой инструкции, если одно из значений выше совпало с вашим ответом. Если совпадений нет — перейдите к шагу №5 этой инструкции.

4. Перейдите в Настройки ресурса → Кеширование → Кеширование на CDN. Настройте опцию в соответствии с инструкцией «Настроить и проверить параметры кеширования на CDN-серверах».

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

Проверьте опцию Очистка

Как понять, что опция Очистка не сработала:

• CDN возвращает устаревший файл.

• Файл в кеше CDN и тот же файл на источнике не совпадают.

Как исправить ошибку:

1. Подождите 15 минут, чтобы кеш очистился на всех CDN-серверах.

2. Выполните приведённые ниже команды в терминале или консоли. Так вы запросите один и тот же файл и с источника, и с CDN:

curl -I cdn.example.com/image.png

curl -H "Host: example.com" -I http(s)://10.0.0.1/image.png

где:

• cdn.example.com — персональный домен CDN-ресурса

• /image.png — путь до файла, который вы запрашиваете

• http или https — зависит от протокола, по которому отвечает источник

• example.com — значение заголовка Host

• 10.0.0.1 — IP-адрес источника

3. Сравните ответы команд и обратите внимание на значения заголовков:

• Content-Length — размер объекта в байтах

• ETag — набор символов, по которому CDN определяет, изменился ли файл

• X-Cached-Since — время в формате UTC, когда файл был закеширован на CDN

В случае если у двух файлов не совпадают значения заголовков Etag и Content-Length, или время в значении заголовка X-Cached-Since устарело, значит, во время очистки кеша произошла ошибка. Тогда перейдите к следующему шагу этой инструкции.

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

4. Попробуйте повторить очистку кеша в соответствии с инструкцией «Очистка: выборочно или полностью очистить кеш CDN-ресурса». При выборе Очистки по шаблону обратите внимание на шаблон пути. Мы советуем проверять его, используя сервис регулярных выражений. Для этого введите шаблон пути для очистки кеша в строку в верхней части страницы, а в нижней части — URL файла. Если появится надпись no match, в шаблоне пути есть ошибка. Исправьте её и повторите очистку кеша.

Если вы прошли все шаги этой инструкции, но всё ещё наблюдаете проблемы, свяжитесь с нашей техподдержкой в чате или по почте support@edgecenter.ru. Будем рады помочь