Ошибка 404 beget - Решение и исправление самых разных ошибок на TopOshibok.ru

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

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

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

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

Что за название – .htaccess

Название .htaccess (сокр. от «hypertext access») означает, что файл служебный и не относится непосредственно к файлам сайта, а применяется для настроек веб-сервера, являясь частью конфигурации сервера Apache.

Ключевые возможности .htaccess

В этом файле задаются серверные настройки Apache, поэтому в нем, например, можно:

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

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

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

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

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

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

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

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

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

Redirect [status] URI_LOCAL URL_REDIRECT

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

$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 – содержит 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 – содержит путь к корневой директории сервера.
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 включает или выключает работу механизма преобразования. Если она установлена в положение off, этот модуль совсем не работает. Заметьте, что по умолчанию настройки преобразований не наследуются. Это означает, что вы должны иметь RewriteEngine on директиву для каждого виртуального хоста, в котором вы хотите использовать этот модуль.
Синтаксис RewriteEngine выглядит следующим образом:

RewriteEngine on | off

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

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

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

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

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]

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

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 - необязательное поле, указывающее дополнительные опции

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Этот флаг не дает 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 такую строчку:

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

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

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

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

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

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

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

DirectoryIndex 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 предоставляет возможность выдать вместо аскетичного технического текста, не изобилующего деталями, свою страницу, где вы можете человеческим языком объяснить пользователю, что произошло и что делать.

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

# содержание файла .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».

Кодировка

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

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

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

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

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

AddDefaultCharset WINDOWS-1251

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

CharsetSourceEnc WINDOWS-1251

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

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

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

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

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

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

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

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

Order Allow,Deny
Allow from all
Deny from 81.222.144.12 81.222.144.20

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

Order Deny,Allow
Deny from all
Allow from 81.222.144.12 81.222.144.20

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 определяет пользователей, которые могут получить доступ:

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>

Следует помнить, что при таком ограничении доступа пароли передаются по каналам связи в открытом виде и при определенных обстоятельствах могут быть перехвачены злоумышленниками. Поэтому в целях безопасности рекомендуется организовывать доступ к закрытым областям веб-сайта через защищенное 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 или apache2.conf, так что нам они неинтересны. По сути, данные директивы переопределяют значение остальных директив.

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

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

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

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

Запрет на загрузку изображений с сайта

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

Обратите внимание!

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

Предотвратить воровство контента можно с помощью такого кода:

Options +FollowSymlinks
RewriteEngine On
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^https://(www.)?mysite.com/ [nc]
RewriteRule .*.(gif|jpg|png)$ https://mysite.com/img/goaway.gif[nc]

Замените «mysite.com» на адрес вашего сайта и создайте изображение с произвольной формулировкой о том, что красть чужой контент нехорошо, по адресу https://mysite.com/img/goaway.gif. В результате такое изображение и будет демонстрироваться на ресурсе того, кто заимствовал ваш контент.

Запрет на выполнение вредоносных скриптов

Указанные ниже директивы помогут защитить сайт от скриптовых инъекций (внесения в URI сторонних элементов через XSS или переменные Apache), при попытке которых злоумышленник в результате попадет на страницу с ошибкой 403 («Доступ запрещен»).

Options +FollowSymLinks
RewriteEngine On
RewriteCond %{QUERY_STRING} (\<|%3C).*script.*(\>|%3E) [NC,OR]
RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR]
RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2})
RewriteRule ^(.*)$ index.php [F,L]

Чек-лист: как не навредить сайту при работе с .htaccess

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

Удачной работы! Если возникнут вопросы, напишите нам, пожалуйста, тикет из Панели управления аккаунта, раздел «Помощь и поддержка», а если вы захотите обсудить эту статью или в целом возможности файла .htaccess – ждем вас в нашем сообществе в Telegram.

Источник

Хостинг Beget является популярным ресурсом для хранения сайтов, однако пользователи иногда сталкиваются с проблемами при загрузке CSS/HTML. Ниже рассмотрены наиболее распространенные проблемы и возможные решения.

Ошибка «404 Not Found»

Это означает, что файл CSS/HTML не найден на сервере. Решение:

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

Ошибка «403 Forbidden»

Эта ошибка означает, что доступ к файлу запрещен сервером. Решение:

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

Ошибка «500 Internal Server Error»

