Beget ошибка 500 - Исправление ошибок и поиск оптимальных решений проблем

Содержание

Как мне удалось вылечить ошибку 500
Опубликовано emanno
Волшебный файл .htaccess
Директивы простого перенаправления (редирект)
Директивы сложного перенаправления (mod_rewrite)
Индексные страницы
Обработка ошибок
Кодировка
Управление доступом
Паролирование директорий
Указание опций PHP

Как мне удалось вылечить ошибку 500

Сегодня мне очень помог мой хостинг Beget, про который я не устану повторять хорошие слова. Чтобы вы не подумали, что это проплаченный пиар, специально не вставляю рефссылку)).

Ситуация была такая. С Rotapost стали приходить сообщения, что задания на сайте kniganew.ru не проходят проверку. К чудачествам этой биржи я привык, поэтому особенно не обращал на них внимания. Но как оказалось, зря. Прошла неделя, а «неправильных» заданий становилось все больше. Что за фигня? Пошел проверять.

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

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

Ну, ладно — я не великий специалист в программировании, пошел на поклон к техподдержке Beget. Ребята ответили, что не видят проблем со своей стороны. Пишу обратно в Ротапост и получаю ответ:

Вероятно, Вашим хостером были заблокированы IP наших роботов (162.221.224.025,
162.221.224.046 ), которые проверяют доступность сайта, роботу возвращается ошибка 403 (доступ запрещен). Вам нужно обратиться к хостеру Вашего сайта, чтобы он исключил наши IP из заблокированных.

Бью челом обратно в beget с просьбой помочь. И парни мне помогли: оказалось, была синтаксическая ошибка в файле footer, который они отредактировали и все заработало!

Усиленно чешу репу и начинаю вспоминать, откуда ноги растут. Оказалось, что накосячил сам: несколько дней назад сменил шаблон вордпресс и отредактировал footer вручную (убрал левые ссылки). По невнимательности (да и матчасть хромает) я сделал это некорректно. Результат: хитрая ошибка 500, которую оказалось непросто определить!

Спасибо, хостинг Beget.ru!

ЗЫ. Из плохих новостей. Намедни случился апдейт ТИЦ и слетела десятка с книжного блога. На блог по диетам опять зеро. Пришлось давить жабу и вкладывать 1000 руб. на закупку вечных ссылок.

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

Опубликовано emanno

Здравствуйте, друзья! Меня зовут Михаил и я автор этого блога. Если у вас возникли вопросы, вы всегда можете связаться со мной по электронной почте или Асе. Загляните на страничку Контакты. Там расположена вся нужная информация. Посмотреть больше записей

Источник

Волшебный файл .htaccess

Apache — самый распространённый HTTP-сервер. Распространяется бесплатно, включая исходные тексты. Поддерживаются сценарии на CGI (включая FastCGI), PHP, Perl, Java. Аутентификация — базовая, message-digest, TLS (SSL). С апреля 1996 это самый популярный HTTP-сервер в Интернете, в августе 2007 года он работал на 51% всех веб-серверов.

.htaccess — файл дополнительной конфигурации веб-сервера Apache, а также подобных ему серверов. Позволяет задавать большое количество дополнительных параметров и разрешений для работы веб-сервера у отдельных пользователей (а также на различных папках отдельных пользователей), таких как управляемый доступ к каталогам, переназначение типов файлов и т.д., не предоставляя доступа к главному конфигурационному файлу, т.е. не влияя на работу всего сервиса целиком.

.htaccess является подобием httpd.conf с той разницей, что действует только на каталог, в котором располагается, и на его дочерние каталоги. Возможность использования .htaccess присутствует в любом каталоге пользователя.

Файл .htaccess может быть размещен в любом каталоге сайта. Директивы этого файла действуют на все файлы в текущем каталоге и во всех его подкаталогах (если эти директивы не переопределены директивами нижележащих файлов .htaccess).

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

Директивы простого перенаправления (редирект);
Директивы сложного перенаправления (mod_rewrite);
Индексные страницы;
Обработка ошибок;
Кодировка;
Управление доступом;
Паролирование директорий;
Указание опций PHP.

Список всех доступных директив можно посмотреть тут.

Директивы простого перенаправления (редирект)

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

Более сложный пример — мы хотим определенные страницы нашего сайта переадресовывать на другие сайты:

Теперь при обращении к http://mysite.ru/linux будет открываться http://www.linux.org, а при обращении к http://mysite.ru/linux/download.html будет http://www.linux.org/dist/download_info.html . В последнем примере WEB-сервер будет передавать код 301, что означает «документ перемещен постоянно».

Синтаксис команды Redirect выглядит следующим образом:

Директива RedirectMatch аналогична директиве Redirect за исключением того, что в RedirectMatch возможно использование регулярных выражений, что, несомненно, может быть удобно в некоторых условиях. Например, для организации передачи параметров скрипту в теле URL:

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

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

Круглые скобки () используются для выделения групп символов. В дальнейшем к ним можно обращаться по номеру.
Символ ^ обозначает начало строки.
Символ $ обозначает конец строки.
Символ . обозначает любой символ.
Символ | обозначает альтернативу. Например, выражения «A|B» означают «A или B».
Символ ? ставится после символа (группы), который может как присутствовать, так и отсутствовать.
Символ * ставится после символа (группы), который может отсутствовать или присутствовать неограниченное число раз подряд.
Символ + действует аналогично символу * с той лишь разницей, что предшествующий ему символ обязательно должен присутствовать хотя бы один раз.
Квадратные скобки [] используются для перечисления допустимых символов.
Квадратные скобки [^] используются для перечисления недоступных символов.
Символ ставится перед спецсимволами, если они нужны в своем первозданном виде.
Все, что расположено после символа ‘#‘, считается комментарием.

Это все основные примитивы, с помощью которых можно построить любое регулярное выражение.

Директивы сложного перенаправления (mod_rewrite)

Модуль mod_rewrite, имеющийся в составе Apache — это мощнейшее интеллектуальное средство преобразования URL-адресов. С ним возможны почти все типы преобразований, которые могут выполняться или нет в зависимости от разных условий, факторов.

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

Директива RewriteCond определяет условие, при котором происходит преобразование. RewriteCond определяет условия для какого-либо правила. Перед директивой RewriteRule располагаются одна или несколько директив RewriteCond. Следующее за ними правило преобразования используется только тогда, когда URI соответствует условиям этой директивы, а также условиям этих дополнительных директив.

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

