Htaccess проверка: Файл .htaccess: правильное использование, примеры и рекомендации

Редирект в .htaccess со старого домена на новый

#Со старого домена на новый
RewriteEngine on
RewriteCond %{HTTP_HOST} ^www\.staryy-sait\.ru$ [NC]
RewriteRule ^(.*)$ http://novyy-sait.ru/$1 [L,R=301]
RewriteCond %{HTTP_HOST} ^staryy-sait\.ru$ [NC]
RewriteRule ^(.*)$ http://novyy-sait.ru/$1 [L,R=301]

Редирект в .htaccess с адреса с WWW на адрес без WWW

Options +FollowSymLinks
RewriteEngine On
RewriteCond %{HTTP_HOST} ^https://www.адрес сайта\.ru$ [NC]
RewriteRule ^(.*)$ https://адрес сайта.ru/$1 [R=301,L]

Редирект в .htaccess на адрес сайта без слэша в конце

RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} ^(.+)/$
RewriteRule ^(.+)/$ /$1 [R=301,L]

Редирект в .htaccess со старой страницы на новую

RewriteEngine On
RewriteRule ^(.*)url.html$ http://vash-sait.ru/new-url.html [R=301,L]

Редирект в .htaccess — перевод из верхнего регистра символов в URL в нижний

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

RewriteEngine On
RewriteBase /

RewriteRule ![A-Z] - [S=28]

RewriteRule ^([^A]*)A(.*)$ $1a$2
RewriteRule ^([^B]*)B(.*)$ $1b$2
RewriteRule ^([^C]*)C(.*)$ $1c$2
RewriteRule ^([^D]*)D(.*)$ $1d$2
RewriteRule ^([^E]*)E(.*)$ $1e$2
RewriteRule ^([^F]*)F(.*)$ $1f$2
RewriteRule ^([^G]*)G(.*)$ $1g$2
RewriteRule ^([^H]*)H(.*)$ $1h$2
RewriteRule ^([^I]*)I(.*)$ $1i$2
RewriteRule ^([^J]*)J(.*)$ $1j$2
RewriteRule ^([^K]*)K(.*)$ $1k$2
RewriteRule ^([^L]*)L(.*)$ $1l$2
RewriteRule ^([^M]*)M(.*)$ $1m$2
RewriteRule ^([^N]*)N(.*)$ $1n$2
RewriteRule ^([^O]*)O(.*)$ $1o$2
RewriteRule ^([^P]*)P(.*)$ $1p$2
RewriteRule ^([^Q]*)Q(.*)$ $1q$2
RewriteRule ^([^R]*)R(.*)$ $1r$2
RewriteRule ^([^S]*)S(.*)$ $1s$2
RewriteRule ^([^T]*)T(.*)$ $1t$2
RewriteRule ^([^U]*)U(.*)$ $1u$2
RewriteRule ^([^V]*)V(.*)$ $1v$2
RewriteRule ^([^W]*)W(.*)$ $1w$2
RewriteRule ^([^X]*)X(.*)$ $1x$2
RewriteRule ^([^Y]*)Y(.*)$ $1y$2
RewriteRule ^([^Z]*)Z(.*)$ $1z$2

Как написать .htaccess файл для сайта

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

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

Делается это разрешение при помощи следующего блока кода:

<Directory /home/my_site/www>
        AllowOverride All
        #Другие директивы ...
</Directory>

Здесь в теге <Directory> указывается физический путь на сервере до корня вашего сайта, и внутри тега указывается директива AllowOverride. Эта директива может быть установлена в None, чтобы сервер не читал файл .htaccess. Если она установлена в All — сервер будет допускать все директивы .htaccess файла. Значение по умолчанию: AllowOverride All.

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

Синтаксис файлов .htaccess в общем случае аналогичен синтаксису главного файла конфигурации apache. Однако, администратор может ограничивать для пользователей доступ к тем или иным директивам. То есть, несмотря на то, что команда, в принципе, может исполняться из .htaccess, администратор может запретить доступ к конкретной директиве. Учитывайте это при работе. Также хочу заметить такой момент, когда вы пишите директивы работающие с каталогами? то в главных конфигурационных файлах apache их нужно оборачивать в тег <Directory /path/…> с указанием каталога к которому они применимы, однако при написании этих директив в .htaccess файле уже не нужно их оборачивать в тег <Directory>, если вы хотите что бы они применялись к текущему каталогу файла .htaccess, если же вы хотите применить их только к вложенному каталогу то тогда, опять же, нужно обернуть в тег <Directory>.

