Fehlerbehebung bei HTTP 404 Nicht gefunden auf IIS – Ein Leitfaden für Systemadministratoren

Aktivieren Sie detaillierte Fehler in IIS und nehmen Sie die genaue angeforderte URL, dann vergleichen Sie sie mit den Site-Bindings, um zu identifizieren, welcher Site oder VDir gemeint ist. Diese erste Aktion enthüllt oft, ob die Ressource fehlt, verloren ist oder sich an einem anderen Ort in Ihrer Infrastruktur befindet, und hilft Ihnen, den Eigentümer der Zuordnung und den korrekten Pfad schnell zu finden.

Identifizieren Sie, ob der 404 von einer fehlenden Datei, einer falsch konfigurierten virtuellen Verzeichnis oder einer Weiterleitung stammt, die auf einen nicht existierenden Ort verweist. In IIS Manager überprüfen Sie die VDir-Einstellungen und verifizieren den physischen Pfad auf der Festplatte, dann prüfen Sie die Berechtigungen auf dem Ordner, damit der Worker-Prozess über verschiedene Sites fortfahren kann. Wenn Sie mehrere Sites haben, listen Sie deren Root-Ordner und die von ihnen bedienten Orte auf, um Cross-Site-Verwirrung zu vermeiden.

Für Web-Apps, die Permalinks verwenden, stellen Sie sicher, dass die URL-Rewriting-Regeln oder Handler-Mappings keinen echten 404 mit einer freundlichen Seite maskieren. Aktualisieren Sie die web.config oder URL-Rewrite-Regeln, dann testen Sie den Internet-Pfad aus einem Browser und aus server-seitigen Logs, um zu bestätigen, dass die resultierende URL zu einer tatsächlichen Datei oder einem gültigen Routing auflöst.

Wenn die Ressource nicht vorhanden ist, erstellen Sie einen Platzhalter oder verschieben Sie die Datei an den vorgesehenen Ort, oder konfigurieren Sie eine ordnungsgemäße statische/ASP.NET-Route, um die Ressource zu bedienen. Für jede Site halten Sie einen Eintrag über den Eigentümer und den vorgesehenen Inhaltsort, um zukünftige Identifikationen zu beschleunigen. Verwenden Sie Permalinks, um zu überprüfen, dass kanonische URLs auf existierende Ressourcen abbilden, und reduzieren Sie so zukünftige verlorene 404s.

Fahren Sie dann mit einer systematischen Überprüfung fort: Überprüfen Sie die internetgerichtete URL, stellen Sie sicher, dass DNS und Host-Header auf die korrekte Site verweisen, und ordnen Sie die Permalinks einem realen Dateipfad zu. Wenn Sie immer noch einen 404 sehen, verfolgen Sie die Anfrage aus dem IIS-Request-Log, identifizieren Sie, wo der Pfad verloren geht, und passen Sie entsprechend an, wobei Sie die Änderungen für den Eigentümer und das Team dokumentieren.

IIS-Logs auf 404-Muster und fehlgeschlagene URLs analysieren

Exportieren Sie die neuesten IIS-Logs und filtern Sie nach 404-Antworten. Suchen Sie nach häufigen URL-Pfaden und dem ersten gesehenen Zeitstempel, um wiederkehrende Probleme zu identifizieren, die Menschen betreffen, die versuchen, Ihre Site zu erreichen.

Muster in 404s enthüllen gängige Ursachen: fehlende Ressourcen, falsch konfigurierte VDir-Einträge und ein Tippfehler in einem Link. Einige Probleme stammen von umgeleiteten oder verschobenen Inhalten, während andere aus interner Navigation oder externen Verweisen kommen. Notieren Sie den VDir-Wert in Ihren Notizen, um die Indexierung konsistent zu halten. Erstellen Sie eine Liste der Top-Verstößer und verfolgen Sie die Zählungen im Laufe der Zeit, um gelegentliche Fehlschläge von regelmäßig wiederkehrenden Problemen zu unterscheiden.

Verwenden Sie die Felder für Referrer und User-Agent, um zu bewerten, ob das Problem aus Suchmaschinen, anderen Sites oder direkten Abfragen stammt. Dies hilft Ihnen, die Ursache zu priorisieren und die Benutzererfahrung mit weniger Reibung zu verbessern.

