Po wdrożeniu aplikacji strona główna nagle zwraca 403 Forbidden, choć Nginx działa, a pliki są na serwerze. Najczęściej blokuje ją brak pliku indeksowego, niedostępne uprawnienia albo reguła dostępu, ale sam kod odpowiedzi nie wskazuje jeszcze, która z tych przyczyn wystąpiła.
Najpierw odczytaj powód z logu, dopiero potem zmieniaj konfigurację
- „directory index … is forbidden” zwykle oznacza brak pliku indeksowego w żądanym katalogu.
- „Permission denied” kieruje do uprawnień pliku lub któregoś katalogu nadrzędnego.
- „access forbidden by rule” wskazuje na regułę dostępu, na przykład
deny. - Nie włączaj odruchowo
autoindex, bo zamiast strony możesz ujawnić publiczny spis plików.
403 nie podaje przyczyny, ale log zwykle ją zdradza
Kod 403 oznacza, że serwer odmawia dostępu do żądanego zasobu. W Nginx przyczyną może być konfiguracja strony, brak pliku indeksowego, prawa systemu plików lub ograniczenie dostępu dla danego adresu IP. Komunikat widoczny w przeglądarce nie wystarcza do diagnozy, bo różne problemy mogą wyglądać identycznie.
Uważam, że pierwszą zmianą nie powinno być masowe ustawianie praw na plikach. Najpierw odśwież stronę, a zaraz potem sprawdź najnowszy wpis w error.log. Ścieżka do logu zależy od konfiguracji, więc jeśli standardowe miejsce jest puste, poszukaj dyrektywy error_log w konfiguracji serwera.
sudo tail -n 50 /var/log/nginx/error.logNajbardziej przydatna jest końcówka wpisu, która nazywa problem. To ona rozstrzyga, czy szukać w plikach, konfiguracji dostępu, czy poza samym Nginx.
Treść wpisu wskazuje, od którego testu zacząć
Nie każdy błąd 403 oznacza problem z uprawnieniami. Przykładowo komunikat o indeksie katalogu i komunikat o odmowie systemu operacyjnego prowadzą do zupełnie innych napraw, dlatego najpierw dopasuj log do objawu.
| Wpis w logu lub sytuacja | Prawdopodobna przyczyna | Co sprawdzić |
|---|---|---|
directory index of ".../" is forbidden |
Żądany katalog nie zawiera pliku indeksowego rozpoznawanego przez konfigurację. | Sprawdź root, zawartość katalogu oraz dyrektywę index. |
Permission denied lub (13: Permission denied) |
Proces Nginx nie może odczytać pliku albo przejść przez katalog na ścieżce. | Sprawdź prawa pliku i katalogów nadrzędnych oraz to, z jakim użytkownikiem działa proces roboczy. |
access forbidden by rule |
Żądanie trafia na regułę ograniczającą dostęp. | Przejrzyj dyrektywy allow i deny w pasującym bloku location lub server. |
| Brak odpowiadającego wpisu w logu Nginx | 403 może zwracać inna warstwa, na przykład aplikacja, CDN, proxy lub panel hostingowy. | Ustal, który komponent obsłużył żądanie, i sprawdź jego logi oraz nagłówki odpowiedzi. |
Przy regułach dostępu kolejność ma znaczenie: Nginx sprawdza dyrektywy allow i deny po kolei, aż znajdzie dopasowanie. Dokumentacja modułu ngx_http_access_module wskazuje też, że reguły z poziomu nadrzędnego są dziedziczone tylko wtedy, gdy w bieżącym bloku nie zdefiniowano własnych reguł dostępu. To może wyjaśnić, dlaczego poprawka w jednym location nie zmienia zachowania innego.
Brak indeksu naprawiasz bez otwierania katalogu
Gdy w logu pojawia się informacja o zabronionym indeksie katalogu, sprawdź, czy katalog wskazany przez root rzeczywiście zawiera stronę startową. Domyślną nazwą w Nginx jest index.html; jeśli aplikacja korzysta z innego pliku, trzeba uwzględnić go w konfiguracji index.
location / {
root /var/www/app/public;
index index.html index.php;
}W przykładzie ścieżka /var/www/app/public musi odpowiadać katalogowi, w którym faktycznie znajdują się pliki serwowane przez Nginx. Dyrektywa index może też spowodować wewnętrzne przekierowanie do innego bloku location, więc jeśli plik istnieje, a błąd zostaje, sprawdź również konfigurację dopasowaną do jego ścieżki. Tak działa moduł ngx_http_index_module.
Nie włączaj autoindex on jako szybkiego lekarstwa. Ta dyrektywa generuje listę plików w katalogu, a nie stronę aplikacji; jeśli trafi na publiczną ścieżkę, może ujawnić nazwy i strukturę dostępnych tam zasobów. Zostaw domyślne autoindex off, chyba że celowo udostępniasz katalogi. Opis działania modułu znajduje się w dokumentacji ngx_http_autoindex_module.
Przy Permission denied sprawdź całą ścieżkę, nie sam plik
Plik może mieć prawo odczytu, a mimo to pozostać niedostępny dla Nginx, jeśli proces nie może przejść przez któryś katalog nadrzędny. Sprawdź więc ścieżkę od katalogu głównego aż po plik, zamiast zmieniać uprawnienia wyłącznie na index.html.
namei -l /var/www/app/public/index.htmlWynik pokazuje uprawnienia kolejnych elementów ścieżki. Porównaj je z użytkownikiem procesu roboczego Nginx, który możesz ustalić w konfiguracji, między innymi przez dyrektywę user. Nie stosuj bez namysłu rekurencyjnego chmod 777: przyznaje szeroki dostęp i zaciemnia właściwą przyczynę problemu.
Jeśli prawa plików wyglądają poprawnie, sprawdź dodatkowe mechanizmy systemowe, takie jak ACL lub SELinux, oraz sposób montowania woluminu w kontenerze. Przy wdrożeniu kontenerowym ścieżka podana w root musi być dostępna wewnątrz kontenera, a nie wyłącznie na hoście.
Po zmianie konfiguracji sprawdź, czy naprawiasz właściwą warstwę
403 dla strony startowej i 403 tylko dla pliku statycznego sugerują inne tropy. Jeśli błąd dotyczy jednego endpointu aplikacji, sprawdź także odpowiedź backendu; Nginx może przekazywać ją dalej zamiast samodzielnie blokować dostęp.
Po edycji konfiguracji przetestuj jej składnię, a dopiero później przeładuj serwer. Polecenie nginx -t sprawdza poprawność konfiguracji, natomiast nginx -T dodatkowo wypisuje aktywną konfigurację, co pomaga wykryć plik dołączany przez include lub nieoczekiwany blok obsługujący żądanie.
sudo nginx -t
sudo systemctl reload nginxJeśli konfiguracja przechodzi test, a 403 nadal występuje, sprawdź, czy zmieniony blok faktycznie obsługuje ten host i adres URL. Warto też ponownie odczytać log po pojedynczym żądaniu, bo nowy wpis pokaże, czy naprawa usunęła pierwotną przyczynę, czy odsłoniła kolejną.
Najbezpieczniejsza naprawa zaczyna się od jednego wpisu
Przy Nginx 403 najkrótsza droga prowadzi od konkretnego żądania do odpowiadającej mu linii w logu, a potem do jednej sprawdzanej zmiany. Brak indeksu wymaga poprawienia ścieżki lub dyrektywy index, odmowa systemu plików wymaga sprawdzenia całej ścieżki, a blokada regułą prowadzi do konfiguracji allow i deny.
Po każdej poprawce wykonaj ponownie to samo żądanie i sprawdź nowy wpis. Dzięki temu nie pomylisz skutecznej naprawy z przypadkowym obejściem, które otwiera dostęp szerzej, niż wymaga tego aplikacja.
