Felsökning av HTTP 404 Hittades inte på IIS - En guide för systemadministratörer

Aktivera detaljerade fel i IIS och ta den exakta begärda URL:en, sedan jämför den med webbplatsbindningarna för att identifiera vilken webbplats eller vdir som är avsedd. Denna första åtgärd avslöjar ofta om resursen saknas, är förlorad eller finns på en annan plats i din infrastruktur, vilket hjälper dig att snabbt lokalisera ägaren till mappningen och den korrekta sökvägen.

Identifiera om 404-felet kommer från en saknad fil, en felkonfigurerad virtuell katalog eller en omdirigering som pekar på en icke-existerande plats. I IIS-hanteraren, inspektera vdir-inställningarna och verifiera den fysiska sökvägen på disken, sedan kontrollera behörigheterna på mappen så att arbetsprocessen kan fortsätta över olika webbplatser. Om du har flera webbplatser, lista deras rotmappar och de platser de betjänar för att förhindra förvirring mellan webbplatser.

För webbappar som använder permanlänkar, se till att URL-omskrivningsregler eller hanterarmappningar inte maskerar en verklig 404 med en vänlig sida. Uppdatera web.config eller URL-omskrivningsregler, sedan testa internet-sökvägen från en webbläsare och från server-sidans loggar för att bekräfta att den resulterande URL:en löser till en faktisk fil eller en giltig rutt.

Om resursen inte finns, skapa en platshållare eller flytta filen till den avsedda platsen, eller konfigurera en korrekt statisk/ASP.NET-rutt för att betjäna resursen. För varje webbplats, håll en registrering av ägaren och den avsedda innehållsplatsen för att påskynda framtida identifieringar. Använd permanlänkar för att verifiera att kanoniska URL:er mappar till befintliga resurser, vilket minskar framtida förlorade 404:or.

Fortsätt sedan med en systematisk verifiering: kontrollera den internetvända URL:en, se till att DNS och värd-huvuden pekar på den korrekta webbplatsen, och mappa permanlänkarna till en verklig fil-sökväg. Om du fortfarande ser en 404, spåra förfrågan från IIS-förfrågningsloggen, identifiera var sökvägen går förlorad, och justera därefter, dokumentera ändringarna för ägaren och teamet.

Analysera IIS-loggar för 404-mönster och misslyckade URL:er

Exportera de senaste IIS-loggarna och filtrera för 404-svar. Leta efter frekventa URL-sökvägar och den första sedda tidsstämpeln för att pinpointa återkommande problem som påverkar personer som försöker nå din webbplats.

Mönster i 404:or avslöjar vanliga orsaker: saknade resurser, felkonfigurerade vdir-poster och en stavfel i en länk. Vissa problem uppstår från omdirigerat eller flyttat innehåll, medan andra kommer från intern navigering eller externa referenser. Registrera vdir-värdet i dina anteckningar för att hålla indexeringen konsekvent. Bygg en lista över toppförbrytare och spåra antal över tid för att skilja tillfälliga missar från regelbundet återkommande problem.

Använd referrer- och user-agent-fälten för att bedöma om problemet kommer från sökning, andra webbplatser eller direkta uppslag. Detta hjälper dig att prioritera lösning av grundorsaken och förbättra användarupplevelsen med mindre friktion.

Exportera en tabellvänlig vy av 404:or, inklusive URL-sökväg, antal, först sedd, referrer och anteckningar. Detta utskriftsvänliga format stödjer uppdatering av intressenter och upprätthållande av en enda källa till sanning för optimering av sökvägar och indexering.

URL-sökväg	Status	Antal	FörstSed	Referrer	Anteckningar
/images/logo.png	404	120	2025-11-01 08:23:11	https://example.com/home	Saknad fil på disken
/docs/guide.html	404	68	2025-11-02 09:12:05	https://example.com/manuals	Flyttad till /docs/user-guide.html; uppdatera länkar
/shop/vdir/index.html	404	42	2025-11-03 11:01:22	https://example.com/shop/	VDir-felkonfiguration; verifiera sökväg

Åtgärder för att lösa och förhindra 404:or

