.htaccess w praktyce - przekierowania, blokady, pułapki

Gotowe reguły .htaccess, które naprawdę się przydają: HTTPS i jedna wersja adresu, ochrona wp-config, blokada PHP w uploads - plus ratunek po błędzie 500.

Plik .htaccess to najpotężniejszy i zarazem najbardziej niebezpieczny plik na Twoim hostingu. Kilka linijek potrafi przekierować całą domenę, zablokować dostęp do panelu logowania czy naprawić linki po migracji - i te same kilka linijek z jedną literówką kładzie stronę błędem 500. W tym przewodniku zbieramy reguły, które realnie przydają się właścicielowi strony firmowej, wraz z wyjaśnieniem, co robią i jak je bezpiecznie testować.

Wszystkie przykłady działają na serwerach Apache i LiteSpeed (LiteSpeed czyta .htaccess w formacie zgodnym z Apache). Na naszym hostingu WordPress ma już swój blok reguł - pokażemy też, gdzie dopisywać własne, żeby nie zepsuć tego, co jest.

Czym jest .htaccess i gdzie leży

.htaccess to plik konfiguracyjny serwera WWW działający na poziomie katalogu. Serwer czyta go przy każdym żądaniu do danego katalogu i jego podkatalogów - zmiany działają natychmiast, bez restartu czegokolwiek. Główny plik strony leży w katalogu public_html.

Dwie rzeczy praktyczne na start. Po pierwsze, pliki zaczynające się od kropki są domyślnie ukryte - w kliencie FTP włącz pokazywanie plików ukrytych (w FileZilli: Serwer - Wymuś pokazywanie plików ukrytych), inaczej będziesz przekonany, że pliku nie ma. Po drugie, przed każdą zmianą pobierz kopię obecnego pliku. Cofnięcie błędu to wtedy jedno wgranie, a bez kopii - zgadywanie, jak wyglądał oryginał. Podstawy pracy z plikami przez FTP opisuje poradnik o FileZilli.

Blok WordPressa: czego nie ruszać

Świeży WordPress tworzy w .htaccess sekcję zaczynającą się od # BEGIN WordPress i kończącą # END WordPress. To reguły odpowiedzialne za ładne adresy podstron. Zasada jest prosta: własne reguły dopisuj POZA tym blokiem - najlepiej powyżej. WordPress przy zapisie ustawień bezpośrednich linków przebudowuje zawartość swojego bloku i wszystko, co w nim dopiszesz, może zostać nadpisane bez ostrzeżenia.

Przekierowania: przypadki z życia

Teorię kodów 301/302 i decyzję „kiedy który" omawia osobny przewodnik po przekierowaniach - tutaj same gotowce.

Wymuszenie HTTPS i jednej wersji adresu (z www albo bez) - najczęstsza potrzeba, jedna spójna reguła zamiast dwóch osobnych przekierowań łańcuszkiem:

RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} ^www\. [NC]
RewriteRule ^ https://twojadomena.pl%{REQUEST_URI} [L,R=301]

Ten wariant prowadzi do wersji bez www. Jeśli Twoją wersją główną jest www, zamień warunek drugi na RewriteCond %{HTTP_HOST} !^www\. [NC] i cel na adres z www. Ważne: zanim to włączysz, certyfikat SSL musi już działać - inaczej wyślesz gości prosto na ostrzeżenie przeglądarki.

Pojedyncze przekierowanie starej podstrony (np. po zmianie struktury):

Redirect 301 /stara-oferta https://twojadomena.pl/oferta

Stara domena na nową, z zachowaniem ścieżek:

RewriteEngine On
RewriteCond %{HTTP_HOST} ^(www\.)?staradomena\.pl$ [NC]
RewriteRule ^(.*)$ https://nowadomena.pl/$1 [L,R=301]

Pułapka, którą widzimy stale: testowanie przekierowań w zwykłym oknie przeglądarki. Przeglądarka zapamiętuje przekierowania 301 bardzo agresywnie - po poprawce dalej widzisz stare zachowanie i wydaje się, że reguła nie działa. Testuj w trybie prywatnym albo poleceniem curl -I https://adres, które pokazuje nagłówki bez żadnego cache.

Reguły bezpieczeństwa, które warto mieć

Blokada podglądu katalogów - żeby wejście w katalog bez pliku index nie wyświetlało listy plików:

Options -Indexes

Ochrona wp-config.php - plik z hasłem do bazy nigdy nie powinien być osiągalny po HTTP:

<Files wp-config.php>
Require all denied
</Files>

