Как найти ошибку на удаленном сервере

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

500 Internal Server Error (Внутренняя ошибка сервера)

Серверу не удалось обработать запрос к сайту. Возможных причин для этого может быть много, но сузить их круг можно, восстановив последовательность ваших действий перед сообщением об ошибке. Также изучите само сообщение: комментарий «Internal Server Error» говорит о проблемах с файлом .htaccess, текст «HTTP ERROR 500» — о проблемах со скриптами, а текст «PHP Parse error: syntax error, unexpected» или «Internal Server Error nginx» — о неполадках в CMS.

1. Проверьте сайт, созданный с помощью CMS, на наличие проблем с плагинами или ошибок в коде. В этом вам могут лог-файлы. При обнаружении проблемного плагина обновите его или верните прежнюю версию. Если это не помогло, откажитесь от него. Если ошибка произошла после обновления CMS, проведите обновление повторно.

2. Посмотрите файл .htaccess на предмет ошибок в командах. Закомментируйте директиву Options, поставив перед ней решётку: если после этого ошибка 500 перестанет появляться, значит, есть нарушения в синтаксисе и в описании команд.

3. Убедитесь, что права доступа к файлам, папкам и скриптам выставлены верно. Для папок рекомендуется значение 755, для скриптов — 600, а для других файлов — 644. При других вариантах прав доступ к сайту может блокироваться в целях безопасности.

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

5. Отдельно обратите внимание на CGI-скрипты: вероятно, строки в них имеют не те окончания, что исправляется загрузкой скриптов через FTP в режиме ASCII. Также некорректная работа CGI-скриптов может быть причиной ошибок в HTTP-заголовках, что тоже приводит к ошибке 500. Либо же имеются ошибочные директивы, предназначенные для работы со скриптами.

502 Bad Gateway (Ошибочный шлюз)

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

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

2. Убедитесь, что на ваш сайт не совершается DDoS-атака. В противном случае обратитесь к хостинг-провайдеру.

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

4. Проверьте нагрузку на сервер. Если лимит превышается, необходимо увеличить объём оперативной памяти.

5. Посмотрите настройки сервера. Возможными поводами для появления ошибки 502 могут быть:
• неполадки после установки обновлений;
• превышение лимитов на число обращений к внешним ресурсам и на время ответа сервера;
• некорректные лимиты в файлах конфигурации ini;
• превышение лимита на число php-cgi-процессов;
• недостаточная оптимизация скриптов;
• недостаточная оптимизация запросов;
• неправильная работа модулей (если ошибка возникает при обращении к скриптам конкретного расширения).

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

503 Service Unavailable (Сервис недоступен)

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

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

2. Как и в случае с ошибкой 502, удостоверьтесь, что на сайт не производится DDoS-атака.

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

4. Проверьте, не слишком ли активно посещают ваш сайт поисковые роботы. Если это имеет место быть, ограничьте их активность.

5. Удалите тяжёлые или вовсе ненужные плагины и компоненты.

6. Если возможно, оптимизируйте подгрузку файлов сайта, чтобы снизить число запросов.

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

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

9. Оптимизируйте SQL-запросы, выявите самые медленные из них с помощью лог-файлов.

504 Gateway Timeout (Шлюз не отвечает)

Один из серверов не дождался ответа от вышестоящего сервера, о чём сообщает кодом 504.

1. Перезагрузите страницу, убедитесь в стабильности работы сетевых устройств.

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

3. При чрезмерной нагрузке на сервер увеличьте его ресурсы или оптимизируйте сайт.

4. Если возможно, увеличьте время ожидания при использовании nginx как прокси-сервера для Apache. Для этого добавьте эти строки в блоке server в файле nginx.conf:

proxy_connect_timeout 600;
proxy_send_timeout 600;
proxy_read_timeout 600;
send_timeout 600;

5. Если у вас нет возможности менять настройки сервера, обратитесь к хостинг-провайдеру.

Также посмотрите ответы на вопросы из нашего раздела FAQ:

• Отчего возникает ошибка 500?
• Отчего возникает ошибка 503?
• Как изменить страницы ошибок 403, 404 и 500?

Кстати, недавно мы в целом рассказали о кодах состояния сервера, к которым относятся в том числе и коды ошибок.

