> For the complete documentation index, see [llms.txt](https://docs.instantroot.de/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.instantroot.de/kvm-server/linux/404-not-found-beheben.md). # 404 Not Found beheben Ein 404-Fehler bedeutet, dass der Webserver erreichbar ist, die angeforderte Seite oder Datei aber nicht gefunden wurde. Der Server antwortet also grundsätzlich, kann den aufgerufenen Pfad jedoch nicht ausliefern. Typische Meldungen sind: * `404 Not Found` * `Not Found` * `The requested URL was not found on this server` * `404 Seite nicht gefunden` * `nginx 404 Not Found` * `Apache 404 Not Found` ### Was bedeutet 404 Not Found? Wenn du eine Webseite öffnest, fragt dein Browser eine bestimmte Adresse beim Server an. Beispiel: `https://deinedomain.de/kontakt` Der Webserver sucht dann nach der passenden Datei, Route oder Anwendung für `/kontakt`. Wenn der Webserver dort nichts findet, gibt er den Statuscode `404 Not Found` zurück. Das bedeutet: * die Domain zeigt grundsätzlich auf einen Server * der Webserver antwortet * die angeforderte Seite oder Datei wurde nicht gefunden Ein 404-Fehler ist daher kein vollständiger Serverausfall. ### Häufige Ursachen Ein 404-Fehler kann mehrere Ursachen haben: * falsche URL * Datei wurde gelöscht * Datei liegt im falschen Ordner * Domain zeigt auf den falschen Webroot * falsche Virtual-Host-Konfiguration * fehlende `index.html` oder `index.php` * falsche Weiterleitung * fehlerhafte `.htaccess` * falsche Nginx-Konfiguration * Anwendung hat keine passende Route * WordPress-Permalinks sind fehlerhaft * Cache zeigt eine alte Adresse * Groß- und Kleinschreibung stimmt nicht ### Zuerst prüfen Prüfe zuerst die einfache Ursache: die URL. Achte besonders auf: * Tippfehler * falsche Domain * falschen Unterordner * fehlende Datei-Endung * Groß- und Kleinschreibung * unnötige Leerzeichen * alte Links oder Bookmarks Beispiel: `/Kontakt` ist unter Linux nicht dasselbe wie `/kontakt`. Linux-Dateisysteme unterscheiden Groß- und Kleinschreibung. Windows tut das oft nicht. ### Prüfen, ob der Webserver erreichbar ist Wenn du eine 404-Meldung siehst, ist der Webserver grundsätzlich erreichbar. Trotzdem solltest du prüfen, ob du wirklich den richtigen Server erreichst. Öffne dazu testweise die Startseite deiner Domain: `https://deinedomain.de` Wenn die Startseite funktioniert, betrifft der Fehler wahrscheinlich nur eine bestimmte Unterseite. Wenn auch die Startseite nicht funktioniert, liegt möglicherweise ein anderes Problem vor, zum Beispiel DNS, Webserver, SSL oder Firewall. ### Datei oder Ordner prüfen Wenn du eine statische Datei aufrufen möchtest, muss sie im richtigen Ordner liegen. Beispiel: Du rufst auf: `https://deinedomain.de/test.html` Dann muss die Datei `test.html` im Webverzeichnis deiner Domain liegen. Typische Webverzeichnisse sind zum Beispiel: | Webserver | Häufiges Webverzeichnis | | -------------------- | -------------------------------------- | | Apache | `/var/www/html` | | Nginx | `/var/www/html` | | Plesk | je nach Domain im Kundenverzeichnis | | aaPanel | je nach Website-Pfad | | eigene Konfiguration | abhängig von deiner Virtual-Host-Datei | Prüfe per SSH, ob die Datei vorhanden ist. Beispiel: `ls -la /var/www/html` Wenn die Datei fehlt, lade sie erneut hoch oder lege sie an. ### Startdatei prüfen Wenn du nur die Domain aufrufst, sucht der Webserver nach einer Startdatei. Beispiel: `https://deinedomain.de` Typische Startdateien sind: * `index.html` * `index.htm` * `index.php` Wenn keine Startdatei vorhanden ist, kann je nach Konfiguration ein 404-Fehler oder eine andere Meldung erscheinen. Prüfe deshalb, ob eine Startdatei im Webverzeichnis liegt. Beispiel: `ls -la /var/www/html/index.*` ### Webroot prüfen Der Webroot ist der Ordner, aus dem der Webserver die Webseite ausliefert. Wenn deine Dateien im falschen Ordner liegen, findet der Webserver sie nicht. Beispiel: Deine Webseite liegt hier: `/var/www/meine-webseite` Der Webserver ist aber so eingestellt: `/var/www/html` Dann ruft der Webserver weiterhin `/var/www/html` auf und findet deine Dateien nicht. Prüfe deshalb die Webserver-Konfiguration. ### Apache Virtual Host prüfen Bei Apache wird der Webroot meistens in einer Virtual-Host-Datei festgelegt. Typischer Pfad: `/etc/apache2/sites-available/deinedomain.conf` Suche dort nach: `DocumentRoot` Beispiel: `DocumentRoot /var/www/html` Der angegebene Pfad muss zu dem Ordner passen, in dem deine Webseite liegt. Nach Änderungen an der Apache-Konfiguration solltest du die Konfiguration prüfen. Befehl: `apachectl configtest` Wenn die Prüfung erfolgreich ist, Apache neu laden: `systemctl reload apache2` ### Nginx Server Block prüfen Bei Nginx wird der Webroot in einem Server Block festgelegt. Typischer Pfad: `/etc/nginx/sites-available/deinedomain` Suche dort nach: `root` Beispiel: `root /var/www/html;` Der angegebene Pfad muss zu dem Ordner passen, in dem deine Webseite liegt. Nach Änderungen an der Nginx-Konfiguration solltest du die Konfiguration prüfen. Befehl: `nginx -t` Wenn die Prüfung erfolgreich ist, Nginx neu laden: `systemctl reload nginx` ### Dateirechte prüfen Wenn Dateien vorhanden sind, aber nicht gelesen werden können, kann es je nach Konfiguration ebenfalls zu Fehlern kommen. Prüfe die Rechte deiner Dateien und Ordner. Beispiel: `ls -la /var/www/html` Typische Rechte: * Ordner: `755` * Dateien: `644` Beispielbefehle: `find /var/www/html -type d -exec chmod 755 {} \;` `find /var/www/html -type f -exec chmod 644 {} \;` Der Webserver-Benutzer muss die Dateien lesen können. Bei Debian und Ubuntu ist das häufig: `www-data` ### .htaccess prüfen Bei Apache kann eine fehlerhafte `.htaccess` dazu führen, dass Seiten nicht gefunden werden. Das betrifft besonders: * WordPress * Laravel * Symfony * Weiterleitungen * Rewrite-Regeln * alte CMS-Systeme Prüfe, ob im Webverzeichnis eine `.htaccess` vorhanden ist. Beispiel: `ls -la /var/www/html/.htaccess` Zum Test kannst du die Datei kurz umbenennen: `mv /var/www/html/.htaccess /var/www/html/.htaccess_backup` Danach Webseite erneut aufrufen. Wenn die Seite danach funktioniert, liegt das Problem wahrscheinlich an einer Rewrite-Regel. **Wichtig:** Benenne die Datei nach dem Test wieder zurück oder erstelle eine korrekte neue `.htaccess`. ### Apache Rewrite-Modul prüfen Viele Anwendungen benötigen das Apache-Modul `rewrite`. Prüfe und aktiviere es bei Bedarf. Befehl: `a2enmod rewrite` Danach Apache neu laden: `systemctl reload apache2` Außerdem muss im Apache Virtual Host häufig `AllowOverride All` erlaubt sein, damit `.htaccess`-Regeln greifen. Beispiel: `AllowOverride All` Wenn `AllowOverride None` gesetzt ist, werden `.htaccess`-Regeln ignoriert. ### Nginx Rewrite-Regeln prüfen Bei Nginx wird keine `.htaccess` verwendet. Weiterleitungen und Routen müssen direkt in der Nginx-Konfiguration stehen. Für viele PHP-Anwendungen wird eine Regel wie diese benötigt: `try_files $uri $uri/ /index.php?$query_string;` Wenn diese Regel fehlt, funktionieren Unterseiten oft nicht und zeigen 404. Das betrifft zum Beispiel: * Laravel * Symfony * viele PHP-Frameworks * eigene Anwendungen mit Routing Nach Änderungen Nginx prüfen und neu laden: `nginx -t` `systemctl reload nginx` ### WordPress 404 beheben Bei WordPress entstehen 404-Fehler häufig durch fehlerhafte Permalinks. Typische Anzeichen: * Startseite funktioniert * Unterseiten zeigen 404 * Beiträge zeigen 404 * Adminbereich funktioniert Lösung: 1. Melde dich im WordPress-Adminbereich an. 2. Öffne **Einstellungen**. 3. Öffne **Permalinks**. 4. Klicke auf **Änderungen speichern**, ohne etwas zu ändern. Dadurch werden die Rewrite-Regeln neu geschrieben. Wenn das nicht hilft, prüfe die `.htaccess` und das Apache Rewrite-Modul. ### CMS oder Framework prüfen Wenn du ein CMS oder Framework nutzt, kann ein 404 auch aus der Anwendung selbst kommen. Beispiele: * WordPress findet einen Beitrag nicht * Laravel findet keine Route * Symfony findet keinen Controller * Node.js Anwendung kennt den Pfad nicht * React/Vue Single Page App wird falsch ausgeliefert Prüfe in diesem Fall: * sind die Routen korrekt? * wurde die Anwendung richtig gebaut? * zeigt der Webserver auf den richtigen `public`-Ordner? * sind Umleitungsregeln korrekt? * läuft der Backend-Dienst? * stimmen Umgebungsvariablen? Bei Laravel muss der Webroot normalerweise auf den Ordner `public` zeigen, nicht auf das Hauptverzeichnis des Projekts. ### Single Page Apps prüfen Bei React, Vue oder ähnlichen Single Page Apps tritt häufig ein 404 auf, wenn eine Unterseite direkt aufgerufen wird. Beispiel: `https://deinedomain.de/dashboard` Die Anwendung erwartet, dass der Webserver immer die `index.html` ausliefert und das Routing im Browser übernimmt. Bei Nginx wird dafür oft benötigt: `try_files $uri /index.html;` Bei Apache wird dafür eine passende Rewrite-Regel in der `.htaccess` benötigt. ### DNS prüfen Ein 404 kann auch erscheinen, wenn deine Domain auf den falschen Server zeigt. Das passiert zum Beispiel nach einem Serverwechsel oder einer neuen IP-Adresse. Prüfe deshalb, ob die Domain auf die richtige IP-Adresse zeigt. Beispiel: `deinedomain.de` muss auf die IP-Adresse deines KVM-Servers zeigen. Wenn die Domain noch auf einen alten Server zeigt, zeigt dieser möglicherweise eine fremde oder alte 404-Seite an. DNS-Änderungen können einige Minuten bis mehrere Stunden dauern. ### Cache prüfen Manchmal wird ein alter 404-Fehler zwischengespeichert. Prüfe: * Browsercache * CDN-Cache * WordPress-Cache * Proxy-Cache * Nginx-Cache * Cloudflare-Cache, falls verwendet Teste die Seite in einem privaten Browserfenster oder auf einem anderen Gerät. ### Logs prüfen Logs zeigen oft genauer, warum eine Seite nicht gefunden wurde. #### Apache Logs Typische Pfade: `/var/log/apache2/error.log` `/var/log/apache2/access.log` Live anzeigen: `tail -f /var/log/apache2/error.log` #### Nginx Logs Typische Pfade: `/var/log/nginx/error.log` `/var/log/nginx/access.log` Live anzeigen: `tail -f /var/log/nginx/error.log` Achte in den Logs auf den angefragten Pfad und den tatsächlichen Dateipfad. ### Unterschied zwischen 404 und anderen Fehlern Ein 404 bedeutet, dass die Seite nicht gefunden wurde. Andere Fehler bedeuten etwas anderes: | Fehler | Bedeutung | | ------------------------- | ----------------------------------------- | | 403 Forbidden | Zugriff verboten | | 404 Not Found | Seite oder Datei nicht gefunden | | 500 Internal Server Error | interner Fehler in Anwendung oder Server | | 502 Bad Gateway | Upstream-Dienst antwortet nicht korrekt | | 503 Service Unavailable | Dienst nicht verfügbar | | DNS-Fehler | Domain zeigt nicht korrekt auf den Server | Wenn du einen anderen Fehler siehst, solltest du den passenden Artikel zu diesem Fehler verwenden. ### Checkliste Prüfe bei einem 404-Fehler der Reihe nach: 1. Ist die URL korrekt? 2. Gibt es Tippfehler? 3. Zeigt die Domain auf den richtigen Server? 4. Liegt die Datei im richtigen Webverzeichnis? 5. Gibt es eine `index.html` oder `index.php`? 6. Stimmt der Webroot in Apache oder Nginx? 7. Sind die Dateirechte korrekt? 8. Funktioniert die `.htaccess`? 9. Ist bei Apache `mod_rewrite` aktiv? 10. Sind bei Nginx die `try_files`-Regeln korrekt? 11. Sind WordPress-Permalinks neu gespeichert? 12. Zeigt die Anwendung auf die richtige Route? 13. Wurde ein Cache geleert? 14. Was steht in den Webserver-Logs? ### Support kontaktieren Wenn du den 404-Fehler nicht selbst beheben kannst, kontaktiere den Support. Gib bitte folgende Informationen an: * betroffene Domain * genaue URL, die den Fehler zeigt * verwendeter Webserver: Apache oder Nginx * verwendetes System: zum Beispiel WordPress, Laravel, React, eigenes Projekt * ob die Startseite funktioniert * ob nur Unterseiten betroffen sind * wann der Fehler erstmals aufgetreten ist * welche Änderungen zuletzt vorgenommen wurden * relevante Logauszüge, falls vorhanden **Sicherheit:** Sende niemals Passwörter, private SSH-Keys, API-Tokens oder Datenbankzugänge an den Support.