Для чего мы можем использовать .htaccess файл. Вариантов здесь немало, вот самые распространенные из них:
1.Для управления разрешениями на доступы к каталогам сайта (запаролить директорию, запретить доступ к файлам определенного формата, или доступ к сайту в определенный промежуток времени, запретить или открыть доступ с определенных IP адресов, управлять роботами поисковиков)
2.Для перезаписи текущего URL на новый в зависимости от условий (см. также описание mod_rewrite сервера Apache и логику его обработки правил )
3.Для явного указания кодировки сайта.
4.Для разрешения или запрета просмотра файлов сайта
5.Для защиты от хотлинка
6.Для выполнения ридирктов
7.Для задания своих страниц ошибок
8.Для переопределения индексного файла
9…. и многое другое.

Давайте для примера напишем некий обобщенный файл .htaccess.
В него мы соберем наиболее распространенные случаи использования директив и добавим к ним комментарии. И из этого шаблона путем удаления не нужного вы сможете всегда подготовить конкретный .htaccess для ваших задач. Здесь символ # — это символ комментария применяемый в конфигах apache.

Подробные пояснения к коду шаблона см. после него.

# .htaccess начало шаблона
# Установка временной зоны
SetEnv TZ Europe/Moscow

# Установим принудительно кодировку страниц сайта
AddDefaultCharset UTF-8

# Зададим index файл который будет
# отдаваться если запрошенный не найден
DirectoryIndex index.php index.html

# Запретим пользователям просматривать файлы директории
Options -Indexes

# Разрешим следовать за символическими связями в этом каталоге
Options +FollowSymLinks

# Разрешение доступа только для указанных IP
Order Deny,Allow
Deny from all
Allow from x.x.x.x

# Или запрет доступа по IP
Order allow,deny
deny from x.x.x.x
deny from x.x.x.x
allow from all

# Запретить всем, то только
# одну эту строку указать
Deny from all

# Закрыть доступ к вложенной директории относительно текущего файла
# можно так, или положив туда отдельный .htaccess файл
<Directory /passwds/>
    Order Deny,Allow
    Deny from All
</Directory>

# Закрыть директорию паролем
AuthType Basic
AuthName "Enter a password"
#путь до файла с паролями и пользователями
AuthUserFile /full/path/to/.htpasswd
require valid-user

# или закрыть вложенную директорию паролем
<Directory /passwds/>
    AuthType Basic
    AuthName "Enter a password"
    #путь до файла с паролями и пользователями (абсолютный или относительно ServerRoot)
    AuthUserFile /full/path/to/.htpasswd
    require valid-user
</Directory>

# Запрет на доступ для файла .htpasswd
# для всех посетителей кроме разрешенных IP
<Files ".htpasswd">
    Order Deny,Allow
    Deny from all
    Allow from x.x.x.x, x.x.x.xx
</Files>

# Блок если нужно отключить обработку PHP
# можно и для <Directory> задать
<IfModule mod_php5.c>
  php_value engine off
</IfModule>
<IfModule mod_php4.c>
  php_value engine off
</IfModule>
#

# Блок изменение настроек PHP
# некоторые директивы зависят от версии PHP
#php_flag register_globals off
#php_value memory_limit 16M
#for files uploading - if needed
#php_value max_execution_time 500
#php_value max_input_time 500
#php_value upload_max_filesize 30M
#php_value post_max_size 30M
#php_flag display_errors off

#Настройка PHP для загрузки больших файлов до 256M
php_value memory_limit 256M
php_value upload_max_filesize 256M
php_value post_max_size 256M
#