Exportieren Sie eine tabellenfreundliche Ansicht der 404s, einschließlich URL-Pfad, Zählung, erst gesehen, Referrer und Notizen. Dieses druckfreundliche Format unterstützt die Aktualisierung von Stakeholdern und die Wartung einer einzigen Quelle der Wahrheit für die Optimierung von Pfaden und Indexierung.

URL-Pfad	Status	Zählung	ErstGesehen	Referrer	Notizen
/images/logo.png	404	120	2025-11-01 08:23:11	https://example.com/home	Fehlende Datei auf der Festplatte
/docs/guide.html	404	68	2025-11-02 09:12:05	https://example.com/manuals	Verschoben nach /docs/user-guide.html; Links aktualisieren
/shop/vdir/index.html	404	42	2025-11-03 11:01:22	https://example.com/shop/	VDir-Fehlkonfiguration; Pfad überprüfen

Aktionen zur Behebung und Verhinderung von 404s

Für fehlende Ressourcen stellen Sie die Datei wieder her oder erstellen Sie eine 301-Weiterleitung zur korrekten URL. Für falsch konfigurierte VDirs überprüfen Sie den VDir-Pfad in IIS Manager, prüfen Sie applicationHost.config und stellen Sie sicher, dass ein existierender physischer Pfad vorhanden ist. Für Tippfehler korrigieren Sie den Link, aktualisieren Sie den Inhalt über die Seite und erfrischen Sie interne Suchindizes regelmäßig.

Drucken Sie einen zusammengefassten Bericht aus und teilen Sie ihn mit dem Support-Team. Halten Sie eine laufende Liste der Änderungen aktualisiert, um zu verfolgen, was funktioniert hat und was nicht. Für mehrere häufige Verstößer implementieren Sie gezielte Weiterleitungen und entfernen Sie tote Links, um zukünftige Fehler zu reduzieren.

Überprüfen Sie die gesammelten Muster regelmäßig, optimieren Sie die Behandlung von 404s und testen Sie Weiterleitungen in einer Staging-Umgebung, bevor Sie Updates auf die Produktion anwenden. Dieser Ansatz minimiert Fehler und hilft den Menschen, eine reibungslosere Erfahrung zu haben, wenn sie Ihre Site navigieren.

Site-Bindings, Host-Header und virtuelle Verzeichnisse überprüfen

Überprüfen und korrigieren Sie Bindings sofort: Stellen Sie sicher, dass der Host-Header, die IP und der Port der Anfrage des Clients entsprechen und dass der Site-Name der verwendeten URL entspricht.

Binding-Überprüfungen

• Öffnen Sie IIS Manager, navigieren Sie zu Sites > [Ihre Site] > Bindings. Überprüfen Sie, ob eine Binding für http (und https, falls verwendet) mit der korrekten IP und Port vorhanden ist. Wenn mehrere Sites dieselbe IP:Port teilen, fügen Sie einen Hostnamen (Host-Header)-Wert hinzu, der mit der aktuellen URL übereinstimmt, um Anfragen ordnungsgemäß zu routen.

• Testen Sie Anfragen mit dem genauen Host-Header: curl -I -H "Host: example.com" http://server/ oder verwenden Sie einen Browser. Wenn der 404 anhält, kann die Binding korrekt sein, aber der angeforderte Pfad wird von einer anderen Site gehandhabt.

• Für https überprüfen Sie, ob das Zertifikat mit dem Hostnamen in der Binding übereinstimmt. Prüfen Sie das Subjekt und SANs und stellen Sie sicher, dass die Binding das richtige Zertifikat auf Port 443 verwendet. Eine Fehlanpassung kann zu fehlgeschlagenen Anfragen führen, die wie fehlende Ressourcen aussehen.

• Überprüfen Sie DNS- und Proxy-Schichten: Stellen Sie sicher, dass die eingehende Anfrage den erwarteten Host-Header trägt; eine Fehlkonfiguration des Proxys kann Anfragen auf der falschen Site landen lassen und 404s für gültige Pfade erzeugen.

Virtuelle Verzeichnisse und Pfadkonfiguration