För saknade resurser, återställ filen eller skapa en 301-omdirigering till den korrekta URL:en. För felkonfigurerade vdirs, verifiera vdir-sökvägen i IIS-hanteraren, kontrollera applicationHost.config och se till att en befintlig fysisk sökväg finns. För stavfel, fixa länken, uppdatera innehåll om sidan och uppdatera interna sökindex regelbundet.

Skriv ut en sammanfattad rapport och dela den med supportteamet. Håll uppdaterad en löpande lista över ändringar för att spåra vad som fungerade och vad som inte gjorde det. För flera frekventa förbrytare, implementera riktade omdirigeringar och ta bort döda länkar för att minska framtida fel.

Granska regelbundet de mönster du samlar, optimera hanteringen av 404:or och testa omdirigeringar i en staging-miljö innan du tillämpar uppdateringar på produktion. Detta tillvägagångssätt minimerar misstag och hjälper människor att ha en smidigare upplevelse när de navigerar din webbplats.

Verifiera webbplatsbindningar, värd-huvuden och virtuella kataloger

Granska och korrigera bindningar omedelbart: se till att värd-huvudet, IP och port matchar klientens förfrågan och att webbplatsnamnet motsvarar den URL som används.

Bindningskontroller

• Öppna IIS-hanteraren, navigera till Webbplatser > [din webbplats] > Bindningar. Verifiera att det finns en bindning för http (och https om använt) med korrekt IP och port. Om flera webbplatser delar samma IP:port, lägg till ett värdnamn (värd-huvud) värde som matchar den aktuella URL:en för att routa förfrågningar korrekt.

• Testa förfrågningar med det exakta värd-huvudet: curl -I -H "Host: example.com" http://server/ eller använd en webbläsare. Om 404 kvarstår, kan bindningen vara korrekt men den begärda sökvägen hanteras av en annan webbplats.

• För https, verifiera att certifikatet matchar värdnamnet i bindningen. Kontrollera ämnet och SAN:erna, och se till att bindningen använder rätt certifikat på port 443. En missmatch kan leda till misslyckade förfrågningar som ser ut som saknade resurser.

• Inspektera DNS och proxy-lager: se till att den inkommande förfrågan bär det förväntade värd-huvudet; en proxy-felkonfiguration kan orsaka att förfrågningar landar på fel webbplats, vilket ger 404:or för giltiga sökvägar.

Virtuella kataloger och sökvägskonfiguration

1. Verifiera att den virtuella katalogens alias finns under webbplatsen; aliaset bör visas som en URL-segment (till exempel /files). Granska den fysiska sökvägen i höger panel och bekräfta att mappen finns och är tillgänglig för app pool-identiteten.

2. Konvertera till Application när katalogen ska köra kod. Högerklicka på den virtuella katalogen > Konvertera till Application, välj den korrekta Application Pool och se till att pool-identiteten har läsbeförigheter till den fysiska sökvägen.

3. Kontrollera standarddokument om du förlitar dig på katalog-nivå-URL:er; se till att det finns ett giltigt standarddokument (index.html, default.aspx, etc.) eller ange en explicit fil-sökväg i dina länkar.

4. Granska web.config-regler och URL-omskrivningar som kan omdirigera till en icke-existerande sökväg. En dålig regel kan producera en saknad-resurs-404 för annars giltiga sidor; justera eller ta bort konflikterande regler.

5. Validera behörigheter: ge läs-/kör- till IIS_IUSRS och app pool-identiteten på den fysiska sökvägen, och verifiera NTFS ACL:er som tillåter åtkomst för den förväntade användaren. Saknade behörigheter orsakar ofta 404:or som ser ut som att innehållet är borta.

6. Testa igen efter ändringar: begär den problematiska URL:en och bekräfta en 200 eller lämplig omdirigering; om en omdirigering loopar eller en resurs förblir saknad, granska omskrivningsregler och startloggar i application pool.

Använd en grundläggande crawl för att avslöja det aktuella problemet med saknade sidor orsakade av bindningar eller virtuella kataloger. Grep genom IIS-loggarna för 404-poster för att hitta vilka förfrågningar som misslyckas, sedan adressera grundorsaken och testa igen i en ny crawl. Spara resultaten och dela en koncist sammanfattning med administratörer och kollegor på LinkedIn för att hålla alla alignerade medan du hanterar problemet.