$N — (0 Условие’ (лексически больше);
‘=Условие’ (лексически равно);
‘-d’ (является ли каталогом);
‘-f’ (является ли обычным файлом);
‘-s’ (является ли обычным файлом с ненулевым размером);
‘-l’ (является ли символической ссылкой);
‘-F’ (проверка существования файла через подзапрос);
‘-U’ (проверка существования URL через подзапрос).

Все эти проверки также могут быть предварены префиксом восклицательный знак (‘!’) для инвертирования их значения.

RewriteEngine включает или выключает работу механизма преобразования. Если она установлена в положение off, этот модуль совсем не работает. Заметьте, что по умолчанию настройки преобразований не наследуются. Это означает, что вы должны иметь RewriteEngine on директиву для каждого виртуального хоста, в котором вы хотите использовать этот модуль.
Синтаксис RewriteEngine выглядит следующим образом:

Используйте для комбинирования условий в правилах OR вместо AND. Типичный пример — перенаправление запросов на поддомены в отдельные каталоги.

Для выдачи главной страницы какого-либо сайта, согласно «User-Agent:» заголовку запроса, Вы можете использовать следующие директивы:

Для выдачи разных сайтов для разных браузеров, согласно «User-Agent:» заголовку запроса, Вы можете использовать следующие директивы:

Общий синтаксис директивы RewriteRule выглядит следующим образом:

В подстановке вы можете использовать, в том числе, и специальные флаги путем добавления в качестве третьего аргумента директивы RewriteRule. Флаги — это разделённый запятыми следующий список флагов:

Префикс в Подстановке вида http://thishost[thisport]/ (создающий новый URL из какого-либо URI) запускает внешний редирект (перенаправление). Если нет никакого кода, в подстановке ответ будет со HTTP статусом 302 (ВРЕМЕННО ПЕРЕМЕЩЕН). Для остановки процесса преобразования вам также нужно написать флаг ‘L’.

Это делает текущий URL запрещённым, например, клиенту немедленно отправляется ответ с HTTP статусом 403 (ЗАПРЕЩЕНО). Используйте этот флаг в сочетании с соответствующими RewriteConds для блокирования URL по некоторым критериям.

Этот флаг делает текущий URL «мертвым», т.е., немедленно отправляется HTTP ответ со статусом 410 (GONE). Используйте этот флаг для маркировки «мертвыми» несуществующие более страницы.

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

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

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

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

Принудительно установить MIME-тип целевого файла в MIME-тип. К примеру, это можно использовать для имитации mod_alias директивы ScriptAlias, которая принудительно устанавливает для всех файлов внутри отображаемого каталога MIME тип равный «application/x-httpd-cgi».

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

Это делает Шаблон нечувствительным к регистру, т.е. нет различий между ‘A-Z’ и ‘a-z’, когда Шаблон применяется к текущему URL.

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

Этот флаг не даёт mod_rewrite применять обычные правила экранирования URI к результату преобразования. Обычно, специальные символы (такие как ‘%’, ‘$’, ‘;’, и так далее) будут экранированы их шестнадцатиричными подстановками (‘%25’, ‘%24’, и ‘%3B’, соответственно); этот флаг не дает это делать.

Если в подкаталогах в .htaccess нет ни одной директивы модуля mod_rewrite, то все правила преобразования наследуются из родительского каталога.

При наличии в файле .htaccess каких-либо директив модуля mod_rewrite не наследуется ничего, а состояние по умолчанию выставляется таким же, как в главном конфигурационном файле веб-сервера (по умолчанию «off»). Поэтому, если нужны правила преобразования для конкретного каталога, то нужно еще раз вставить директиву «RewriteEngine on» в .htaccess для конкретного каталога.

При наследовании правил из верхних каталогов и добавлении к ним новых свойственных только данному каталогу — необходимо выставить в начале следующее: «RewriteEngine on» и «RewriteOptions inherit» — последняя директива сообщает серверу о продолжении.

Примеры использования mod_rewrite можно посмотреть тут.

Индексные страницы

Когда пользователь заходит на хост, например, http://gentoo.org, принято, что открывается индексный файл index.* , а при его отсутствии отображается либо содержимое каталога, либо отдается ошибка 403 FORBIDDEN (если отключена опция «просмотр директорий»).

За листинг файлов отвечает директива Indexes (показывать посетителю список файлов, если в выбранном каталоге нет файла index.html или его аналога).

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

А чтобы выдавал листинг, нужно:

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

Выдает листинг каталога, т.е. его содержание со всем содержанием, за исключением файлов-скриптов PHP и Perl.

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

Если же вы хотите что бы при обращении к каталогу открывался не index.html, а, например, файл htaccess.php или /cgi-bin/index.pl:

Обработка ошибок

В ходе работы сервера иногда возникают ошибки, однако правильнее называть их не сбоями в работе сервера, а стандартными кодами возврата, оговоренными в стандарте HTTP_RFC2616. Вообще, в RFC ошибки называются «Status Codes», но мы их будем называть именно ошибками — так привычнее.

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

Вот список ошибок 4xx и 5xx:

400 — Bad Request
401 — Unauthorized
402 — Payment Required
403 — Forbidden
404 — Not Found
405 — Method Not Allowed
406 — Not Acceptable
407 — Proxy Authentication Required
408 — Request Time-out
409 — Conflict
410 — Gone
411 — Length Required
412 — Precondition Failed
413 — Request Entity Too Large
414 — Request-URI Too Large
415 — Unsupported Media Type
500 — Internal Server Error
501 — Not Implemented
502 — Bad Gateway
503 — Service Unavailable
504 — Gateway Time-out
505 — HTTP Version not supported

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

Пример переопределения страниц ошибок приведен ниже:

Более подробно об обработке ошибок можно прочитать в документации по Apache на странице «Custom error responses».

Кодировка

Иногда браузер пользователя не может корректно определить тип кодировки выдаваемого документа. Для решения этой проблемы используемая кодировка указывается в настройках Web-сервера Apache и заголовке передаваемого документа. Причем для корректного распознания эти кодировки должны совпадать. На наших серверах по умолчанию используется кодировка UTF-8.

В HTML для указания кодировки используется тег:

Наиболее часто встречаются типы кодировки для русского языка передаваемые в заголовке документа:

Windows-1251 — Кириллица (Windows).
KOI8-r — Кириллица (КОИ8-Р).
cp866 — Кириллица (DOS).
Windows-1252 — Западная Европа (Windows).
Windows-1250 — Центральная Европа (Windows).
UTF-8 — двух байтовая кодировка.

Теперь рассмотрим указание кодировки по умолчанию через .htaccess. AddDefaultCharset задает дефолтную таблицу символов (кодировку) для всех выдаваемых страниц на веб-сервере Apache. Указываем кодировку на все файлы, в которой по умолчанию получает документы браузер:

При загрузке файла на сервер возможна перекодировка. Указываем, что все получаемые файлы будут иметь кодировку windows-1251, для этого напишем:

Если необходимо отменить перекодировку сервером файлов:

Управление доступом

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

Для запрета или разрешения доступа ко всем файлам и папкам в текущей и во всех вложенных директориях используется директива Order, синтаксис ее очень прост:

В зависимости от того, в каком порядке указаны директивы, меняется логика работы сервера. В случае, если Deny,Allow, то запрещается доступ со всех IP кроме оговоренных, в случае, если Allow,Deny, разрешается доступ со всех IP кроме оговоренных. Далее должны идти секции описания для доступа и запрета. Ключевое слово all означает со всех IP.

Например, мы хотим запретить (блокировать) доступ с IP 81.222.144.12 и 81.222.144.20 и разрешить всем остальным. Нам необходимо добавить в .htaccess следующий код:

Для обратной ситуации, когда мы хотим запретить доступ со всех IP кроме 81.222.144.12 и 81.222.144.20, нам необходимо добавить в .htaccess следующий код:

Запрет или разрешение на доступ можно указывать не только на все файлы, но так же можно указывать на отдельный файл или группы файлов. Например, мы хотим запретить доступ всех пользователей, кроме IP 81.222.144.12, к файлу passwd.html, который расположен в текущей директории:

Так же можно запретить или разрешить доступ к определенной группе файлов. Например, к файлам с расширением «.key«:

Паролирование директорий

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

Данный файл нужно положить в ту директорию, на которую мы хотим поставить пароль.

Директива AuthName выводит сообщение при запросе пароля, все сообщение необходимо писать в одну строчку, синтаксис директивы тривиален:

Директива AuthType выбирает тип аутентификации. Возможны следующие типы: Basic или Digest. Второй может не поддерживаться некоторыми браузерами, поэтому пользоваться им не рекомендуется.

AuthUserFile указывает имя файла с паролями для аутентификации пользователей (пароли в этом файле будут шифрованными). Путь к файлу с паролями задается относительно корня веб-сервера. Храните файл с паролями в папке, доступ к которой закрыт для пользователей. Желательно поместить этот файл вне иерархии вашего веб-сайта, например, рядом с каталогом public_html. Размещать его выше каталога сайта нецелесообразно. Это не увеличит безопасность, но потребует дополнительной настройки прав доступа в связи с изоляцией сайтов.

Если у Вас установлена операционная система семейства Windows, Вы можете подключится к серверу по SSH (инструкцию по подключению можно найти тут) и воспользоваться утилитой htpasswd.

Запустив htpasswd без параметров мы увидим:

Здесь не будут рассматриваться все параметры этой команды, но вы можете сами прочитать подробности, запустив htpasswd в unix shell, или ознакомившись с соответствующей страницей документации по Apache.

Итак, изначально у нас еще нет файла с паролями и нам нужно его создать:

После выполнения данной операции htpasswd создаст файл passwords, в котором окажется пользователь test1 и его пароль в зашифрованном виде:

А теперь мы хотим добавить еще одного пользователя. Так как файл с паролями у нас уже есть, мы просто не будем использовать ключ ‘-c’:

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

Указывая valid-user, Вы разрешаете доступ всем пользователям, перечисленным в файле паролей.

Приведем пример для доступа определенных пользователей из файла с паролями .htpasswd:

Также, как и с запретом доступа по IP, здесь можно использовать расширение . Ниже приведены два примера: установки пароля на один определенный файл и на группу файлов.

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

Указание опций PHP

Директивы для конфигурирования PHP можно размещать не только в файле php.ini, но также и в конфигурационных файлах Apache для вашего сайта – .htaccess. Это позволяет проводить тонкую настройку php для разных директорий.

Для работы с PHP в конфигурационных файлах Apache доступны 4 директивы: php_value, php_flag, php_admin_value, php_admin_flag, которые отличаются значимостью, типом устанавливаемых значений и местом применения.

Директивы php_admin_value, php_admin_flag выставляются только в файле httpd.conf, так что нам они не интересны. По сути, данные директивы переопределяют значение остальных директив.

Директива php_flag служит для установки логических значений директив в php.ini, в то время как директива php_value служит для установки строковых и числовых значений директив php.ini, т.е. любых типов значений, за исключением логических.

Синтаксис директив очень прост:

Приведем перечень наиболее часто используемых директив:

mysql.default_host — Устанавливает имя хоста базы данных.
Пример: php_value mysql.default_host localhost
mysql.default_user — Устанавливает имя пользователя базы данных.
Пример: php_value mysql.default_user alexey
mysql.default_password — Устанавливает пароль пользователя базы данных.
Пример: php_value mysql.default_password Hry5Gw2
display_errors — Разрешает вывод ошибок и предупреждений в браузер.
Пример: php_flag display_errors 0
display_startup_errors — Включает отображение ошибок, возникающих при запуске PHP.
Пример: php_flag display_startup_errors 0
error_reporting — Определяет типы (уровни важности) фиксируемых ошибок.
Пример: php_value error_reporting 32767
auto_prepend_file — Определение файла, который будет выводится в начале каждого php-скрипта. Путь указывается от корня файловой системы сервера.
Пример: php_value auto_prepend_file /www/server/prepend.php
auto_append_file — Определение файла, который будет выводится в конце каждого php-скрипта.
Пример: php_value auto_append_file /www/server/append.php
sendmail_from — Устанавливает e-mail отправителя, который применяется при отправке почтовых сообщений с помощью PHP.
Пример: php_value sendmail_from root@beget.com
user_agent — Устанавливает строку User-agent, которая используется PHP при обращении к удаленным серверам.
Пример: php_value user_agent “Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)”

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