# Перезапись URL
<IfModule mod_rewrite.c>
    RewriteEngine On
    
    # установить корневой URL как /
    RewriteBase /

    #Все запросы с HTTP на HTTPS
    RewriteCond %{HTTPS} =off
    RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,QSA,L]

    #Только для указанных каталогов все запросы с http на https redirect
    RewriteCond %{HTTPS} =off
    RewriteCond %{REQUEST_URI} /(admin|secret)/ [NC]
    RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,QSA,L]
    
    # 301 Редирект как принудительная
    #постановка замыкающего слеша
    #RewriteCond %{REQUEST_URI} /+[^\.]+$
    #RewriteRule ^(.+[^/])$ %{REQUEST_URI}/ [R=301,L]
    #
    
    # 301 Редирект c www.site.ru на site.ru
    # как удаление www
    RewriteCond %{HTTP_HOST} ^www\.site\.ru [NC]
    RewriteRule ^(.*)$ http://site.ru/$1 [R=301,QSA,L]
    #

    #301 Универсальный редирект с домена www. на без www.
    RewriteCond %{HTTP_HOST} ^www\.(.*) [NC]
    RewriteRule ^(.*)$ http://%1/$1 [R=301,L]

    #301 Универсальный редирект с домена без www. на www.
    RewriteCond %{HTTP_HOST} ^(.*)$ [NC]
    RewriteCond %{HTTP_HOST} !^www\. [NC]
    RewriteRule ^(.*)$ http://www.%1/$1 [R=301,L]

    # 301 Редирект с указанных доменов на основной
    RewriteCond %{HTTP_HOST} ^www.domen.net$ [NC,OR]
    RewriteCond %{HTTP_HOST} ^domain.net$ [NC,OR]
    RewriteCond %{HTTP_HOST} ^www.domain.net$ [NC]
    RewriteRule ^(.*)$ http://domain.net/$1 [R=301,QSA,L]
    #

    #Редирект с преобразованием GET параметров
    RewriteCond %{QUERY_STRING} do=page [NC]
    RewriteCond %{QUERY_STRING} id=(\d+) [NC]
    RewriteRule .* /page/%1/? [R=301,L]
    
    # Внутреннее пере направление на index.php для CMS
    # Если запрошены не существующие файл или директория
    # То перенаправлять запрос на index.php
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule . /index.php [L]
    #
   
    # или еще вариант внутреннего пере направления на index.php
    RewriteCond $1 !^(index\.php|images|robots\.txt|public)
    RewriteCond %{REQUEST_URI} !\.(cssіjsіjpgіgifіpng)$
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule ^(.*)$ index.php?/$1 [L,QSA]
    # или как:
    RewriteRule ^(.*)$ index.php [L]
    #

   #Еще вариант, для тех у кого не WordPress и кто хочет избавиться
   #от ненужных запросов (боты и т.п.) к темам, к админки и каталогам WordPress вида
   #где, что не файл и не директория, и не начинается с /wp-,
   #то делаем внутренний redirect на index.php
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    #если у вас не WordPress добавим это и также блок после этого
    RewriteCond %{REQUEST_URI} !^/wp- [NC]
    RewriteRule . /index.php [L]
   #если у вас не WordPress то всем кто ломиться в /wp-...   
   #отдадим 410 Gone status - рекомендация забыть этот URL
   #RewriteRule "oldproduct" "-" [G,NC] #общий пример
    RewriteCond %{REQUEST_URI} ^/wp- [NC]
    RewriteRule . - [G,L]
    
    # Зашита от хотлинка
    RewriteCond %{HTTP_REFERER} !^$
    RewriteCond %{HTTP_REFERER} !^http://site\.ru/ [NC]
    RewriteCond %{HTTP_REFERER} !^https://site\.ru/ [NC]
    RewriteCond %{HTTP_REFERER} !^http://www\.site\.ru/ [NC]
    RewriteCond %{HTTP_REFERER} !^https://www\.site\.ru/ [NC]
    RewriteRule \.(jpeg|png|bmp|gif|jpg|js|css)$ - [F]
    #

   # Еще вариант антихотлинка ресурсов (картинок)
   RewriteCond %{HTTP_REFERER} !^$
   RewriteCond %{HTTP_REFERER} !^http://(.+\.)?server\.ru/ [NC]
   RewriteCond %{HTTP_REFERER} !^https://(.+\.)?server\.ru/ [NC]
   RewriteCond %{REQUEST_URI} !null\.gif$ [NC]
   # Перенаправим на картинку заглушку dummy.gif
   RewriteRule \.(jpg|jpeg|gif|bmp|png)$ http://server.ru/dummy.gif [L]

    
    # Еще вариант антихотлинка ресурсов (картинок)
    RewriteCond %{HTTP_REFERER} !^$
    #Замените ?mysite\.com/ на адрес вашего блога
    RewriteCond %{HTTP_REFERER} !^http://(.+\.)?mysite\.com/ [NC]
    RewriteCond %{HTTP_REFERER} !^$
    #Замените /images/nohotlink.jpg на ваше изображение с запрещением хотлинка
    RewriteRule .*\.(jpe?g|gif|bmp|png)$ /images/nohotlink.jpg [L]
    
    # Еще вариант антихотлинка ресурсов (картинок)
    RewriteCond %{HTTP_REFERER} !^http://(.+\.)?mysite\.com/ [NC]
    RewriteCond %{HTTP_REFERER} !^$
    RewriteCond %{HTTP_REFERER} !google. [NC]
    RewriteCond %{HTTP_REFERER} !yandex. [NC]
    RewriteCond %{HTTP_REFERER} !search?q=cache [NC]
    RewriteCond %{HTTP_REFERER} !msn. [NC]
    RewriteCond %{HTTP_REFERER} !yahoo. [NC]
    RewriteRule .*\.(jpe?g|gif|bmp|png)$ /images/nohotlink.jpe [L]

    #