Validera fil-sökvägar, fysisk existens och filbehörigheter

Verifiera webbplatsens Physical Path i IIS-hanteraren och se till att sökvägen finns på disken. I Basic Settings för webbplatsen eller den virtuella katalogen, bekräfta att mappen du pekar på innehåller det innehåll du förväntar dig. Om sökvägen ändrats, återställ den ursprungliga platsen eller korrigera mappningen i snap-in så att förfrågningar adresserar rätt mapp; annars laddar IIS inget och du ser 404:or.

Bekräfta att filen faktiskt finns på filsystemet och att app pool-identiteten har rättigheter att traversera och läsa den. Använd File Explorer eller icacls för att verifiera ACL:er på mappen och alla överordnade mappar. Ge Read och List Folder Contents och Traverse till app pool-identiteten (till exempel IIS APPPOOLYourAppPool) på innehållsroten och filerna inom. Om behörigheterna är felaktiga, indikerar IIS åtkomstvägran och motorn kan returnera 404 även när filen finns. Justera ACL:erna lämpligt och testa igen. Om du är osäker, tilldela tillfälligt lästillgång till en känd användare för att bekräfta att filen laddas.

Kontrollera mime-typ-mappning för de tillägg du betjänar. Öppna mime-typen för webbplatsen och se till att tillägget har en associerad mime-typ; saknade mappningar ger ofta en 404. Om behövs, lägg till vanliga typer (.html, .css, .js, bilder, typsnitt) och verifiera att den korrekta content-type skickas. Verifiera också att permalink-stil-URL:er laddas från rätt mapp; en missmatch mellan permalink-rutt och fysisk sökväg kan utlösa 404 för både statiska och dynamiska tillgångar.

Granska webbplatsens förfrågningsauktoriseringsinställningar. I snap-in, navigera till webbplatsens Authorization Rules och se till att klientidentiteten är tillåten att läsa den begärda mappen. Om en deny-regel blockerar filen, kan motorn returnera 404 för vissa sökvägar; ta bort regeln eller inskränk den hjälper. Bekräfta att Anonymous Authentication är aktiverat om du förlitar dig på offentlig åtkomst, och kontrollera domän-nivå- eller webbplats-nivå-inställningar om flera webbplatser delar samma innehållsrot.

Aktivera och kontrollera loggar och spårning. Slå på Failed Request Tracing för 404-fel eller granska IIS-loggar för att identifiera antalet träffar och den begärande adressen. Leta efter den exakta URL:en, den mappade sökvägen och fil-sökvägen från motorn; denna identifierande data hjälper till att lokalisera källan. Använd informationen för att återställa en korrekt sökväg, fixa laddningsordningen och förhindra frustrerande återkommande. På internetvända webbplatser, verifiera att domänprofiler och den fysiska sökvägen alignerar; en liten missmatch kan bryta åtkomst för flera webbplatser. Efter ändringar, återanvänd app pool för att tillämpa de nya mappningarna och behörigheterna. Om du adresserar en 404 konsekvent, adressera grundorsaken först och verifiera sedan användarresan över alla webbplatser.

Granska URL-omskrivningsregler och anpassade felkonfigurationer

Exportera de aktuella URL-omskrivningsreglerna från IIS för varje webbplats och jämför dem med en känd-god baslinje för att pinpointa felkonfigurationer som leder till 404-resultat. Detta kommer att avslöja om problemet uppstår i en omskriven URL, en saknad resurs eller en olämplig anpassad fel-sökväg.

Vad som ska inspekteras

Lokalisera reglerna i web.config eller via URL Rewrite-modulen för varje webbplats. Granska mönstret och villkoren som utlöser en omskrivning eller omdirigering, och verifiera att målets URL pekar på en befintlig resurs eller en korrekt html-sida definierad i Custom Errors. Bekräfta att 404-posten är definierad och att sökvägen som används av fel-sidan finns under webbplatsroten. Kontrollera konflikter mellan webbplatser som delar en enda application pool som mappar samma sökvägar.

