Řešení problémů s chybou HTTP 404 Not Found na IIS - Průvodce pro systémové administrátory

Povolte podrobné chyby v IIS a získejte přesnou požadovanou URL, poté ji porovnejte s vazbami webu, abyste identifikovali, který web nebo vdir je zamýšlen. Tato první akce často odhalí, zda je zdroj chybějící, ztracený nebo se nachází na jiném místě ve vaší infrastruktuře, což vám pomůže rychle najít vlastníka mapování a správnou cestu.

Identifikujte, zda 404 pochází z chybějícího souboru, špatně nakonfigurovaného virtuálního adresáře nebo přesměrování, které ukazuje na neexistující umístění. V Správci IIS zkontrolujte nastavení vdir a ověřte fyzickou cestu na disku, poté zkontrolujte oprávnění k adresáři, aby pracovní proces mohl pokračovat přes různé weby. Pokud máte několik webů, uveďte jejich kořenové složky a umístění, která obsluhují, aby se zabránilo záměně mezi weby.

Pro webové aplikace používající trvalé odkazy zajistěte, aby pravidla přepisování URL nebo mapování obslužných programů nemaskovala skutečnou 404 chybu přátelskou stránkou. Aktualizujte web.config nebo pravidla přepisování URL, poté otestujte internetovou cestu z prohlížeče a ze serverových logů, abyste potvrdili, že výsledná URL vede k skutečnému souboru nebo platné trase.

Pokud zdroj není přítomen, vytvořte zástupný symbol nebo přesuňte soubor na zamýšlené umístění, nebo nakonfigurujte správnou statickou/ASP.NET trasu pro obsluhu zdroje. Pro každý web si vedte záznam o vlastníkovi a zamýšleném umístění obsahu, aby se urychlily budoucí identifikace. Používejte trvalé odkazy k ověření, že kanonické URL mapují na existující zdroje, což snižuje budoucí ztracené 404.

Pokračujte pak systematickou ověřením: zkontrolujte internetově vystavenou URL, zajistěte, že DNS a hlavičky hostitele ukazují na správný web, a mapujte trvalé odkazy na skutečnou cestu k souboru. Pokud stále vidíte 404, sledujte požadavek z logu požadavků IIS, identifikujte, kde se cesta ztratila, a upravte podle toho, dokumentujte změny pro vlastníka a tým.

Analyzujte logy IIS pro vzory 404 a selhávající URL

Exportujte nejnovější logy IIS a filtrujte pro odpovědi 404. Hledejte časté cesty URL a časové razítko prvního výskytu, abyste identifikovali opakující se problémy ovlivňující lidi, kteří se snaží dostat na váš web.

Vzory v 404 odhalují běžné příčiny: chybějící zdroje, špatně nakonfigurované položky vdir a překlep v odkazu. Některé problémy pocházejí z přesměrovaného nebo přesunutého obsahu, zatímco jiné z vnitřní navigace nebo externích odkazů. Zapište hodnotu vdir do svých poznámek, aby se udržela konzistentní indexace. Vytvořte seznam největších pachatelů a sledujte počty v průběhu času, abyste rozlišili příležitostné chyby od pravidelně se opakujících problémů.

Používejte pole referrer a user-agent k posouzení, zda problém pochází z vyhledávání, jiných webů nebo přímých vyhledávání. To vám pomůže upřednostnit řešení kořenové příčiny a zlepšení uživatelského zážitku s menším třením.

Exportujte tabulkový pohled 404, včetně cesty URL, počtu, prvního výskytu, referreru a poznámek. Tento tisknutelný formát podporuje aktualizaci stakeholderů a udržování jediného zdroje pravdy pro optimalizaci cest a indexace.

URL Path	Status	Count	FirstSeen	Referrer	Notes
/images/logo.png	404	120	2025-11-01 08:23:11	https://example.com/home	Chybějící soubor na disku
/docs/guide.html	404	68	2025-11-02 09:12:05	https://example.com/manuals	Přesunuto do /docs/user-guide.html; aktualizujte odkazy
/shop/vdir/index.html	404	42	2025-11-03 11:01:22	https://example.com/shop/	Špatná konfigurace VDir; ověřte cestu

Akce k vyřešení a prevenci 404