1. Überprüfen Sie, ob der Alias des virtuellen Verzeichnisses unter der Site existiert; der Alias sollte als URL-Segment erscheinen (z. B. /files). Überprüfen Sie den physischen Pfad im rechten Bereich und bestätigen Sie, dass der Ordner existiert und für die App-Pool-Identität zugänglich ist.

2. Konvertieren Sie zu Application, wenn das Verzeichnis Code ausführen soll. Rechtsklick auf das virtuelle Verzeichnis > Convert to Application, wählen Sie den korrekten Application Pool aus und stellen Sie sicher, dass die Pool-Identität Leseberechtigungen für den physischen Pfad hat.

3. Überprüfen Sie Standarddokumente, wenn Sie auf Verzeichnisebene-URLs angewiesen sind; stellen Sie sicher, dass ein gültiges Standarddokument (index.html, default.aspx usw.) vorhanden ist oder geben Sie einen expliziten Dateipfad in Ihren Links an.

4. Überprüfen Sie web.config-Regeln und URL-Rewrites, die in einen nicht existierenden Pfad umleiten könnten. Eine schlechte Regel kann einen Ressourcen-fehlt-404 für ansonsten gültige Seiten erzeugen; passen Sie widersprüchliche Regeln an oder entfernen Sie sie.

5. Validieren Sie Berechtigungen: Erteilen Sie Lesen/Ausführen an IIS_IUSRS und die App-Pool-Identität für den physischen Pfad und überprüfen Sie NTFS-ACLs, die den Zugriff für den erwarteten Benutzer erlauben. Fehlende Berechtigungen verursachen oft 404s, die so aussehen, als ob der Inhalt weg ist.

6. Testen Sie nach Änderungen erneut: Fordern Sie die problematische URL an und bestätigen Sie einen 200-Status oder eine angemessene Weiterleitung; wenn eine Weiterleitung loop oder eine Ressource weiterhin fehlt, überprüfen Sie Rewrite-Regeln und Start-Logs im Application Pool.

Verwenden Sie einen grundlegenden Crawl, um das aktuelle Problem mit fehlenden Seiten durch Bindings oder virtuelle Verzeichnisse aufzudecken. Grepen Sie durch die IIS-Logs nach 404-Einträgen, um zu finden, welche Anfragen fehlschlagen, dann beheben Sie die Ursache und testen Sie erneut in einen frischen Crawl. Speichern Sie die Ergebnisse und teilen Sie eine knappe Zusammenfassung mit Administratoren und Kollegen auf LinkedIn, um alle im Einklang zu halten, während Sie das Problem bearbeiten.

Dateipfade, physische Existenz und Dateiberechtigungen validieren

Überprüfen Sie den Physical Path der Site in IIS Manager und stellen Sie sicher, dass der Pfad auf der Festplatte existiert. In Basic Settings für die Site oder das virtuelle Verzeichnis bestätigen Sie, dass der Ordner, auf den Sie verweisen, den erwarteten Inhalt enthält. Wenn der Pfad geändert wurde, stellen Sie den ursprünglichen Ort wieder her oder korrigieren Sie die Zuordnung im Snap-in, damit Anfragen den richtigen Ordner ansprechen; andernfalls lädt IIS nichts und Sie sehen 404s.

Bestätigen Sie, dass die Datei tatsächlich auf dem Dateisystem existiert und dass die App-Pool-Identität Rechte hat, sie zu durchlaufen und zu lesen. Verwenden Sie Datei-Explorer oder icacls, um ACLs auf dem Ordner und allen übergeordneten Ordnern zu überprüfen. Erteilen Sie Lesen und Ordnerinhalt auflisten und Durchlaufen an die App-Pool-Identität (z. B. IIS APPPOOLYourAppPool) am Inhaltsroot und den Dateien darin. Wenn Berechtigungen falsch sind, gibt IIS Zugriffsverweigerung an und der Engine kann 404 zurückgeben, auch wenn die Datei existiert. Passen Sie die ACLs entsprechend an und testen Sie erneut. Wenn Sie unsicher sind, weisen Sie vorübergehend Lesezugriff einem bekannten Benutzer zu, um zu bestätigen, dass die Datei lädt.