Эта ошибка может возникнуть из-за неправильной конфигурации сервера или ограничений ресурсов. Решение:

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

Отсутствие обновлений

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

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

Неправильное отображение CSS

Иногда CSS отображается неправильно из-за некорректных настроек файлов или HTML-разметки. Решение:

Проверьте CSS на наличие синтаксических ошибок или опечаток.
Проверьте HTML-разметку на наличие неправильных тегов или атрибутов.
Убедитесь, что ширина блоков или элементов соответствует размерам контейнера.

Вывод

Исправление ошибок при загрузке CSS/HTML на хостинг Beget может быть простым, если следовать базовым шагам по проверке файлов и настроек. Однако в случае серьезных проблем рекомендуется обратиться в службу поддержки хостинга.

Источник

5750 / 4131 / 1506

Регистрация: 06.01.2011

Сообщений: 11,279

31.07.2011, 16:58. Показов 7747. Ответов 5

Я купил хостинг, зарегистрировал домен, закачал файлы сайта на купленный хостнг. Потом решил зайти на свой сайт, но на экран почему-то выводится ошибка 404. Может, кто объяснит, почему так получилось?

61 / 60 / 7

Регистрация: 25.05.2011

Сообщений: 388

31.07.2011, 22:22

в каждой папке должен быть индексный файл, будь то index.html или index.php, если такого файла не существует, то не мудрено — error 404

1098 / 529 / 22

Регистрация: 27.10.2010

Сообщений: 1,870

31.07.2011, 22:42

1. должен быть стартовый файл, по умолчанию это обычно index.html или index.htm
2. Если по каким то причинам вы не хотите его именно так называть, то это можно исправить в настройках сайта, но index.* все таки лучше.
3. проверьте РеГиСтР ваших файлов. Если сервер на *nix (а это скорее всего именно так), то Index.html, index.html и index.HTML будут разные файлы.

87 / 87 / 1

Регистрация: 03.01.2011

Сообщений: 328

01.08.2011, 06:58

Еще проверьте в какую папку закачали сайт, там надо в конкретную /www/mydomain.ru например в ISPmanager.

5750 / 4131 / 1506

Регистрация: 06.01.2011

Сообщений: 11,279

01.08.2011, 10:06

[ТС]

ГРОМАДНОЕ вам всем спасибо, очень помогли! Просто прекрасно, что существуют такие форумы. Я оказывается вот что неправильно сделал:
— Закачал файлы сайта просто в папку «www»
А оказывается нужно было в папке «www» создать папку с названием моего сайта «christians-love.ru» и в неё закачать файлы сайта.

87 / 87 / 1

Регистрация: 03.01.2011

Сообщений: 328

01.08.2011, 10:11

Сообщение от Lyodik

Просто прекрасно, что существуют такие форумы.

Скорей всего у купленного Вами хостинга есть техподдержка, которая всегда поможет Вам
Посмотрите внимательно на их сайте пункт «Контакты»

Источник

Про location

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

Отличия:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(beget) error_page 404 = @apache

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

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

504 Gateway Time-out

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

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

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

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

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

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

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

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

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

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

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

да

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

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

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

да

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

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

Limit_req, limit_req_zone, burst

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник

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

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

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

Директивы простого перенаправления (редирект);
Директивы сложного перенаправления (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

Теперь при обращении к 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 выглядит следующим образом:

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)

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

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

$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

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

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

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

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]

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

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 - необязательное поле указывающее дополнительные опции

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Код возврата — это трехзначное число, на основании которого можно судить о том, насколько успешно был обработан запрос. Код возврата начинающиеся на 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 предоставляет возможность выдать вместо аскетичного технического текста, не изобилиющего деталями, свою страницу, где Вы можете человеческим языком объяснить пользователю, что произошло и что делать.

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

# содержание файла .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».

Кодировка

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

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

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

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

AddDefaultCharset WINDOWS-1251

CharsetSourceEnc WINDOWS-1251

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

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

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

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

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

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

Order Allow,Deny
Allow from all
Deny from 81.222.144.12 81.222.144.20

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

Order Deny,Allow
Deny from all
Allow from 81.222.144.12 81.222.144.20

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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_admin_value, php_admin_flag выставляются только в файле httpd.conf, так что нам они не интересны. По сути, данные директивы переопределяют значение остальных директив.

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

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

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

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

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

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