При поддержке блога про гаджеты и usb мышки 2USB.ru и интернет-магазина дизайнерских флешек shop.2usb.ru

Существует три способа проверить логи событий на удаленном компьютере:

Использование оснастки Eventvwr.msc

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

Использование EventQuery.VBS

Операционные системы Windows (Windows XP и более поздние) включают встроенное средство командной строки позволяющее проверить логи событий на удаленных системах. За более подробной информацией по сценарию EventyQuery.VBS перейдите по адресу /technet.microsoft.com/en-us/library/bb490900.aspx

Использование PsLogList.exe

Компания Sysinternals (теперь Microsoft Sysinternals) разработало утилиту PsLogList. С помощью данной утилиты можно проверять логи событий или сохранять их в текстовый файл. За более подробной информацией по утилите и возможным в ней ключам перейдите по ссылке technet.microsoft.com/en-us/sysinternals/bb897544.aspx

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

Полезная информация

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

Обычные посетители сайта обращают внимание в первую очередь на качественный контент, а поисковые краулеры – на ответы сервера.

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

Немного теории

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

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

Сперва определимся с терминами.

• Клиент – компьютер, смартфон или другое мобильное устройство, которое имеет подключение к интернету.
• Сервер – определенный компьютер, который хранит все данные сайта (включая страницы и системные файлы). Именно на сервере «живет» сайт.

Выделяют пять классов ответов. Идентифицировать класс можно по первой цифре.

• 5** – техническая ошибка на стороне сервера. Точная причина указывается сразу после кода. Иногда пятисотая говорит о внутренних сбоях, реже – о превышении статической нагрузки на сервер.
• 4** – сбой на стороне юзера.
• 3** – обнаружен редирект на другой адрес (не ошибка).
• 2** – запрос обработан успешно (не ошибка).
• 1** – служебный класс кодов, который чаще всего относится к информационным сообщениям (не ошибка).

Логика кодов, таким образом, весьма проста:

Что значат коды состояния HTTP

Причины / решения / пояснения ошибок, я буду давать только для самых часто встречающихся кодов. Для всех остальных – только краткое описание.

Двухсотые – успешные запросы

200 – успешный запрос данных. Код не является ошибкой.

201 – завершена успешная транзакция. Код говорит о том, что сформирован новый ресурс (или документ).

202 – запрос принят, но еще не завершен. Необходимо дождаться окончания обработки.

203 – данные получены не из первоисточника (возвращаемые данные идут не от исходного сервера, а от какого-то другого) и могут быть устаревшими.

204 – запрос был обработан правильно, но отсутствует содержимое. Есть заголовок ответа, но содержимое для него отсутствует. Обновлять и актуализировать содержимое не нужно.

205 – клиенту необходимо осуществить сброс содержимого. Саму страницу обновлять не требуется.

206 – ошибка частичного содержимого. Если клиент хочет выполнить загрузку данных в несколько потоков, а сервер выполняет только часть GET-запроса, будет возникать 206-ая ошибка.

GET-запрос предназначен для получения данных, в то время как POST-запрос нужен для отправки данных.

Код также может быть отправлен с сервера, когда клиент запросил диапазон (например, условно: «Дайте мне первые 2 МБ видеоданных»). Происходит возврат только частичного контента, соответствующего Range-заголовку (данный заголовок дает понять серверу, какую именно часть страницы от него требуют, и какую ему нужно вернуть).

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

207 – выполнено несколько операций. Найти их можно в XML, в строке MultiStatus.

226 – обработан IM-заголовок. Содержимое будет возвращено для получения информации об ответе вместе с ранее обозначенными параметрами.

Трехсотые – запросы на редирект

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

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

302 – документ был временно перемещен на новый URL. Это абсолютно корректный ответ сервера, который актуален для веб-страниц с распродажами или сезонными акциями, распространяющимися на какой-либо товар. Код указывает, что данный URI будет учитываться клиентом в последующих запросах. Другими словами, страница была найдена, но перенесена. Такие документы из индекса не удаляются. Если адрес был изменен навсегда, вместо 302-го, лучше использовать 303-ий или 307-ой ответ.

