.htaccess – co to jest i jak go wykorzystać?

Plik konfiguracyjny, który Apache nazywa rozproszonym

Nazwa „rozproszona konfiguracja” dobrze oddaje istotę rzeczy. To nie jest osobny mechanizm, tylko ta sama konfiguracja serwera, przeniesiona bliżej plików i wczytywana inaczej. Cała reszta różnic wynika właśnie z tego „inaczej”.

Apache odradza własny plik i tłumaczy dlaczego

Rzecz, która ginie w poradnikach: dokumentacja Apache zaleca nie używać .htaccess, jeśli ma się dostęp do głównej konfiguracji. „If you have access to the main server configuration file, you should put all of your configuration there instead of in .htaccess files”.1

Powód jest mierzalny, nie estetyczny. Włączenie obsługi tych plików każe serwerowi szukać ich w każdym katalogu, i to niezależnie od tego, czy gdziekolwiek istnieją: „permitting .htaccess files causes a performance hit, whether or not you actually even use them! Also, the .htaccess file is loaded every time a document is requested”.1

Do tego dochodzi przeszukiwanie katalogów nadrzędnych, bo serwer musi złożyć komplet obowiązujących dyrektyw. Dokumentacja podaje przykład: przy żądaniu pliku z katalogu /www/htdocs/example serwer sprawdza cztery lokalizacje, „even if none of those files are present”.1 Sama dokumentacja od razu to relatywizuje: taki rachunek obowiązuje tylko wtedy, gdy obsługę włączono już od katalogu głównego, co nie jest typowe.1 Uczciwie jest cytować obie części tego zdania, nie samą pierwszą.

Alternatywa działa odwrotnie: „Directives in the main configuration are loaded once at server start, rather than on every request”.1 Stąd praktyczna właściwość, dla której .htaccess bywa jednak wybierany: zmiana działa natychmiast, bez przeładowania serwera. To nie jest zaleta konstrukcyjna, tylko konsekwencja wczytywania pliku przy każdym żądaniu.

Domyślnie mechanizm jest wyłączony

Powszechne wyobrażenie mówi, że .htaccess po prostu „działa”. W rzeczywistości obsługę trzeba włączyć dyrektywą AllowOverride, której wartością domyślną jest None.2 Dokumentacja idzie dalej i formułuje zalecenie wprost: „For security and performance reasons, do not set AllowOverride to anything other than None in your <Directory "/"> block”.2

Na hostingu współdzielonym decyzję podjął więc administrator, nie właściciel strony. Można powiedzieć, że korzystamy z odstępstwa od zalecenia producenta, zrobionego po to, żeby użytkownicy bez dostępu do głównej konfiguracji mogli w ogóle cokolwiek ustawić.

Plik jest przy tym specyficzny dla Apache. Dokumentacja nginx nie zna takiej dyrektywy, a osobny jej rozdział poświęcony jest temu, jak przenieść reguły z .htaccess do konfiguracji serwera. Otwiera go zdanie o ludziach, którzy „during their shared hosting life used to configure everything using only Apache’s .htaccess files”.3 Na serwerze innym niż Apache plik zwyczajnie nic nie robi.

Nasz plik: 74 linie, trzy bloki i jeden po sklepie, którego nie ma

Sprawdziliśmy własny serwer 2 września 2026 roku. Plik ma 2729 bajtów i 74 linie, a w całej instalacji WordPressa jest ich 28. Zawartość dzieli się na trzy oznaczone bloki: reguły wtyczki przyspieszającej, blok WordPressa i blok po sklepie Ecwid, który w serwisie od dawna nie działa. Blokowaniem robotów ten plik u nas nie steruje. Od tego jest plik robots.txt. Najliczniejsze dyrektywy to nagłówki wygasania dla typów plików, w sumie czternaście, oraz sześć reguł przepisywania adresów.

Ścieżka do katalogu strony ma siedem segmentów. Gdyby obsługa plików była włączona od katalogu głównego, każde żądanie oznaczałoby osiem dodatkowych zajrzeń do systemu plików, czyli dokładnie ten rachunek, który dokumentacja pokazuje na przykładzie czterech.