Granska utvärderingsordningen: den första matchande regeln stoppar vidare bearbetning. Leta efter inkommande eller utgående regler som kan fånga en 404 innan den anpassade felhanteraren körs, och se till att det finns en fallback 404-sida på den konfigurerade platsen. Granska eventuella globala eller webbplats-nivå-inställningar som kan åsidosätta den per-webbplats-konfigurationen.

Hur man tillämpar fixar

Om en regel är felkonfigurerad, justera matchmönstret, omskrivningsåtgärden och destinationen. Se till att en saknad resurs inte omskrivs till en befintlig sökväg som returnerar ett icke-404-svar. Uppdatera Custom Errors-sektionen så att 404-förfrågningar routas till en verklig html-fil och verifiera att filen är distribuerad med korrekta behörigheter. Efter ändringar, återanvänd app pool och testa från olika klientmiljöer för att bekräfta konsekventa resultat. Använd serverloggar och Failed Request Tracing (FRT)-data för att identifiera den exakta regeln och den slutliga svarsidan.

Återskapa misslyckanden med riktade tester och övervaka svar

Rekommendation: Återskapa 404:an med riktade tester och övervaka svar i en delad instrumentpanel. Fånga bevis i accessloggen och tilldela en ägare för varje mönster för att påskynda remediering. Detta tillvägagångssätt hjälper ledningen att se den aktuella påverkan och prioritera fixar över webbplatsomfång.

Exportera de senaste 200 404-posterna från accessloggen för webbplatsen. För varje post, registrera tid, klient-IP, värdnamn, begärd URL, referrer, user-agent, status och svarsstorlek. Om du observerar saknade tillgångar under relaterade sökvägar, indikerar detta mönster snarare än isolerade fall. Bygg en koncist testlista från dessa signaler för att ta nästa steg.

Testa sökvägsvariationer: begär kända saknade URL:er med och utan avslutande snedstreck; ändra skiftläget på segment; lägg till eller ta bort frågesträngar; jämför svar för statiska tillgångar mot dynamiska rutter. Inkludera både GET- och HEAD-metoder för att bekräfta att servern returnerar 404 innan några oavsiktliga omdirigeringar eller omskrivningar sker.

Använd Failed Request Tracing (FRT) när tillgängligt, och korskolla med accessloggen för samma tidsstämplar. Dessa spår indikerar vilken regel eller modul som blockerade resursen, eller om resursen verkligen saknas. Koppla resultat till en instrumentpanel-mätvärde: antal 404:or per rutt, per värd och per konto. Denna utmärkta korrelation påskyndar undersökningen och avslöjar aktuella hotspots.

För resurser bakom en omskrivnings- eller ruttlager, kontrollera relaterad web.config, URL-omskrivningsregler och eventuella htaccess-liknande konfigurationer som IIS kan hedra via omskrivningsmoduler. Om 404:an indikerar ett mappningsproblem, justera regeln eller fil-sökvägen, sedan kör testerna igen för att bekräfta fixen innan du flyttar till produktion. I fall där 404:an pekar på en blockerad resurs, verifiera blocklistan eller åtkomstbegränsningar och se till att de alignerar med avsedda åtkomstmönster.

Dokumentera fynd i instrumentpanelen och dela sammanfattningen med webbplatsägaren och ledningen. Om behövs, publicera insikter på LinkedIn för kors-team-synlighet. Processen bör vara upprepningsbar: spara testinmatningarna, fånga svar och bifoga relaterade loggar från accessloggen så att de kan granskas av kontoägaren eller säkerhetsteamet.

Sätt att förbättra motståndskraft: bygg en liten testram som itererar genom testlistan, registrerar statuskoder och flaggar toppar. Använd dessa signaler för att agera på saknade tillgångar, uppdatera innehållsinventarier och blockera bullriga prober per IP endast när motiverat. Håll alltid den aktuella testsviten alignerad med webbplatsinventariet och MIME-typ-mappningar för att förhindra regressioner.

Innan någon ändring, se till att du har ägarens godkännande och en rollback-plan. Den pågående övervakningsinstrumentpanelen bör indikera om 404-hastigheten är stabil, stigande eller återgår till baslinje. Ett välkänt testregime påskyndar incident-svar och hjälper teamet att leverera en smidigare användarupplevelse.