HTTP 404 Ei löytynyt -virheen vianetsintä IIS:ssä – Järjestelmäydenpitäjän opas

Käytä IIS:ssä yksityiskohtaisia virheitä ja ota tarkka pyydetty URL, sitten vertaa sitä sivuston sidoksilla tunnistaaksesi, mikä sivusto tai vdir on tarkoitettu. Tämä ensimmäinen toiminto paljastaa usein, puuttuuko resurssi, onko se kadonnut vai sijaitseeko se eri paikassa infrastruktuurissasi, auttaen sinua löytämään kartoituksen omistajan ja oikean polun nopeasti.

Tunnista, johtuuko 404 puuttuvasta tiedostosta, väärin määritetystä virtuaalidirektoriumista vai ohjauksesta, joka osoittaa olemattomaan sijaintiin. IIS Managerissa tarkista vdir-asetukset ja vahvista fyysinen polku levyllä, sitten tarkista kansion käyttöoikeudet, jotta työntekijäprosessi voi jatkaa eri sivustojen yli. Jos sinulla on useita sivustoja, listaa niiden juurikansiot ja palveltavat sijainnit estääksesi sivustojen välistä sekaannusta.

Verkkosovelluksissa, jotka käyttävät pysyviä linkkejä, varmista, että URL-uudelleenkirjoitus -säännöt tai käsittelijäkartoitukset eivät peitä todellista 404 ystävällisellä sivulla. Päivitä web.config tai URL-uudelleenkirjoitus -säännöt, sitten testaa internet-polku selaimesta ja palvelimen lokitiedostoista vahvistaaksesi, että tuloksena oleva URL ratkeaa todelliseen tiedostoon tai kelvolliseen reittiin.

Jos resurssia ei ole olemassa, luo paikkamerkki tai siirrä tiedosto tarkoitettuun sijaintiin tai määritä asianmukainen staattinen/ASP.NET-reitti resurssin tarjoamiseksi. Jokaiselle sivustolle pidä kirjaa omistajasta ja tarkoitetusta sisällön sijainnista nopeuttaaksesi tulevia tunnistuksia. Käytä pysyviä linkkejä vahvistaaksesi, että kanoniset URL-osoitteet kuvaavat olemassa olevia resursseja, vähentäen tulevia kadonneita 404-virheitä.

Sitten jatka systemaattisella vahvistuksella: tarkista internetiin suuntautuva URL, varmista, että DNS ja isäntäotsikot osoittavat oikeaan sivustoon, ja kuvaa pysyvät linkit todelliseen tiedostopolkuun. Jos näet edelleen 404:n, jäljitä pyyntö IIS-pyyntölokista tunnistaaksesi, missä polku katoaa, ja säädä sen mukaan dokumentoiden muutokset omistajalle ja tiimille.

Analysoi IIS-lokeja 404-kuvioiden ja epäonnistuneiden URL-osoitteiden varalta

Vie uusimmat IIS-lokit ja suodata 404-vastaukset. Etsi toistuvia URL-polkuihin ja ensimmäiseen nähdyn aikaleiman mukaan paikantaaksesi toistuvia ongelmia, jotka vaikuttavat ihmisiin, jotka yrittävät päästä sivustollesi.

404-virheiden kuviot paljastavat yleisiä syitä: puuttuvat resurssit, väärin määritetyt vdir-merkinnät ja linkin kirjoitusvirhe. Jotkut ongelmat johtuvat ohjatusta tai siirretystä sisällöstä, kun taas toiset tulevat sisäisestä navigoinnista tai ulkoisista viittauksista. Kirjaa vdir-arvo muistiinpanoihisi pitääksesi indeksoinnin johdonmukaisena. Rakenna lista pahimmista rikkureista ja seuraa laskentaa ajan myötä erottaaksesi satunnaiset missaukset säännöllisesti toistuvista ongelmista.

Käytä viittaajaa ja käyttäjäagenttia arvioidaksesi, johtuuko ongelma hausta, muista sivustoista vai suorista hauista. Tämä auttaa priorisoimaan juurisyyn ratkaisemisen ja parantamaan käyttökokemusta vähemmällä kitkalla.