Pro chybějící zdroje obnovte soubor nebo vytvořte 301 přesměrování na správnou URL. Pro špatně nakonfigurované vdir ověřte cestu vdir v Správci IIS, zkontrolujte applicationHost.config a zajistěte existující fyzickou cestu. Pro překlepy opravte odkaz, aktualizujte obsah o stránce a pravidelně obnovujte interní vyhledávací indexy.

Vytiskněte shrnutou zprávu a sdílejte ji s podporním týmem. Udržujte aktualizovaný běžící seznam změn, abyste sledovali, co fungovalo a co ne. Pro více častých pachatelů implementujte cílená přesměrování a odstraňte mrtvé odkazy, aby se snížily budoucí chyby.

Pravidelně kontrolujte sbírané vzory, optimalizujte zpracování 404 a testujte přesměrování v stagingovém prostředí před aplikací aktualizací na produkci. Tento přístup minimalizuje chyby a pomáhá lidem mít hladší zážitek při navigaci na vašem webu.

Ověřte vazby webu, hlavičky hostitele a virtuální adresáře

Okamžitě zkontrolujte a opravte vazby: zajistěte, že hlavička hostitele, IP a port odpovídají požadavku klienta a že název webu odpovídá používané URL.

Kontroly vazeb

• Otevřete Správce IIS, přejděte na Sites > [váš web] > Bindings. Ověřte, zda existuje vazba pro http (a https, pokud je použita) s správnou IP a portem. Pokud více webů sdílí stejnou IP:port, přidejte hodnotu názvu hostitele (hlavička hostitele), která odpovídá aktuální URL, aby se požadavky správně směrovaly.

• Testujte požadavky s přesnou hlavičkou hostitele: curl -I -H "Host: example.com" http://server/ nebo použijte prohlížeč. Pokud 404 přetrvává, vazba může být správná, ale požadovaná cesta je zpracována jiným webem.

• Pro https ověřte, zda certifikát odpovídá hostname v vazbě. Zkontrolujte subjekt a SANy a zajistěte, že vazba používá správný certifikát na portu 443. Nesoulad může vést k selhávajícím požadavkům, které vypadají jako chybějící zdroje.

• Zkontrolujte DNS a vrstvy proxy: zajistěte, že příchozí požadavek nese očekávanou hlavičku hostitele; špatná konfigurace proxy může způsobit, že požadavky přistanou na špatném webu, což vede k 404 pro platné cesty.

Konfigurace virtuálních adresářů a cest

1. Ověřte, zda alias virtuálního adresáře existuje pod webem; alias by měl appearovat jako segment URL (např. /files). Zkontrolujte fyzickou cestu v pravém panelu a potvrďte, že složka existuje a je přístupná identitou app poolu.

2. Převeďte na Application, když adresář má spouštět kód. Klikněte pravým tlačítkem na virtuální adresář > Convert to Application, vyberte správný Application Pool a zajistěte, že identita poolu má oprávnění k čtení fyzické cesty.

3. Zkontrolujte výchozí dokumenty, pokud spoléháte na URL na úrovni adresáře; zajistěte platný výchozí dokument (index.html, default.aspx atd.) nebo uveďte explicitní cestu k souboru ve vašich odkazech.

4. Zkontrolujte pravidla web.config a přepisy URL, které by mohly přesměrovat do neexistující cesty. Špatné pravidlo může produkovat 404 chybějícího zdroje pro jinak platné stránky; upravte nebo odstraňte konfliktní pravidla.

5. Ověřte oprávnění: udělte čtení/spuštění IIS_IUSRS a identitě app poolu na fyzické cestě a ověřte, že NTFS ACL umožňují přístup pro očekávaného uživatele. Chybějící oprávnění často způsobují 404, které vypadají, jako by obsah byl pryč.

6. Opětovně otestujte po změnách: požádejte o problematickou URL a potvrďte 200 nebo vhodné přesměrování; pokud dochází k smyčce přesměrování nebo zdroj zůstává chybějící, zkontrolujte pravidla přepisu a logy spuštění v application poolu.

Používejte základní crawl k odhalení aktuálního problému s chybějícími stránkami způsobenými vazbami nebo virtuálními adresáři. Prohledejte logy IIS pomocí grep pro položky 404, abyste našli, které požadavky selhávají, poté řešte kořenovou příčinu a znovu otestujte do čerstvého crawlu. Uložte výsledky a sdílejte stručné shrnutí s administrátory a kolegy na LinkedIn, aby všichni zůstali sladění, zatímco řešíte problém.

