Het oplossen van HTTP 404 Niet gevonden op IIS - Een handleiding voor systeembeheerders

Schakel gedetailleerde fouten in IIS in en neem de exacte gevraagde URL, vergelijk deze vervolgens met de site-bindings om te identificeren welke site of vdir bedoeld is. Deze eerste actie onthult vaak of de bron ontbreekt, verloren is gegaan, of zich op een andere locatie in uw infrastructuur bevindt, waardoor u snel de eigenaar van de mapping en het juiste pad kunt lokaliseren.

Identificeer of de 404 voortkomt uit een ontbrekend bestand, een verkeerd geconfigureerde virtuele directory, of een redirect die naar een niet-bestaande locatie wijst. In IIS Manager, controleer de vdir-instellingen en verifieer het fysieke pad op schijf, controleer vervolgens de machtigingen op de map zodat het workerproces kan doorgaan over verschillende sites. Als u meerdere sites hebt, som hun rootmappen en de locaties die ze bedienen op om verwarring tussen sites te voorkomen.

Voor webapps die permalinks gebruiken, zorg ervoor dat de URL-herschrijfregels of handler-mappings geen echte 404 maskeren met een vriendelijke pagina. Werk de web.config of URL-herschrijfregels bij, test vervolgens het internetpad vanuit een browser en vanuit server-side logs om te bevestigen dat de resulterende URL oplost naar een echt bestand of een geldige route.

Als de bron niet aanwezig is, maak een placeholder aan of verplaats het bestand naar de bedoelde locatie, of configureer een juiste statische/ASP.NET-route om de bron te bedienen. Voor elke site, houd een record bij van de eigenaar en de bedoelde contentlocatie om toekomstige identificaties te versnellen. Gebruik permalinks om te verifiëren dat canonieke URL's naar bestaande bronnen mappen, waardoor toekomstige verloren 404's worden verminderd.

Ga vervolgens door met een systematische verificatie: controleer de internetgerichte URL, zorg ervoor dat DNS en host-headers naar de juiste site wijzen, en map de permalinks naar een echt bestandspad. Als u nog steeds een 404 ziet, traceer het verzoek vanuit het IIS-verzoeklogboek, identificeer waar het pad verloren gaat, en pas aan dienovereenkomstig, documenteer de wijzigingen voor de eigenaar en het team.

Analyseer IIS-logs op 404-patronen en mislukte URL's

Exporteer de nieuwste IIS-logs en filter op 404-reacties. Zoek naar frequente URL-paden en het eerste waargenomen tijdstempel om terugkerende problemen te pinpointen die mensen beïnvloeden die proberen uw site te bereiken.

Patronen in 404's onthullen veelvoorkomende oorzaken: ontbrekende bronnen, verkeerd geconfigureerde vdir-invoeren, en een typfout in een link. Sommige problemen ontstaan uit doorgestuurde of verplaatste content, terwijl andere komen uit interne navigatie of externe referenties. Noteer de vdir-waarde in uw notities om indexering consistent te houden. Bouw een lijst op van top-overtreders en volg tellingen in de loop van de tijd om incidentele missers te onderscheiden van regelmatig herhalende problemen.

Gebruik de referrer- en user-agent-velden om te beoordelen of het probleem komt van zoekopdrachten, andere sites, of directe opzoekingen. Dit helpt u prioriteit te geven aan het oplossen van de hoofdoorzaak en het verbeteren van de gebruikerservaring met minder wrijving.

Exporteer een tabelvriendelijke weergave van 404's, inclusief URL-pad, telling, eerste waargenomen, referrer en notities. Dit printvriendelijke formaat ondersteunt het bijwerken van belanghebbenden en het onderhouden van een enkele bron van waarheid voor het optimaliseren van paden en indexering.

URL Pad	Status	Telling	EersteWaargenomen	Referrer	Notities
/images/logo.png	404	120	2025-11-01 08:23:11	https://example.com/home	Ontbrekend bestand op schijf
/docs/guide.html	404	68	2025-11-02 09:12:05	https://example.com/manuals	Verplaatst naar /docs/user-guide.html; werk links bij
/shop/vdir/index.html	404	42	2025-11-03 11:01:22	https://example.com/shop/	VDir verkeerde configuratie; verifieer pad

Acties om 404's op te lossen en te voorkomen