Читайте нашу статью, если хотите узнать, как настроить редирект 404-й ошибки через .htaccess.

Если сервер не может найти страницу, на которую хочет перейти посетитель, то в окне браузера у пользователя отобразится ошибка 404. Давайте разберемся, как ошибка влияет на поведение пользователей и SEО-показатели сайта, а также как и зачем делать редирект этой ошибки.

Redirect error 404 SMF

Ошибка 404 (File not found) возникает в тех случаях, когда сервер не может найти запрашиваемую пользователем страницу. От этого не застрахован ни один сайт. Чаще всего ошибка возникает по следующим причинам:

сайта или страницы больше не существует,
сайт перенесли на новый адрес, но не настроили на него переадресацию со старой страницы,
структура сайта изменилась и URL-адреса страниц стали неактуальными,
пользователь ввел некорректный адрес страницы, например, 2domains.ru/asdfjkl:

Вне зависимости от причины ошибки срабатывает такой механизм: браузер пользователя запрашивает информацию у сервера, сервер не находит нужной страницы и возвращает ответ о том, что она не найдена. В результате у пользователя в браузере отображается “Not Found (404)”.

Как ошибка влияет на SEO-показатели сайта и что делать

В большинстве случаев наличие ошибок напрямую или косвенно может повлиять на SEO-показатели сайта. Рассмотрим эти показатели и как их можно улучшить.

Посещаемость

В том, что на сайте время от времени встречаются 404-е ошибки, нет ничего криминального. Описку в адресе хоть раз, но делал каждый пользователь интернета. Принимать меры стоит в том случае, если “error 404” встречается на сайте слишком часто. Если пользователи будут регулярно замечать проблемы, они почувствуют дискомфорт и могут перейти к конкуренту.

Даже если ресурс занимает топовые позиции, негативный опыт отталкивает потенциальных клиентов и влияет на снижение посещений в будущем. Поэтому важно следить, чтобы на сайте не было битых ссылок и несуществующих страниц. В этом помогут специальные онлайн-сервисы от Яндекс и Гугл. Если они найдут проблемы, приведите сайт в порядок: замените некорректные ссылки, настройте 301-й редирект со старых адресов на новые и внесите нужные настройки.

Лояльность

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

Страница с ошибкой на сайте pikabu.ru

Страница с ошибкой на сайте www.idesign.com.mt

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

Страница с ошибкой на сайте helpscout.com

Страница с ошибкой на сайте flippingbook.com

Страница с ошибкой на сайте kayako.com

В популярных CMS (например WordPress, Joomla и Drupal) есть готовые страницы 404. Однако они могут контрастировать с общим дизайном сайта или быть не слишком информативными, что в очередной раз оттолкнет пользователя. Идеальный вариант — создать страничку с ошибкой конкретно под ваш сайт. Вы можете заказать её у разработчика или сделать самостоятельно, если имеете опыт в вёрстке и веб-дизайне.

Продвижение

Иногда при загрузке несуществующей страницы вместо реального кода 404 браузер получает в ответ от сервера код 200 (success). Такие случаи называют ложной ошибкой 404. Проблема в том, что из-за кода 200 Яндекс и Google считают, что страница есть и её нужно проиндексировать. Подробнее читайте в справке Google.

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

Настройка редиректа .htaccess на страницу с ошибкой 404

Если у вас ещё нет готовой свёрстанной страницы 404, создайте её удобным вам способом:

найдите бесплатные шаблоны страниц, выберите один из них и скачайте. Затем добавьте файл шаблона в корневой каталог сайта;
создайте страницу самостоятельно с помощью HTML и CSS. Назовите файл страницы “404.html” и добавьте его в корневой каталог сайта;
настройте один из плагинов (All 404 Redirect to Homepage & Broken images Redirection, 404 Page by SeedProd или 404 to 301), если у вас WordPress. Обратите внимание: в этом случае настраивать редирект .htaccess не нужно.

Как настраивается редирект:

1. В корневом каталоге сайта откройте конфигурационный файл .htaccess и добавьте в него следующую строку:

ErrorDocument 404 https://site.ru/404.html

Вместо site.ru укажите домен вашего сайта. Затем сохраните изменения.

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