Для запрещения выполнения php в текущей директории и во всех вложенных, необходимо в .htaccess прописать следующие строки:

Удачной работы! Если возникнут вопросы — напишите нам, пожалуйста, тикет из Панели управления аккаунта, раздел «Помощь и поддержка».

Источник

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

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

Вероятно, Вашим хостером были заблокированы IP наших роботов (162.221.224.025,
162.221.224.046 ), которые проверяют доступность сайта, роботу возвращается ошибка 403 (доступ запрещен). Вам нужно обратиться к хостеру Вашего сайта, чтобы он исключил наши IP из заблокированных.

Спасибо, хостинг Beget.ru!

Здравствуйте, друзья! Меня зовут Михаил и я автор этого блога. Если у вас возникли вопросы, вы всегда можете связаться со мной по электронной почте или Асе.
Загляните на страничку Контакты. Там расположена вся нужная информация.
Посмотреть больше записей

Источник

Внутрь public_html нужно класть весь проект

В том то и проблема, что я так делал, а затем делал редирект через ИндексДериктору внутри htaccess на точку входа. Но мне не понравился результат. Мне приходилось ручками менять все ссылки на подключаемые ресурсы с /css/resurs.css на public/css/resurs.css. Это явный фейл. Как только я что-то отредактирую в шаблоне, так после копирования файла все это проделываю заново.

на Бегете доступны директории выше корня вебсервера