</IfModule>

# Вывод 404 ошибки если выключен mod_rewrite
<IfModule !mod_rewrite.c>
    ErrorDocument 404 /index.php
</IfModule>

# Зададим свои страницы для ошибок
ErrorDocument 404 /err_404.html
ErrorDocument 403 /err_403.html
#

# Блок кода редиректа на мобильную версию сайта
# Как вариант привожу здесь, больше для примера
<ifModule mod_rewrite.c>
    RewriteEngine on
    # Проверить строку UserAgent браузера
    RewriteCond %{HTTP_USER_AGENT} acs [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} alav [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} alca [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} amoi [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} audi [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} aste [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} avan [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} benq [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} bird [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} blac [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} blaz [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} brew [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} cell [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} cldc [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} cmd- [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} dang [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} doco [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} eric [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} hipt [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} inno [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} ipaq [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} java [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} jigs [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} kddi [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} keji [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} leno [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} lg-c [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} lg-d [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} lg-g [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} lge- [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} maui [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} maxo [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} midp [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} mits [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} mmef [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} mobi [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} mot- [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} moto [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} mwbp [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} nec- [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} newt [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} noki [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} opwv [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} palm [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} pana [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} pant [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} pdxg [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} phil [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} play [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} pluc [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} port [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} prox [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} qtek [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} qwap [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} sage [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} sams [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} sany [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} sch- [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} sec- [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} send [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} seri [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} sgh- [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} shar [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} sie- [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} siem [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} smal [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} smar [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} sony [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} sph- [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} symb [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} t-mo [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} teli [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} tim- [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} tosh [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} tsm- [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} upg1 [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} upsi [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} vk-v [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} voda [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} w3cs [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} wap- [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} wapa [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} wapi [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} wapp [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} wapr [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} webc [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} winw [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} winw [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} xda [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} xda- [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} up.browser [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} up.link [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} windows.ce [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} iemobile [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} mini [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} mmp [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} symbian [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} midp [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} wap [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} phone [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} ipad [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} iphone [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} iPad [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} iPhone [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} ipod [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} iPod [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} pocket [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} mobile [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} android [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} Android [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} pda [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} PPC [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} Series60 [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} Opera.Mini [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} Moby [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} Mobi [NC,OR]
     
    # Проверить служебные заголовки, отсылаемые браузером
    RewriteCond %{HTTP_ACCEPT} "text/vnd.wap.wml" [NC,OR]
    RewriteCond %{HTTP_ACCEPT} "application/vnd.wap.xhtml+xml" [NC,OR]
     
    # Проверить исключения
    RewriteCond %{HTTP_USER_AGENT} !windows.nt [NC]
    RewriteCond %{HTTP_USER_AGENT} !bsd [NC]
    RewriteCond %{HTTP_USER_AGENT} !x11 [NC]
    RewriteCond %{HTTP_USER_AGENT} !unix [NC]
    RewriteCond %{HTTP_USER_AGENT} !macos [NC]
    RewriteCond %{HTTP_USER_AGENT} !macintosh [NC]
    RewriteCond %{HTTP_USER_AGENT} !playstation [NC]
    RewriteCond %{HTTP_USER_AGENT} !google [NC]
    RewriteCond %{HTTP_USER_AGENT} !yandex [NC]
    RewriteCond %{HTTP_USER_AGENT} !bot [NC]
    RewriteCond %{HTTP_USER_AGENT} !libwww [NC]
    RewriteCond %{HTTP_USER_AGENT} !msn [NC]
    RewriteCond %{HTTP_USER_AGENT} !america [NC]
    RewriteCond %{HTTP_USER_AGENT} !avant [NC]
    RewriteCond %{HTTP_USER_AGENT} !download [NC]
    RewriteCond %{HTTP_USER_AGENT} !fdm [NC]
    RewriteCond %{HTTP_USER_AGENT} !maui [NC]
    RewriteCond %{HTTP_USER_AGENT} !webmoney [NC]
    RewriteCond %{HTTP_USER_AGENT} !windows-media-player [NC]
     
    # При выполнении условий переадресация на мобильную версию сайта
    RewriteRule ^(.*)$ http://mobile.version.of.site.ru [L,R=302]
</ifModule>