Vie taulukkoystävällinen näkymä 404-virheistä, mukaan lukien URL-polku, määrä, ensimmäinen nähty, viittaaja ja muistiinpanot. Tämä tulostusystävällinen muoto tukee sidosryhmien päivittämistä ja ylläpitääkseen yksittäistä totuuden lähdettä polkujen optimointiin ja indeksointiin.

URL-polku	Tila	Määrä	EnsimmäinenNäkymä	Viittaaja	Muistiinpanot
/images/logo.png	404	120	2025-11-01 08:23:11	https://example.com/home	Puuttuva tiedosto levyllä
/docs/guide.html	404	68	2025-11-02 09:12:05	https://example.com/manuals	Siirretty /docs/user-guide.html; päivitä linkit
/shop/vdir/index.html	404	42	2025-11-03 11:01:22	https://example.com/shop/	VDir-määrittelyvirhe; vahvista polku

Toimet 404-virheiden ratkaisemiseksi ja estämiseksi

Puuttuville resursseille palauta tiedosto tai luo 301-ohjaus oikeaan URL-osoitteeseen. Väärin määritetyille vdireille vahvista vdir-polku IIS Managerissa, tarkista applicationHost.config ja varmista olemassa oleva fyysinen polku. Kirjoitusvirheille korjaa linkki, päivitä sivun sisältö ja päivitä sisäiset hakemistot säännöllisesti.

Tulosta tiivistetty raportti ja jaa se tukitiimille. Pidä päivitettynä listaa muutoksista seurataaksesi, mikä toimi ja mikä ei. Useille toistuville rikkureille toteuta kohdennetut ohjaukset ja poista kuolleet linkit vähentääksesi tulevia virheitä.

Tarkista keräämiäsi kuvioita säännöllisesti, optimoiden 404-virheiden käsittelyä, ja testaa ohjauksia kehitysympäristössä ennen päivitysten soveltamista tuotantoon. Tämä lähestymistapa minimoi virheet ja auttaa ihmisiä saamaan sujuvamman kokemuksen sivustosi navigoinnissa.

Vahvista sivuston sidokset, isäntäotsikot ja virtuaalidirektoriumit

Tarkista ja korjaa sidokset välittömästi: varmista, että isäntäotsikko, IP ja portti vastaavat asiakkaan pyyntöä ja että sivuston nimi vastaa käytössä olevaa URL-osoitetta.

Sidostarkistukset

• Avaa IIS Manager, siirry Sites > [sivustosi] > Bindings. Vahvista, että http:lle (ja https:lle jos käytössä) on sidoksen oikealla IP:llä ja portilla. Jos useat sivustot jakavat saman IP:portin, lisää isäntänimi (isäntäotsikko) -arvo, joka vastaa nykyistä URL-osoitetta pyyntöjen reitittämiseksi oikein.

• Testaa pyynnöt tarkalla isäntäotsikolla: curl -I -H "Host: example.com" http://server/ tai käytä selainta. Jos 404 jatkuu, sidoksen voi olla oikein, mutta pyydetty polku käsitellään toisella sivustolla.

• Https:lle vahvista, että sertifikaatti vastaa sidoksen isäntänimeä. Tarkista aihe ja SAN:t, ja varmista, että sidoksen käyttää oikeaa sertifikaattia portissa 443. Epäyhteensopivuus voi johtaa epäonnistuneisiin pyyntöihin, jotka näyttävät puuttuvilta resursseilta.

• Tarkista DNS ja proxy-kerrokset: varmista, että saapuva pyyntö kantaa odotetun isäntäotsikon; proxy-määrittelyvirhe voi aiheuttaa pyyntöjen laskeutumisen väärälle sivustolle, tuottaen 404-virheitä kelvollisille poluille.

Virtuaalidirektoriumit ja polkumäärittely

1. Vahvista, että virtuaalidirektoriumin alias on olemassa sivuston alla; aliasin pitäisi näkyä URL-segmenttinä (esimerkiksi /files). Tarkista fyysinen polku oikeassa paneelissa ja vahvista, että kansio on olemassa ja saavutettavissa sovelluspulun tunnuksella.