А подскажите пошагово что нужно подправить у себя при переносе, а что на самом хостинге? Первый раз делаю, уже чего только не пробовал. Везде дают разные советы, разные настройки htaccess. Перепробовал их, что-то не так делаю. А пробовать всевозможные комбинации, которые советуют — это можно недели убить.
Один из вопросов: нужно ли как-то после переноса системы запускать установку и апдейт композера? Вопрос возник вчера после того, как я заархивировал весь проект товарищу и он не смог запустить его у себя на локалхосте. После установки и апдейта композера все заработало. Пожет мне что-то подобное нужно сделать и на хостинге?
Вот что я исправлял у себя в проекте перед переносом:

В index.php
$this->app->bind(‘path.public’, function() {
return _DIR_ . ‘/../../public_html’;
});

В файле webpack.mix.js в начале mix.setPublicPath(‘public_html’);
Этого достаточно?

и + если тариф не бесплатный можно направить вебсервер на любую директорию

у меня первый месяц бесплатный

Источник

Директивы простого перенаправления (редирект);
Директивы сложного перенаправления (mod_rewrite);
Индексные страницы;
Обработка ошибок;
Кодировка;
Управление доступом;
Паролирование директорий;
Указание опций PHP.

Список всех доступных директив можно посмотреть тут.

Директивы простого перенаправления (редирект)

Redirect / http://www.example.com
# http://www.example.com - URL, на который мы перенаправляем запросы

Более сложный пример — мы хотим определенные страницы нашего сайта переадресовывать на другие сайты:

Redirect /linux http://www.linux.org
Redirect /linux/download.html http://www.linux.org/dist/download_info.html
Redirect 301 /kernel http://www.linux.org

Синтаксис команды Redirect выглядит следующим образом:

Redirect [status] URI_LOCAL URL_REDIRECT

status : необязательное поле, определяет код возврата. Допустимые значения:

    * permanent (301 — документ перемещен постоянно)
    * temp (302 — документ перемещен временно)
    * seeother (303 — смотрите другой)
    * gone (410 — убран)

URI_LOCAL : локальная часть URL запрашиваемого документа.

URL_REDIRECT : URL, куда должен быть выполнен редирект.

RedirectMatch /(.*)/(.*)/index.html$ http://mysite.ru/script.php?par1=$1&par2=$2

Круглые скобки () используются для выделения групп символов. В дальнейшем к ним можно обращаться по номеру.
Символ ^ обозначает начало строки.
Символ $ обозначает конец строки.
Символ . обозначает любой символ.
Символ | обозначает альтернативу. Например, выражения «A|B» означают «A или B».
Символ ? ставится после символа (группы), который может как присутствовать, так и отсутствовать.
Символ * ставится после символа (группы), который может отсутствовать или присутствовать неограниченное число раз подряд.
Символ + действует аналогично символу * с той лишь разницей, что предшествующий ему символ обязательно должен присутствовать хотя бы один раз.
Квадратные скобки [] используются для перечисления допустимых символов.
Квадратные скобки [^] используются для перечисления недоступных символов.
Символ ставится перед спецсимволами, если они нужны в своем первозданном виде.
Все, что расположено после символа ‘#‘, считается комментарием.

Это все основные примитивы, с помощью которых можно построить любое регулярное выражение.

Директивы сложного перенаправления (mod_rewrite)

$N — (0 <= N <= 9) предоставляющие доступ к сгруппированным частям (в круглых скобках!) шаблона из соответствующей директивы RewriteRule (единственной, следующей сразу за текущим набором директив RewriteCond).
%N — (1 <= N <= 9) предоставляющие доступ к сгруппированным частям (в круглых скобках!) шаблона из соответствующей директивы RewriteCond в текущем наборе условий.
%{NAME_OF_VARIABLE} — где NAME_OF_VARIABLE может быть одной из ниже приведенных переменных

Ниже приводится список всех доступных переменных %{NAME_OF_VARIABLE} с их кратким описанием.

HTTP_USER_AGENT — Содержит информацию о типе и версии браузера и операционной системы посетителя.
HTTP_REFERER — Приводится адрес страницы, с которой посетитель пришёл на данную страницу.
HTTP_COOKIE — Список COOKIE, передаваемых браузером.
HTTP_FORWARDED — Cодержит IP-адрес прокси-сервера или сервера балансировки нагрузки.
HTTP_HOST — Адрес сервера, например, beget.com .
HTTP_ACCEPT — Описываются предпочтения клиента относительно типа документа.
REMOTE_ADDR — IP-адрес посетителя.
REMOTE_HOST — Адрес посетителя в нормальной форме — например, rt99.net.ru .
REMOTE_IDENT — Имя удаленного пользователя. Имеет формат имя.хост, например, kondr.www.rtt99.net.ru
REMOTE_USER — Тоже, что и REMOTE_IDENT, но содержит только имя. Пример: kondr
REQUEST_METHOD — Позволяет определить тип запроса (GET или POST). Должен обязательно анализироваться, т.к. определяет дальнейший способ обработки информации.
SCRIPT_FILENAME — Полный путь к веб-странице на сервере.
PATH_INFO — Содержит в себе все, что передавалось в скрипт.
QUERY_STRING — Содержит строчку, переданную в качестве запроса при вызове CGI скрипта.
AUTH_TYPE — Используется для идентификации пользователя
DOCUMENT_ROOT — Cодержит путь к корневой директории сервера.
SERVER_ADMIN — Почтовый адрес владельца сервера, указанный при установке.
SERVER_NAME — Адрес сервера, например, kondr.beget.com
SERVER_ADDR — IP-адрес вашего сайта.
SERVER_PORT — Порт, на котором работает Apache.
SERVER_PROTOCOL — Версия HTTP протокола.
SERVER_SOFTWARE — Название сервера, например, Apache/1.3.2 (Unix)
TIME_YEAR, TIME_MON, TIME_DAY, TIME_HOUR, TIME_MIN, TIME_SEC, TIME_WDAY, TIME — Переменные, предназначенные для работы со временем в разных форматах.
API_VERSION — Это версия API модуля Apache (внутренний интерфейс между сервером и модулем) в текущей сборке сервера, что определено в include/ap_mmn.h.
THE_REQUEST — Полная строка HTTP-запроса, отправленная браузером серверу (т.е., «GET /index.html HTTP/1.1»). Она не включает какие-либо дополнительные заголовки отправляемые браузером.
REQUEST_URI — Ресурс, запрошенный в строке HTTP-запроса.
REQUEST_FILENAME — Полный путь в файловой системе сервера к файлу или скрипту, соответствующему этому запросу.
IS_SUBREQ — Будет содержать текст «true», если запрос выполняется в текущий момент как подзапрос, «false» в другом случае. Подзапросы могут быть сгенерированы модулями, которым нужно иметь дело с дополнительными файлами или URI для того, чтобы выполнить собственные задачи.

Условие — это шаблон условия, т.е. какое-либо регулярное выражение, применяемое к текущему экземпляру «Сравниваемая Строка», т.е. «Сравниваемая Строка» просматривается на поиск соответствия Условию.

Помните, что Условие — это perl-совместимое регулярное выражение с некоторыми дополнениями:

