Ошибка на сайте… Что делать?
Когда код попадает в продакшн, программист выпускает во внешний мир, вместе с полезным функционалом, ещё и ошибки. Вполне возможно, что они, например, на некоем сайте, будут иногда приводить к мелким сбоям, которые спишут на самые разные причины, так и не докопавшись до сути. Знающему своё дело разработчику хорошо бы предусмотреть какой-то механизм, благодаря которому он сможет встретиться со своими ошибками, выслушать их рассказ о тех приключениях, которые им пришлось пережить, и, в результате, их исправить.
Сегодня мы хотим поделиться с вами переводом статьи программиста Дэвида Гилбертсона, в которой он рассказывает о разработанной им экспериментальной системе, позволяющей отслеживать и воспроизводить ошибки в веб-проектах, написанных на React. Полагаем, подобный подход можно перенести и в другие среды, но обо всём по порядку.
Подходы к сбору сведений об ошибках
Возможно, вы пользуетесь такой вот простой системой сбора сведений об ошибках в веб-проектах (прошу не кидаться в меня камнями за следующий пример):
window.onerror = err => fetch(`/errors/$`);Для того, чтобы посмотреть на отчёты по ошибкам, достаточно попросить дружественного айтишника дать вам файл со всеми записями о страницах 404, начинающимися с /errors , и вот оно — счастье.
Однако, тот «код», который вы при таком подходе получите, не поможет вам узнать, о том, где именно произошла ошибка. Вероятно, тут потребуется кое-что усовершенствовать и формировать сообщения об ошибках, в которых содержатся сведения о файле и о номере строки:
window.addEventListener('error', e => < fetch('/errors', < method: 'POST', body: `$(in $ $:$)`, >); >);Этот код балансирует где-то на грани рамок приличия, однако, это пока всего лишь скелет чего-то более серьёзного. Если ошибка связана с конкретными данными, тогда вам сведения о номерах строк особой пользы не принесут.
Хорошо было бы, если бы у вас был полный отчёт о деятельности пользователя в момент возникновения ошибки, что даст возможность воссоздать ситуацию, в которой произошёл сбой. Например, нечто вроде этого:
Отчёт о деятельности пользователя
Самое интересное здесь то, что пользователь перешёл к странице с подробными сведениями о товаре (шаг 4) и щёлкнул по кнопке покупки (на пятом, последнем шаге).
Я могу сразу предположить, что тут, вероятно, что-то подозрительное творится с данными для конкретного товара, поэтому я могу перейти по той же самой ссылке и нажать на кнопку покупки, на которой написано «Buy this for $».
Сделав это, я, конечно, увижу ту же самую ошибку. Этот конкретный товар не имеет цены, поэтому вызов toLocaleString и приводит к сбою. Перед нами — типичный недосмотр не слишком опытного разработчика.
Но что если порядок взаимодействия пользователя с сайтом гораздо сложнее? Может быть пользователь был на одной из многих вкладок, работа с которыми не отражается в URL, или ошибка возникла в ходе проверки данных из формы. Переход по ссылке и нажатие на кнопку такую ошибку не выявит.
Мне бы в такой ситуации хотелось иметь возможность воспроизвести все действия пользователя до момента возникновения ошибки. В идеале — просто щёлкая в ходе воспроизведения по некоей кнопке, на которой написано «Следующий шаг».
Вот как, если я не лишился воображения, я себе всё это представляю:
Воспроизведение действий пользователя путём наблюдения за DOM
Сведения об ошибке, выводимые на экран, и файл, открывающийся в моём редакторе — это заслуга Create React App.
Хочу отметить, что я действительно построил, в виде эксперимента, систему, которая позволяет провести нечто вроде «немодерируемого тестирование юзабилити». Я написал код, который отслеживает действия пользователя, а потом воспроизводит их, и затем спросил одного знающего человека, Джона, о том, что он обо всём этом думает. Он сказал, что это — дурацкая идея, но добавил, что мой код может быть полезен для воспроизведения ошибок.
Собственно, об этом я и хочу тут рассказать. Спасибо, Джон.
Ядро системы
Код, о котором идёт речь, можно найти здесь. Возможно, вам будет интереснее почитать его, чем мой рассказ. Ниже я показываю упрощённые версии функций и даю ссылки на их полные тексты.
У меня есть модуль, record.js, который содержит несколько функций для перехвата различных действий пользователя. Всё это попадает в объект journey , который можно передать на сервер при возникновении ошибки.
Во входной точке приложения я начинаю сбор сведений, вызвав функцию startRecording() , которая выглядит так:
const journey = < meta: <>, steps: [], >; export const startRecording = () => < journey.meta.startTime = Date.now(); journey.meta.startUrl = document.location.href; journey.meta.screenWidth = window.innerWidth; journey.meta.screenHeight = window.innerHeight; journey.meta.userAgent = navigator.userAgent; >;При возникновении ошибки объект journey , например, можно отправить на сервер, для анализа. Для этого подключается соответствующий обработчик события:
window.addEventListener('error', sendErrorReport);При этом функция sendErrorReport объявлена в том же модуле, что и объект journey :
export const sendErrorReport = (err) => < journey.meta.endTime = Date.now(); journey.meta.error = `$(in $ $:$)`; fetch('/error', < method: 'POST', body: JSON.stringify(journey) >) .catch(console.error); >;Кстати, если кто-то может объяснить, почему команда JSON.stringify(err) не даёт мне тело ошибки — это будет очень здорово.
Пока всё это особой пользы не приносит. Однако, сейчас у нас есть каркас, на котором можно построить всё остальное.
Если ваше приложение основано на состояниях (то есть, DOM выводится только основываясь на некоем главном состоянии), значит жить вам будет проще (и я рискну предположить, что вероятность того, что вы встретитесь с ошибками, будет меньше). При попытке воспроизвести ошибку вы можете просто воссоздать состояние, что, вероятно, даст вам возможность эту ошибку вызвать.
Если ваше приложение основано не на самых свежих технологиях, в нём применяются привязки и показ чего-либо, основанный непосредственно на том, как именно пользователь взаимодействует со страницей, тогда дело становится немного сложнее. Для воспроизведения ошибки вам понадобится воссоздать щелчки мышью, события, связанные с потерей и получением фокуса элементами, и, полагаю, нажатия на клавиши клавиатуры. Правда, затрудняюсь сказать, как быть, если пользователь вставляет нечто в поля из буфера обмена. Тут я только могу пожелать удачи в экспериментах.
Хочу признаться — я человек ленивый и эгоистичный, поэтому то, о чём буду рассказывать, будет нацелено на технологии, с которыми работаю я, а именно — на проекты, построенные на React и Redux.
Вот что именно я хочу перехватывать:
- Все диспетчеризованные действия (в результате можно будет включить «воспроизведение» изменений хранилища состояния).
- Изменения URL (а это значит — можно будет обновлять и URL).
- Щелчки по странице (это даст возможность своими глазами видеть, по каким именно кнопкам и ссылкам щёлкает пользователь).
- Скроллинг (это позволит узнать, что именно пользователь видел на странице в момент ошибки).
Перехват действий Redux
Вот код, который используется для перехвата и сохранения в объекте journey действий Redux:
export const captureActionMiddleware = () => next => action => < journey.steps.push(< time: Date.now(), type: INTERACTION_TYPES.REDUX_ACTION, data: action, >); return next(action); >;Самое важное, что нужно понимать в этом коде, заключается в той роли, которую он играет в проекте. А именно, он занят тем, что помещает «действия» Redux, по мере их выполнения, в объект journey .
Затем я применил вышеописанную функцию при создании хранилища Redux, передав ссылку на неё функции этого фреймворка applyMiddleware() :
const store = createStore( reducers, applyMiddleware(captureActionMiddleware), ); ReactDOM.render( > , document.getElementById('root') );Запись изменений URL
Место, где выполняется перехват изменений URL зависит от того, как в приложении выполняется маршрутизация.
Роутер React не особенно хорошо помогает в деле определения изменений URL, поэтому придётся прибегнуть к такому подходу или, может быть, к такому. Хотелось бы мне, с помощью роутера React, просто задать обработчик для onRouteChange . Тут стоит отметить и то, что подобное нужно не только мне. Например, многие сталкиваются с необходимостью отправки сведений о просмотрах виртуальных страниц в Google Analytics.
Как бы там ни было, я предпочитаю писать собственную систему маршрутизации для большинства сайтов, так как это занимает всего-то минут семнадцать, а в итоге то, что получается, работает очень быстро.
Для перехвата изменений URL я подготовил следующую функцию, которая вызывается каждый раз, когда меняется URL:
export const captureCurrentUrl = () => < journey.steps.push(< time: Date.now(), type: INTERACTION_TYPES.URL_CHANGE, data: document.location.href, >); >;Я вызываю её в двух местах. Там же, где выполняю команду history.push() для обновления URL, и ещё в событии popstate , которое вызывается если пользователь нажимает кнопку Назад в браузере:
window.addEventListener('popstate', () => < // ещё какие-то действия, необходимые для обработки события captureCurrentUrl(); >);Запись действий пользователя
Пожалуй, это самый «навязчивый» механизм перехвата информации о работе с сайтом, так как его приходится встраивать буквально повсюду. Я бы, если бы это зависело только от моих желаний, не заморачивался бы этим. Однако, мне встречались ошибки, которые, как я думал, невозможно воспроизвести, не зная о том, где именно щёлкнул пользователь.
В любом случае, задача это была интересная, поэтому тут я расскажу о её решении. При разработке на React я всегда пользуюсь компонентами и , в итоге разработка централизованной системы перехвата кликов достаточно проста. Взглянем на :
const Link = props => ( data-interaction-id= // посмотрите сюда onClick= < e.preventDefault(); captureInteraction(e); // и сюда historyManager.push(props.to); >> > );К тому, о чём мы тут говорим, относятся строки data-interaction-id= и captureInteraction(e); .
Когда приходит время воспроизвести сессию, мне хотелось бы выделять то, по чему щёлкнул пользователь. Для этого мне нужен какой-то селектор. Могу с уверенностью заявить, что элементы, щелчки по которым я отслеживаю, имеют идентификаторы ( id ), но по какой-то причине, о которой я уже и не помню, я решил, что тут лучше подойдёт нечто, специально предназначенное для моей системы наблюдения за активностью пользователей.
Вот функция captureInteraction() :
export const captureInteraction = (e) => < journey.steps.push(< time: Date.now(), type: INTERACTION_TYPES.ELEMENT_INTERACTION, data: < interactionId: e.target.dataset.interactionId, textContent: e.target.textContent, >, >); >;Здесь можно найти её полный код, в котором проверяется, чтобы элемент, после воспроизведения сессии, можно было снова найти.
Как и при работе с другими сведениями, я собираю то, что мне нужно, а потом выполняю команду journey.steps.push .
Скроллинг
Мне осталось рассказать лишь о том, как я записываю данные о скроллинге для того, чтобы знать о том, какие именно части страниц просматривает пользователь. Если, например, страницу перемотали до самого низа и начали заполнять форму, воспроизведение этого без скроллинга особой пользы не принесёт.
Я собираю все последовательные события скроллинга в одно событие для того, чтобы не тратить ресурсы системы на запись множества мелких событий и использую Lodash , так как установка и очищение тайм-аутов в циклах мне не по душе.
const startScrollCapturing = () => < function handleScroll() < journey.steps.push(< type: INTERACTION_TYPES.SCROLL, data: window.scrollY, >); > window.addEventListener('scroll', debounce(handleScroll, 200)); >;В рабочей версии этого кода исключаются события, связанные со сплошным скроллингом.
Функция startScrollCapturing() вызывается при первом запуске приложения.
Дополнительные идеи
Вот небольшой список идей, не использованных в моём проекте. Возможно, вам они покажутся достойными реализации.
- Перехват нажатий на клавиши клавиатуры вроде Escape , Tab или Enter .
- Запись сведений об изменении размеров рабочего окна приложения (для тех случаев, когда важно воспроизведение происходящего с учётом позиции скроллинга).
- Вызов, в процессе воспроизведения, вместо перехвата позиции скроллинга, scrollIntoView() для элемента при его выделении.
- Создание копии localStorage и cookies , если они влияют на поведение сайта.
- И, наконец, пользователям обычно не очень-то нравится, если кто-то перехватывает и сохраняет всё, что они вводят, в особенности номера кредитных карт, пароли, и так далее. Поэтому очень важно, чтобы никто не знал о том, что во время работы с вашим сайтом его действия куда-то записываются (вы, конечно, понимаете, что я шучу).
Возможно, вы полагаете, что мы уже заканчиваем разговор, но к этому моменту мы лишь записали то, что пользователь делает на сайте. Сейчас займёмся самым интересным — воспроизведением записи.
Воспроизведение действий пользователя
Говоря о воспроизведения действий, выполненных пользователем при работе с сайтом, мне хотелось бы обсудить два вопроса:
- Интерфейс, который я используя для исследования причин ошибок путём воспроизведения действий пользователя.
- Механизм, встраиваемый в код сайта и позволяющий управлять им извне.
Интерфейс для воспроизведения действий пользователя
На странице для повторения действий пользователя используется iFrame , где открывается сайт, на котором и выполняется воспроизведение шагов, ранее записанных в объект journey .
Эта страница загружает сведения о сеансе работы, в ходе которого произошла ошибка, после чего отправляет каждый записанный шаг на сайт, что меняет его состояние, приводя в итоге к возникновению той же ошибки.
Когда я открываю данную страницу, то вижу простенький неприглядный интерфейс, после чего сайт загружается так, будто его просматривают на iPad (тут использована обычная картинка планшета, мне так больше нравится).
Вот та же самая анимированная картинка, которую я показывал в начале статьи. Здесь можно найти её код.
Процесс воспроизведения сеанса работы пользователя
Когда я нажимаю на кнопку Next step , iFrame отправляется сообщение с использованием конструкции iFrame.contentWindow.postMessage(nextStep, ‘*’) . Тут есть одно исключение, связанное с изменениями URL. А именно, в подобной ситуации просто меняется свойство iFrame src . Для приложения это, фактически, является полным обновлением страницы, поэтому то, будет ли это работать, зависит от того, как вы переносите состояние приложения между страницами.
Если вы не знаете, то postMessage — это метод объекта Window, созданный для того, чтобы обеспечить взаимодействие между различными окнами (в данном случае это главное окно страницы и окно, открытое в iFrame ).
Собственно говоря, это всё, что можно сказать о странице для воспроизведения действий пользователя.
Механизмы для управления сайтом извне
Механизм воспроизведения действий пользователя при работе с сайтом реализован в файле playback.js.
При запуске приложения я вызываю функцию, которая ожидает сообщений, которые попадают в хранилище и могут быть вызваны позже. Делается это только в режиме разработки.
const store = createStore( // тут будут храниться сообщения ); if (process.env.NODE_ENV === 'development')
Вот где используется этот код.
Интересующая нас функция выглядит так:
export const startListeningForPlayback = (store) => < window.addEventListener('message', (message) => < switch (message.data.type) < case INTERACTION_TYPES.REDUX_ACTION: store.dispatch(message.data.data); break; case INTERACTION_TYPES.SCROLL: window.scrollTo(0, message.data.data); break; case INTERACTION_TYPES.ELEMENT_INTERACTION: highlightElement(message.data.data.interactionId); break; default: // это - не то сообщение, которое нас интересует return; >>); >;Здесь можно найти её полную версию.
При работе с действиями Redux осуществляется их диспетчеризация в хранилище и больше ничего.
При воспроизведении скроллинга выполняется именно то, чего можно ожидать. В данной ситуации важно, чтобы страница имела правильную ширину. Можно заметить, взглянув в репозиторий проекта, что всё будет работать неправильно, если пользователь изменит размеры окна или, например, повернёт мобильное устройство, на котором смотрит сайт, но я думаю, что вызов scrollIntoView() — это, в любом случае, разумное решение.
Функция highlightElement() просто добавляет вокруг элемента рамку. Её код выглядит так:
function highlightElement(interactionId) < const el = document.querySelector(`[data-interaction-id="$"]`); el.style.outline = '5px solid rgba(255, 0, 0, 0.67)'; setTimeout(() => < el.style.outline = ''; >, 2000); >Как обычно, вот — полный код этой функции.
Итоги
Мы рассмотрели простую систему сбора информации об ошибках в React/Redux приложениях. Полезна ли она на практике? Полагаю, это зависит от того, сколько ошибок проявляется в вашем проекте, и насколько сложным оказывается их поиск.
Возможно, вполне достаточно будет, при возникновении ошибки, записывать URL и сохранять сведения о ней, что позволит выявить источник проблемы. Или, возможно, система записи действий пользователя покажется вам удачной, а страница для воспроизведения сеанса работы с сайтом — нет. Если вы, например, сталкиваетесь с ошибками, которые, скажем, происходят лишь в Safari 9 на iOS, страница воспроизведения сеанса окажется бесполезной, так как с её помощью нельзя будет повторить ошибку.
Если говорить о разного рода исследованиях, об одном из которых я только что рассказал, то для меня момент истины настаёт, когда я задаю себе вопрос о том, готов ли я встроить то, что было создано в результате эксперимента, в один из моих реальных проектов. В данном случае ответ на этот вопрос отрицательный.
В любом случае, работа над системой перехвата и воспроизведения действий пользователя — это интересный опыт, который позволил мне узнать что-то новое. Кроме того, я полагаю, что однажды мне всё это может пригодиться, если надо будет по-быстрому внедрить систему мониторинга на каком-нибудь сайте.
Уважаемые читатели! Как вы обходитесь с ошибками? Предлагаем поучаствовать в опросе и поделиться вашими идеями по этому поводу.
Ошибка «Сайт недоступен»: почему она возникает и способы решения
Посетитель заходит в браузер, вбивает запрос, среди ответов поисковика выбирает ссылку на ваш сайт, нажимает ее и… Not Found. Страшный сон любого сайтовладельца, правда? Плод труда всей команды рушится в прямом смысле слова на последнем клике. Чтобы сайт никогда не подсовывал читателям такие «письма счастья», мы рассмотрим причины возникновения самых распространенных ошибок и подскажем, как их решить.
Ошибка 403 (Forbidden)
- Неправильный индексный файл. Файл главной страницы должен иметь одно из названий (все символы в нижнем регистре – это важно): index.shtml, index.html, index.htm, index.phtml или index.php.
- Страница находится в некорректной папке. Чтобы узнать, в какую папку нужно загружать файлы, войдите в раздел «Мои домены» контрольной панели. Напротив каждого домена будет поле «Папка».
- Неправильно настроены права (иногда – Ошибка 500). Возможно, при создании страницы администратор случайно задал в CMS неправильный уровень доступа. В зависимости от настроек системы и типа данных, значение прав доступа может меняться. Чаще всего для файлов устанавливают значение 640, а для каталогов – 750.
Ошибка 404 (Not Found)
С этой ошибкой сталкивался, наверное, каждый пользователь интернета. Она означает, что указанной страницы по этому адресу больше нет. Чтобы не попадать в такую ситуацию, не забывайте время от времени проводить ревизию внешних ссылок или оговаривайте этот момент с партнерами, которые ссылаются на ваш сайт. И обратите внимание на регистр символов в ссылке, ведь https://website/pic.jpg и https://website/pic.JPG – это ссылка на два разных файла.
Большинство современных CMS позволяют отследить, сколько раз пользователи переходили на несуществующие адреса. Ознакомившись с этой статистикой, веб-мастер может установить директивы переадресации на актуальные адреса с помощью CMS или настройками веб-сервера.
Ошибка 500 (Internal Server Error)
Ошибка 500 возникает в случаях, когда сервер не может выполнить запрос пользователя. Виной тому могут быть следующие причины.
- Проблемы с файлом .htacсess. Найдите файл .htacсess в корневом каталоге веб-сайта и проверьте, не произошло ли в нем каких-нибудь изменений.
- Ошибка в скрипте или неправильные заголовки ответа. В контрольной панели найдите ошибки лог-файлов и проверьте файл error_log.
Ошибка 503 (Service Unavailable)
Пользователь видит ошибку 503, когда сайт не успевает обрабатывать все запросы. Это может происходить по следующим причинам.
- Много запросов к веб-серверу. Возможно, на странице много картинок и JS-скриптов. Если можно, объединяйте некоторые ресурсы в один файл. А еще старайтесь не переусердствовать с такими элементами, как чат, боты-индексаторы, поисковики.
- Проблема со скриптами. Тяжелые и устаревшие компоненты CMS замедляют работу сайта. Здесь все просто – выявите все ненужное и беспощадно отключите. 🙂 А еще сократите число SQL-запросов и оптимизируйте их. Не забудьте про почтовую рассылку – расположите скрипт в системном cron’е и перенесите рассылку на время наименьшей загруженности сервера.
- DDoS-атака. Может быть, ваш сайт не успевает обрабатывать все запросы, потому что кто-то нарочно его «бомбардирует». Защититься от атак – задачка нетривиальная, но вполне посильная. Кстати, мы уже писали об этом.
Как обнаружить ошибку раньше пользователя?
Плохо, когда о багах на сайте вы узнаете от посетителей. Лучше, конечно, чтобы ошибок вообще не возникало, но раз уж мы с вами живем в реальном мире, можно научиться отслеживать их раньше, чем они попадутся на глаза читателю.
Используйте для этого встроенные возможности браузера. Для Google Chrome это вкладка Dev Tools, а для Mozilla Firefox – расширение Firebug (настраивается в меню Adds On). Во вкладке Network (или Net) вы увидите некоторые ошибки страницы. А еще лучше – доверьте управление сайтом профессиональному веб-мастеру.
Выводы
В принципе, избежать неприятных ситуаций с ошибками сайта нетрудно. Особенно, если у вас в команде есть грамотный специалист. Вовремя обновляйте CMS, следите за внешними ссылками, проверяйте страницы на наличие ошибок, не дожидаясь жалоб от посетителей – и будет вам счастье. 🙂 Но даже если ошибки уже начали докучать читателям сайта – не отчаивайтесь. Разложите все по полочкам, выясните, когда ошибка начала проявляться впервые, с чем это может быть связано, кем и для чего в последнее время вносились изменения и т. д. Ну, а по вопросам качественного хостинга как небольших, так и масштабных веб-ресурсов обращайтесь к нам за грамотной консультацией 24/7.
ERROR 404: самые частые ошибки сайтов и как их исправить
Ошибки сайтов – это наболевшая тема как для пользователей, так и для владельцев веб-ресурсов. Они могут вызвать недовольство посетителей, прервать важные операции, а в некоторых случаях даже снизить продажи или стать причиной потери клиентов.
Общие сведения об ошибках HTTP: что означают эти цифры
Ошибки HTTP разделяются на две основные категории: ошибки клиента и ошибки сервера. Ошибки клиента начинаются с 4xx и возникают, когда запрос не может быть выполнен из-за какой-то проблемы на стороне пользователя. Это может быть неправильно сформулированный запрос (400), попытка доступа без авторизации (401) и т.д. Ошибки сервера начинаются с 5xx и обычно свидетельствуют о проблемах на стороне сервера, которые не позволяют ему обработать запрос. Это может быть внутренняя ошибка сервера (500), плохой шлюз (502) и т.д.
Понимание ошибок HTTP имеет важное значение как для пользователей, так и для владельцев сайтов. Для пользователей это помогает лучше понять, что происходит при взаимодействии с сайтом и как решить возникшую проблему. Для владельцев сайтов понимание этих ошибок помогает в оптимизации работы веб-ресурса, улучшает UX и повышает общее качество предоставляемых услуг. Вместе с тем, это позволяет избегать потери клиентов из-за технических проблем и улучшает репутацию сайта.
Клиенты часто жалуются на ошибки вашего сайта?
Обратитесь к нам за бесплатной консультацией. Мы выявим причины ошибок и исправим их.
Ошибки клиента – 400: Bad Request, 401: Unauthorized, 403: Forbidden, 404: Not Found
Ошибка 400: Bad Request
Ошибкой 400: Bad Request называют HTTP-ответ сервера, когда он не может интерпретировать запрос от клиента из-за неправильного синтаксиса. Это может произойти из-за несоответствия протоколу, некорректных данных в запросе или неверного URL.
Для решения проблемы с 400 ошибкой необходимо убедиться, что ваш запрос сформулирован правильно и соответствует принятым стандартам HTTP. Проверьте формат URL, данные, отправленные с запросом, и используемые заголовки. Если вы владелец сайта, внимательно проверьте код, ответственный за обработку запросов.
Предотвращение ошибки 400 включает в себя мониторинг и поддержание в актуальном состоянии программного обеспечения сервера, корректное структурирование запросов и внимательное тестирование веб-приложений перед их запуском.
Ошибка 401: Unauthorized
Ошибка 401: Unauthorized в HTTP означает, что для доступа к запрашиваемому ресурсу требуется аутентификация. Эта ошибка появляется, когда пользователь пытается получить доступ к защищенной части сайта без предоставления правильных учетных данных или в случае неверных учетных данных.
Для решения этой ошибки, пользователю следует убедиться, что он ввел правильные учетные данные. Если проблема не в этом, возможно, есть проблемы с сессией или куки, которые могут быть решены путем выхода из системы и повторного входа. Если вы владелец сайта, убедитесь, что ваша система аутентификации работает правильно и безопасно.
Предотвращение ошибки 401 включает в себя регулярное обновление и тестирование систем безопасности сайта. Также важно обеспечивать пользователям четкие инструкции по входу в систему и обработке учетных данных, чтобы избежать возникновения таких ошибок.
403: Forbidden
Ошибка 403: Forbidden – это HTTP-ответ, который означает, что у пользователя нет прав на просмотр определенной страницы или ресурса, даже если он уже аутентифицирован. Это может быть вызвано ограничениями на уровне сервера, конфигурационными проблемами или политиками безопасности сайта.
Если вы столкнулись с ошибкой 403, как пользователь, убедитесь, что у вас есть необходимые права для доступа к этому ресурсу. Если вы владелец сайта, регулярно проверяйте и обновляйте настройки доступа к вашему сайту, чтобы избежать необоснованных ограничений.
Для предотвращения ошибки 403 важно внимательно настроить права доступа и разрешения на вашем веб-сервере. Следует обеспечить корректную работу системы авторизации и правильную конфигурацию файла. htaccess (если используется). Всегда обращайте внимание на права и ограничения пользователей при разработке сайта.
404: Not Found
Ошибка 404: Not Found – это сообщение, которое возвращается сервером, когда запрашиваемый ресурс не может быть найден. Это может быть вызвано неверно введенным URL, удалением или перемещением веб-страницы, или ссылкой на несуществующую страницу.
Если вы столкнулись с ошибкой 404 как пользователь, проверьте, правильно ли введен URL. Если вы владелец сайта, убедитесь, что все ссылки и редиректы работают правильно и ведут на существующие страницы.
Для предотвращения ошибки 404, регулярно проводите аудит ссылок на вашем сайте, чтобы убедиться, что все они ведут к правильным местам. Если страница была перемещена или удалена, установите редиректы, чтобы пользователи были автоматически перенаправлены на новый URL. Также можно настроить пользовательскую страницу 404, чтобы помочь пользователям найти то, что они искали.
Невозможно установить безопасное соединение – что делать?
Данная ошибка часто встречается, при чем в любом браузере. Вы открываете сайт и видите сообщение: «Невозможно установить безопасное соединение». Это окно сопровождается информационным сообщением, в нем говориться, что сайт ненадежен, а ваши данные могут попасть в руки мошенников. Обратите внимания, что коды ошибки «Невозможно установить безопасное соединение» могут быть разные:
- ERR_CERT_DATE_INVALID
- ERR_CERT_INVALID
- ERR_CERT_COMMON_NAME_INVALID
- ERR_CERT_REVOKED
- ERR_CERT_AUTHORITY_INVALID
- ERR_SSL_PINNED_KEY_NOT_IN_CERT_CHAIN
Что делать? Есть несколько вариантов:
- Ошибка «Невозможно установить безопасное соединение» находится на стороне сайта и связана с его сертификатом безопасности. Владельцу сайта с такой ошибкой следует обновить сертификат. А пользователю остается просто ожидать.
- При коде ошибки ERR_CERT_DATE_INVALID пользователю необходимо актуализировать дату и время на устройстве.
- Код ERR_CERT_AUTHORITY_INVALID сообщается о проблеме с VPN или прокси на устройстве пользователя. В такой ситуации необходимо отключить данные программы.
Со стороны клиента ошибка «Невозможно установить безопасное соединение» также может быть связана с проблемами передачи данных у мобильного оператора или же у провайдера, стоит обратиться к колл-центр и уточнить, в чем дело.
Ошибки сайтов часто мешают клиентам и администраторам, снижая количество продаж. Как решить эту проблему?
Звучит просто, но нужно исправить эти ошибки. Наши специалисты помогут наладить работу сайта, вернуть стабильность работы, что позволит вашим клиентам совершать покупки быстрее и проще.
Ошибки сервера – 500: Internal Server Error, 502: Bad Gateway, 503: Service Unavailable, 504: Gateway Timeout
500: Internal Server Error
Ошибка 500: Internal Server Error – это обобщенное сообщение об ошибке, которое говорит о непредвиденной проблеме на сервере. Это может быть вызвано различными причинами, включая проблемы с программным обеспечением сервера, некорректными настройками или ошибками в коде веб-сайта.
Если вы столкнулись с ошибкой 500 как пользователь, попробуйте обновить страницу или вернуться позже. Если вы владелец сайта, проверьте журналы ошибок сервера для выявления проблемы. Обновите и настройте программное обеспечение сервера, а также убедитесь, что ваш код написан корректно.
Чтобы предотвращать ошибку 500, необходимо регулярно проводить обслуживание и обновление сервера, следить за его нагрузкой и своевременно исправлять ошибки в коде сайта. Качественное тестирование перед внедрением новых изменений также поможет избежать многих проблем.
502: Bad Gateway
Ошибка 502: Bad Gateway возникает, когда сервер, действуя как шлюз или прокси, получает недействительный ответ от внутреннего сервера. Это может произойти из-за проблем с сетью, перегрузкой сервера или конфигурационными ошибками.
Если вы столкнулись с ошибкой 502 как пользователь, попробуйте обновить страницу или вернуться позже. Если вы владелец сайта, проверьте настройки сервера, особенно если вы используете прокси-серверы или балансировщики нагрузки.
Предотвращение ошибки 502 включает в себя регулярное мониторинг и обновление программного обеспечения сервера, а также оптимизацию его производительности и нагрузки. Проверьте также все настройки прокси-серверов и балансировщиков нагрузки, чтобы убедиться, что они правильно сконфигурированы и взаимодействуют с вашим основным сервером без проблем.
503: Service Unavailable
Ошибка 503: Service Unavailable указывает на временные проблемы на сервере, который не может в данный момент обработать запросы. Это может быть вызвано перегрузкой сервера, его отключением для обслуживания или проблемами с сетью.
Если вы столкнулись с ошибкой 503 как пользователь, попробуйте обновить страницу или вернуться позже. Если вы владелец сайта, проверьте состояние сервера и его загруженность. Возможно, нужно оптимизировать ресурсы или провести обслуживание.
Чтобы предотвращать ошибку 503, важно регулярно проводить обслуживание сервера и оптимизировать его производительность. Мониторинг нагрузки на сервер поможет определить пиковые периоды и позволит правильно настроить распределение ресурсов. Если сервер отключается для обслуживания, убедитесь, что пользователи уведомлены заранее и предложены альтернативы.
504: Gateway Timeout
Ошибка 504: Gateway Timeout возникает, когда сервер, действующий как шлюз или прокси, не может вовремя получить ответ от другого сервера. Это может быть вызвано задержками сети, перегрузкой сервера или проблемами с его конфигурацией.
Если вы столкнулись с ошибкой 504 как пользователь, попробуйте обновить страницу или вернуться позже. Если вы владелец сайта, проверьте настройки вашего сервера и прокси, а также состояние сети.
Чтобы предотвращать ошибку 504, важно регулярно проводить мониторинг и оптимизацию вашего сервера и сетевых подключений. Проверьте настройки таймаутов и убедитесь, что ваш прокси-сервер или шлюз настроены правильно. Также обеспечьте достаточную пропускную способность для предотвращения перегрузки.
Почему важно уметь читать и исправлять ошибки сайтов
В нашей статье мы рассмотрели различные типы ошибок сайтов, включая ошибки 400, 401, 403, 404 на стороне клиента и ошибки 500, 502, 503, 504 на стороне сервера. Каждая из этих ошибок имеет свои причины и требует уникальных подходов к решению и предотвращению.
Понимание этих ошибок и способов их решения жизненно важно для обеспечения гладкого и эффективного взаимодействия с веб-сайтами. Как для пользователей, так и для владельцев сайтов, осознание причин ошибок и умение применять решения помогает избежать препятствий и неудобств при использовании Интернета.
Нашим основным советом будет регулярная проверка и обновление вашего сайта или веб-сервера, а также внимательное следование рекомендациям и наилучшим практикам безопасности и производительности.
Избавим ваш сайт от ошибок и стабилизируем его работу
Обратитесь прямо сейчас и получите бесплатную консультацию, диагностику и план работ по исправлению ошибок.
Что делать, если на страницах сайта возникают ошибки сервера
В этой статье разберем, что может сделать администратор сайта, чтобы исправить ошибки сервера при доступе к веб-странице. Это пригодится тем, кто сам занимается сайтом компании без программиста в штате.
Что такое ошибки сервера
Когда вы пытаетесь зайти на веб-сайт, браузер отправляет HTTP-запрос на сервер, где этот сайт находится. Каждый HTTP-запрос, принятый сервером, получает код состояния HTTP — трехзначное число. Если в этом числе первая цифра — 5, это ошибка сервера. Коды класса 5** возвращаются веб-сервером, когда он сталкивается с ошибкой и не может обработать запрос клиента.
500: Internal Server Error
Самая распространенная внутренняя ошибка сервера. Код генерируется при любой проблеме, которая не относится к ошибкам 502–524, поэтому у кода 500 много причин появления.
Причины появления:
- ошибки в скриптах сайта, в коде CMS и их плагинов;
- неверные директивы, указанные в файле .htaccess;
- ошибки в конфигурационных файлах веб-сервера при использовании ручного режима настройки.
В редких случаях ошибка 500 может появиться из-за внедрения в файлы сайта вредоносного кода.
Устраняем своими силами
Проверьте логи ошибок веб-сервера. На хостинге RU-CENTER они размещены в каталоге /var/log, он открывается через панель управления хостингом → «Файловый менеджер». Так как используется веб-сервер Apache совместно с nginx, то логи размещаются в отдельных директориях: httpd и nginx соответственно.
Логи веб-сервера Apache (httpd)
Лог-файл — это текстовый файл с информационными сообщениями веб-сервера. Если ошибка связана с неверными директивами в .htaccess, с ошибками в работе CGI-скриптов или в файле конфигурации веб-сервера, вы увидите причину ошибки в логе веб-сервера и сможете ее устранить.
- имя_сайта.access_log — лог обращений к сайту;
- имя_сайта.error_log — лог ошибок сайта;
- php_XY_error_log — лог ошибок веб-сервера для выбранной версии PHP;
- файлы с расширением .gz — архивные логи за предыдущие дни.
Если не получилось
Если ошибка возникает при работе PHP-скрипта, текст ошибки в лог может не попасть. В этом случае нужна дополнительная диагностика, рекомендуем обратиться за консультацией к разработчику сайта или специалистам службы поддержки.
502: Bad Gateway
Ошибка означает, что сервер не смог обработать полученный запрос по техническим причинам.
Причины появления
- Веб-сервер выключен.
- В конфигурации веб-сервера есть ошибка.
- Для работы сайта недостаточно оперативной памяти или других ресурсов. Например, при DDoS-атаке на сайт, когда на обработку «паразитных» запросов тратятся ресурсы веб-сервера.
- Произошла ошибка при работе с памятью в скрипте, это часто встречается при использовании старых версий PHP.
- Время выполнения скрипта превысило установленные на сервере ограничения.
Устраняем своими силами
- Проанализируйте уровень общей нагрузки на сервер и нагрузки в момент появления ошибки. На хостинге RU-CENTER это можно сделать в панели управления хостингом в разделе «Ресурсы» → «Статистика». Обратите внимание на пики потребления оперативной памяти.
Статистика нагрузки на сервер в панели управления хостингом RU-CENTER
- Проверьте лог-файлы веб-сервера и сайта, как мы писали выше, посмотрите на запросы к сайту во время, когда значения были пиковыми, а также обратите внимание на их количество. Если вы обнаружите в них подозрительные сообщения, обратитесь в техподдержку хостинг-провайдера.
Если не получилось
Обратитесь к техническому специалисту, чтобы проверить оптимальность работы скриптов на сайте и оценить скорость обработки запросов. Иногда стоит отказаться от таких операций или оптимизировать их.
503: Service Unavailable
Ошибка означает, что в течение некоторого времени сервер не сможет обрабатывать запросы из-за технических неисправностей.
Причины появления
- Передача большого объема данных.
- Превышено время ожидания загрузки.
- Большое количество запросов к серверу.
- На хостинге RU-CENTER этот код может появиться при обращении к сайту, которого на хостинге нет.
Устраняем своими силами
Если на сайте все процессы (код, скрипты) работают без перебоев, вероятно, причина ошибки 503 — недостаток ресурсов. Чтобы решить проблему, может потребоваться переход на более производительный тариф или сервер. Для принятия решения проконсультируйтесь со службой поддержки и разработчиком сайта.
Если не получилось
Обратитесь в службу поддержки хостинг-провайдера или к разработчику.
504: Gateway Timeout
Серверу не хватило времени, чтобы получить ответ от другого сервера и завершить операцию. Как правило, среднее время загрузки не должно быть больше 1–3 секунд.
Причины появления
- Долгая обработка запроса скриптами сайта.
- Обработка большого количества данных.
Устраняем своими силами
Нужно проверить, что происходит на сервере в момент появления ошибки 504. Если вы обрабатываете большие объемы данных или выполняете операции, требующие длительного времени, настройте эти операции не через браузер, а с помощью планировщика заданий или по SSH.
Еще для устранения ошибки можно попробовать увеличить в настройках PHP время выполнения скрипта (max_execution_time) и время получения данных (max_input_time).
Если не получилось
Обратитесь в службу поддержки хостинг-провайдера или к разработчику.
505: HTTP Version Not Supported
Ошибка 505 появляется, если использовать версию протокола HTTP, которую не поддерживает сервер.
Причины появления
- Заражение вирусом, который получил контроль над браузером или исходящим трафиком.
- Работа с устаревшим браузером, который не поддерживает современные версии HTTP.
- Сервер не поддерживает новые версии протокола, по которым проходит соединение.
Устраняем своими силами
- Поищите вирусы с помощью вашей антивирусной программы. Вредоносные ПО могут повредить и удалить файлы, нужные браузеру для определения состояний.
- Обновите систему — версию ОС и/или браузера. Это поможет предотвратить не только ошибку 505, но и ряд других проблем. Если вы отключили автоматические обновления, рекомендуем скачать и установить их.
Если не получилось
Проверьте актуальность программного обеспечения на веб-сервере. Рекомендуем привлечь для этого специалиста.
520: Web Server Is Returning an Unknown Error
Ошибка 520 может появляться, если вы используете для своего сайта сервисы Cloudflare для перенаправления трафика. Если Cloudflare не удается обработать ответ сервера, на котором размещен сайт, то он выдает эту ошибку.
Причины появления
- Разрыв соединения, когда запрос к серверу был успешным.
- Превышение размера заголовка запроса (больше 16 Кб).
- Ответ сервера не содержит информацию.
- Ответ сервера некорректен.
Устраняем своими силами
Если любое из вышеперечисленных условий исходит от веб-сервера, на котором размещен сайт, нужно обратиться в техподдержку хостинг-провайдера.
Правила ограничения скорости Cloudflare или другие запросы фильтрации иногда могут вызывать проблемы в работе сайта. Важно проверить и протестировать ваш сайт после подключения сервисов Cloudflare. Если на сервере хостинга используются системы безопасности, блокирующие запросы к сайту, обязательно укажите IP-адреса Cloudflare в белом списке, чтобы исключить вероятность блокировки запросов.
Если не получилось
521: Web Server Is Down
Ошибка 521 может появляться, если вы используете для своего сайта сервисы Cloudflare для перенаправления трафика. Браузер показывает ошибку 521, когда веб-сервер неожиданно обрывает соединение с Cloudflare.
Причины появления
Невозможно получить ответ от сервера.
Система безопасности веб-сервера внесла запросы Cloudflare в черный список. Это связано с тем, что система работает по принципу обратного прокси-сервера. Ваша система безопасности могла принять периодические подключения от статических IP-адресов за DDoS-атаку. Из-за этого адреса блокируются или ограничиваются по скорости.
Устраняем своими силами
Возможно, веб-сервер отключен или работает с перебоями. В таком случае:
- Убедитесь, что ваш веб-сервер работает нормально.
- Просмотрите журналы ошибок сервера, чтобы выявить причину ошибки.
Если веб-сервер или хостинг-провайдер блокируют запросы Cloudflare, внесите в белый список все диапазоны IP-адресов сервиса в брандмауэре сервера или другом программном обеспечении для защиты — для этого проконсультируйтесь со службой поддержки провайдера.
Если не получилось
522: Connection Timed Out
Ошибка 522 может появляться, если вы используете для своего сайта сервисы Cloudflare для перенаправления трафика. Ошибка возникает, когда превышено время ожидания ответа от веб-сервера.
Причины появления
- Веб-сервер не может ответить на запрос из-за высокой загруженности.
- Система защиты веб-сервера блокирует запросы Cloudflare.
- Нет доступа к веб-серверу.
- Некорректно указаны настройки DNS на Cloudflare: запросы отправляются по другому адресу.
- Неверная настройка маршрутизации между Cloudflare и веб-сервером.
Устраняем своими силами
- IP-адреса Cloudflare не блокируются в брандмауэре;
- ваш хостинг-провайдер не ограничивает скорость и не блокирует запросы от Cloudflare;
- веб-сервер не перегружен.
Если не получилось
Обратитесь в техническую поддержку Cloudflare, чтобы устранить неисправную маршрутизацию в сети между Cloudflare и исходным веб-сервером.
524: A Timeout Occurred
Ошибка 524 может появляться, если вы используете для своего сайта сервисы Cloudflare для перенаправления трафика. Браузер покажет эту страницу, когда подключение к веб-серверу будет установлено, но его ответ превысит лимит ожидания. Cloudflare ожидает HTTP-ответ в течение 100 секунд.
Причины появления
- Проблемы в работе PHP-скриптов или сбой базы данных.
- Высокая загруженность веб-сервера.
Устраняем своими силами
Проверьте доступные ресурсы веб-сервера, включая процессор, оперативную память и общий уровень трафика. Высокий уровень использования памяти или высокая загрузка процессора могут сигнализировать о проблеме с ресурсами. Может потребоваться переход на более производительный тариф или сервер. Для принятия решения проконсультируйтесь со службой поддержки и разработчиком сайта.
Если вы регулярно отправляете HTTP-запросы, выполнение которых занимает более 100 секунд (например, экспорт больших данных), подумайте о перемещении этих длительных процессов в поддомен, который не проксируется Cloudflare.