Depanarea erorii HTTP 404 Not Found pe IIS - Ghid pentru administratori de sistem

Activați erorile detaliate în IIS și notați URL-ul exact solicitat, apoi comparați-l cu legăturile site-ului pentru a identifica care site sau vdir este vizat. Această primă acțiune dezvăluie adesea dacă resursa lipsește, este pierdută sau se află într-o altă locație în infrastructura dvs., ajutându-vă să localizați proprietarul mapării și calea corectă rapid.

Identificați dacă eroarea 404 provine dintr-un fișier lipsă, un director virtual configurat greșit sau o redirecționare care pointează către o locație inexistentă. În IIS Manager, inspectați setările vdir și verificați calea fizică pe disc, apoi verificați permisiunile pe folder pentru ca procesul de lucru să poată continua pe diferite site-uri. Dacă aveți mai multe site-uri, listați folderele rădăcină și locațiile pe care le deservesc pentru a preveni confuziile între site-uri.

Pentru aplicațiile web care folosesc legături permanente, asigurați-vă că regulile de rescriere URL sau mapări de manipulări nu maschează o eroare 404 reală cu o pagină prietenoasă. Actualizați web.config sau regulile de rescriere URL, apoi testați calea de internet dintr-un browser și din jurnalele server-side pentru a confirma că URL-ul rezultat se rezolvă la un fișier real sau o rută validă.

Dacă resursa nu este prezentă, creați un placeholder sau mutați fișierul în locația intenționată, sau configurați o rută statică/ASP.NET adecvată pentru a deservi resursa. Pentru fiecare site, păstrați o înregistrare a proprietarului și a locației conținutului intenționat pentru a accelera identificările viitoare. Folosiți legăturile permanente pentru a verifica că URL-urile canonice se mapează la resurse existente, reducând erorile 404 pierdute viitoare.

Apoi continuați cu o verificare sistematică: verificați URL-ul orientat către internet, asigurați-vă că DNS și antetele host pointează către site-ul corect și mapați legăturile permanente la o cale de fișier reală. Dacă vedeți în continuare o eroare 404, urmăriți cererea din jurnalul de cereri IIS, identificând unde se pierde calea și ajustați în consecință, documentând modificările pentru proprietar și echipă.

Analizați jurnalele IIS pentru modele de 404 și URL-uri eșuate

Exportați cele mai recente jurnale IIS și filtrați pentru răspunsuri 404. Căutați căi URL frecvente și timestamp-ul primei apariții pentru a identifica probleme recurente care afectează oamenii care încearcă să acceseze site-ul dvs.

Modelele în erorile 404 dezvăluie cauze comune: resurse lipsă, intrări vdir configurate greșit și o greșeală de scriere într-un link. Unele probleme provin din conținut redirecționat sau mutat, în timp ce altele vin din navigare internă sau referințe externe. Înregistrați valoarea vdir în notele dvs. pentru a menține indexarea consistentă. Construiți o listă cu principalii infractori și urmăriți numerele în timp pentru a distinge ratările ocazionale de problemele care se repetă regulat.

Folosiți câmpurile referrer și user-agent pentru a evalua dacă problema vine din căutări, alte site-uri sau căutări directe. Acest lucru vă ajută să prioritizați rezolvarea cauzei rădăcină și îmbunătățirea experienței utilizatorului cu mai puțină frecare.

Exportați o vedere prietenoasă cu tabelele pentru erorile 404, incluzând calea URL, număr, prima văzută, referrer și note. Acest format prietenos cu imprimarea susține actualizarea stakeholderilor și menținerea unei singure surse de adevăr pentru optimizarea căilor și indexării.

Cale URL	Status	Număr	PrimaVăzută	Referrer	Note
/images/logo.png	404	120	2025-11-01 08:23:11	https://example.com/home	Fișier lipsă pe disc
/docs/guide.html	404	68	2025-11-02 09:12:05	https://example.com/manuals	Mutat la /docs/user-guide.html; actualizați linkurile
/shop/vdir/index.html	404	42	2025-11-03 11:01:22	https://example.com/shop/	Configurare greșită VDir; verificați calea

Acțiuni pentru a rezolva și preveni erorile 404