Вы можете предварять строку шаблона префиксом ‘!’ для указания несоответствия шаблону;
‘ <Условие’ (лексически меньше);
‘>Условие’ (лексически больше);
‘=Условие’ (лексически равно);
‘-d’ (является ли каталогом);
‘-f’ (является ли обычным файлом);
‘-s’ (является ли обычным файлом с ненулевым размером);
‘-l’ (является ли символической ссылкой);
‘-F’ (проверка существования файла через подзапрос);
‘-U’ (проверка существования URL через подзапрос).

RewriteEngine on | off

# По умолчанию RewriteEngine off

RewriteEngine on

RewriteCond %{REMOTE_HOST} ^mysubdomain1.* [OR]
RewriteCond %{REMOTE_HOST} ^mysubdomain2.* [OR]
RewriteCond %{REMOTE_HOST} ^mysubdomain3.*
RewriteRule ^(.*)$ ^mysubdomain_public_html/$1

RewriteCond %{REMOTE_HOST} ^mysubdomain4.*
RewriteRule ^(.*)$ ^mysubdomain4_public_html/$1

RewriteEngine on

RewriteCond %{HTTP_USER_AGENT} ^Mozilla.*
RewriteRule ^$ /homepage.max.html [L]

RewriteCond %{HTTP_USER_AGENT} ^Lynx.*
RewriteRule ^$ /homepage.min.html [L]

RewriteRule ^$ /homepage.std.html [L]

RewriteEngine on

RewriteCond %{HTTP_USER_AGENT} ^Mozilla.*
RewriteRule ^(.*)$ /mozilla/$1 [L]

RewriteCond %{HTTP_USER_AGENT} ^Lynx.*
RewriteRule ^(.*)$ /lynx/$1 [L]

RewriteRule ^(.*)$ /default/$1 [L]

Общий синтаксис директивы RewriteRule выглядит следующим образом:

RewriteRule Шаблон Подстановка [flag]

# flag - необязательное поле указывающее дополнительные опции

'redirect|R [=code]'
(вызывает редирект)

'forbidden|F [=code]' 
(делает URL запрещенным)

'gone|G [=code]' 
(делает URL «мёртвым»)

'proxy|P [=code]' 
(вызвает прокси)

'last|L [=code]' 
(последнее правило)

'next|N [=code]' 
(следуюший раунд)

'chain|C [=code]' 
(связь со следующим правилом)

'type|T=MIME-тип [=code]'
(принудительно установить MIME тип)

'nosubreq|NS [=code]'
(используется только в случае не внутреннего подзапроса)

'nocase|NC [=code]' 
(не учитывать регистр)

'qsappend|QSA [=code]' 
(добавлять строку запроса)

'noescape|NE [=code]' 
(не экранировать URI при выводе)

Примеры использования mod_rewrite можно посмотреть тут.

Индексные страницы

# Запрет выдачи листинга пустого каталога
Options -Indexes

А чтобы выдавал листинг, нужно:

Выдает листинг каталога, т.е. его содержание со всем содержанием, за исключением файлов-скриптов PHP и Perl.

DirectoryIndex index.html index.shtml index.pl index.cgi index.php

DirectoryIndex htaccess.php /cgi-bin/index.pl

Обработка ошибок

Вот список ошибок 4xx и 5xx:

400 — Bad Request
401 — Unauthorized
402 — Payment Required
403 — Forbidden
404 — Not Found
405 — Method Not Allowed
406 — Not Acceptable
407 — Proxy Authentication Required
408 — Request Time-out
409 — Conflict
410 — Gone
411 — Length Required
412 — Precondition Failed
413 — Request Entity Too Large
414 — Request-URI Too Large
415 — Unsupported Media Type
500 — Internal Server Error
501 — Not Implemented
502 — Bad Gateway
503 — Service Unavailable
504 — Gateway Time-out
505 — HTTP Version not supported

Пример переопределения страниц ошибок приведен ниже:

# содержание файла .htaccess:

ErrorDocument 404 http://bg10.ru/error/404.htm
ErrorDocument 403 http://bg10.ru/error/403.htm
ErrorDocument 400 http://bg10.ru/error/400.htm
ErrorDocument 500 http://bg10.ru/error/500.htm

# в случае ошибки "FORBIDDEN" показывается текстовое сообщение, которое
# обязательно должно начинаться с кавычки, кавычка в сообщении не выводится:

ErrorDocument 403 "Sorry can't allow you access today, 403 Status Codes Apache"

Более подробно об обработке ошибок можно прочитать в документации по Apache на странице «Custom error responses».

Кодировка

В HTML для указания кодировки используется тег:

Наиболее часто встречаются типы кодировки для русского языка передаваемые в заголовке документа:

Windows-1251 — Кириллица (Windows).
KOI8-r — Кириллица (КОИ8-Р).
cp866 — Кириллица (DOS).
Windows-1252 — Западная Европа (Windows).
Windows-1250 — Центральная Европа (Windows).
UTF-8 — двух байтовая кодировка.

AddDefaultCharset WINDOWS-1251

CharsetSourceEnc WINDOWS-1251

Если необходимо отменить перекодировку сервером файлов:

Управление доступом

Order [Deny,Allow] | [Allow,Deny]

# По умолчанию Deny,Allow

Order Allow,Deny
Allow from all
Deny from 81.222.144.12 81.222.144.20

Order Deny,Allow
Deny from all
Allow from 81.222.144.12 81.222.144.20

<Files "passwd.html">
  Order Deny,Allow
  Deny from all
  Allow from 81.222.144.12
</Files>

<Files ".(key)$">
  Order Deny,Allow
  Deny from all
  Allow from 81.222.144.12
</Files>

Паролирование директорий

AuthName "Protected area, need authorization"
AuthType Basic
AuthUserFile /home/t/test/.authfile
require valid-user

Данный файл нужно положить в ту директорию, на которую мы хотим поставить пароль.

Запустив htpasswd без параметров мы увидим:

beget@ginger ~ # htpasswd
   Usage:
   htpasswd [-cmdps] passwordfile username
   htpasswd -b[cmdps] passwordfile username password
   -c Create a new file.
 beget@ginger ~ #

Итак, изначально у нас еще нет файла с паролями и нам нужно его создать:

beget@ginger ~ # htpasswd -c authfile test1
   New password:
   Re-type new password
   Adding password for user test1
 beget@ginger ~ #

beget@ginger ~ $ cat .authfile
   test1:zgco1KREjBY8M
beget@ginger ~ $

beget@ginger ~ # htpasswd .authfile test2
   New password:
   Re-type new password:
   Adding password for user test2

beget@ginger ~ $ cat .authfile
   test1:zgco1KREjBY8M
   test2:eN3uA6t0kzV1c
beget@ginger ~ $

Require USER_NAME | valid-user

Указывая valid-user, Вы разрешаете доступ всем пользователям, перечисленным в файле паролей.

