403 oznacza, że serwer odmawia dostępu do zasobu. Sprawdź, czy blokowana jest cała strona, katalog czy konkretne żądanie, a następnie porównaj log, katalog dokumentów, reguły dostępu i zabezpieczenia.
Czy odmowa dostępu jest rzeczywiście błędem?
403 przy próbie otwarcia katalogu kopii lub konfiguracji może być prawidłowym zabezpieczeniem. Problem zaczyna się wtedy, gdy odmowa obejmuje stronę główną, formularz albo publiczną podstronę. Nie usuwaj ograniczeń dostępu tylko dlatego, że przeglądarka pokazuje nieprzyjemny komunikat.
Zapisz pełny URL, godzinę i czynność wywołującą odpowiedź. Czy to otwarcie strony, zapis w panelu czy wysłanie formularza? Jeśli tylko jedna operacja kończy się 403, rozwiązanie dotyczące pliku index raczej nie wyjaśni całego zdarzenia.
Sprawdź zakres i warstwę blokady
Otwórz stronę w prywatnym oknie i porównaj wynik z innej sieci. Nie próbuj masowo ponawiać blokowanego formularza: może to utrudnić odczyt logów i uruchomić kolejne ograniczenia. Zanotuj identyfikator żądania, jeżeli strona błędu go wyświetla.
| Zakres problemu | Najbardziej użyteczna kontrola |
|---|---|
| Tylko katalog bez pliku | Czy istnieje index i czy listowanie jest celowo wyłączone |
| Cała domena po wdrożeniu | Katalog dokumentów, właściciel i reguły dostępu |
| Tylko zapis formularza | Log WAF, reguła bezpieczeństwa i treść żądania |
| Tylko jedna sieć | Blokada adresu IP lub ograniczenie dostępu |
| Tylko panel administratora | Wtyczka ochronna, lista dozwolonych adresów, sesja |
Jeżeli korzystasz z CDN lub WAF, 403 może powstawać przed dotarciem do hostingu. Wygląd strony błędu jest wskazówką, lecz potwierdzenie powinno pochodzić z logów właściwej warstwy.
Katalog strony i plik wejściowy
Po przesłaniu archiwum częstym problemem jest dodatkowy poziom katalogów. Pliki znajdują się np. w public_html/blog/, a domena nadal wskazuje na public_html/. Sprawdź katalog dokumentów skonfigurowany w panelu i obecność właściwego index.html lub index.php.
Nie włączaj listowania katalogu jako sposobu uruchomienia witryny. Lista plików nie zastępuje strony głównej i może ujawnić pliki, których nie zamierzałeś publikować. Jeśli aplikacja ma katalog public, sprawdź jej instrukcję wdrożenia — główny katalog projektu nie zawsze jest katalogiem przeznaczonym do udostępnienia w internecie.
Uprawnienia i właściciel
Proces obsługujący stronę musi mieć odpowiedni dostęp do plików oraz katalogów po drodze. Prawa i właściciel zależą od sposobu uruchamiania aplikacji na hostingu. Nie stosuj rekurencyjnego chmod 777. Taka zmiana może zwiększyć ryzyko zapisu przez nieuprawnione procesy i nadal nie rozwiązać problemu właściciela.
Porównaj ustawienia z działającymi plikami tego samego konta albo poproś operatora o przywrócenie praw właściwych dla usługi. Zapisz dokładny komunikat permission denied z logu, jeżeli występuje. Sama wartość widoczna w kliencie plików nie pokazuje wszystkich warstw kontroli dostępu.
.htaccess, WordPress i WAF
Na Apache reguły autoryzacji mogą celowo odmawiać dostępu. Zachowaj kopię .htaccess i przejrzyj ostatnie zmiany, szczególnie blokady IP i reguły ochrony panelu. Nie usuwaj całego pliku bez rozpoznania: może zawierać również routing i zabezpieczenia aplikacji. Nginx nie interpretuje .htaccess.
Jeśli blokada zaczęła się po instalacji wtyczki bezpieczeństwa, sprawdź jej log i dokumentację. Dla WAF przekaż operatorowi konkretny adres, czas i identyfikator zdarzenia. Celem jest korekta błędnej reguły dla danej operacji, a nie globalne wyłączenie ochrony.
Kiedy uznać naprawę za zakończoną?
Powtórz dokładnie operację, która wcześniej zawodziła, oraz sprawdź inne publiczne podstrony. Upewnij się, że katalogi prywatne pozostały chronione. Jeśli przygotowujesz wdrożenie na hostingu Castpol, podaj strukturę aplikacji i jej katalog publiczny — ułatwia to poprawne uruchomienie strony od początku.