Pentru resurse lipsă, restaurați fișierul sau creați o redirecționare 301 către URL-ul corect. Pentru vdir-uri configurate greșit, verificați calea vdir în IIS Manager, verificați applicationHost.config și asigurați-vă că există o cale fizică existentă. Pentru greșeli de scriere, corectați linkul, actualizați conținutul despre pagină și reîmprospătați indexurile de căutare interne regulat.

Imprimați un raport rezumat și partajați-l cu echipa de suport. Continuați să actualizați o listă curentă de modificări pentru a urmări ce a funcționat și ce nu. Pentru mai mulți infractori frecvenți, implementați redirecționări țintite și eliminați linkurile moarte pentru a reduce erorile viitoare.

Revizuiți regulat modelele pe care le colectați, optimizând gestionarea erorilor 404 și testând redirecționările într-un mediu de staging înainte de a aplica actualizări în producție. Această abordare minimizează greșelile și ajută oamenii să aibă o experiență mai lină când navighează pe site-ul dvs.

Verificați legăturile site-ului, antetele host și directoarele virtuale

Revizuiți și corectați legăturile imediat: asigurați-vă că antetul host, IP și portul se potrivesc cu cererea clientului și că numele site-ului corespunde cu URL-ul în uz.

Verificări de legături

• Deschideți IIS Manager, navigați la Sites > [site-ul dvs.] > Bindings. Verificați dacă există o legătură pentru http (și https dacă este folosită) cu IP și portul corect. Dacă mai multe site-uri împart același IP:port, adăugați o valoare de nume host (antet host) care se potrivește cu URL-ul curent pentru a ruta cererile corect.

• Testați cererile cu antetul host exact: curl -I -H "Host: example.com" http://server/ sau folosiți un browser. Dacă eroarea 404 persistă, legătura poate fi corectă, dar calea solicitată este gestionată de alt site.

• Pentru https, verificați dacă certificatul se potrivește cu numele host din legătură. Verificați subiectul și SAN-urile și asigurați-vă că legătura folosește certificatul corect pe portul 443. O nepotrivire poate duce la cereri eșuate care arată ca resurse lipsă.

• Inspectați DNS și straturile proxy: asigurați-vă că cererea în incoming poartă antetul host așteptat; o configurare greșită a proxy-ului poate cauza ca cererile să aterizeze pe site-ul greșit, rezultând 404 pentru căi valide.

Directoare virtuale și configurare cale

1. Verificați dacă aliasul directorului virtual există sub site; aliasul ar trebui să apară ca un segment URL (de exemplu /files). Revizuiți calea fizică în panoul din dreapta și confirmați că folderul există și este accesibil de identitatea app pool.

2. Convertiți la Application când directorul ar trebui să ruleze cod. Faceți clic dreapta pe directorul virtual > Convert to Application, selectați Application Pool-ul corect și asigurați-vă că identitatea pool-ului are permisiuni de citire la calea fizică.

3. Verificați documentele implicite dacă vă bazați pe URL-uri la nivel de director; asigurați-vă că există un document implicit valid (index.html, default.aspx etc.) sau furnizați o cale de fișier explicită în linkurile dvs.

4. Revizuiți regulile web.config și rescrierile URL care ar putea redirecționa într-o cale inexistentă. O regulă proastă poate produce o eroare 404 de resursă lipsă pentru pagini altfel valide; ajustați sau eliminați regulile conflictuale.

5. Validați permisiunile: acordați citire/executare la IIS_IUSRS și identitatea app pool pe calea fizică și verificați ACL-urile NTFS care permit accesul pentru utilizatorul așteptat. Permisiunile lipsă cauzează adesea erori 404 care arată ca și cum conținutul a dispărut.

6. Testați din nou după modificări: solicitați URL-ul problematic și confirmați un 200 sau o redirecționare adecvată; dacă o redirecționare bouclează sau o resursă rămâne lipsă, revizuiți regulile de rescriere și jurnalele de pornire în app pool.

Folosiți un crawl de bază pentru a descoperi problema curentă despre pagini lipsă cauzate de legături sau directoare virtuale. grep prin jurnalele IIS pentru intrări 404 pentru a găsi care cereri eșuează, apoi abordați cauza rădăcină și testați din nou într-un crawl proaspăt. Salvați rezultatele și partajați un rezumat concis cu administratorii și colegii pe linkedin pentru a menține pe toată lumea aliniat în timp ce gestionați problema.