Überprüfen Sie die MIME-Typ-Zuordnung für die von Ihnen bedienten Erweiterungen. Öffnen Sie den MIME-Typ für die Site und stellen Sie sicher, dass die Erweiterung einen zugeordneten MIME-Typ hat; fehlende Zuordnungen erzeugen oft einen 404. Falls nötig, fügen Sie gängige Typen (.html, .css, .js, Bilder, Schriftarten) hinzu und überprüfen Sie, dass der korrekte Content-Type gesendet wird. Überprüfen Sie auch, ob permalink-ähnliche URLs aus dem korrekten Ordner laden; eine Fehlanpassung zwischen permalink-Route und physischem Pfad kann 404 für statische und dynamische Assets auslösen.

Überprüfen Sie die Anfragenautorisierungseinstellungen der Site. Im Snap-in navigieren Sie zu den Authorization Rules der Site und stellen Sie sicher, dass die Client-Identität berechtigt ist, den angeforderten Ordner zu lesen. Wenn eine Verweigerungsregel die Datei blockiert, kann der Engine 404 für einige Pfade zurückgeben; das Entfernen der Regel oder ihre Eingrenzung hilft. Bestätigen Sie, dass Anonymous Authentication aktiviert ist, wenn Sie auf öffentlichen Zugriff angewiesen sind, und überprüfen Sie domain- oder site-level-Einstellungen, wenn mehrere Sites denselben Inhaltsroot teilen.

Aktivieren und überprüfen Sie Logs und Tracing. Schalten Sie Failed Request Tracing für 404-Fehler ein oder überprüfen Sie IIS-Logs, um die Anzahl der Treffer und die anfragende Adresse zu identifizieren. Suchen Sie nach der genauen URL, dem zugeordneten Pfad und dem Dateipfad aus dem Engine; diese identifizierenden Daten helfen, die Quelle zu lokalisieren. Verwenden Sie die Informationen, um einen korrekten Pfad wiederherzustellen, die Lade-Reihenfolge zu beheben und frustrierende Wiederholungen zu verhindern. Auf internetgerichteten Sites überprüfen Sie, dass die Domain-Profile und der physische Pfad übereinstimmen; eine kleine Fehlanpassung kann den Zugriff für mehrere Sites unterbrechen. Nach Änderungen recyclen Sie den App Pool, um die neuen Zuordnungen und Berechtigungen anzuwenden. Wenn Sie einen 404 konsequent beheben, adressieren Sie zuerst die Ursache und überprüfen Sie dann die Benutzerreise über alle Sites.

URL-Rewrite-Regeln und Custom-Errors-Konfigurationen überprüfen

Exportieren Sie die aktuellen URL-Rewrite-Regeln aus IIS für jede Site und vergleichen Sie sie mit einer bekannten guten Basislinie, um Fehlkonfigurationen zu identifizieren, die zu 404-Ergebnissen führen. Dies wird enthüllen, ob das Problem in einer umgeschriebenen URL, einer fehlenden Ressource oder einem unangemessenen Custom-Error-Pfad liegt.

Was zu überprüfen ist

Locate the rules in web.config or via the URL Rewrite module for each site. Review the pattern and conditions that trigger a rewrite or redirect, and verify that the target URL points to an existing resource or a proper html page defined in Custom Errors. Confirm that the 404 entry is defined and that the path used by the error page exists under the site root. Check for conflicts between sites sharing a single application pool that map the same paths.

Audit the order of evaluation: the first matching rule stops further processing. Look for inbound or outbound rules that may capture a 404 before the custom error handler runs, and ensure there is a fallback 404 page at the configured location. Review any global or site-level settings that may override the per-site configuration.

How to apply fixes

If a rule is misconfigured, adjust the match pattern, rewrite action, and destination. Ensure a missing resource does not get rewritten to an existing path that returns a non-404 response. Update the Custom Errors section so 404 requests route to a real html file and verify the file is deployed with correct permissions. After changes, recycle the app pool and test from different client environments to confirm consistent results. Use server logs and Failed Request Tracing (FRT) data to identify the exact rule and the final response page.

Fehler mit gezielten Tests reproduzieren und Antworten überwachen