2. Muunna sovellukseksi, kun direktoriumin pitäisi suorittaa koodia. Napsauta hiiren oikealla virtuaalidirektoriumia > Convert to Application, valitse oikea Application Pool ja varmista, että pulun tunnus on lukuoikeudet fyysiseen polkuun.

3. Tarkista oletussivut, jos luotat direktoriumitason URL-osoitteisiin; varmista, että kelvollinen oletussivu (index.html, default.aspx jne.) on olemassa tai anna eksplisiittinen tiedostopolku linkeissäsi.

4. Tarkista web.config-säännöt ja URL-uudelleenkirjoitukset, jotka voivat ohjata olemattomaan polkuun. Huono sääntö voi tuottaa puuttuvan resurssin 404-virheen muuten kelvollisille sivuille; säädä tai poista ristiriitaiset säännöt.

5. Vahvista käyttöoikeudet: anna luku/suoritus IIS_IUSRS:lle ja sovelluspulun tunnukselle fyysiseen polkuun, ja tarkista NTFS ACL:t sallivat pääsyn odotetulle käyttäjälle. Puuttuvat käyttöoikeudet aiheuttavat usein 404-virheitä, jotka näyttävät siltä, että sisältö on poissa.

6. Testaa uudelleen muutosten jälkeen: pyydä ongelmallinen URL ja vahvista 200 tai asianmukainen ohjaus; jos ohjaus silmukoituu tai resurssi pysyy puuttuvana, tarkista uudelleenkirjoitussäännöt ja käynnistyslokit sovelluspulussa.

Käytä perusryömiä paljastaaksesi nykyisen ongelman puuttuvista sivuista, jotka johtuvat sidoksista tai virtuaalidirektorioista. Grep IIS-lokeista 404-merkintöjä löytääksesi, mitkä pyynnöt epäonnistuvat, sitten käsittele juurisyytä ja testaa uudelleen uuteen ryömiin. Tallenna tulokset ja jaa tiivis yhteenveto ylläpitäjille ja kollegoille LinkedInissä pitääksesi kaikki linjassa, kun käsittelet ongelmaa.

Vahvista tiedostopolut, fyysinen olemassaolo ja tiedostokäyttöoikeudet

Vahvista sivuston fyysinen polku IIS Managerissa ja varmista, että polku on olemassa levyllä. Basic Settings -osiossa sivustolle tai virtuaalidirektoriumille vahvista, että osoittama kansio sisältää odotetun sisällön. Jos polku on muuttunut, palauta alkuperäinen sijainti tai korjaa kartoitus snap-inissä, jotta pyynnöt osoittavat oikeaan kansioon; muuten IIS lataa tyhjää ja näet 404-virheitä.

Vahvista, että tiedosto todella on olemassa tiedostojärjestelmässä ja että sovelluspulun tunnuksella on oikeudet kulkea ja lukea se. Käytä File Exploreria tai icaclsia ACL:ien vahvistamiseen kansiossa ja kaikissa emokansioissa. Anna Luku ja Luettele kansion sisältö ja Kulje sovelluspulun tunnukselle (esimerkiksi IIS APPPOOLYourAppPool) sisällön juureen ja tiedostoihin sisällä. Jos käyttöoikeudet ovat virheelliset, IIS ilmoittaa pääsykiellosta ja moottori voi palauttaa 404 vaikka tiedosto on olemassa. Säädä ACL:t sopivasti ja testaa uudelleen. Jos et ole varma, anna väliaikaisesti lukuoikeus tunnetulle käyttäjälle vahvistaaksesi tiedoston latautumisen.

Tarkista mime-tyyppien kartoitus palveltaville laajennuksille. Avaa sivuston mime-tyyppi ja varmista, että laajennuksella on liitetty mime-tyyppi; puuttuvat kartoitukset tuottavat usein 404. Tarvittaessa lisää yleisiä tyyppejä (.html, .css, .js, kuvat, fontit) ja vahvista, että oikea content-type lähetetään. Vahvista myös, että permalink-tyyliset URL-osoitteet ladataan oikeasta kansiosta; permalink-reitin ja fyysisen polun epäyhteensopivuus voi laukaista 404 sekä staattisille että dynaamisille resursseille.