Ověřte cesty k souborům, fyzickou existenci a oprávnění k souborům

Ověřte fyzickou cestu webu v Správci IIS a zajistěte, že cesta existuje na disku. V Basic Settings pro web nebo virtuální adresář potvrďte, že složka, na kterou ukazujete, obsahuje očekávaný obsah. Pokud se cesta změnila, obnovte původní umístění nebo opravte mapování v snap-inu, aby požadavky adresovaly správnou složku; jinak IIS nenačte nic a uvidíte 404.

Potvrďte, že soubor skutečně existuje na souborovém systému a že identita app poolu má práva k procházení a čtení. Používejte Průzkumník souborů nebo icacls k ověření ACL na složce a všech nadřazených složkách. Udělte Čtení a Seznam obsahu složky a Procházení identitě app poolu (např. IIS APPPOOLYourAppPool) na kořeni obsahu a souborech uvnitř. Pokud jsou oprávnění nesprávná, IIS indikuje odepření přístupu a engine může vrátit 404 i když soubor existuje. Upravte ACL vhodně a znovu otestujte. Pokud si nejste jisti, dočasně přiřaďte přístup k čtení známému uživateli, abyste potvrdili, že se soubor načte.

Zkontrolujte mapování typů MIME pro rozšíření, která obsluhujete. Otevřete typ MIME pro web a zajistěte, že rozšíření má přiřazený typ MIME; chybějící mapování často vede k 404. Pokud je potřeba, přidejte běžné typy (.html, .css, .js, obrázky, písma) a ověřte, že se odesílá správný content-type. Také ověřte, že permalink-style URL se načítají ze správné složky; nesoulad mezi permalink trasou a fyzickou cestou může spustit 404 pro statické i dynamické assety.

Zkontrolujte nastavení autorizace požadavků webu. V snap-inu přejděte na Authorization Rules webu a zajistěte, že identita klienta má povolen přístup k požadované složce. Pokud pravidlo deny blokuje soubor, engine může vrátit 404 pro některé cesty; odstranění pravidla nebo jeho zúžení pomůže. Potvrďte, že je povolena anonymní autentizace, pokud spoléháte na veřejný přístup, a zkontrolujte nastavení na úrovni domény nebo webu, pokud více webů sdílí stejný kořen obsahu.

Povolte a zkontrolujte logy a trasování. Zapněte Failed Request Tracing pro chyby 404 nebo zkontrolujte logy IIS k identifikaci počtu zásahů a adresy požadující. Hledejte přesnou URL, mapovanou cestu a cestu k souboru z enginu; tyto identifikující údaje pomáhají najít zdroj. Používejte informace k obnovení správné cesty, opravě pořadí načítání a prevenci frustrujících opakování. Na internetově vystavených webech ověřte, že profily domény a fyzická cesta se shodují; malý nesoulad může narušit přístup pro více webů. Po změnách recycle app pool, aby se aplikovala nová mapování a oprávnění. Pokud řešíte 404 konzistentně, řešte kořenovou příčinu nejprve a poté ověřte uživatelskou cestu přes všechny weby.

Zkontrolujte pravidla přepisování URL a konfigurace vlastních chyb

Exportujte aktuální pravidla přepisování URL z IIS pro každý web a porovnejte je s známou dobrým baseline, abyste identifikovali špatné konfigurace vedoucí k výsledkům 404. To odhalí, zda problém pochází z přepsané URL, chybějícího zdroje nebo nesprávné cesty vlastní chyby.

Co zkontrolovat

Najděte pravidla v web.config nebo přes modul URL Rewrite pro každý web. Zkontrolujte vzor a podmínky, které spouštějí přepsání nebo přesměrování, a ověřte, že cílová URL ukazuje na existující zdroj nebo správnou html stránku definovanou v Custom Errors. Potvrďte, že položka 404 je definována a že cesta použitá chybovou stránkou existuje pod kořenem webu. Zkontrolujte konflikty mezi weby sdílejícími stejný application pool, které mapují stejné cesty.