Validați căile de fișiere, existența fizică și permisiunile fișierelor

Verificați Calea Fizică a site-ului în IIS Manager și asigurați-vă că calea există pe disc. În Setări de Bază pentru site sau directorul virtual, confirmați că folderul la care indicați conține conținutul așteptat. Dacă calea s-a schimbat, restaurați locația originală sau corectați maparea în snap-in pentru ca cererile să adreseze folderul corect; altfel IIS nu încarcă nimic și vedeți erori 404.

Confirmați că fișierul există de fapt pe sistemul de fișiere și că identitatea app pool are drepturi să traverseze și să-l citească. Folosiți File Explorer sau icacls pentru a verifica ACL-urile pe folder și toate folderele părinte. Acordați Citire și Listă Conținut Folder și Traversează identității app pool (de exemplu IIS APPPOOLYourAppPool) pe rădăcina conținutului și fișierele din interior. Dacă permisiunile sunt incorecte, IIS indică refuz de acces și motorul poate returna 404 chiar dacă fișierul există. Ajustați ACL-urile corespunzător și re-testați. Dacă nu sunteți sigur, atribuiți temporar acces de citire unui utilizator cunoscut pentru a confirma că fișierul se încarcă.

Verificați maparea tipului MIME pentru extensiile pe care le deserviți. Deschideți tipul MIME pentru site și asigurați-vă că extensia are un tip MIME asociat; mapările lipsă rezultă adesea în 404. Dacă este necesar, adăugați tipuri comune (.html, .css, .js, imagini, fonturi) și verificați că se trimite content-type corect. De asemenea, verificați că URL-urile de stil permalink se încarcă din folderul corect; o nepotrivire între ruta permalink și calea fizică poate declanșa 404 pentru atât active statice, cât și dinamice.

Revizuiți setările de autorizare a cererilor site-ului. În snap-in, navigați la Reguli de Autorizare ale site-ului și asigurați-vă că identitatea clientului este permisă să citească folderul solicitat. Dacă o regulă de refuz blochează fișierul, motorul poate returna 404 pentru unele căi; eliminarea regulii sau îngustarea ei ajută. Confirmați că Autentificarea Anonimă este activată dacă vă bazați pe acces public și verificați setările la nivel de domeniu sau site dacă mai multe site-uri împart aceeași rădăcină de conținut.

Activați și verificați jurnalele și trasarea. Activați Failed Request Tracing pentru erori 404 sau revizuiți jurnalele IIS pentru a identifica numărul de hit-uri și adresa solicitantă. Căutați URL-ul exact, calea mapată și calea fișierului din motor; aceste date de identificare ajută la localizarea sursei. Folosiți informațiile pentru a restaura o cale corectă, a repara ordinea de încărcare și a preveni reocurențe frustrante. Pe site-urile orientate către internet, verificați că profilele de domeniu și calea fizică se aliniază; o mică nepotrivire poate sparge accesul pentru mai multe site-uri. După modificări, reciclați app pool pentru a aplica noile mapări și permisiuni. Dacă abordați o eroare 404 consistent, abordați mai întâi cauza rădăcină și apoi verificați parcursul utilizatorului pe toate site-urile.

Revizuiți regulile de rescriere URL și configurațiile de erori personalizate

Exportați regulile curente de rescriere URL din IIS pentru fiecare site și comparați-le cu o linie de bază cunoscută-bună pentru a identifica misconfigurările care duc la rezultate 404. Acest lucru va dezvălui dacă problema provine dintr-un URL rescris, o resursă lipsă sau o cale de eroare personalizată improprie.

Ce să inspectați

Localizați regulile în web.config sau prin modulul URL Rewrite pentru fiecare site. Revizuiți modelul și condițiile care declanșează o rescriere sau redirecționare și verificați că URL-ul țintă pointează către o resursă existentă sau o pagină html adecvată definită în Erori Personalizate. Confirmați că intrarea 404 este definită și că calea folosită de pagina de eroare există sub rădăcina site-ului. Verificați conflictele între site-uri care împart un singur app pool care mapează aceleași căi.