Voor ontbrekende bronnen, herstel het bestand of maak een 301-redirect naar de juiste URL. Voor verkeerd geconfigureerde vdir's, verifieer het vdir-pad in IIS Manager, controleer applicationHost.config, en zorg ervoor dat een bestaand fysiek pad aanwezig is. Voor typfouten, repareer de link, werk content over de pagina bij, en vernieuw interne zoekindexen regelmatig.

Print een samenvattend rapport en deel het met het supportteam. Blijf een lopende lijst van wijzigingen bijwerken om bij te houden wat werkte en wat niet. Voor meerdere frequente overtreders, implementeer gerichte redirects en verwijder dode links om toekomstige fouten te verminderen.

Herzie de patronen die u verzamelt regelmatig, optimaliseer de afhandeling van 404's, en test redirects in een staging-omgeving voordat u updates toepast op productie. Deze aanpak minimaliseert fouten en helpt mensen een soepelere ervaring te hebben bij het navigeren op uw site.

Verifieer site-bindings, host-headers en virtuele directories

Herzie en corrigeer bindings onmiddellijk: zorg ervoor dat de host-header, IP en poort overeenkomen met het verzoek van de klant en dat de sitenaam overeenkomt met de gebruikte URL.

Binding-controles

• Open IIS Manager, navigeer naar Sites > [uw site] > Bindings. Verifieer dat er een binding is voor http (en https indien gebruikt) met de juiste IP en poort. Als meerdere sites dezelfde IP:poort delen, voeg een hostnaam (host-header) waarde toe die overeenkomt met de huidige URL om verzoeken correct te routeren.

• Test verzoeken met de exacte host-header: curl -I -H "Host: example.com" http://server/ of gebruik een browser. Als 404 aanhoudt, kan de binding correct zijn maar wordt het gevraagde pad afgehandeld door een andere site.

• Voor https, verifieer dat het certificaat overeenkomt met de hostnaam in de binding. Controleer het onderwerp en SAN's, en zorg ervoor dat de binding het juiste certificaat gebruikt op poort 443. Een mismatch kan leiden tot mislukte verzoeken die eruitzien als ontbrekende bronnen.

• Controleer DNS en proxy-lagen: zorg ervoor dat het inkomende verzoek de verwachte host-header draagt; een proxy-verkeerde configuratie kan ervoor zorgen dat verzoeken op de verkeerde site landen, resulterend in 404's voor geldige paden.

Virtuele directories en padconfiguratie

1. Verifieer dat de virtuele directory-alias bestaat onder de site; de alias moet verschijnen als een URL-segment (bijvoorbeeld /files). Herzie het fysieke pad in het rechterpaneel en bevestig dat de map bestaat en toegankelijk is door de app pool-identiteit.

2. Converteer naar Application wanneer de directory code moet draaien. Klik met de rechtermuisknop op de virtuele directory > Converteer naar Application, selecteer de juiste Application Pool, en zorg ervoor dat de pool-identiteit leesmachtigingen heeft op het fysieke pad.

3. Controleer standaarddocumenten als u vertrouwt op directory-niveau URL's; zorg ervoor dat er een geldig standaarddocument is (index.html, default.aspx, enz.) of geef een expliciet bestandspad op in uw links.

4. Herzie web.config-regels en URL-herschrijvingen die kunnen redirecten naar een niet-bestaand pad. Een slechte regel kan een ontbrekende-bron 404 produceren voor anderszins geldige pagina's; pas aan of verwijder conflicterende regels.

5. Valideer machtigingen: verleen lezen/uitvoeren aan IIS_IUSRS en de app pool-identiteit op het fysieke pad, en verifieer NTFS ACL's die toegang toestaan voor de verwachte gebruiker. Ontbrekende machtigingen veroorzaken vaak 404's die eruitzien alsof content verdwenen is.

6. Test opnieuw na wijzigingen: verzoek de problematische URL en bevestig een 200 of passende redirect; als een redirect lus veroorzaakt of een bron nog steeds ontbreekt, herzie herschrijfregels en opstartlogs in de application pool.

Gebruik een basis-crawl om het huidige probleem met ontbrekende pagina's veroorzaakt door bindings of virtuele directories te onthullen. grep door de IIS-logs voor 404-invoeren om te vinden welke verzoeken falen, pak vervolgens de hoofdoorzaak aan en test opnieuw in een frisse crawl. Sla de resultaten op en deel een beknopte samenvatting met beheerders en collega's op LinkedIn om iedereen op één lijn te houden terwijl u het probleem afhandelt.