#Универсальный 302 редирект на мобильную версию сайта
<ifModule mod_rewrite.c>
    RewriteEngine on
    #Универсальный редирект на мобильную версию сайта
    RewriteCond %{HTTP_HOST} ^(.*)$ [NC]
    RewriteCond %{HTTP_USER_AGENT} (?i:midp|samsung|nokia|j2me|avant|docomo|novarra|palmos|palmsource|opwv|chtml|pda|mmp|blackberry|mib|symbian|wireless|nokia|hand|mobi|phone|cdm|upb|audio|SIE|SEC|samsung|HTC|mot-|mitsu|sagem|sony|alcatel|lg|eric|vx|NEC|philips|mmm|xx|panasonic|sharp|wap|sch|rover|pocket|benq|java|pt|pg|vox|amoi|bird|compal|kg|voda|sany|kdd|dbt|sendo|sgh|gradi|jb|dddi|moto|iphone|android) [NC]
    RewriteRule ^$  http://m.%1 [R=302,L]
</ifModule>

# .htaccess конец шаблона

Разъяснения по коду шаблона:

Расшифрую некоторые флаги из директив:

• RewriteCond … [NC] — NC значит регистр нечувствительное сравнение выполнять
• RewriteCond … [NC,OR] — NC см. выше, OR — значит объединять RewriteCond через OR, по умолчанию если ничего не указана то RewriteCond объединяются через AND оператор.
• RewriteRule … [L] — L значит закончить (остановить обработку) на этом RewriteRule правиле любые дальнейшие преобразования URL, т.е. последующие RewriteRule не выполнять.
• RewriteRule … [L,R=302] — L см. выше, R=302 значит выполнить редирект с кодом 302 на преобразованный URL
• RewriteRule … [R=301,QSA,L] — L и R см. выше, QSA — при преобразовании URL выполнять при стыковку заданных частей, а не замену.
• RewriteRule … [F] — F, значит отказать в выдачи результата по этому URL кодом 403 Forbidden.
• RewriteRule . — [G,L] G|Gone — [G] flag значит отдать код 410 Gone status — рекомендация забыть этот URL

AuthUserFile — задает путь к файлу с паролями для http авторизации пользователя. Путь может быть абсолютный от корня файловой системы Linux сервера или относительный от ServerRoot apache. В Ubuntu ServerRoot «/etc/apache2» по умолчанию. При задании относительного пути от ServerRoot apache начальный слеш в пути не указывается, иначе путь будет восприниматься как абсолютный от корня Linux. Также, если путь содержит недопустимые символы и пробелы его нужно заключать в кавычки, это общее правило.

Order, Deny, Allow

Теперь еще раз, но уже более детально, хотелось бы вернуться к директивам управление доступом: Order, Deny, Allow и более детально описать ее синтаксис и логику.

Директива Order синтаксис: Order [Deny,Allow] или [Allow,Deny]

По умолчанию директива Order имеет порядок: Deny,Allow. Обратите внимание, что Deny,Allow пишутся без пробела.

В зависимости от того в каком порядке указаны директивы Deny,Allow или Allow,Deny меняется логика работы.

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

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

# Разрешить ВСЕМ кроме указанных IP
Order Allow,Deny
Allow from all
Deny from x.x.x.x x.x.x.xx

Обратите внимание что IP записаны через пробел. Можно также указать IP как IP/маска.

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

# Запретить ВСЕМ кроме указанных IP
Order Deny,Allow
Deny from all
Allow from x.x.x.x x.x.x.xx

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

# Запретить файл passwd.html ВСЕМ кроме указанных IP
<Files «passwd.html»>
  Order Deny,Allow
  Deny from all
  Allow from x.x.x.x
</Files>

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

# Запретить файлы *.key ВСЕМ кроме указанных IP
<Files «\.(key)$»>
  Order Deny,Allow
  Deny from all
  Allow from x.x.x.x
</Files>

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

.htaccess

15.10.2014

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

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

Редиректы

Редиректы осуществляются с помощью модуля mod_rewrite. Задаются правила преобразований в виде следующей конструкции:

<IfModule mod_rewrite.c>
  Options +FollowSymLinks
  RewriteEngine On

  [СЮДА ПИШЕМ ПРАВИЛА]  

</IfModule>

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

RewriteCond [СТРОКА ДЛЯ СРАВНЕНИЯ] [УСЛОВИЕ] [ФЛАГИ]
RewriteCond [СТРОКА ДЛЯ СРАВНЕНИЯ] [УСЛОВИЕ] [ФЛАГИ]
RewriteRule [ШАБЛОН] [СТРОКА ПОДСТАНОВКИ] [ФЛАГИ]

