Türkei (Türkisch)
Germany (German)
Worldwide (English)
AnforderungsflussClient, NGINX und Backend-Verbindungsbrempunkt
Halkali Merkez Viertel Fatih Str. Ozgur Apt. No. 46, Kucukcekmece, Istanbul, 34303, TR
403 Forbidden bedeutet, dass NGINX die Anfrage verstanden hat, aber den Zugriff auf die Ressource verweigert hat. Das Problem kann durch eine fehlende Indexdatei, Ordner-Ausführungsberechtigung, Besitz, Zulassungs-/Verweigerungsregel, SELinux, Symlink-Richtlinie oder Sicherheitsschicht verursacht werden.
2026/07/17 03:31:08 [error] 2261#2261: *731 directory index of "/var/www/example/" is forbidden
2026/07/17 03:31:12 [error] 2261#2261: *734 open() "/var/www/example/index.php" failed (13: Permission denied)403 ist anders als 404, was bedeutet, dass die Datei nicht gefunden wurde. NGINX sieht möglicherweise die Quelle oder das Verzeichnis, aber die Konfiguration oder der Zugriff auf das Betriebssystem wird blockiert.
Wenn die Verzeichnisanfrage keine index.php oder index.html findet und autoindex deaktiviert ist, schreibt NGINX 'directory index ... is forbidden'. In diesem Fall sollte anstelle der Erhöhung der Berechtigungen die Dokumentenwurzel und die Index-Anweisung überprüft werden.
Die Datei mit 644 und der Ordner mit 755 ist nicht ausreichend. Der NGINX-Worker-Benutzer muss Ausführungsberechtigungen auf allen übergeordneten Ordnern bis zum Document-Root haben.
Die allow- und deny-Regeln werden in der Reihenfolge ausgewertet. Ein von dem oberen http/server-Block vererbtes deny oder ein falsches IP-Netzwerk kann dazu führen, dass bestimmte Besucher eine 403-Seite sehen.
SELinux-Kontext kann den Zugriff sogar dann blockieren, wenn die Unix-Rechte auf RHEL-basierten Systemen korrekt erscheinen. Der AVC-Log sollte vor dem Schließen der Sicherheitslage überprüft werden.
Die Verwendung von 777 für die 403-Lösung ist kein Fix, sondern eine Sicherheitslücke; namei, stat, NGINX-Worker und Sicherheitslogs sollten die Zugriffskette beweisen.
Suchen Sie nach dem Ausdruck, den Sie in der E-Mail, im Browser oder im SSH-Protokoll sehen. Jede Karte enthält eine Bedeutung, eine wahrscheinliche Ursache und eine sichere erste Maßnahme.
Bedeutung: Keine geeignete Indexdatei im Verzeichnis oder Verzeichnisanzeige ist deaktiviert.
Mögliche Ursache: Falscher root, fehlende Index oder Index-Direktive.
Bedeutung: NGINX kann die Datei auf Betriebssystemebene nicht öffnen.
Mögliche Ursache: Datei-/Ordnerberechtigungen, Besitz, ACL oder SELinux.
Bedeutung: NGINX allow/deny oder eine ähnliche Zugriffsregel blockierte die Anfrage.
Mögliche Ursache: Falsches IP-Netzwerk, Include-Datei oder von der oberen Block geerbt.
Bedeutung: Symlink-Richtlinie oder Ziel-Verzeichnis-Zugriff wurde verweigert.
Mögliche Ursache: disable_symlinks, Rechte- oder Eigenalleerungleichheit.
Bedeutung: Der allgemeine Browser-Meldung zeigt den ursprünglichen Grund nicht an.
Mögliche Ursache: Index, Berechtigung, Zugriffsregel oder Sicherheitsschicht.
Bedeutung: Die Server-Konfiguration hat den Client abgelehnt.
Mögliche Ursache: IP-Richtlinie, location-Deny oder Plesk-Extra-Direktive.
Bedeutung: Kernel-Sicherheitspolitik blockierte NGINX-Zugriff.
Mögliche Ursache: Falscher Kontext oder erforderlicher boolean geschlossen.
Bedeutung: FastCGI-Ziel weist auf den falschen Skriptpfad hin.
Mögliche Ursache: root/alias- und SCRIPT_FILENAME-Inkompatibilität.
Es wurden keine Datensätze gefunden, die diesem Ausdruck entsprechen.
Befehle sind für den Root-Zugriff vorgesehen. Sammeln Sie zunächst nur den Status und die Protokolle. Ändern Sie die dauerhafte Einstellung nicht, ohne den Grund dafür zu erkennen.
namei -l /var/www/example/index.php
stat /var/www/example /var/www/example/index.php
getfacl -p /var/www/example 2>/dev/nullZeigt den gesamten Zugriffszweig einschließlich der Elternordner an.
ps -eo user,group,cmd | grep '[n]ginx: worker'
grep -n '^user' /etc/nginx/nginx.confBestimmt den tatsächlichen Benutzer, der Zugriff auf die Dateien benötigt.
nginx -T | grep -nE 'server_name|root |alias |index |allow |deny |disable_symlinks'Zeigt aktive virtuelle Hosts und Zugriffsanweisungen an.
getenforce
ls -Zd /var/www/example
ausearch -m AVC -ts recent | tail -n 50Überprüft SELinux-Einschränkung außerhalb von Unix-Rechten.
tail -n 150 /var/log/nginx/error.log
curl -skI https://example.com/Testet die Anfrage und die Log-Zeile gleichzeitig.
nginx -t && systemctl reload nginxWenn die Konfiguration erfolgreich ist, läuft sie ununterbrochen.
Obwohl die Grundursache des NGINX-Fehlers dieselbe ist, variieren Paketpfade, Dienstnamen, Sicherheitsebenen und die Verwaltung virtueller Hosts je nach verwendeter Linux-Distribution oder Plesk-Infrastruktur.
NGINX 403 Forbidden mit systemd, Paketpfad und journald-Prüfunglen.
namei -l /var/www/example/index.php
nginx -T | grep -nE 'root |index |allow |deny '
tail -n 100 /var/log/nginx/error.logNGINX 403 Forbidden mit SELinux, PHP-FPM-Pool und RHEL-basierten Dienstkontrollen.
namei -l /var/www/example/index.php
getenforce
ausearch -m AVC -ts recent | tail -n 30Plesk-generierte NGINX-Virtualhostdateien in nginx 403 Forbidden Prüfungle.
tail -n 100 /var/www/vhosts/system/example.com/logs/proxy_error_log
plesk repair web example.com -n
nginx -tZuerst herausfinden, warum NGINX ablehnt; testiere die Indexe, Berechtigungen, Zugriffsregeln und Sicherheitslayer einzeln.
Bestimmen Sie, ob der Fehler für alle gilt, oder nur für eine bestimmte IP-Adresse oder Domain.
curl -skI https://example.com/korumali/Verzeichnisindex, Zugriffsverbot oder Access Forbidden gefunden.
tail -n 100 /var/log/nginx/error.logÜberprüfen Sie, dass der aktive Serverblock den realen Dateipfad ansieht.
nginx -T | grep -nE 'server_name|root |index 'Ausführungsberechtigung für NGINX-Worker muss in allen übergeordneten Ordnern vorhanden sein.
namei -l /var/www/example/index.phpTrennen Sie allow/deny-, ACL-, SELinux- und WAF-Protokolle.
nginx -T | grep -nE 'allow |deny '; ausearch -m AVC -ts recent | tailErstellen Sie Änderungen nur an der fehlerhaften Pfad/Regel und überprüfen Sie die neue 403-Einträge.
nginx -t && systemctl reload nginx
curl -skI https://example.com/korumali/Fügen Sie die richtige Indexdatei hinzu oder treffen Sie eine bewusste Autoindex-Entscheidung.
ls -la /var/www/example; nginx -T | grep -n 'index 'Überprüfen Sie allow/deny-, WAF- und fail2ban-Protokolle.
nginx -T | grep -nE 'allow |deny 'Die echten Zielrechte und die disable_symlinks-Direktive untersuchen.
readlink -f /var/www/example/current; namei -l /var/www/example/currentSELinux AVC-Protokolle und Datei-Kontext sollten überprüft werden.
ls -Zd /var/www/example; ausearch -m AVC -ts recent | tailTrennen Sie die Uploads-Eigenalleerschaft, die Hotlink/WAF-Regel und die Ortsumschreibung.
curl -skI https://example.com/wp-content/uploads/test.jpgÜberprüfen Sie den Inhalt der zusätzlichen nginx-Direktiven auf dem Domains-Bildschirm.
plesk repair web example.com -nFehlende Indexdatei, falscher Root, Dateiberechtigungen, Eigenalleerschaft, allow/deny-Regeln, SELinux oder Sicherheitslayer sind die häufigsten Ursachen.
Stellen Sie zunächst sicher, dass der korrekte Document-Root index.php oder index.html enthält und dass die Index-Direktive diese Datei enthält.
Nein. Die Sicherheitslücke 777 schafft und versteckt den realen Besitzer/Zugriffschain-Probleme. name, stat und worker-Benutzerkontrolle sollten durchgeführt werden.
SELinux, ACL, allow/deny, WAF, Symlink-Politik oder falsche document root Unix-Rechte können trotz korrekter Einstellung noch einen 403-Fehler erzeugen.
Überprüfen Sie die Benutzerrichtlinie in nginx.conf und den Benutzer des laufenden Worker-Prozesses mit der ps-Kommandozeile.
Uploads-Berechtigungen, Sicherheits-Plugin, WAF, Hotlink-Regel, verweigerte Standort oder falscher PHP-Skriptpfad.
Überprüfen Sie zunächst die Domain proxy_error_log und zusätzliche NGINX-Direktiven; falls erforderlich, sollte der Befehl plesk repair web für die betreffende Domain verwendet werden.
Durch die gemeinsame Analyse von cPanel, WHM, CloudLinux, LiteSpeed, MariaDB, Exim und Sicherheitsebenen beheben wir die Grundursache des Fehlers, anstatt nur den Dienst zu entfernen.