Valideer bestandspaden, fysiek bestaan en bestandmachtigingen

Verifieer het Physical Path van de site in IIS Manager en zorg ervoor dat het pad bestaat op schijf. In Basic Settings voor de site of virtuele directory, bevestig dat de map waarnaar u wijst de content bevat die u verwacht. Als het pad is gewijzigd, herstel de oorspronkelijke locatie of corrigeer de mapping in de snap-in zodat verzoeken het juiste bestandadres aanroepen; anders laadt IIS niets en ziet u 404's.

Bevestig dat het bestand daadwerkelijk bestaat op het bestandssysteem en dat de app pool-identiteit rechten heeft om het te doorzoeken en te lezen. Gebruik File Explorer of icacls om ACL's op de map en alle bovenliggende mappen te verifiëren. Verleen Lezen en Mapinhoud Lijsten en Doorzoeken aan de app pool-identiteit (bijvoorbeeld IIS APPPOOLYourAppPool) op de content-root en de bestanden daarin. Als machtigingen onjuist zijn, geeft IIS toegangweigering aan en kan de engine 404 retourneren zelfs wanneer het bestand bestaat. Pas de ACL's dienovereenkomstig aan en test opnieuw. Als u onzeker bent, wijs tijdelijk lees toegang toe aan een bekende gebruiker om te bevestigen dat het bestand laadt.

Controleer mime-type mapping voor de extensies die u bedient. Open het mime-type voor de site en zorg ervoor dat de extensie een geassocieerd mime-type heeft; ontbrekende mappings leveren vaak een 404 op. Voeg indien nodig veelvoorkomende typen toe (.html, .css, .js, afbeeldingen, lettertypen) en verifieer dat het juiste content-type wordt verzonden. Verifieer ook dat permalink-stijl URL's laden vanuit de juiste map; een mismatch tussen permalink-route en fysiek pad kan 404 triggeren voor zowel statische als dynamische assets.

Herzie de verzoekautorisatie-instellingen van de site. In de snap-in, navigeer naar de Authorization Rules van de site en zorg ervoor dat de client-identiteit is toegestaan om de gevraagde map te lezen. Als een weigeringsregel het bestand blokkeert, kan de engine 404 retourneren voor sommige paden; het verwijderen van de regel of het beperken helpt. Bevestig dat Anonymous Authentication is ingeschakeld als u vertrouwt op openbare toegang, en controleer domein- of site-niveau-instellingen als meerdere sites dezelfde content-root delen.

Schakel logs en tracing in en controleer ze. Zet Failed Request Tracing aan voor 404-fouten of herzie IIS-logs om het aantal hits en het aanvragende adres te identificeren. Zoek naar de exacte URL, het gemapte pad, en het bestandspad vanuit de engine; deze identificerende data helpen de bron te lokaliseren. Gebruik de informatie om een correct pad te herstellen, de laadvolgorde te repareren, en frustrerende herhalingen te voorkomen. Op internetgerichte sites, verifieer dat de domeinprofielen en het fysieke pad overeenkomen; een kleine mismatch kan toegang breken voor meerdere sites. Na wijzigingen, recycle de app pool om de nieuwe mappings en machtigingen toe te passen. Als u een 404 consistent aanpakt, pak dan eerst de hoofdoorzaak aan en verifieer vervolgens de gebruikersreis over alle sites.

Herzie URL-herschrijfregels en Custom Errors-configuraties

Exporteer de huidige URL-herschrijfregels vanuit IIS voor elke site en vergelijk ze met een bekende-goede baseline om verkeerde configuraties te pinpointen die leiden tot 404-resultaten. Dit zal onthullen of het probleem ontstaat in een herschreven URL, een ontbrekende bron, of een onjuist custom error-pad.

Wat te inspecteren

Locateer de regels in web.config of via de URL Rewrite-module voor elke site. Herzie het patroon en de voorwaarden die een herschrijving of redirect triggeren, en verifieer dat de doel-URL wijst naar een bestaande bron of een juiste html-pagina gedefinieerd in Custom Errors. Bevestig dat de 404-invoer is gedefinieerd en dat het pad gebruikt door de foutpagina bestaat onder de site-root. Controleer op conflicten tussen sites die een enkele application pool delen die dezelfde paden mappen.