Строки RewriteCond — задают условия для срабатывания следующего за ними правила RewriteRule. Условий может быть несколько, они накладываются по правилу AND. Но можно изменить правило на OR с помощью флага OR.

В качестве [СТРОКИ ДЛЯ СРАВНЕНИЯ] могут использоваться различные переменные. Ссылка на полный список Я приведу только те, которые нужны чаще всего:

[УСЛОВИЕ] также как и [ШАБЛОН] представляют собой perl совместимое регулярное выражение, с некоторыми дополнениями, позволяющими например проверить файл ли это, или существующий url.

[ФЛАГИ] Флаги пишутся в квадратных скодках через запятую: [NC,OR]. Флаги для условий:

Подвыражения в регулярных выражениях (заключенные в скобки), доступны для вставки в [СТРОКУ ПОДСТАНОВКИ], обращаться к подвыражениям нужно так: %N — для подвыражений в условиях (RewriteCond) и $N — для подвыражений в правилах (RewriteRule), где N — порядковый номер подвыражения.

RewriteRule — правило подстановки. Если запрос подходит под вышестоящие проверки и [ШАБЛОН], то применяется правило подстановки. Здесь регулировать поведение также можно с помощью флагов. Флаги есть разные, приведу наиболее часто используемые:

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

Внимание! Браузеры кешируют редиректы!!!

Причем обычные сочетания типа Ctrl+F5 или Ctrl+R не помагают. Я во время тестирования каждый раз открываю страницу в НОВОМ окне в режиме инкогнито. Причем старые страницы в режими инкогнито надо закрывать.

Примеры

Универсальный редирект с www на без www

Тут самое интересное, почему то везде приводятся примеры, жестко привязанные к домену сайта. Зачем?, если есть универсальное решение:

RewriteCond %{HTTP_HOST} ^www\.(.*) [NC]
RewriteRule ^(.*)$ http://%1/$1 [R=301,L]

Проверяем доменное имя, если оно начинается с www, то сработает правило: «все, на http://%1/$1«. Здесь %1 это наш домен без www (взят из условия), а $1 это адрес (взят из самого правила).

Универсальный редирект с без www на www

RewriteCond %{HTTP_HOST} ^(.*)$ [NC]
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule ^(.*)$ http://www.%1/$1 [R=301,L]

Тут маленько сложнее. Первое условие нужно для того чтобы получить домен (%1), оно всегда истина. Второе условие проверяет, что домен начинается не с www. Ну и само правило, аналогичное предыдущему примеру

Простой редирект

RewriteRule ^news/happy.* /news.html [R=301,L]

Для простого редиректа условия задавать не обязательно, только правило.

Реврайт без редиректа

RewriteRule ^news/happy.* /news.html [L]

Иногда требуется, чтобы был редирект без смены адреса, т.е. реврайт без редиректа. Для этого просто не указываем флаг редирект (R), и получаем желаемый результат, теперь по адресу news/happy получим news.html, а в адресной строке останется news/happy

Редирект от GET параметров

Например, нужно что бы со страницы /?action=page&id=15 был редирект на /page/15/:

RewriteCond %{QUERY_STRING} action=page [NC]
RewriteCond %{QUERY_STRING} id=(\d+) [NC]
RewriteRule .* /page/%1/? [R=301,L]

Поясню, первым условиям проверяем что есть get параметр action=page, вторым условием проверяем что id равно числу. Эти условия нельзя объединять, т.к. параметры могут идти и наоборот, т.е. index.php?action=page&id=15 и index.php?id=15&action=page должны быть равноценны. Но и наконец правило, там все обычно, кроме знака вопрос (?) на конце. Он нам нужен, чтобы отсечь исходные GET параметры, иначе получим /page/15/?action=page&id=15

Редирект на мобильную версию сайта

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

RewriteCond %{HTTP_USER_AGENT} (?i:midp|samsung|nokia|j2me|avant|docomo|novarra|palmos|palmsource|opwv|chtml|pda|mmp|blackberry|mib|symbian|wireless|nokia|hand|mobi|phone|cdm|upb|audio|SIE|SEC|samsung|HTC|mot-|mitsu|sagem|sony|alcatel|lg|eric|vx|NEC|philips|mmm|xx|panasonic|sharp|wap|sch|rover|pocket|benq|java|pt|pg|vox|amoi|bird|compal|kg|voda|sany|kdd|dbt|sendo|sgh|gradi|jb|dddi|moto|iphone|android) [NC] 
RewriteCond %{HTTP_HOST} site.ru
RewriteRule ^$ http://m.site.com/ [R=302,L]

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

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

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

Универсальная версия

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