Auditujte pořadí vyhodnocení: první shodující pravidlo zastaví další zpracování. Hledejte inbound nebo outbound pravidla, která mohou zachytit 404 před spuštěním obslužného programu vlastní chyby, a zajistěte fallback 404 stránku na nakonfigurovaném umístění. Zkontrolujte globální nebo nastavení na úrovni webu, které mohou přepsat konfiguraci na úrovni webu.

Jak aplikovat opravy

Pokud je pravidlo špatně nakonfigurované, upravte vzor shody, akci přepsání a cíl. Zajistěte, že chybějící zdroj nedostane přepsán do existující cesty, která vrátí odpověď non-404. Aktualizujte sekci Custom Errors, aby požadavky 404 vedly k skutečnému html souboru, a ověřte, že soubor je nasazen s správnými oprávněními. Po změnách recycle app pool a otestujte z různých klientských prostředí, abyste potvrdili konzistentní výsledky. Používejte serverové logy a data Failed Request Tracing (FRT) k identifikaci přesného pravidla a finální stránky odpovědi.

Reproduktujte selhání cílenými testy a monitorujte odpovědi

Doporučení: Reproduktujte 404 cílenými testy a monitorujte odpovědi v sdíleném dashboardu. Zachyťte důkazy v accesslogu a přiřaďte vlastníka pro každý vzor, aby se urychlila remediacia. Tento přístup pomáhá managementu vidět aktuální dopad a upřednostnit opravy přes rozsahy webů.

Exportujte posledních 200 položek 404 z accesslogu pro web. Pro každou položku zapište čas, IP klienta, hostname, požadovanou URL, referrer, user-agent, stav a velikost odpovědi. Pokud pozorujete chybějící assety pod souvisejícími cestami, to indikuje vzory spíše než izolované případy. Vytvořte stručný seznam testů z těchto signálů pro další kroky.

Testujte variace cest: požádejte o známé chybějící URL s a bez koncové lomítko; změňte velikost písmen segmentů; přidejte nebo odeberte řetězce dotazů; porovnejte odpovědi pro statické assety proti dynamickým trasám. Zahrňte metody GET i HEAD, abyste potvrdili, že server vrátí 404 před jakýmkoli nechtěným přesměrováním nebo přepsáním.

Používejte Failed Request Tracing (FRT), když je dostupné, a zkřížově zkontrolujte s accesslogem pro stejné časové razítka. Tyto stopy indikují, které pravidlo nebo modul blokoval zdroj, nebo zda je zdroj skutečně chybějící. Spojte výsledky s metrikou dashboardu: počet 404 podle trasy, podle hosta a podle účtu. Tato vynikající korelace urychluje vyšetřování a odhaluje aktuální hotspotů.

Pro zdroje za vrstvou přepisu nebo směrování zkontrolujte související web.config, pravidla URL Rewrite a jakékoli konfigurace podobné htaccess, které IIS může respektovat přes moduly přepisu. Pokud 404 indikuje problém s mapováním, upravte pravidlo nebo cestu k souboru, poté znovu spusťte testy, abyste potvrdili opravu před přesunem do produkce. V případech, kdy 404 ukazuje na blokovaný zdroj, ověřte seznam bloků nebo omezení přístupu a zajistěte, že se shodují s zamýšlenými vzory přístupu.

Dokumentujte nálezy v dashboardu a sdílejte shrnutí s vlastníkem webu a managementem. Pokud je potřeba, publikujte insights na LinkedIn pro viditelnost přes týmy. Proces by měl být opakovatelný: uložte vstupy testů, zachyťte odpovědi a připojte související logy z accesslogu, aby je mohli zkontrolovat vlastník účtu nebo bezpečnostní tým.

Spůsoby zlepšení odolnosti: vytvořte malý testovací harness, který iteruje přes seznam testů, zaznamenává stavy kódů a označuje špičky. Používejte tyto signály k akci na chybějící assety, aktualizaci inventářů obsahu a blokování hlučných sond podle IP pouze tehdy, když je to oprávněné. Vždy udržujte aktuální testovací sadu sladěnou s inventářem webu a mapováním typů MIME, aby se zabránilo regresiím.

Před jakoukoli změnou zajistěte schválení vlastníka a plán rollbacku. Průběžný monitorovací dashboard by měl indikovat, zda je míra 404 stabilní, rostoucí nebo se vrací k baseline. Dobře prováděný testovací režim urychluje odpověď na incidenty a pomáhá týmu dodat hladší uživatelský zážitek.