Risoluzione dei problemi HTTP 404 Non trovato su IIS - Una guida per l'amministratore di sistema

Abilita gli errori dettagliati in IIS e prendi l'URL richiesto esatto, quindi confrontalo con i binding del sito per identificare quale sito o vdir è previsto. Questa prima azione spesso rivela se la risorsa è mancante, persa o risiede in una posizione diversa nella tua infrastruttura, aiutandoti a localizzare rapidamente il proprietario del mapping e il percorso corretto.

Identifica se il 404 deriva da un file mancante, una directory virtuale configurata male o un redirect che punta a una posizione inesistente. In Gestione IIS, ispeziona le impostazioni della vdir e verifica il percorso fisico su disco, quindi controlla i permessi sulla cartella in modo che il processo worker possa continuare su diversi siti. Se hai diversi siti, elenca le loro cartelle radice e le posizioni che servono per prevenire confusione tra siti.

Per le app web che utilizzano permalink, assicurati che le regole di URL rewriting o i handler mappings non mascherino un vero 404 con una pagina amichevole. Aggiorna il web.config o le regole di URL rewrite, quindi testa il percorso internet da un browser e dai log server-side per confermare che l'URL risultante risolva in un file effettivo o un percorso valido.

Se la risorsa non è presente, crea un segnaposto o sposta il file nella posizione prevista, o configura un percorso statico/ASP.NET appropriato per servire la risorsa. Per ciascun sito, mantieni un record del proprietario e della posizione del contenuto previsto per accelerare le identificazioni future. Usa i permalink per verificare che gli URL canonici mappino su risorse esistenti, riducendo i futuri 404 persi.

Quindi continua con una verifica sistematica: controlla l'URL rivolto a internet, assicurati che DNS e header host puntino al sito corretto e mappa i permalink a un percorso file reale. Se vedi ancora un 404, traccia la richiesta dal log delle richieste IIS, identificando dove il percorso è perso, e adatta di conseguenza, documentando le modifiche per il proprietario e il team.

Analizza i log IIS per pattern di 404 e URL falliti

Esporta gli ultimi log IIS e filtra per risposte 404. Cerca percorsi URL frequenti e il timestamp del primo avvistamento per individuare problemi ricorrenti che influenzano le persone che cercano di raggiungere il tuo sito.

I pattern nei 404 rivelano cause comuni: risorse mancanti, voci vdir configurate male e un errore di battitura in un link. Alcuni problemi originano da contenuti reindirizzati o spostati, mentre altri provengono da navigazione interna o riferimenti esterni. Registra il valore vdir nelle tue note per mantenere l'indicizzazione coerente. Crea un elenco dei principali colpevoli e traccia i conteggi nel tempo per distinguere i mancanti occasionali dai problemi che si ripetono regolarmente.

Usa i campi referrer e user-agent per valutare se il problema proviene da ricerche, altri siti o ricerche dirette. Questo ti aiuta a dare priorità alla risoluzione della causa principale e a migliorare l'esperienza utente con meno attriti.

Esporta una vista compatibile con tabella dei 404, inclusi percorso URL, conteggio, primo avvistamento, referrer e note. Questo formato stampabile supporta l'aggiornamento degli stakeholder e il mantenimento di una singola fonte di verità per ottimizzare i percorsi e l'indicizzazione.

Percorso URL	Stato	Conteggio	Primo Avvistamento	Referrer	Note
/images/logo.png	404	120	2025-11-01 08:23:11	https://example.com/home	File mancante su disco
/docs/guide.html	404	68	2025-11-02 09:12:05	https://example.com/manuals	Spostato in /docs/user-guide.html; aggiorna i link
/shop/vdir/index.html	404	42	2025-11-03 11:01:22	https://example.com/shop/	Misconfigurazione VDir; verifica il percorso

Azioni per risolvere e prevenire i 404

Per le risorse mancanti, ripristina il file o crea un redirect 301 all'URL corretto. Per le vdir configurate male, verifica il percorso vdir in Gestione IIS, controlla applicationHost.config e assicurati che esista un percorso fisico. Per gli errori di battitura, correggi il link, aggiorna il contenuto sulla pagina e rinfresca regolarmente gli indici di ricerca interni.