303 – нужно направить пользователя на иной URL. 303-ый код можно получить исключительно GET-запросом. В идеале, этот код нужно отдавать, когда требуется редиректнуть посетителя на близкорелевантую, но не идентичную странице.

304 – документ не модифицировался. Этот код не является стандартным редиректом. Он помогает краулерам определять страницы, которые не изменились с последнего визита.

Если на вашем сайте немного страниц (до 1 000), использовать код 304 нет смысла. Если вас напрягает этот редирект, то в заголовке нужно поправить параметр Last-Modified (последняя дата изменения) – он не должен быть старше, чем заголовок If-Modified-Since (если изменялся спустя заданное количество времени).

305 – доступ к этому документу возможен исключительно через прокси.

307 – документ был временно перемещен на иной URL. Идеальный вариант, если требуется временно редиректнуть посетителя, но оставить техническую возможность отправки POST-запросов.

Четырехсотые – сбои на стороне клиента

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

401 – отсутствует аутентификация. Код отдается, когда для доступа требуется пароль или регистрация.

403 – отсутствует доступ к документу. Возникает, когда пользователь хочет открыть системные файлы (robots, htaccess). Либо вы сделали опечатку при вводе URL и пытаетесь воспользоваться веб-страницей, которая не предназначена для обычного пользователя, либо вам нужно: пройти авторизацию для доступа к системным файлам.

404 – отсутствует соответствующий ресурс по введенному URL. Разберитесь, по каким причинам была удалена / перемещена страница. Возможно, вы допустили ошибку и удалили ее случайно. Если так – просто восстановите ее.

Задумайтесь над созданием красивой, кастомизированной 404-ой. Например, такой:

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

406 – некорректный / неподдерживаемый краулером формат запроса. Код отдается, когда сервер не способен возвратить ответ, релевантный листу допустимых значений. Самый распространенный случай – поисковый робот не поддерживает кодировку документа или его язык. Убедитесь, что в теле сообщения содержится лист доступных ресурсов. Подробное описание ошибка на сайте веб-разработчиков Mozilla.

407 – отсутствует регистрация прокси или авторизация файервола.

408 – таймаут запроса. Соединение разорвано, так как полный запрос не был передан. Другими словами, запрос занял слишком много времени, а сервер не готов был ждать. На каждом сайте существует свое время таймаута. Проверьте наличие интернета и просто обновите страницу. Подробное объяснение этой ошибки на сайте веб-разработчиков Mozilla.

409 – несовместимость двух запросов. Запрос невозможно выполнить при текущем состоянии сервера. Самый распространенный случай – операции c PUT-запросом. Например, когда нужно скачать файл, возраст которого превышает возраст уже существующего, расположенного на сервере.

410 – ресурс более не существует по указанному URL. Если страница удаляется целенаправленно, лучше делать так, чтобы она отдавала именно 410-ый. Краулер обойдет такую страницу, получит этот код и больше никогда на нее не вернется, так как поймет, что она удалена навсегда. Если речь о веб-странице, которая была удалена временно, гораздо эффективнее использовать 404-ый ответ. Если страница удалена намерено и навсегда, но в SERP имела хорошие места и приносила трафик, лучше сделать редирект на максимально релевантную существующую страницу.

411 – сервер сам отклоняет отправляемый запрос, так как не находит значение Content-Length. Этот ответ характерен как для обычных POST-запросов, так и для PUT-запросов (подразумевают замену существующих представлений документа на данные, которые содержатся в самом запросе).

412 –не были до конца выполнены условные поля HTTP-заголовка, например, If-Match. 412-ый код появляется в случаях, когда доступ к целевому документу отклоняется. Нужно проверить соблюдение и корректность HTTP-заголовков выполняемого запроса.

413 – у каждого сервера есть свой собственный максимальный размер запроса, определяемый не самим HTTP-протоколом (у него ограничения по длине запроса просто напросто отсутствуют), а ограничениями со стороны браузеров. Браузеры поддерживают запросы от 2 до 8 килобайт. Вышеуказанный код отдается, когда сервер не понимает запрос из-за слишком большого размера.

414 – возникает, когда отправляется чрезвычайно длинный URL. Запросы, содержащие излишне длинные URL, не могут правильно интерпретироваться сервером. Самые частые случаи появления этого ответа – попытка передать удлиненные параметры (излишне большое количество данных через GET- запрос).