Empfehlung: Reproduzieren Sie den 404 mit gezielten Tests und überwachen Sie Antworten in einem gemeinsamen Dashboard. Erfassen Sie Beweise im Accesslog und weisen Sie einem Eigentümer für jedes Muster zu, um die Behebung zu beschleunigen. Dieser Ansatz hilft dem Management, den aktuellen Einfluss zu sehen und Fixes über Site-Bereiche zu priorisieren.

Exportieren Sie die letzten 200 404-Einträge aus dem Accesslog für die Site. Für jeden Eintrag notieren Sie Zeit, Client-IP, Hostname, angeforderte URL, Referrer, User-Agent, Status und Antwortgröße. Wenn Sie fehlende Assets unter verwandten Pfaden beobachten, deutet dies auf Muster hin statt isolierter Fälle. Erstellen Sie eine knappe Testliste aus diesen Signalen, um die nächsten Schritte zu unternehmen.

Testen Sie Pfadvariationen: Fordern Sie bekannte fehlende URLs mit und ohne abschließenden Schrägstrich an; ändern Sie die Groß-/Kleinschreibung von Segmenten; hängen Sie Query-Strings an oder entfernen Sie sie; vergleichen Sie Antworten für statische Assets gegen dynamische Routen. Schließen Sie sowohl GET- als auch HEAD-Methoden ein, um zu bestätigen, dass der Server 404 zurückgibt, bevor unbeabsichtigte Weiterleitungen oder Rewrites auftreten.

Verwenden Sie Failed Request Tracing (FRT), wenn verfügbar, und kreuzprüfen Sie mit dem Accesslog für dieselben Zeitstempel. Diese Traces zeigen an, welche Regel oder welches Modul die Ressource blockiert hat oder ob die Ressource wirklich fehlt. Binden Sie Ergebnisse an eine Dashboard-Metrik: Zählung von 404s nach Route, nach Host und nach Account. Diese exzellente Korrelation beschleunigt die Untersuchung und enthüllt aktuelle Hotspots.

Für Ressourcen hinter einer Rewrite- oder Routing-Schicht überprüfen Sie verwandte web.config, URL-Rewrite-Regeln und htaccess-ähnliche Konfigurationen, die IIS über Rewrite-Module ehren könnte. Wenn der 404 auf ein Zuordnungsproblem hinweist, passen Sie die Regel oder den Dateipfad an, dann führen Sie die Tests erneut aus, um die Behebung zu bestätigen, bevor Sie zur Produktion übergehen. In Fällen, in denen der 404 auf eine blockierte Ressource hinweist, überprüfen Sie die Blockliste oder Zugriffsbeschränkungen und stellen Sie sicher, dass sie mit den vorgesehenen Zugriffsmustern übereinstimmen.

Dokumentieren Sie Erkenntnisse im Dashboard und teilen Sie die Zusammenfassung mit dem Site-Eigentümer und dem Management. Falls nötig, veröffentlichen Sie Erkenntnisse auf LinkedIn für Cross-Team-Sichtbarkeit. Der Prozess sollte wiederholbar sein: Speichern Sie die Testeingaben, erfassen Sie Antworten und hängen Sie verwandte Logs aus dem Accesslog an, damit sie vom Account-Eigentümer oder Security-Team überprüft werden können.

Wege zur Verbesserung der Resilienz: Erstellen Sie einen kleinen Test-Harness, der durch die Testliste iteriert, Statuscodes aufzeichnet und Spitzen markiert. Verwenden Sie diese Signale, um auf fehlende Assets zu reagieren, Inhaltsinventare zu aktualisieren und laute Sonden nur bei Rechtfertigung nach IP zu blockieren. Halten Sie die aktuelle Testsuite immer mit dem Site-Inventar und MIME-Typ-Zuordnungen im Einklang, um Regressionen zu verhindern.

Vor jeder Änderung stellen Sie sicher, dass Sie die Genehmigung des Eigentümers und einen Rollback-Plan haben. Das laufende Überwachungs-Dashboard sollte anzeigen, ob die 404-Rate stabil ist, steigt oder zum Baseline zurückkehrt. Ein gut geführtes Testregime beschleunigt die Incident-Response und hilft dem Team, eine reibungslosere Benutzererfahrung zu liefern.