Stampa un report riassuntivo e condividilo con il team di supporto. Continua ad aggiornare un elenco in corso delle modifiche per tracciare cosa ha funzionato e cosa no. Per più colpevoli frequenti, implementa redirect mirati e rimuovi i link morti per ridurre gli errori futuri.

Esamina regolarmente i pattern che raccogli, ottimizzando la gestione dei 404, e testa i redirect in un ambiente di staging prima di applicare gli aggiornamenti alla produzione. Questo approccio minimizza gli errori e aiuta le persone ad avere un'esperienza più fluida quando navigano nel tuo sito.

Verifica binding del sito, header host e directory virtuali

Esamina e correggi i binding immediatamente: assicurati che l'header host, IP e porta corrispondano alla richiesta del client e che il nome del sito corrisponda all'URL in uso.

Controlli dei binding

• Apri Gestione IIS, naviga a Siti > [il tuo sito] > Binding. Verifica che ci sia un binding per http (e https se usato) con l'IP e la porta corretti. Se più siti condividono lo stesso IP:porta, aggiungi un valore nome host (header host) che corrisponda all'URL corrente per instradare correttamente le richieste.

• Testa le richieste con l'esatto header host: curl -I -H "Host: example.com" http://server/ o usa un browser. Se il 404 persiste, il binding potrebbe essere corretto ma il percorso richiesto è gestito da un altro sito.

• Per https, verifica che il certificato corrisponda al nome host nel binding. Controlla il soggetto e i SAN, e assicurati che il binding usi il certificato giusto sulla porta 443. Una mancata corrispondenza può portare a richieste fallite che sembrano risorse mancanti.

• Ispeziona DNS e layer proxy: assicurati che la richiesta in arrivo porti l'header host previsto; una misconfigurazione proxy può causare che le richieste atterrino sul sito sbagliato, producendo 404 per percorsi validi.

Directory virtuali e configurazione del percorso

1. Verifica che l'alias della directory virtuale esista sotto il sito; l'alias dovrebbe apparire come un segmento URL (ad esempio /files). Esamina il percorso fisico nel pannello destro e conferma che la cartella esista ed è accessibile dall'identità del pool di applicazioni.

2. Converti in Applicazione quando la directory dovrebbe eseguire codice. Clic destro sulla directory virtuale > Converti in Applicazione, seleziona il Pool di Applicazioni corretto e assicurati che l'identità del pool abbia permessi di lettura sul percorso fisico.

3. Controlla i documenti predefiniti se ti affidi su URL a livello di directory; assicurati che ci sia un documento predefinito valido (index.html, default.aspx, ecc.) o fornisci un percorso file esplicito nei tuoi link.

4. Esamina le regole web.config e le riscritture URL che potrebbero reindirizzare in un percorso inesistente. Una regola cattiva può produrre un 404 di risorsa mancante per pagine altrimenti valide; adatta o rimuovi regole conflittuali.

5. Valida i permessi: concedi lettura/esecuzione a IIS_IUSRS e all'identità del pool di applicazioni sul percorso fisico, e verifica che gli ACL NTFS permettano l'accesso per l'utente previsto. I permessi mancanti spesso causano 404 che sembrano contenuti spariti.

6. Testa di nuovo dopo le modifiche: richiedi l'URL problematico e conferma un 200 o un redirect appropriato; se un redirect si cicla o una risorsa rimane mancante, esamina le regole di riscrittura e i log di avvio nel pool di applicazioni.

Usa un crawl di base per scoprire il problema attuale riguardo alle pagine mancanti causate da binding o directory virtuali. grep attraverso i log IIS per voci 404 per trovare quali richieste stanno fallendo, quindi affronta la causa principale e testa di nuovo in un crawl fresco. Salva i risultati e condividi un riassunto conciso con amministratori e colleghi su LinkedIn per mantenere tutti allineati mentre gestisci il problema.

Valida percorsi file, esistenza fisica e permessi file