415 – некорректный медиаформат. Текущий тип данных не может быть интерпретирован сервером.

416 – некорректное значение Range (диапазон). Ответ возникает в случаях, когда в самом HTTP-заголовке прописывается некорректный байтовый диапазон. 416-ый отдается в случаях, когда сервер не может взаимодействовать с запрашиваемыми диапазонами. Причина – отсутствие диапазона в необходимом документе или опечатка в синтаксисе.Сервер просто не имеет возможности работать с запрашиваемыми диапазонами. Проверьте синтаксис значения Range – он должен обязательно соблюдаться. Скорее всего, документ просто не имеет запрашиваемых диапазонов. Обновите страницу.

417 – указанное значение Expect не может быть удовлетворено (речь о заголовке запроса). Прокси некорректно идентифицировал содержимое поля «Expect: 100-Continue». Устранить эту ошибку самостоятельно не удастся. Если вы используете прокси Squid, обратитесь в поддержку. Вам нужно активировать ignore_expect_100. Другой вариант ­ разрешите BS_PingHost обращаться к интернет-сети без участия прокси.

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

423 – используемый ресурс был заблокирован для выбранного HTTP—метода. Перезагрузите роутер и компьютер. Используйте только статистический IP.

424 – зависимый ресурс был блокирован по соображением безопасности. Данный код отдается, если в запросе присутствуют признаки несанкционированного доступа к файлам CMS.

426 – некорректные значения полей Upgrade и Conection. Этот ответ возникает, когда серверу требуется обновление до SSL-протокола, но клиент не имеет его поддержки.

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

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

Пятисотые – серверные сбои

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

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

501 – не выполнено. Этот код отдается, когда сам сервер не может идентифицировать метод запроса. Сами вы эту ошибку не исправите. Устранить ее может только сервер.

502 – шлюзовый сбой. Возникает при получении некорректного ответа от сервера, находящегося по иерархии выше. Актуально исключительно для прокси и шлюзовых конфигураций.

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

504 – отсутствует ответ. Этот код отдается в одной ситуации – если сервер не может получит ответ за необходимый период времени. Отклика нет и возникает таймаут. Как и 501-ый ответ, 504-ый исправить самостоятельно не получится. Здесь дело в прокси, часто – в веб-сервере. Первым делом просто обновите веб-страницу. Если не помогло, нужно почистить DNS-кэш. Для этого используем сочетание горячих клавиш Windows+R и вводим команду cmd (Control+пробел). В открывшемся окне указываем команду ipconfig / flushdns и подтверждаем ее нажатием Enter.

Также полезно посмотреть, как страница ведет себя различных мобильных устройствах и в разных браузерах. Проверьте дебаг. Если сайт на WP, то проверить дебан проще всего. Достаточно добавить этот код в wp-config.php:

Теперь все сбои будут фиксировать в файле debug.log (находится в папке wp-сontents). Если вы используете другую CMS, найдите к ней мануал и посмотрите, как активировать в ней журнал ошибок.

Также 504-ая отдает, когда на сайте существуют проблемы, связанные с задействованием CDN или кастомизированных серверов DNS. Отключите CDN на своем сайте.

Иногда 504-ый код пропадает, если просто подождать несколько часов. Часто 504-ая появляется на сайтах, которые используют CloudFlare.

505 – отсутствует поддержка текущей версии HTTP-протокола.

507 – не хватает места на жестком диске для выполнения запроса.

510 – не найдено расширение, желающее задействовать клиент.

Массово проверяем ответ веб-страницы

Самый простой способ проверить ответ веб-страницы – воспользоваться готовыми сервисами. Наиболее популярны:

• mainspy;
• 2ip;
• cy-pr;
• wwhois;
• 4seo.

Возьмем для примера mainspy. Тут проверить код ответа проще всего:

Таким образом, для проверки кода просто открываем страницу и вводим необходимые URL. Кликаем «Проверить». Будет выведен отчет. Напротив каждого проверяемого URL будет отображаться код ответа сервера:

Кроме перечисленных сервисов есть также замечательный плагин для Google Chrome – HTTP Header Spy. Он позволяет проверять код ответа сервера как одной, так и нескольких страниц сразу:

Послесловие

Коды ответа HTTP – это универсальный язык, который понимают не только краулеры Google / «Яндекса», но и люди. 5 классов кодов позволят с первого взгляда определить, где именно существует ошибка при выполнении HTTP запроса и куда копать для ее устранения.

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

24 мая, 2017 12:25 пп
4 869 views
| Комментариев нет

Linux, SSH

SSH – это основной метод доступа и управления виртуальными серверами. Работа с ошибками или сбоями SSH бывает сложной, потому что при этом вы теряете (или рискуете потерять) доступ к серверу. В этой серии статей рассматриваются наиболее распространенные проблемы, с которыми вы можете столкнуться при работе с SSH, способы их устранения, повторное развертывание и поддержка сервера после устранения ошибок.

Данное руководство научит вас:

• Определять, когда необходимо устранять неполадки (в некоторых случаях это не поможет: лучше мигрировать на новый сервер или выполнить повторное развёртывание).
• Анализировать ресурсы и определять навыки, необходимые для эффективного решения проблем SSH.

Рекомендации к повторному развёртыванию и миграции сервера

В некоторых ситуациях (например, после случайного запуска команд rm и chmod) ошибки SSH невозможно исправить.

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

• Поврежденные файловые системы.
• Неправильные привилегии файловой системы и владельцы файлов.
• Поврежденные системные пакеты и библиотеки.

Чтобы быстро вернуть сервер в оперативный режим, нужно определить, есть ли возможность восстановить SSH или же лучше сосредоточиться на восстановлении данных для повторного развёртывания сервера.

Обычно определить ошибки SSH при загрузке сервера можно по выводу запуска веб-консоли. Проблемы, связанные с файловой системой, или сбои при запуске консоли свидетельствуют о том, что устранение неполадок SSH – не лучший вариант. В таком случае лучше попытаться спасти как можно больше данных. Иногда восстановить рабочую среду можно с помощью резервных копий или снапшотов системы. Балансировщики нагрузки в отдельных случаях могут обеспечить быстрое восстановление и развёртывание сервера. Кроме того, вы можете обратиться за помощью в службу поддержки хостинг-провайдера.

Статья по теме: Балансировщики нагрузки и высокая доступность

Что нужно знать для устранения неполадок SSH

Если вы решили, что устранение неполадок SSH – наилучшее решение в сложившихся обстоятельствах, вам нужно собрать дополнительную информацию.

Ознакомьтесь с руководствами по SSH.

• Создание SSH-ключей для подключения к VPS с помощью PuTTY
• Установка SSH-соединения с VPS из браузера с помощью GateOne
• Использование SSH для подключения к удаленному серверу на Ubuntu

При устранении неполадок SSH обычно требуется доступ к консоли. Консоль – альтернативный способ подключения к серверу в случае сбоя SSH (при условии, что сервер запущен и у вас есть root-пароль).

Восстановление root-пароля

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

Статья по теме: Установка и изменение пароля на заблокированном сервере FreeBSD

Расширенный вывод

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

Клиент OpenSSH поддерживает расширенный вывод. Он включается с помощью флага –v.

ssh -v user@your_server_ip

Чем больше флагов v вы используете, тем подробнее вывод. Иногда достаточно использовать –v, но в отдельных случаях проблема видна только с помощью -vvv.

Клиент PuTTY поддерживает журнал событий (Event Log). Доступ к нему можно получить в окне приложения. Кроме того, PuTTY предоставляет возможность журналирования сессий.

Управление файлами и привилегиями

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

Статья по теме: Привилегии в Linux: что это и как с ними работать

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

Домашний каталог пользователя отмечается как ~. Пользователь с именем 8host найдёт настройки ssh в /home/8host/.ssh.

Проверка логов

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

Читайте также:

• Чтение и настройка логов в Ubuntu и Centos
• Основы Systemd: управление сервисами и журналирование

Кроме написания полезных статей 8HOST занимается хостингом VPS в Нидерландах с безлимитным трафиком всего от 4 евро в месяц!

Заключение

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

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

Tags: OpenSSH, PuTTY, SSH