Auditati ordinea de evaluare: prima regulă potrivită oprește procesarea ulterioară. Căutați reguli inbound sau outbound care pot captura o eroare 404 înainte ca manipulatorul de erori personalizat să ruleze și asigurați-vă că există o pagină 404 de rezervă la locația configurată. Revizuiți orice setări globale sau la nivel de site care pot suprascrie configurația per-site.

Cum să aplicați corecțiile

Dacă o regulă este configurată greșit, ajustați modelul de potrivire, acțiunea de rescriere și destinația. Asigurați-vă că o resursă lipsă nu este rescrisă la o cale existentă care returnează un răspuns non-404. Actualizați secțiunea Erori Personalizate pentru ca cererile 404 să routeze la un fișier html real și verificați că fișierul este implementat cu permisiuni corecte. După modificări, reciclați app pool și testați din diferite medii client pentru a confirma rezultate consistente. Folosiți jurnalele serverului și datele Failed Request Tracing (FRT) pentru a identifica regula exactă și pagina de răspuns finală.

Reproduceți eșecurile cu teste țintite și monitorizați răspunsurile

Recomandare: Reproduceți eroarea 404 cu teste țintite și monitorizați răspunsurile într-un dashboard partajat. Capturați dovezi în accesslog și atribuiți un proprietar pentru fiecare model pentru a accelera remedierea. Această abordare ajută managementul să vadă impactul curent și să prioritizeze corecțiile pe scopuri site.

Exportați ultimele 200 de intrări 404 din accesslog pentru site. Pentru fiecare intrare, înregistrați timpul, IP client, hostname, URL solicitat, referrer, user-agent, status și mărimea răspunsului. Dacă observați active lipsă sub căi înrudite, acest lucru indică modele mai degrabă decât cazuri izolate. Construiți o listă concisă de teste din aceste semnale pentru a face pașii următori.

Testați variații de căi: solicitați URL-uri cunoscute lipsă cu și fără slash final; schimbați cazul segmentelor; adăugați sau eliminați șiruri de interogare; comparați răspunsurile pentru active statice împotriva rutelor dinamice. Includeți atât metode GET, cât și HEAD pentru a confirma că serverul returnează 404 înainte de orice redirecționări sau rescrieri neintenționate.

Folosiți Failed Request Tracing (FRT) când este disponibil și verificați încrucișat cu accesslog pentru aceleași timestamp-uri. Aceste urme indică care regulă sau modul a blocat resursa sau dacă resursa este cu adevărat lipsă. Legați rezultatele la o metrică dashboard: număr de 404-uri pe rută, pe host și pe cont. Această corelație excelentă accelerează investigația și dezvăluie puncte fierbinți curente.

Pentru resurse din spatele unui strat de rescriere sau rutare, verificați web.config înrudit, reguli URL Rewrite și orice configurații asemănătoare htaccess pe care IIS le poate onora prin module de rescriere. Dacă eroarea 404 indică o problemă de mapare, ajustați regula sau calea fișierului, apoi rulați din nou testele pentru a confirma corecția înainte de a trece la producție. În cazuri în care eroarea 404 pointează la o resursă blocată, verificați lista de blocare sau restricțiile de acces și asigurați-vă că se aliniază cu modelele de acces intenționate.

Documentați descoperirile în dashboard și partajați rezumatul cu proprietarul site-ului și managementul. Dacă este necesar, publicați insights pe linkedin pentru vizibilitate cross-team. Procesul ar trebui să fie repetabil: salvați intrările de test, capturați răspunsurile și atașați jurnalele înrudite din accesslog pentru ca ele să poată fi revizuite de proprietarul contului sau echipa de securitate.

Moduri de a îmbunătăți reziliența: construiți un ham de test mic care iterează prin lista de teste, înregistrează codurile de status și semnalează spike-uri. Folosiți aceste semnale pentru a acționa pe active lipsă, actualizați inventarele de conținut și blocați sonde zgomotoase prin IP doar când este justificat. Țineți întotdeauna suita de teste curentă aliniată cu inventarul site-ului și mapările de tip MIME pentru a preveni regresii.

Înainte de orice modificare, asigurați-vă că aveți aprobarea proprietarului și un plan de rollback. Dashboard-ul de monitorizare ongoing ar trebui să indice dacă rata de 404 este stabilă, în creștere sau se întoarce la linia de bază. Un regim de test bine condus accelerează răspunsul la incidente și ajută echipa să livreze o experiență utilizator mai lină.