Najciekawsze okazało się coś innego. Adres pliku otwarty z zewnątrz zwraca kod HTTP 403, czyli dostęp jest zablokowany. Ale reguły, która to robi, w naszym pliku nie ma wcale: nie zawiera on ani jednej dyrektywy odmawiającej dostępu do samego siebie. Blokada pochodzi z głównej konfiguracji serwera, czyli z miejsca, w którym Apache zaleca trzymać reguły. Ochrona, którą powszechnie przypisuje się temu plikowi, w naszym przypadku w ogóle z niego nie wynika.

Test wymagał zresztą poprawki. Pierwsza wersja porównywała odpowiedź dla realnego pliku z odpowiedzią dla nazwy zmyślonej i obie dawały 403, co wyglądało na niedziałający sprawdzian. Powód był prozaiczny: zmyśloną nazwę utworzyliśmy przez dopisanie znaków do nazwy właściwej, więc też podpadała pod regułę blokującą. Dopiero nazwa spoza tego wzorca dała 404 i pokazała, że test w ogóle rozróżnia oba przypadki. Kontrola musi leżeć poza zakresem reguły, którą sprawdza.

Co z tego wynika w praktyce

Pierwszy wniosek dotyczy zakresu. Zanim wpisze się regułę do .htaccess, dobrze jest sprawdzić, czy nie ma jej już w konfiguracji serwera albo we wtyczce. U nas przekierowania 301 obsługuje osobny mechanizm, a nie ten plik, więc dopisywanie ich tutaj tworzyłoby drugie, konkurencyjne źródło prawdy.

Drugi dotyczy porządków. Blok po nieużywanym sklepie jest wczytywany przy każdym żądaniu tak samo jak reszta. To niewielki koszt, ale zerowy pożytek, a przy okazji mylący ślad dla kogoś, kto będzie ten plik czytał za rok.

Trzeci dotyczy ryzyka. Błąd składni w tym pliku nie ogranicza się do jednej funkcji: potrafi wyłączyć cały katalog wraz z podkatalogami, bo dyrektywy obowiązują w dół drzewa.1 Dlatego kopia przed edycją nie jest przesadną ostrożnością, tylko jedynym szybkim sposobem powrotu, gdy strona przestanie odpowiadać.

Najczęstsze pytania

Czy .htaccess działa na każdym serwerze?
Nie. To mechanizm Apache. Nginx nie zna takiej dyrektywy i wymaga przeniesienia reguł do własnej konfiguracji.3

Czy używanie .htaccess spowalnia stronę?
Sama możliwość ich używania kosztuje, bo serwer szuka tych plików przy każdym żądaniu, nawet jeśli nie istnieją.1 Skala zależy od tego, od którego katalogu obsługę włączono.

Dlaczego zmiany w .htaccess działają natychmiast?
Bo plik jest wczytywany przy każdym żądaniu, w odróżnieniu od głównej konfiguracji, która ładuje się raz przy starcie serwera.1

Czy trzeba samemu blokować dostęp do tego pliku?
Zwykle nie, bo robi to konfiguracja serwera. Lepiej to jednak sprawdzić, niż zakładać. U nas blokada działa, choć w samym pliku nie ma jej ani śladu.

Źródła

1. Apache HTTP Server Documentation, „htaccess files” — definicja plików rozproszonej konfiguracji, zalecenie używania głównej konfiguracji, mechanizm kosztu wraz z zastrzeżeniem oraz różnica w momencie wczytywania. Zobacz dokumentację Apache →

2. Apache HTTP Server Documentation, „Core Directives — AllowOverride” — domyślna wartość None oraz zalecenie dotyczące katalogu głównego. Zobacz opis dyrektywy AllowOverride →

3. nginx documentation, „Converting rewrite rules” — dokument o przenoszeniu reguł z .htaccess do konfiguracji nginx. Zobacz dokumentację nginx →