Приведем пример для доступа определенных пользователей из файла с паролями .htpasswd:

AuthName "Protected area, need authorization"
AuthType Basic
AuthUserFile /home/t/test/.authfile
require Alexey Kondr Fenix

Также, как и с запретом доступа по IP, здесь можно использовать расширение <Files> . Ниже приведены два примера: установки пароля на один определенный файл и на группу файлов.

<Files "passwd.html">
  AuthName "Protected area, need authorization"
  AuthType Basic
  AuthUserFile /home/t/test/.authfile
  require valid-user
</Files>

<Files ".(key)$">
  AuthName "Protected area, need authorization"
  AuthType Basic
  AuthUserFile /home/t/test/.authfile
  require valid-user
</Files>

Указание опций PHP

Синтаксис директив очень прост:

php_flag  имя директивы on | off
php_value  имя директивы VALUE

Приведем перечень наиболее часто используемых директив:

mysql.default_host — Устанавливает имя хоста базы данных.
Пример: php_value mysql.default_host localhost
mysql.default_user — Устанавливает имя пользователя базы данных.
Пример: php_value mysql.default_user alexey
mysql.default_password — Устанавливает пароль пользователя базы данных.
Пример: php_value mysql.default_password Hry5Gw2
display_errors — Разрешает вывод ошибок и предупреждений в браузер.
Пример: php_flag display_errors 0
display_startup_errors — Включает отображение ошибок, возникающих при запуске PHP.
Пример: php_flag display_startup_errors 0
error_reporting — Определяет типы (уровни важности) фиксируемых ошибок.
Пример: php_value error_reporting 32767
auto_prepend_file — Определение файла, который будет выводится в начале каждого php-скрипта. Путь указывается от корня файловой системы сервера.
Пример: php_value auto_prepend_file /www/server/prepend.php
auto_append_file — Определение файла, который будет выводится в конце каждого php-скрипта.
Пример: php_value auto_append_file /www/server/append.php
sendmail_from — Устанавливает e-mail отправителя, который применяется при отправке почтовых сообщений с помощью PHP.
Пример: php_value sendmail_from root@beget.com
user_agent — Устанавливает строку User-agent, которая используется PHP при обращении к удаленным серверам.
Пример: php_value user_agent “Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)”

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

php_flag  display_errors 1
php_flag  display_startup_errors 1
php_value  error_reporting 2047

Источник

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

Что значит ошибка 500

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

В итоге возникает сообщение вида:

Для неподготовленного пользователя это просто апокалипсис! Изображение взято в рамку для устрашения

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

Обратите внимание, что за 500-ю ошибку (как и другие ошибки, начинающиеся с «пятерки») несут ответственность либо администраторы сервера, либо веб-разработчики. И только в исключительных случаях — пользователи.

Что не поможет, если возникла 500-я ошибка

Перезагрузка компьютера. В сетевой архитектуре он является клиентом, т.е. не он вызывает проблему.
Смена браузера. Даже если до этого Google Chrome всегда помогал, когда подводил Firefox, в этот раз он едва ли поможет. Еще и на программу просто так обидитесь!
Переустановка программного обеспечения. Это будет иметь призрачный шанс на успех, если только у вас установлено совсем старое ПО, которой разработчики в принудительном порядке закрыли доступ в интернет.
Перезагрузка роутера / перетыкание проводов. Это решение для неисправности сети в целом — и то не всегда.

Как действовать, если ошибка 500 появилась на чужом сайте

Выждать. Если вы не являетесь администратором ресурса, то не сможете посмотреть и изменить файл настроек, покопаться в сайте и попытаться исправить что-то там и т. п. Ждем, когда администратор решит проблему, и через некоторое время повторяем попытку открыть нужную страницу.
Связаться с техподдержкой. Конечно, здорово, когда за сайтом следят в режиме 24/7, но бывает и так, что администратор просто отсутствовал на месте и не знает, что сайт уже 2 часа как «лежит».

Если вам позарез нужна нужная страница, можно открыть ее сохраненную копию:

Ничто не помешает вам изучить список самых красивых рыб в мире!

Как действовать, если ошибка 500 появилась на вашем сайте

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

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

Посмотрите, что в файле .htaccess

У всех сайтов на Apache при получении FTP-доступа можно увидеть в корневой папке файл .htaccess, содержащий все серверные настройки.

Этот файл с моего сайта выглядит следующим образом:

Так выглядит содержимое .htaccess для CMS WordPress

Чаще всего сайты могут функционировать и без него. То есть вы можете добавить в имя файла какой-то символ (например, .htaccess 1) и потом снова зайти на проблемную страницу.

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

Также в ряде случаев можно найти строку, которая начинается с Options (вы можете увидеть ее на изображении выше) и закомментировать ее с помощью символа решетки — «#». Если не помогло, комментируйте другие строки в файле, а потом по очереди снимайте «решетку» — возможно, так вы выявите ошибочную запись.

Также дело может быть в разграничении прав доступа при внесении изменений в файл. У хостера может стоять запрет на изменение содержимого файла. Надо скачать файл на свой ПК и через «Блокнот», Notepad++ или любой другой текстовый редактор изменить .htaccess и загрузить на сайт с заменой предыдущей версии файла.

Изучите лог ошибок сервера

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

Для своего сайта я сгенерировал журнал FTP-сервера. Хостер — Beget

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

Теперь ясно, по каким адресам искать журнал доступа (пока не активен) и журнал ошибок (активирован)

Удалите или отключите недавно установленные плагины или компоненты

Если у вас на сайте (WordPress — ярчайший пример) установлено много плагинов, они могут вступить в конфликт и блокировать действия друг друга. Такое может привести к уже ставшей родной ошибке 500 и прочим неприятностям.

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

Оптимизируйте скрипты

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

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

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

Увеличьте объем оперативной памяти сервера

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

Запросите поддержку

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

Русскоязычный форум Mozilla.
IT-форум вебмастеров и разработчиков.
Киберфорум.
Форум сайтостроения.

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

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

Итоги. 6 рекомендаций по исправлению 500 Server Internal Error

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

Тем не менее, вы можете попробовать сделать эти шаги, чтобы ускорить устранение ошибки:

Просто перезагрузите нужную страницу с помощью клавиши F5 или клавиатурного сочетания Ctrl-К. Также можно повторить ввод адреса в строку браузера (иногда одно это снимает проблему, потому что вы просто ошиблись с его содержимым).
Серверная ошибка может быть оперативно устранена техподдержкой сервера. Порой сбойная страница спокойно загружается уже через пять минут. Свяжитесь с представителями ресурса. Если там работают ответственные люди, они наверняка в курсе возникшей проблемы и пытаются ее решить. Если же не в курсе, вы можете стать «спасителем» и косвенно способствовать восстановлению работоспособности страницы. Если сайт весь ушел в 500-ю ошибку, можно узнать владельцев сайта через специальный сервис и попробовать написать им по электронной почте или даже позвонить.
Из сферы ecommerce: допустим, вы оформляете заказ на маркетплейсе, а в это время на странице появляется 500 Internal Server Error. Если не остановиться и продолжать делать заказ, очень может статься, что вы создадите и подтвердите сразу несколько заказов одного и того же товара, причем все они будут оплачены. Да, почти все площадки онлайн-торговли имеют защиту от дублирующихся транзакций, но все же нужно иметь подобное в виду и не пытаться завершить заказ, если такая ошибка возникла во время его совершения.
Проведите чистку браузера. Дело в том, что целевая страница может закешироваться и все время отдавать 500-ю ошибку. Конечно, проблемы со стороны сервера редко связаны с кешированием, но все же стоит воспользоваться встроенным инструментарием браузера для очистки кеша или специализированным ПО типа CCleaner или Reg Organizer.
Удалите все cookie-файлы. Иногда это также помогает устранить неполадки, которые связаны с 500-ой ошибкой. Это можно сделать с помощью озвученных в предыдущем пункте программ. Главное, чтобы браузер был закрыт. После этого нужно снова его открыть и заново загрузить нужную страницу.
Просто выждите некоторое время. Почти всегда дело не в вас, и остается просто перетерпеть неприятность. Можно также посмотреть похожие на целевую страницы, если это возможно.

Источник

30.01.21 — 20:29
30 просмотров

В какой-то момент, что я не успел зафиксировать, у меня перестал отображаться новый сайт. Включай этот. Как в дальнейшем оказалось, я сменил имя пользователя у БД. По дефолту и имя пользователя, и имя БД должно совпадать. Я изменил имя. У меня стала выскакивать ошибка:

The website encountered an unexpected error. Please try again later.

В инспекторе отображалось следующее:

GET https://portfolio.creozavr.com/ 500 (500 Service unavailable (with message))

Я обновил все пакеты через Composer, но не помогло. Залез в Drush и выполнил следующую команду:

drush uli

Дабы посмотреть подключен ли я в качестве админа. Мне Drush выдал на это:

In Connection.php line 423:
                                                                                                    
  SQLSTATE[HY000] [1045] Access denied for user 'login'@'localhost' (using password: YES)  
                                                                                                    
In Connection.php line 416:
                                                                                                    
  SQLSTATE[HY000] [1045] Access denied for user 'login'@'localhost' (using password: YES)

И меня осенило, что имя пользователя я поменял. Вернул все в дефолтный вид и сайт доблестно заработал вновь..

Источник

Если вы не имеете никакого отношения к сайту, на котором возникла данная ошибка, то вам просто нужно ждать, пока администратор изменит ситуацию и сайт вновь возобновит свою работу. Но в том случае, если вы являетесь владельцем сайта, на котором возникла ошибка 500 «Internal Server Error», постарайтесь вспомнить, какие именно изменения и когда вы вносили до появления ошибки. Если вы ничего не меняли на самом сайте и не вносили изменений в файлы, и не знаете почему возникает ошибка 500 то, скорее всего, это может быть одна из следующих причин:

Файл .htaccess используется с недопустимой инструкцией. Чаще всего инструкции php_value и php_flag допускаются только в mod_php, который на хостинге может не использоваться. В CGI или FastCGI такие инструкции показывают ошибку.

Медленная работа скрипта. Например, есть ограничения от веб-сервера: если скрипт не активен в течение 60 секунд или зависает, то он завершается под видом ошибки 500.

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

В панели управления включена несовместимость расширений. Могут быть одновременно включены eaccelerator и APC, или же eaccelerator и XCache, что будет приводить к ошибке Segmentation Fault, а эта ошибка приведет к ошибке 500 «Internal Server Error».

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

Пример ошибки:

...Invalid command 'DirectoryInex', perhaps mis-spelled or defined by a module not included in the server configuration...

Веб-сервер обращает ваше внимание на то, что правило «DirectoryIndex» прописано с ошибкой или же не включено в настройках самого сервера.

Также обратите внимание на то, чтобы в файле .htaccess не было следующих параметров (их можно просто удалить):

php_value
php_flag
php_admin_flag

Приведем такой пример:

php_flagregister_globalsOn

После изменения оно будет выглядеть так:

# php_flagregister_globalsOn

Если по какой-то причине не помогло все, что вы делали, обратитесь в техподдержку хостера и задайте вопрос, почему возникает ошибка 500 internal server error .
Еще рассмотрим вариант, если вы ошиблись и поместили некорректную инструкцию в файл .htaccess. В файле error.log вы найдете приблизительно такое:

[Wed Apr 8 20:01:58 2018] [alert] [client 217.16.16.16] /home/uXXXXX/ваш_домен.ru/www/.htaccess: Invalid command 'DrectoryIndex', perhaps mis-spelled or defined by a module not included in the server configuration

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

И правда, такой инструкции, как DrectoryIndex нет – есть DirectoryIndex. Вся проблема в опечатке.

Если и после выдачи правильных заголовков ошибка 500 не исчезла, необходимо проверить корректность работы скрипта в целом: > perl -cw script.pl script.pl syntax OK

Более подробную информацию о том, почему ошибка 500 «Internal Server Error» возникает на Вашем сайте, вы можете получить в файле error.log, который включается через панель управления хостингом. Обратите внимание, что ведение error.log включается только на время.

Предложить идею урока:

Источник

Друзья, привет! Сегодня поговорим о том, как быстро исправить ошибку в Elementor, а именно, ошибку 500. С чем связана эта ошибка? Начинает эта ошибка выскакивать, когда PHP не хватает памяти или же из-за большой количества скриптов, которые PHP не успевает обрабатывать.

Итак. Начнем. Решить эту проблему можно двумя способами.

Способ 1. Добавить памяти PHP на вашем хостинге

Давайте на примере разберем как это сделать. Я буду показывать это на хостинге beget.ru. Суть всех хостингов понятна, поэтому просто повторяем за мной все шаги. Заходим на хостинг — ищем в личном кабинете — менеджер файлов. Нажимаем на него и попадаем ко всему списку ваших доменов. Ищем в списке нужный домен, на котором нужно устранить ошибку 500 в Elementor. В моем случае, это будет домен workflowp.ru

Выбираем нужный домен

Кликаем по домену — public.html — находим файл wp-config и кликаем по нему.

Открываем этот файл и вставляем функцию (для всех сайтов одинаковая). Просто копируем ее из поля ниже:

  define('WP_MEMORY_LIMIT', '256M');

Вставляем эту функцию на строке 80. Нажимаем вверху файл — сохранить и выходим.

Способ 2. Устранить ошибку 500 в Elementor в файле .htaccess