2. Закройте служебную страницу 404 от индексации для лучшей SEО-оптимизации ресурса. Для этого в корневом каталоге откройте файл robots.txt, добавьте команду ниже и сохраните изменения:

Disallow: /404.html

Готово, вы настроили редирект с помощью .htaccess.

Проверка редиректа 404

Проверить, всё ли верно настроено в .htaccess, вы можете с помощью Яндекс.Вебмастер или Google Search Console.

1. Перейдите в Яндекс.Вебмастер. Если вы ещё не зарегистрированы, укажите домен вашего сайта и добавьте файл в корневую папку сайта, чтобы пройти проверку валидации.
2. Откройте раздел Инструменты — Проверка ответа сервера:

3. Укажите адрес страницы ошибки и кликните Проверить. Если в коде статуса HTTP отображается 404 Not Found, значит всё настроено верно:

1. Перейдите в Google Search Console. Если вы ещё не зарегистрированы, введите ваш домен и добавьте TXT-запись (загрузите файл в корневую папку сайта), чтобы пройти валидацию.
2. В меню справа откройте раздел Покрытие. В информации о страницах ошибок вы должны увидеть аналогичный результат:

Ошибка 404, либо Error 404 Not Found — ошибка, которая появляется, если браузеру не удалось обнаружить на сервере указанный URL.

Сообщение об ошибке 404

Что означает ответ 404

Error 404 Not Found отображается по-разному: «HTTP 404 не найден», «Ошибка 404 Not Found», «404 Страница не найдена». Смысл надписи всегда остаётся тем же: страница отсутствует либо просто не работает. Not Found в переводе означает «не найдено».

Ошибка 404 — классический код ответа по протоколу HTTP. Он свидетельствует, что связь с сервером установлена, но данных по заданному запросу на сервере нет.

Однако если просто ввести в поисковую строку произвольный набор символов, то браузер не покажет ошибку 404 Not Found — появится сообщение, что установить соединение с конкретным сервером невозможно.

Разберёмся в техническом формировании ответа Error 404 Not Found.

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

Что значит код «404». В ответе 404 первая четвёрка указывает на то, что запрос был чрезмерно длительным или в самом адресе была ошибка. Ноль предполагает синтаксическую неточность. Завершающая цифра кода отображает конкретную причину ошибки — «4» означает отсутствие данной ссылки.

Какие ещё ошибки бывают. Ошибку 404 не нужно путать с другими ответами, которые указывают на невозможность связи с сервером. Например, ошибка 403 сообщает, что доступ к URL ограничен, а ответ «Сервер не найден» свидетельствует, что браузер не смог обнаружить место размещения сайта.

Google на 404 странице сообщает о возможных причинах ошибки

Причины ошибки

Причины, по которым HTTP возвращает ответ 404 Not Found:

Неверный адрес. К примеру, при ручном наборе пользователь допустил опечатку в адресе либо ссылка ведёт на несуществующую страницу. При этом домен должен быть написан верно. Если пользователь ошибется в названии домена, страница вообще не загрузится (без показа ошибки).
Битая ссылка. Это нерабочий URL, который никуда не ведёт. Данный вариант иногда возникает при внутренней перелинковке. К примеру, раньше страница существовала, а потом её удалили и забыли убрать ссылку.
Удалённая страница. Когда пользователь попытается перейти на удалённую с сервера страницу, он также увидит ошибку 404. Ссылка для перехода может сохраниться в браузерных закладках или на сторонних ресурсах.
Неправильный редирект на страницу с изменённым адресом. Допустим, в процессе редизайна URL изменили, но оставили без внимания связанные ссылки.
Неполадки на сервере. Это самый редкий вариант.

В большинстве ситуаций ошибка 404 отображается, когда не удаётся обнаружить нужную страницу на доступном сервере.

Причины отсутствия страницы на сайте бывают разными

Возможные последствия для сайта

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

Поисковые системы относятся к Not Found более лояльно. Например, Google отмечает, что 404 страницы не влияют на рейтинг. Но если при индексации роботы будут находить все больше ошибочных страниц, вряд ли это приведёт к более высокому ранжированию.

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

Как выявить ошибку

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

Search Console Google

Консоль поиска Google позволяет находить страницы с ошибкой 404 за несколько кликов:

Войдите в учётную запись Google и перейдите в Search Console.
Откройте раздел «Ошибки сканирования» → «Диагностика».
Кликните на «Not Found».