Blokada wykonywania PHP w katalogu uploads - jedna z najskuteczniejszych barier po włamaniach: nawet jeśli komuś uda się wgrać złośliwy plik przez dziurawą wtyczkę, serwer go nie uruchomi. Utwórz osobny plik .htaccess w katalogu wp-content/uploads z zawartością:

<FilesMatch "\.php$">
Require all denied
</FilesMatch>

Ograniczenie logowania do własnego IP (tylko przy stałym łączu):

<Files wp-login.php>
Require ip 203.0.113.10
</Files>

Te reguły to uzupełnienie, nie zamiennik pełnego zabezpieczenia strony - komplet praktyk zbiera poradnik 12 kroków hardeningu WordPressa. A jeśli chcesz zablokować podkradanie obrazków przez inne strony, dedykowane reguły znajdziesz w tekście o blokowaniu hotlinkingu.

Nagłówki cache dla plików statycznych

Jeśli używasz LiteSpeed Cache, wtyczka ustawia to za Ciebie (sekcja Browser Cache) i poniższe nie jest potrzebne. Przy stronie bez wtyczki cache możesz ustawić czasy ważności ręcznie:

<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/webp "access plus 6 months"
ExpiresByType text/css "access plus 1 month"
ExpiresByType application/javascript "access plus 1 month"
</IfModule>

Dzięki temu powracający gość nie pobiera ponownie grafik i stylów. Sensowną parą dla tych nagłówków jest kompresja odpowiedzi - opisana w tekście o gzip i brotli.

Gdy po zmianie strona pokazuje błąd 500

Internal Server Error tuż po edycji .htaccess to niemal zawsze błąd składni w tym, co właśnie dopisano. Procedura ratunkowa:

  1. Przywróć kopię pliku sprzed zmiany (masz ją, prawda?). Strona wraca natychmiast.
  2. Jeśli kopii nie ma - zmień nazwę pliku na .htaccess_off. Strona wstanie (WordPress bez swojego bloku pokaże błędy 404 na podstronach, ale główna zadziała), a Ty możesz spokojnie szukać literówki.
  3. Dopisuj reguły pojedynczo i po każdej sprawdzaj stronę. Znajdziesz winowajcę w minutę.

Najczęstsze literówki: brak spacji po fladze, niezamknięty nawias sekcji <Files>, cudzysłowy „drukarskie" wklejone z Worda zamiast prostych. Więcej o samych kodach błędów - w przewodniku po błędach HTTP.

Czego w .htaccess nie robić

  • Nie wklejaj hurtowo „mega zestawów bezpieczeństwa" z internetu. Listy po 200 linijek blokujące boty po nazwach sprzed dekady nic nie chronią, a utrudniają diagnostykę. Każda reguła, której nie rozumiesz, to przyszły problem.
  • Nie ustawiaj dyrektyw PHP przez php_value - na nowoczesnych serwerach z PHP w trybie FPM/LSAPI ta składnia kończy się błędem 500. Limity PHP zmienia się w panelu; które i po co, opisuje tekst o ustawieniach php.ini na hostingu.
  • Nie buduj łańcuchów przekierowań. Stary adres - przekierowanie - kolejne przekierowanie - cel. Każdy skok to dodatkowe okrążenie; przekierowuj zawsze bezpośrednio do adresu końcowego.
  • Nie trzymaj reguł „na pamiątkę". Przy przejmowaniu stron po poprzednich wykonawcach regularnie znajdujemy w .htaccess przekierowania do domen, które nie istnieją od lat. Raz na jakiś czas przejrzyj plik i skasuj martwe wpisy.

Podsumowanie

.htaccess najlepiej traktować jak skrzynkę z ostrymi narzędziami: kilka sprawdzonych reguł - wymuszenie HTTPS, przekierowania po zmianach adresów, blokada PHP w uploads, Options -Indexes - załatwia 95% potrzeb zwykłej strony firmowej. Wszystko ponadto dopisuj pojedynczo, z kopią zapasową i testem w trybie prywatnym po każdej zmianie.

Na naszym hostingu LiteSpeed pełna składnia Apache w .htaccess działa od ręki, a jeśli jakaś reguła nie chce zaskoczyć - napisz do pomocy, diagnozujemy takie rzeczy codziennie.

Powiązane poradniki

Wszystkie poradniki z kategorii: Hosting od podstaw

Powiązane usługi McProdukt

  • Hosting WWW NVMe - szybki hosting z LiteSpeed, darmowym SSL i codziennym backupem

Zobacz również