Audit de volgorde van evaluatie: de eerste overeenkomende regel stopt verdere verwerking. Zoek naar inbound of outbound regels die een 404 kunnen vastleggen voordat de custom error-handler draait, en zorg ervoor dat er een fallback 404-pagina is op de geconfigureerde locatie. Herzie eventuele globale of site-niveau-instellingen die de per-site-configuratie kunnen overschrijven.

Hoe fixes toe te passen

Als een regel verkeerd is geconfigureerd, pas het match-patroon, herschrijfactie en bestemming aan. Zorg ervoor dat een ontbrekende bron niet wordt herschreven naar een bestaand pad dat een non-404-respons retourneert. Werk de Custom Errors-sectie bij zodat 404-verzoeken routeren naar een echt html-bestand en verifieer dat het bestand is gedeployed met juiste machtigingen. Na wijzigingen, recycle de app pool en test vanuit verschillende client-omgevingen om consistente resultaten te bevestigen. Gebruik server-logs en Failed Request Tracing (FRT)-data om de exacte regel en de finale respons-pagina te identificeren.

Reproduceer storingen met gerichte tests en monitor reacties

Aanbeveling: Reproduceer de 404 met gerichte tests en monitor reacties in een gedeeld dashboard. Leg bewijs vast in de accesslog en wijs een eigenaar toe voor elk patroon om remediatie te versnellen. Deze aanpak helpt management de huidige impact te zien en fixes te prioriteren over site-scopes.

Exporteer de laatste 200 404-invoeren vanuit de accesslog voor de site. Voor elke invoer, noteer tijd, client IP, hostnaam, gevraagde URL, referrer, user-agent, status en responsgrootte. Als u ontbrekende assets observeert onder gerelateerde paden, geeft dit patronen aan in plaats van geïsoleerde gevallen. Bouw een beknopte testlijst op uit deze signalen om de volgende stappen te nemen.

Test padvariaties: verzoek bekende ontbrekende URL's met en zonder een trailing slash; verander de case van segmenten; voeg query strings toe of verwijder ze; vergelijk reacties voor statische assets tegen dynamische routes. Neem zowel GET- als HEAD-methoden op om te bevestigen dat de server 404 retourneert voordat onbedoelde redirects of herschrijvingen optreden.

Gebruik Failed Request Tracing (FRT) wanneer beschikbaar, en kruiscontroleer met de accesslog voor dezelfde tijdstempels. Deze traces geven aan welke regel of module de bron blokkeerde, of als de bron werkelijk ontbreekt. Koppel resultaten aan een dashboard-metriek: telling van 404's per route, per host en per account. Deze uitstekende correlatie versnelt onderzoek en onthult huidige hotspots.

Voor bronnen achter een herschrijf- of routing-laag, controleer gerelateerde web.config, URL-herschrijfregels en eventuele htaccess-achtige configuraties die IIS kan eren via herschrijfmodules. Als de 404 een mapping-probleem aangeeft, pas de regel of bestandspad aan, voer vervolgens de tests opnieuw uit om de fix te bevestigen voordat u naar productie gaat. In gevallen waar de 404 wijst op een geblokkeerde bron, verifieer de blokkeerlijst of toegangbeperkingen en zorg ervoor dat ze overeenkomen met bedoelde toegangspatronen.

Documenteer bevindingen in het dashboard en deel de samenvatting met de site-eigenaar en management. Indien nodig, publiceer inzichten op LinkedIn voor cross-team zichtbaarheid. Het proces moet herhaalbaar zijn: sla de test-invoer op, leg reacties vast en voeg gerelateerde logs toe uit de accesslog zodat ze kunnen worden herzien door de account-eigenaar of security-team.

Wijzen om veerkracht te verbeteren: bouw een kleine test-harness die door de testlijst itereert, statuscodes opneemt en pieken markeert. Gebruik deze signalen om actie te ondernemen op ontbrekende assets, content-inventarissen bij te werken en lawaaiige probes per IP alleen te blokkeren wanneer gerechtvaardigd. Houd de huidige testsuite altijd afgestemd op de site-inventaris en MIME-type-mappings om regressies te voorkomen.

Voordat u enige wijziging aanbrengt, zorg ervoor dat u goedkeuring van de eigenaar hebt en een rollback-plan. Het lopende monitoring-dashboard moet aangeven of de 404-tarieven stabiel zijn, stijgen of terugkeren naar baseline. Een goed gerund testregime versnelt incidentrespons en helpt het team een soepelere gebruikerservaring te leveren.