Verifica il Percorso Fisico del sito in Gestione IIS e assicurati che il percorso esista su disco. Nelle Impostazioni Base per il sito o la directory virtuale, conferma che la cartella a cui punti contenga il contenuto che ti aspetti. Se il percorso è cambiato, ripristina la posizione originale o correggi il mapping nel snap-in in modo che le richieste indirizzino la cartella giusta; altrimenti IIS non carica nulla e vedi 404.

Conferma che il file esista effettivamente sul filesystem e che l'identità del pool di applicazioni abbia i diritti di attraversare e leggerlo. Usa Esplora File o icacls per verificare gli ACL sulla cartella e tutte le cartelle genitore. Concedi Lettura e Elenca Contenuti Cartella e Attraversa all'identità del pool di applicazioni (ad esempio IIS APPPOOLYourAppPool) sulla radice del contenuto e sui file all'interno. Se i permessi sono incorretti, IIS indica negazione di accesso e il motore potrebbe restituire 404 anche quando il file esiste. Adatta gli ACL appropriatamente e ritesta. Se non sei sicuro, assegna temporaneamente accesso di lettura a un utente noto per confermare che il file si carica.

Controlla il mapping dei tipi MIME per le estensioni che servi. Apri il tipo MIME per il sito e assicurati che l'estensione abbia un tipo MIME associato; i mapping mancanti spesso producono un 404. Se necessario, aggiungi tipi comuni (.html, .css, .js, immagini, font) e verifica che il content-type corretto sia inviato. Verifica anche che gli URL di stile permalink si carichino dalla cartella corretta; una mancata corrispondenza tra rotta permalink e percorso fisico può attivare 404 per asset statici e dinamici.

Esamina le impostazioni di autorizzazione delle richieste del sito. Nel snap-in, naviga alle Regole di Autorizzazione del sito e assicurati che l'identità del client sia autorizzata a leggere la cartella richiesta. Se una regola di negazione blocca il file, il motore potrebbe restituire 404 per alcuni percorsi; rimuovere la regola o restringerla aiuta. Conferma che l'Autenticazione Anonima sia abilitata se ti affidi sull'accesso pubblico, e controlla le impostazioni a livello di dominio o sito se più siti condividono la stessa radice di contenuto.

Abilita e controlla log e tracciamento. Attiva il Tracciamento Richieste Fallite per errori 404 o esamina i log IIS per identificare il numero di hit e l'indirizzo richiedente. Cerca l'URL esatto, il percorso mappato e il percorso file dal motore; questi dati identificativi aiutano a localizzare la fonte. Usa le informazioni per ripristinare un percorso corretto, correggere l'ordine di caricamento e prevenire ricorrenze frustranti. Sui siti rivolti a internet, verifica che i profili di dominio e il percorso fisico siano allineati; una piccola mancata corrispondenza può rompere l'accesso per più siti. Dopo le modifiche, ricicla il pool di applicazioni per applicare i nuovi mapping e permessi. Se stai affrontando un 404 in modo consistente, affronta prima la causa principale e poi verifica il percorso utente su tutti i siti.

Esamina le regole di URL Rewrite e le configurazioni di Errori Personalizzati

Esporta le regole correnti di URL Rewrite da IIS per ciascun sito e confrontale con una baseline nota-good per individuare misconfigurazioni che portano a risultati 404. Questo rivelerà se il problema origina in un URL riscritto, una risorsa mancante o un percorso di errore personalizzato improprio.

Cosa ispezionare

Individua le regole in web.config o tramite il modulo URL Rewrite per ciascun sito. Esamina il pattern e le condizioni che attivano una riscrittura o un redirect, e verifica che l'URL target punti a una risorsa esistente o a una pagina html appropriata definita negli Errori Personalizzati. Conferma che la voce 404 sia definita e che il percorso usato dalla pagina di errore esista sotto la radice del sito. Controlla conflitti tra siti che condividono un singolo pool di applicazioni che mappano gli stessi percorsi.