Самый простой способ для новичков, которые не хотят лезть на хостинг и копаться в поиске этого файла. Быстрый способ к получить доступ к этому файлу из вашей админки сайта — это установка плагина Yoast Seo. Плагин вам в будущем понадобится для настройки страниц к сео-продвижению. В нем можно заполнить сниппеты страниц: Title, Description или закрыть от индексации ненужные страницы.

Итак. Устранить ошибку 500 в Elementor можно с помощью файла .htaccess добавив в самом начале этого файла функцию. Смотрим на скриншот. Функция будет под скрином. Устанавливаем плагин Yoast Seo, активируем его и заходим во вкладку ИНСТРУМЕНТЫ. Далее, нажимаем РЕДАКТОР ФАЙЛОВ. И ищем нужный нам файл .htaccess. В самом начале него вставляем функцию. Сохраняем и закрываем. Ошибка 500 в Elementor должна исчезнуть.

Убираем ошибку 500 в Elementor через файл .htaccess.

 php_value memory_limit 256M

Собственно, а это сама функция, которую нужно вставить в файл .htaccess.

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

Вариант.3 Самое быстрое и простое решение вернуть в работу Elementor

Как правило, при разработке и корректировки сайтов на Elementor в базе данных сохраняется очень много мусора, различных ревизий и прочее. Для того, чтобы сайт на Elementor заработал — вам необходимо установить простой плагин под названием Advanced Database Cleaner.

В репозитории готовых плагинов он будет выглядеть так

Установили плагин и активировали. Теперь переходим в него и видим количество отметок красным, где у нас собрался различный и ненужный мусор в БД. Настоятельно рекомендую перед очисткой базы данных сделать резервную копию — для этого воспользуйтесь плагином UpdraftPlus WordPress Backup Plugin.

И далее делаете все как на скриншоте ниже. Так проделываем со всем, что имеет красные отметки с количеством накопленных сохранений и ревизий.

После такой манипуляции Elementor должен снова загружаться!

Источник

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

Где и когда можно встретить ошибку 500

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

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

Отображаться ошибка может по-разному. Вот пример:

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

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

Комьюнити теперь в Телеграм

Подпишитесь и будьте в курсе последних IT-новостей

Причины возникновения ошибки

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

Основной причиной ошибки 500 может быть:

Неверный синтаксис файла .htaccess. htaccess – это файл, в котором можно задавать настройки для работы с веб-сервером Apache и вносить изменения в работу сайта (управлять различными перенаправлениями, правами доступа к файлам, опциями PHP, задавать собственные страницы ошибок и т.д.).
Узнать больше о файле .htaccess можно в статье «Создание и настройка .htaccess».
Ошибки в скриптах сайта, то есть сценариях, созданных для автоматического выполнения задач или для расширения функционала сайта.
Нехватка оперативной памяти при выполнении скрипта.
Ошибки в коде CMS, системы управления содержимым сайта. В 80% случаев виноваты конфликтующие плагины.

Год хостинга в подарок при заказе лицензии 1С-Битрикс

Выбирайте надежную CMS с регулярными обновлениями системы и профессиональной поддержкой.

Заказать

Как получить больше данных о причине ошибки

Что означает ошибка 500, мы теперь знаем. Когда она перестала быть таким загадочным персонажем, не страшно копнуть глубже — научиться определять причину ошибки. В некоторых случаях это можно сделать самостоятельно, так что обращаться за помощью к профильному специалисту не понадобится.

Отображение ошибки бывает разным. Ее внешний облик зависит от того, чем она вызвана.

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

Сообщение Internal Server Error говорит о том, что есть проблемы с файлом .htaccess (например, виновата некорректная настройка файла). Убедиться, что .htaccess является корнем проблемы, поможет следующий прием: переименуйте файл .htaccess, добавив единицу в конце названия. Это можно сделать с помощью FTP-клиента (например, FileZilla) или файлового менеджера на вашем хостинге (в Timeweb такой есть, с ним довольно удобно работать). После изменения проверьте доступность сайта. Если ошибка больше не наблюдается, вы нашли причину.
Сообщение HTTP ERROR 500 или пустая страница говорит о проблемах со скриптами сайта. В случае с пустой страницей стоит учесть, что отсутствие содержимого сайта не всегда указывает на внутреннюю ошибку сервера 500.

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

Как открыть панель разработчика

Нажмите клавишу F12 (способ актуален для большинства браузеров на Windows). Используйте сочетание клавиш Cmd+Opt+J, если используете Google Chrome на macOS. Или примените комбинацию Cmd+Opt+C в случае Safari на macOS (но перед этим включите «Меню разработки» в разделе «Настройки» -> «Продвинутые»). Открыть инструменты разработчика также можно, если кликнуть правой кнопкой мыши в любом месте веб-страницы и выбрать «Просмотреть код» в контекстном меню.
Откройте вкладку «Сеть» (или «Network») и взгляните на число в поле «Статус». Код ответа об ошибке 500 — это соответствующая цифра.

Более детальную диагностику можно провести с помощью логов.

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

Как вы видите, данных в логи записывается немало, поэтому они разделены по типам. За сведениями о нашей ошибке можно обратиться к логам ошибок (error_log). Обычно такие логи предоставляет служба поддержки хостинга, на котором размещен сайт. В Timeweb вы можете включить ведение логов и заказать необходимые данные в панели управления. Разобраться в полученных логах поможет статья «Чтение логов».

Как устранить ошибку

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

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

У этого файла довольно строгий синтаксис, поэтому неверно написанные директивы (команды) могут привести к ошибке. Попробуйте поочередно удалить команды, добавленные последними, и проверьте работу сайта.
Также найти проблемную директиву можно с помощью логов ошибок (через те же инструменты разработчика в браузере). На ошибку в директиве обычно указывает фраза «Invalid command». Информацию о верном написании директивы или способе исправления ошибок в .htaccess вы можете найти в интернете. Не нужно искать, почему сервер выдает ошибку 500, просто введите в строку поиска название нужной команды или текст ошибки из логов.

Ошибки в скриптах сайта

Скрипт не запускается

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

Не хватает оперативной памяти

Если в логах вы видите ошибку «Allowed memory size», для устранения ошибки 500 стоит оптимизировать работу скрипта. Вы можете воспользоваться специальными расширениями для анализа производительности скрипта или обратиться за помощью к специалисту, который поработает над его оптимизацией.

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

Ошибки в CMS

Если код CMS содержит неверный синтаксис, это может вывести сайт из строя. В таком случае логи сообщат вам об ошибке 500 текстом «PHP Parse error: syntax error, unexpected». Так происходит, когда некорректно работает плагин (или тема, используемая в CMS, но реже) либо есть ошибки в коде. Ошибка может быть допущена случайно, произойти при обновлении плагина или версии CMS.

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

Также в большинстве случаев подобные проблемы помогает решить поддержка CMS.

Информацию о других распространенных ошибках вы можете найти в статье «6 наиболее часто возникающих ошибок HTTP и способы их устранения».

Удачи!

Источник