Чтобы получить список страниц с ошибками, подтвердите права на ресурс — добавьте проверочную запись TXT в записи DNS регистратора домена. Такая запись не повлияет на работу сайта. Подробнее о процедуре подтверждения, читайте в справке Google.

Для использования Search Console Google нужно подтвердить свои права на сайт

Яндекс Вебмастер

Сервис для вебмастеров от Яндекса поможет быстро найти все ошибки 404:

Откройте Вебмастер после авторизации в Яндекс-аккаунте.
Выберите «Индексирование» → «Доступные для поиска страницы» → «Исключённые страницы».
В выданном списке выберите фильтр «Ошибка HTTP: 404».

Чтобы использовать Яндекс.Вебмастер, также нужно подтвердить право владения сайтом — добавить метатег в HTML-код главной страницы.

Для входа в Вебмастер авторизуйтесь в Яндексе

Screaming Frog

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

Инструмент SEO-паук в Screaming Frog помогает найти технические неисправности сайта

SiteAnalyzer

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

SiteAnalyzer бесплатно найдёт неработающие URL

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

Выбор конкретного решения зависит от причины ошибки:

Ссылка ведёт в никуда из-за неверного URL. Для решения проблемы замените ошибочную ссылку на правильный адрес, чтобы сервер отдавал код 200 OK.
Битая ссылка. Подобная ситуация не редкость при внутренней перелинковке страниц. К примеру, ссылка есть, а саму страницу давно удалили. Решений два: удалить ссылку или заменить её на другую.

Удалять и менять ссылки вручную удобно только на небольших сайтах. Исправление ошибок на крупных порталах лучше автоматизировать. Например, с помощью специальных плагинов для внутренней перелинковки (Terms Description, Dagon Design Sitemap Generator) и для автоматического формирования адресов страниц (Cyr-To-Lat).

Чтобы ошибки 404 появлялись как можно реже, достаточно соблюдать простые рекомендации:

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

Мы разобрались, как найти и исправить ошибки Not Found внутри сайта. Но неработающая ссылка может быть расположена и на стороннем ресурсе. Допустим, когда-то на другом сайте разместили рекламную публикацию со ссылкой на определённую страницу. Спустя какое-то время страницу удалили. В этом случае появится ошибка 404. Устранить её можно, связавшись с администрацией ссылающегося сайта. Если же удалить/исправить ссылку нельзя, постарайтесь использовать ошибку с выгодой.

Как сделать страницу 404 полезной

Грамотно оформленная страница с ошибкой Error 404 Not Found — действенный инструмент конвертации посетителей. Ограничений по использованию страницы с ошибкой 404 нет. При этом практически все CMS позволяют настраивать дизайн этой страницы.

Что публиковать на странице 404:

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

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

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

Главное — по возможности отказаться от стандартной страницы 404. Подумайте, как привлечь внимание пользователя. Расскажите ему об отсутствии искомой страницы и предложите взамен что-то полезное или интересное.

Примеры оформления страниц 404

Designzillas

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

Меню на сайте Designzillas есть и на 404 странице

Domenart Studio

Веб-студия «Домен АРТ» использует красочную страницу 404, оформленную в единой стилистике ресурса. Заблудившимся пользователям предлагают попробовать ещё раз ввести адрес или перейти в нужный раздел.

Контакты, поиск, меню — и всё это на 404 странице Domenart Studio

E-co

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

Ошибка 404 «Эко Пауэр» выглядит как страница входа

Дом со всем

Компания «Дом со всем», занимающаяся бурением скважин, разместила на странице 404 свои контакты и перечень услуг. Со страницы можно перейти в любой раздел сайта или заказать обратный звонок. С таким наполнением посетителю не нужно искать дополнительную информацию где-то ещё.

Компания «Дом со всем» предлагает заказать обратный звонок

Kualo

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

На странице Kualo можно просто поиграть и заработать скидки

Рано или поздно с ошибкой 404 сталкивается большинство сайтов. При регулярной проверке можно своевременно исправить неработающие ссылки, чтобы в ответ пользователи получали код 200 OK. Но для крупного ресурса лучше настроить оригинальную страницу, которая будет отображаться при появлении ошибки Not Found и подскажет посетителям, что делать дальше.

Главные мысли

Источник