Audit l'ordine di valutazione: la prima regola corrispondente ferma l'ulteriore elaborazione. Cerca regole inbound o outbound che potrebbero catturare un 404 prima che il gestore di errore personalizzato si esegua, e assicurati che ci sia una pagina 404 di fallback nella posizione configurata. Esamina eventuali impostazioni globali o a livello di sito che potrebbero sovrascrivere la configurazione per sito.

Come applicare le correzioni

Se una regola è configurata male, adatta il pattern di corrispondenza, l'azione di riscrittura e la destinazione. Assicurati che una risorsa mancante non venga riscritta in un percorso esistente che restituisce una risposta non-404. Aggiorna la sezione Errori Personalizzati in modo che le richieste 404 si dirigano a un file html reale e verifica che il file sia distribuito con permessi corretti. Dopo le modifiche, ricicla il pool di applicazioni e testa da diversi ambienti client per confermare risultati consistenti. Usa i log del server e i dati di Tracciamento Richieste Fallite (FRT) per identificare la regola esatta e la pagina di risposta finale.

Riproduci i fallimenti con test mirati e monitora le risposte

Raccomandazione: Riproduci il 404 con test mirati e monitora le risposte in una dashboard condivisa. Cattura evidenze nel accesslog e assegna un proprietario per ciascun pattern per accelerare la remediation. Questo approccio aiuta la gestione a vedere l'impatto attuale e a dare priorità alle correzioni su scope di siti.

Esporta le ultime 200 voci 404 dall'accesslog per il sito. Per ciascuna voce, registra tempo, IP client, hostname, URL richiesto, referrer, user-agent, stato e dimensione risposta. Se osservi asset mancanti sotto percorsi correlati, questo indica pattern piuttosto che casi isolati. Crea un elenco di test conciso da questi segnali per intraprendere i prossimi passi.

Testa variazioni di percorsi: richiedi URL noti mancanti con e senza slash finale; cambia il case dei segmenti; aggiungi o rimuovi stringhe di query; confronta le risposte per asset statici contro rotte dinamiche. Includi sia metodi GET che HEAD per confermare che il server restituisca 404 prima di qualsiasi redirect o riscrittura non intenzionale.

Usa il Tracciamento Richieste Fallite (FRT) quando disponibile, e confronta con l'accesslog per gli stessi timestamp. Queste tracce indicano quale regola o modulo ha bloccato la risorsa, o se la risorsa è veramente mancante. Lega i risultati a una metrica dashboard: conteggio di 404 per rotta, per host e per account. Questa eccellente correlazione accelera l'indagine e rivela hotspot attuali.

Per risorse dietro un layer di riscrittura o routing, controlla web.config correlato, regole URL Rewrite e eventuali configurazioni simili a htaccess che IIS potrebbe onorare tramite moduli di riscrittura. Se il 404 indica un problema di mapping, adatta la regola o il percorso file, quindi riesegui i test per confermare la correzione prima di passare alla produzione. Nei casi in cui il 404 punta a una risorsa bloccata, verifica l'elenco di blocchi o restrizioni di accesso e assicurati che siano allineati con i pattern di accesso previsti.

Documenta le scoperte nella dashboard e condividi il riassunto con il proprietario del sito e la gestione. Se necessario, pubblica insight su LinkedIn per visibilità cross-team. Il processo dovrebbe essere ripetibile: salva gli input di test, cattura le risposte e allega log correlati dall'accesslog in modo che possano essere esaminati dal proprietario dell'account o dal team di sicurezza.

Modi per migliorare la resilienza: crea un piccolo harness di test che itera attraverso l'elenco di test, registra codici di stato e flagga picchi. Usa questi segnali per agire su asset mancanti, aggiornare inventari di contenuto e bloccare probe rumorose per IP solo quando giustificato. Mantieni sempre la suite di test corrente allineata con l'inventario del sito e i mapping dei tipi MIME per prevenire regressioni.

Prima di qualsiasi modifica, assicurati di avere l'approvazione del proprietario e un piano di rollback. La dashboard di monitoraggio in corso dovrebbe indicare se il tasso di 404 è stabile, in aumento o torna al baseline. Un regime di test ben gestito accelera la risposta agli incidenti e aiuta il team a fornire un'esperienza utente più fluida.