RewriteCond %{HTTP_HOST} ^(.*)$ [NC]
RewriteCond %{HTTP_USER_AGENT} (?i:midp|samsung|nokia|j2me|avant|docomo|novarra|palmos|palmsource|opwv|chtml|pda|mmp|blackberry|mib|symbian|wireless|nokia|hand|mobi|phone|cdm|upb|audio|SIE|SEC|samsung|HTC|mot-|mitsu|sagem|sony|alcatel|lg|eric|vx|NEC|philips|mmm|xx|panasonic|sharp|wap|sch|rover|pocket|benq|java|pt|pg|vox|amoi|bird|compal|kg|voda|sany|kdd|dbt|sendo|sgh|gradi|jb|dddi|moto|iphone|android) [NC]
RewriteRule ^$  http://m.%1 [R=302,L]

Редирект с главной страницы

Речь идет про запрос типа site.ru (без site.ru/index.php)

Здесь оказалось не все так очевидно, я столкнулся с необъяснимым поведением.

Реврайт без редиректа (урл не меняется). Рабочий вариант:

RewriteRule ^index.php$  /about/ [L]

Редирект. НЕ рабочий вариант:

RewriteRule ^index.php$  /about/ [R=301,L]

Реврайт без редиректа (урл не меняется). НЕ рабочий вариант:

RewriteRule ^$  /about/ [L]

Редирект. Рабочий вариант:

RewriteRule ^$  /about/ [R=301,L]

Если мне кто — нибудь расскажет почему эти примеры работают крест накрест, а обратно не работают — буду очень рад.

Htaccess WordPress: правильная настройка файла

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

Где лежит htaccess

Htaccess обязательно должен находится в корневой папке сайта, вместе с каталогами типа wp-admin. У меня лежит как показано на снимке, иначе работать не будет, сервер его не найдет.

Как создать чистый htaccess

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

1. В меню выбираем Файл > Сохранить как
2. Появляется окно, в нем вписываем название и папку для сохранения
3. Нажимаем на Сохранить

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

Что нужно добавить в htaccess обязательно

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

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

Стандартный htaccess

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

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

301 редирект на https

Если к ресурсу прикреплен SSL сертификат, то необходимо занести после #BEGIN WordPress конфигурацию 301 редиректа.

RewriteEngine On 
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

Как должен выглядеть правильный htaccess

В итоге правильный код htaccess должен выглядеть так:

# BEGIN WordPress
RewriteEngine On 
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

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

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

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

Что еще можно подключить в htaccess

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

• Кэш браузера
• Gzip сжатие
• Защита wp-config, нет ли доступа его просмотреть

Кэш браузера

Для начала проверим активен ли кэш браузера на сайте, переходим на сервис webpagetest, вводим в поле url главной страницы и находим start scan.

Ждем процесса проверки и смотрим на результаты. Ищем строчку Leverage browser caching и определяем кэшируются ли документы. В моем случае да, исключение – метрика, аналитика и vk, на них повлиять нельзя.

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

<ifModule mod_headers.c>
<FilesMatch "\.(html|htm)$">Header set Cache-Control "max-age=43100</FilesMatch>
<FilesMatch "\.(js|css|txt)$">Header set Cache-Control "max-age=604700</FilesMatch>
<FilesMatch "\.(flv|swf|ico|gif|jpg|jpeg|png)$">Header set Cache-Control "max-age=2591000"</FilesMatch>
<FilesMatch "\.(pl|php|cgi|spl|scgi|fcgi)$">Header unset Cache-Control</FilesMatch>
</IfModule>

Gzip сжатие

Gzip сжатие потеряло актуальность при появлении AMP и Турбо страниц, но пользоваться ими нужно. Проверяем тем же сервисом webpagetest, только ищем строчку “Use gzip compression for transferring compressable responses”.

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

<ifModule mod_gzip.c>
  mod_gzip_on Yes
  mod_gzip_dechunk Yes
  mod_gzip_item_include file \.(html?|txt|css|js|php|pl)$
  mod_gzip_item_include mime ^application/x-javascript.*
  mod_gzip_item_include mime ^text/.*
  mod_gzip_item_exclude rspheader ^Content-Encoding:.*gzip.*
  mod_gzip_item_exclude mime ^image/.* 
  mod_gzip_item_include handler ^cgi-script$
</ifModule>

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

Для безопасности и защиты wp-config

В 99,9% проблемы нет, но перестраховаться стоит. Заходим на сайт и приписываем к адресу /wp-admin.php, смотрим что выдает браузер.

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

<Files wp-config.php>
order allow,deny
deny from all
</Files>