Tarkista sivuston pyyntövaltuutuksen asetukset. Snap-inissä siirry sivuston Authorization Rules -osioon ja varmista, että asiakkaan tunnus on sallittu lukemaan pyydetyn kansion. Jos kieltävä sääntö estää tiedoston, moottori voi palauttaa 404 joillekin poluille; säännön poistaminen tai kaventaminen auttaa. Vahvista, että Anonymous Authentication on käytössä, jos luotat julkiseen pääsyyn, ja tarkista domain- tai sivustotason asetukset, jos useat sivustot jakavat saman sisällön juuren.

Käytä ja tarkista lokit ja jäljitys. Ota käyttöön Failed Request Tracing 404-virheille tai tarkista IIS-lokit tunnistaaksesi osumien määrän ja pyytävän osoitteen. Etsi tarkkaa URL-osoitetta, kartoitettua polkua ja tiedostopolkua moottorista; tämä tunnistetiedot auttavat lähdettä paikantamaan. Käytä tietoja oikean polun palauttamiseen, korjaamaan latausjärjestyksen ja estämään turhauttavia toistumisia. Internetiin suuntautuvilla sivustoilla vahvista, että domain-profiilit ja fyysinen polku ovat linjassa; pieni epäyhteensopivuus voi rikkoa pääsyn useille sivustoille. Muutosten jälkeen kierrätä sovelluspulu uusien kartoitusten ja käyttöoikeuksien soveltamiseksi. Jos käsittelet 404:ää johdonmukaisesti, käsittele juurisyy ensin ja sitten vahvista käyttäjäpolku kaikilla sivustoilla.

Tarkista URL-uudelleenkirjoitussäännöt ja mukautetut virheasetukset

Vie nykyiset URL-uudelleenkirjoitussäännöt IIS:stä jokaiselle sivustolle ja vertaa niitä tunnettuun hyvään peruslinjaan paikantaaksesi määrittelyvirheet, jotka johtavat 404-tuloksiin. Tämä paljastaa, johtuuko ongelma uudelleenkirjoitetusta URL:sta, puuttuvasta resurssista vai sopimattomasta mukautetun virheen polusta.

Mitä tarkistaa

Sijoita säännöt web.config-tiedostosta tai URL Rewrite -moduulista jokaiselle sivustolle. Tarkista kuvio ja ehdot, jotka laukaisevat uudelleenkirjoituksen tai ohjauksen, ja vahvista, että kohde-URL osoittaa olemassa olevaan resurssiin tai asianmukaisesti määriteltyyn html-sivuun mukautetuissa virheissä. Vahvista, että 404-merkintä on määritelty ja että virhesivun käyttämä polku on olemassa sivuston juuressa. Tarkista ristiriidat sivustojen välillä, jotka jakavat saman sovelluspulun ja kuvaavat samoja polkuja.

Tarkasta arvioinnin järjestys: ensimmäinen vastaava sääntö pysäyttää lisäkäsittelyn. Etsi sisään- tai ulossuuntautuvia sääntöjä, jotka voivat kaapata 404:n ennen kuin mukautettu virheenkäsittelijä käynnistyy, ja varmista, että varalla oleva 404-sivu on määritellyssä sijainnissa. Tarkista globaalit tai sivustotason asetukset, jotka voivat ohittaa sivustokohtaisen määrittelyn.

Miten korjaukset sovelletaan

Jos sääntö on väärin määritetty, säädä vastaavuuskuvio, uudelleenkirjoitustoiminto ja kohde. Varmista, että puuttuva resurssi ei uudelleenkirjoiteta olemassa olevaan polkuun, joka palauttaa ei-404-vastauksen. Päivitä mukautettujen virheiden osio niin, että 404-pyynnöt reititetään todelliseen html-tiedostoon ja vahvista, että tiedosto on otettu käyttöön oikeilla käyttöoikeuksilla. Muutosten jälkeen kierrätä sovelluspulu ja testaa eri asiakasyhteyksistä vahvistaaksesi johdonmukaiset tulokset. Käytä palvelinlokitietoja ja Failed Request Tracing (FRT) -tietoja tunnistaaksesi tarkan säännön ja lopullisen vastaussivun.