Посетители спрашивают, а нужно ли добавлять правила для плагинов WooCommerce, BBPress, Elementor и им подобным. Отвечу – нет, все встроено в сами плагинах. Будет полезно прочитать как создавать robots txt. В заключении дам видео инструкцию, чтобы сделать процесс более понятным.

Вывод настройки

Настройка htaccess в WordPress не сложная, потому что разработчики и хостер сделали все условия, чтобы снизить количество ошибок. В статье показал правильный вариант, в котором только стандартные директивы и перенаправление на https, остальные функции должны быть встроены и работать изначально. В любом случае сначала пишем в поддержку, и только потом делаем сами.

.htaccess не работает — способы устранения и устранения неполадок

Обновлено 14 марта 2020 г.

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

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

Общие проблемы .htaccess

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

.htaccess необходимо включить с помощью AllowOverride

Это первое, что необходимо проверить. Если для директивы AllowOverride установлено значение None , то это отключит все файлы .htaccess . Чтобы проверить это, вы должны открыть файл конфигурации Apache (обычно он называется httpd.conf или apache.conf ) и убедитесь, что для директивы AllowOverride установлено значение AllowOverride All . Если вам нужно было внести изменения в конфигурацию Apache, не забудьте сохранить файл и перезапустить Apache .

  sudo service apache2 перезапуск
  

Имя файла написано с ошибкой или не начинается с периода

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

Расположение ваших правил должно быть выше или ниже других

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

Конфликт файлов .htaccess

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

Используется неправильный синтаксис

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

Устранение неполадок .htaccess не работает

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

Использование валидатора .htaccess

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

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

Проверка журнала ошибок Apache

Если после внесения изменений в файл .htaccess ваш веб-сайт сломается, вы также можете проверить журнал ошибок Apache для получения дополнительной отладочной информации.index \ .php $ — [L] RewriteCond% {REQUEST_FILENAME}! -F RewriteCond% {REQUEST_FILENAME}! -D RewriteRule. /index.php [L] # КОНЕЦ WordPress Это какая-то тарабарщина

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

  sudo tail /var/log/apache2/error.log
  

В этом случае Apache выдает следующую ошибку:

  / var / www / wordpress /.htaccess: Неверная команда 'This', возможно, неправильно написана или определена модулем, не включенным в конфигурацию сервера, ссылка: http://yourwebsite.com/
  

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

Отладка с помощью файла конфигурации Apache

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

  
    Параметры Индексы FollowSymLinks MultiViews
    AllowOverride All
    Заказать разрешить, запретить
    разрешить от всех

    # НАЧАТЬ WordPress
    
    # КОНЕЦ WordPress

    Это тарабарщина

  

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

  судо apache2ctl -t
  

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

Отладка mod_rewrite с журналами

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

  Перезапись предупреждений LogLevel: trace6
  

В приведенном выше фрагменте будут регистрироваться все ошибки mod_rewrite вплоть до уровня «предупреждения» в файле error.log . Ознакомьтесь с директивой уровня журнала Apache, чтобы узнать больше. Следует отметить, что чем выше уровень журнала трассировки, тем медленнее будет работать ваш веб-сервер Apache.

Сводка

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

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

php — Как проверить, включен ли mod_rewrite на сервере?

1. Около
2. Товары
3. Для команд

1. Переполнение стека Общественные вопросы и ответы
2. Переполнение стека для команд Где разработчики и технологи делятся частными знаниями с коллегами
3. работы Программирование и связанные с ним технические возможности карьерного роста
4. Талант Нанимайте технических специалистов и создавайте свой бренд работодателя
5. реклама Обратитесь к разработчикам и технологам со всего мира
6. О компании

Загрузка…

apache — .htaccess: проверьте, имеет ли строка запроса определенное значение, или перенаправьте его

1. Около
2. Товары
3. Для команд

1. Переполнение стека Общественные вопросы и ответы
2. Переполнение стека для команд Где разработчики и технологи делятся частными знаниями с коллегами
3. работы Программирование и связанные с ним технические возможности карьерного роста
4. Талант Нанимайте технических специалистов и создавайте свой бренд работодателя
5. реклама Обратитесь к разработчикам и технологам со всего мира

.htaccess — проверьте HTTP_REFERER на сервере Windows

1. Около
2. Товары
3. Для команд

1. Переполнение стека Общественные вопросы и ответы
2. Переполнение стека для команд Где разработчики и технологи делятся частными знаниями с коллегами
3. работы Программирование и связанные с ним технические возможности карьерного роста
4. Талант Нанимайте технических специалистов и создавайте свой бренд работодателя
5. реклама Обратитесь к разработчикам и технологам со всего мира