Toista epäonnistumiset kohdennetuilla testeillä ja seuraa vastauksia

Suositus: Toista 404 kohdennetuilla testeillä ja seuraa vastauksia jaetussa työpöydässä. Tallentaa todisteet accesslogiin ja nimeä omistaja jokaiselle kuviolle nopeuttaaksesi korjausta. Tämä lähestymistapa auttaa johtoa näkemään nykyisen vaikutuksen ja priorisoimaan korjauksia sivustokantojen yli.

Vie viimeiset 200 404-merkintää accesslogista sivustolle. Jokaiselle merkinnälle kirjaa aika, asiakkaan IP, isäntänimi, pyydetty URL, viittaaja, käyttäjäagentti, tila ja vastauksen koko. Jos havaitset puuttuvia resursseja liittyvien polkujen alla, tämä viittaa kuviin eristettyjen tapausten sijaan. Rakenna tiivis testilista näistä signaaleista ottamaan seuraavat askeleet.

Testaa polkujen vaihtelut: pyydä tunnettuja puuttuvia URL-osoitteita peräkkäisen kauttaviivan kanssa ja ilman; muuta segmenttien kirjainkokoa; liitä tai poista kyselymerkkijonot; vertaa vastauksia staattisille resursseille dynaamisia reittejä vastaan. Sisällytä sekä GET- että HEAD-menetelmät vahvistaaksesi, että palvelin palauttaa 404 ennen tahattomia ohjauksia tai uudelleenkirjoituksia.

Käytä Failed Request Tracingia (FRT), kun saatavilla, ja tarkista accesslogin kanssa samoja aikaleimoja. Nämä jäljet osoittavat, mikä sääntö tai moduuli esti resurssin tai jos resurssi todella puuttuu. Yhdistä tulokset työpöydän mittariin: 404-määrä reitillä, isännällä ja tilillä. Tämä erinomainen korrelaatio nopeuttaa tutkimusta ja paljastaa nykyiset kuumakohdat.

Resursseille, jotka ovat uudelleenkirjoitus- tai reititys kerroksen takana, tarkista liittyvät web.config, URL-uudelleenkirjoitussäännöt ja htaccess-tyyliset määrittelyt, joita IIS saattaa kunnioittaa uudelleenkirjoitusmoduulien kautta. Jos 404 viittaa kartoitusongelmaan, säädä sääntöä tai tiedostopolkua, sitten suorita testit uudelleen vahvistaaksesi korjauksen ennen siirtymistä tuotantoon. Tapauksissa, joissa 404 osoittaa estettyyn resurssiin, vahvista estolista tai pääsyrajoitukset ja varmista, että ne ovat linjassa tarkoitettujen pääsykuvioiden kanssa.

Dokumentoi löydökset työpöydässä ja jaa yhteenveto sivuston omistajalle ja johdolle. Tarvittaessa julkaise oivalluksia LinkedInissä tiimien väliseen näkyvyyteen. Prosessin pitäisi olla toistettava: tallenna testisyötteet, tallenna vastaukset ja liitä liittyvät logit accesslogista, jotta ne voidaan tarkistaa tilinomistajan tai tietoturvatiimin toimesta.

Tapoja parantaa kestävyyttä: rakenna pieni testiharness, joka käy läpi testilistan, tallentaa tilakoodit ja merkitsee piikit. Käytä näitä signaaleja toimiaksesi puuttuviin resursseihin, päivittääksesi sisällön inventaariot ja estääksesi meluisat probet IP:llä vain perustellusti. Pidä aina nykyinen testisarja linjassa sivuston inventaarin ja MIME-tyyppien kartoitusten kanssa estääksesi regressiot.

Minkä tahansa muutoksen ennen varmista, että sinulla on omistajan hyväksyntä ja palautussuunnitelma. Jatkuva seuranta-työpöytä pitäisi osoittaa, onko 404-tahti vakaa, nouseva vai palaamassa peruslinjaan. Hyvin hoidettu testiohjelma nopeuttaa häiriövasteita ja auttaa tiimiä toimittamaan sujuvamman käyttökokemuksen.