Dépannage de l'erreur HTTP 404 Non trouvé sur IIS - Guide de l'administrateur système

Activez les erreurs détaillées dans IIS et prenez l'URL demandée exacte, puis comparez-la avec les liaisons de site pour identifier le site ou le vdir concerné. Cette première action révèle souvent si la ressource est manquante, perdue ou réside dans un emplacement différent de votre infrastructure, ce qui vous aide à localiser rapidement le propriétaire du mappage et le chemin correct.

Déterminez si l'erreur 404 provient d'un fichier manquant, d'un répertoire virtuel mal configuré ou d'une redirection pointant vers un emplacement inexistant. Dans le Gestionnaire IIS, inspectez les paramètres vdir et vérifiez le chemin physique sur le disque, puis vérifiez les autorisations sur le dossier afin que le processus de travail puisse continuer sur différents sites. Si vous avez plusieurs sites, répertoriez leurs dossiers racine et les emplacements qu'ils desservent pour éviter toute confusion entre les sites.

Pour les applications Web utilisant des permaliens, assurez-vous que les règles de réécriture d'URL ou les mappages de gestionnaires ne masquent pas une véritable erreur 404 avec une page conviviale. Mettez à jour les règles web.config ou de réécriture d'URL, puis testez le chemin Internet à partir d'un navigateur et des journaux côté serveur pour confirmer que l'URL résultante pointe vers un fichier réel ou un itinéraire valide.

Si la ressource n'est pas présente, créez un espace réservé ou déplacez le fichier vers l'emplacement prévu, ou configurez un itinéraire statique/ASP.NET approprié pour desservir la ressource. Pour chaque site, conservez un enregistrement du propriétaire et de l'emplacement de contenu prévu pour accélérer les identifications futures. Utilisez les permaliens pour vérifier que les URL canoniques correspondent à des ressources existantes, réduisant ainsi les futures erreurs 404 perdues.

Continuez ensuite avec une vérification systématique : vérifiez l'URL accessible via Internet, assurez-vous que le DNS et les en-têtes d'hôte pointent vers le site correct et associez les permaliens à un chemin de fichier réel. Si vous voyez toujours une erreur 404, suivez la requête à partir du journal des requêtes IIS, en identifiant où le chemin est perdu, et ajustez en conséquence, en documentant les modifications pour le propriétaire et l'équipe.

Analysez les journaux IIS pour les modèles d'erreur 404 et les URL ayant échoué

Exportez les journaux IIS les plus récents et filtrez les réponses 404. Recherchez les chemins d'URL fréquents et l'horodatage de la première occurrence pour identifier les problèmes récurrents affectant les personnes qui tentent d'accéder à votre site.

Les modèles dans les erreurs 404 révèlent des causes courantes : ressources manquantes, entrées vdir mal configurées et faute de frappe dans un lien. Certains problèmes proviennent d'un contenu redirigé ou déplacé, tandis que d'autres proviennent de la navigation interne ou de références externes. Enregistrez la valeur vdir dans vos notes pour assurer la cohérence de l'indexation. Créez une liste des principaux contrevenants et suivez les nombres au fil du temps pour distinguer les erreurs occasionnelles des problèmes qui se répètent régulièrement.

Utilisez les champs de référent et d'agent utilisateur pour déterminer si le problème provient d'une recherche, d'autres sites ou de recherches directes. Cela vous aide à prioriser la résolution de la cause profonde et à améliorer l'expérience utilisateur avec moins de frictions.

Exportez une vue conviviale sous forme de tableau des erreurs 404, notamment le chemin d'URL, le nombre, la première occurrence, le référent et les notes. Ce format adapté à l'impression prend en charge la mise à jour des parties prenantes et la maintenance d'une source unique de vérité pour l'optimisation des chemins et de l'indexation.

Chemin d'URL	Statut	Nombre	PremièreOccurrence	Référent	Notes
/images/logo.png	404	120	2025-11-01 08:23:11	https://example.com/home	Fichier manquant sur le disque
/docs/guide.html	404	68	2025-11-02 09:12:05	https://example.com/manuals	Déplacé vers /docs/user-guide.html ; mettre à jour les liens
/shop/vdir/index.html	404	42	2025-11-03 11:01:22	https://example.com/shop/	Mauvaise configuration de VDir ; vérifier le chemin

Actions pour résoudre et prévenir les erreurs 404

Pour les ressources manquantes, restaurez le fichier ou créez une redirection 301 vers l'URL correcte. Pour les vdirs mal configurés, vérifiez le chemin vdir dans le Gestionnaire IIS, vérifiez applicationHost.config et assurez-vous qu'il existe un chemin physique. Pour les erreurs de frappe, corrigez le lien, mettez à jour le contenu de la page et actualisez régulièrement les index de recherche internes.

Imprimez un rapport récapitulatif et partagez-le avec l'équipe de support. Continuez à mettre à jour une liste continue des modifications pour suivre ce qui a fonctionné et ce qui n'a pas fonctionné. Pour plusieurs contrevenants récurrents, implémentez des redirections ciblées et supprimez les liens morts afin de réduire les erreurs futures.

Examinez régulièrement les modèles que vous collectez, optimisez la gestion des erreurs 404 et testez les redirections dans un environnement de préproduction avant d'appliquer les mises à jour à la production. Cette approche minimise les erreurs et aide les personnes à vivre une expérience plus fluide lors de la navigation sur votre site.

Vérifiez les liaisons de site, les en-têtes d'hôte et les répertoires virtuels

Examinez et corrigez immédiatement les liaisons : assurez-vous que l'en-tête d'hôte, l'adresse IP et le port correspondent à la demande du client et que le nom du site correspond à l'URL utilisée.

Vérifications des liaisons

• Ouvrez le Gestionnaire IIS, accédez à Sites > [votre site] > Liaisons. Vérifiez qu'il existe une liaison pour http (et https si utilisé) avec l'adresse IP et le port corrects. Si plusieurs sites partagent la même adresse IP :port, ajoutez une valeur de nom d'hôte (en-tête d'hôte) qui correspond à l'URL actuelle pour acheminer correctement les demandes.

• Testez les demandes avec l'en-tête d'hôte exact : curl -I -H "Host: example.com" http://server/ ou utilisez un navigateur. Si l'erreur 404 persiste, la liaison peut être correcte, mais le chemin d'accès demandé est géré par un autre site.

• Pour https, vérifiez que le certificat correspond au nom d'hôte dans la liaison. Vérifiez le sujet et les SAN et assurez-vous que la liaison utilise le bon certificat sur le port 443. Une incompatibilité peut entraîner des échecs de demandes qui ressemblent à des ressources manquantes.

• Inspectez le DNS et les couches proxy : assurez-vous que la demande entrante porte l'en-tête d'hôte attendu ; une mauvaise configuration du proxy peut entraîner l'arrivée des demandes sur le mauvais site, ce qui génère des erreurs 404 pour les chemins valides.

Répertoires virtuels et configuration du chemin

1. Vérifiez que l'alias de répertoire virtuel existe sous le site ; l'alias doit apparaître sous forme de segment d'URL (par exemple, /files). Passez en revue le chemin physique dans le volet de droite et confirmez que le dossier existe et est accessible par l'identité du pool d'applications.

2. Convertissez en application lorsque le répertoire doit exécuter du code. Cliquez avec le bouton droit sur le répertoire virtuel > Convertir en application, sélectionnez le pool d'applications correct et assurez-vous que l'identité du pool dispose des autorisations de lecture sur le chemin physique.

3. Vérifiez les documents par défaut si vous vous appuyez sur les URL au niveau du répertoire ; assurez-vous qu'il existe un document par défaut valide (index.html, default.aspx, etc.) ou fournissez un chemin de fichier explicite dans vos liens.

4. Passez en revue les règles web.config et les règles de réécriture d'URL qui pourraient rediriger vers un chemin inexistant. Une mauvaise règle peut produire une erreur 404 de ressource manquante pour les pages autrement valides ; ajustez ou supprimez les règles conflictuelles.

5. Validez les autorisations : accordez l'accès en lecture/exécution à IIS_IUSRS et à l'identité du pool d'applications sur le chemin physique, et vérifiez que les listes de contrôle d'accès NTFS autorisent l'accès pour l'utilisateur attendu. Les autorisations manquantes provoquent souvent des erreurs 404 qui donnent l'impression que le contenu a disparu.

6. Testez à nouveau après les modifications : demandez l'URL problématique et confirmez une redirection 200 ou appropriée ; si une redirection se boucle ou qu'une ressource reste manquante, passez en revue les règles de réécriture et les journaux de démarrage dans le pool d'applications.

Utilisez une exploration de base pour découvrir le problème actuel concernant les pages manquantes causées par les liaisons ou les répertoires virtuels. Recherchez à l'aide de grep dans les journaux IIS les entrées 404 pour trouver les requêtes qui échouent, puis corrigez la cause profonde et testez à nouveau dans une nouvelle exploration. Enregistrez les résultats et partagez un résumé concis avec les administrateurs et les collègues sur LinkedIn pour que tout le monde reste aligné pendant que vous gérez le problème.

Validez les chemins de fichiers, l'existence physique et les autorisations de fichiers

Vérifiez le chemin physique du site dans le Gestionnaire IIS et assurez-vous que le chemin existe sur le disque. Dans Paramètres de base du site ou du répertoire virtuel, confirmez que le dossier vers lequel vous pointez contient le contenu que vous attendez. Si le chemin a changé, restaurez l'emplacement d'origine ou corrigez le mappage dans le composant logiciel enfichable afin que les demandes pointent vers le bon dossier ; sinon, IIS ne charge rien et vous voyez des erreurs 404.

Confirmez que le fichier existe réellement sur le système de fichiers et que l'identité du pool d'applications a le droit de le parcourir et de le lire. Utilisez l'Explorateur de fichiers ou icacls pour vérifier les listes de contrôle d'accès sur le dossier et tous les dossiers parents. Accordez les droits Lire, Lister le contenu du dossier et Traverser à l'identité du pool d'applications (par exemple IIS APPPOOLVotrePoolApp) sur la racine du contenu et les fichiers qu'elle contient. Si les autorisations sont incorrectes, IIS indique un refus d'accès et le moteur peut renvoyer une erreur 404 même si le fichier existe. Ajustez les listes de contrôle d'accès de manière appropriée et testez à nouveau. Si vous n'êtes pas sûr, attribuez temporairement l'accès en lecture à un utilisateur connu pour confirmer que le fichier se charge.

Vérifiez le mappage de type MIME pour les extensions que vous desservez. Ouvrez le type MIME pour le site et assurez-vous que l'extension a un type MIME associé ; les mappages manquants génèrent souvent une erreur 404. Si nécessaire, ajoutez des types courants (.html, .css, .js, images, polices) et vérifiez que le type de contenu correct est envoyé. Vérifiez également que les URL de style permalien se chargent à partir du dossier correct ; une inadéquation entre l'itinéraire permalien et le chemin physique peut déclencher une erreur 404 pour les ressources statiques et dynamiques.

Passez en revue les paramètres d'autorisation de la demande du site. Dans le composant logiciel enfichable, accédez aux Règles d'autorisation du site et assurez-vous que l'identité du client est autorisée à lire le dossier demandé. Si une règle de refus bloque le fichier, le moteur peut renvoyer une erreur 404 pour certains chemins ; la suppression de la règle ou sa réduction aide. Confirmez que l'authentification anonyme est activée si vous vous appuyez sur l'accès public et vérifiez les paramètres au niveau du domaine ou du site si plusieurs sites partagent la même racine de contenu.

Activez et vérifiez les journaux et le traçage. Activez le traçage des demandes ayant échoué pour les erreurs 404 ou passez en revue les journaux IIS pour identifier le nombre d'accès et l'adresse demandant l'accès. Recherchez l'URL exacte, le chemin mappé et le chemin de fichier du moteur ; ces données d'identification aident à localiser la source. Utilisez les informations pour restaurer un chemin correct, corriger l'ordre de chargement et prévenir les récurrences frustrantes. Sur les sites accessibles via Internet, vérifiez que les profils de domaine et le chemin physique sont alignés ; une petite inadéquation peut casser l'accès pour plusieurs sites. Après les modifications, recyclez le pool d'applications pour appliquer les nouveaux mappages et autorisations. Si vous corrigez une erreur 404 de manière cohérente, corrigez d'abord la cause profonde, puis vérifiez le parcours utilisateur sur tous les sites.

Passez en revue les règles de réécriture d'URL et les configurations d'erreurs personnalisées

Exportez les règles de réécriture d'URL actuelles d'IIS pour chaque site et comparez-les à une base de référence de qualité connue pour identifier les erreurs de configuration qui entraînent des résultats 404. Cela révélera si le problème provient d'une URL réécrite, d'une ressource manquante ou d'un chemin d'erreur personnalisé incorrect.

Ce qu'il faut inspecter

Localisez les règles dans web.config ou via le module de réécriture d'URL pour chaque site. Passez en revue le modèle et les conditions qui déclenchent une réécriture ou une redirection et vérifiez que l'URL cible pointe vers une ressource existante ou une page html appropriée définie dans Erreurs personnalisées. Confirmez que l'entrée 404 est définie et que le chemin utilisé par la page d'erreur existe sous la racine du site. Recherchez les conflits entre les sites partageant un seul pool d'applications qui mappent les mêmes chemins.

Vérifiez l'ordre d'évaluation : la première règle correspondante arrête tout traitement ultérieur. Recherchez les règles entrantes ou sortantes qui peuvent capturer une erreur 404 avant que le gestionnaire d'erreurs personnalisées ne s'exécute et assurez-vous qu'il existe une page 404 de secours à l'emplacement configuré. Passez en revue les paramètres globaux ou au niveau du site qui peuvent remplacer la configuration par site.

Comment appliquer les correctifs

Si une règle est mal configurée, ajustez le modèle de correspondance, l'action de réécriture et la destination. Assurez-vous qu'une ressource manquante n'est pas réécrite vers un chemin existant qui renvoie une réponse autre que 404. Mettez à jour la section Erreurs personnalisées afin que les requêtes 404 soient acheminées vers un fichier html réel et vérifiez que le fichier est déployé avec les autorisations correctes. Après les modifications, recyclez le pool d'applications et testez à partir de différents environnements clients pour confirmer des résultats cohérents. Utilisez les journaux du serveur et les données de traçage des demandes ayant échoué (FRT) pour identifier la règle exacte et la page de réponse finale.

Reproduisez les échecs avec des tests ciblés et surveiller les réponses

Recommandation : reproduisez l'erreur 404 avec des tests ciblés et surveiller les réponses dans un tableau de bord partagé. Capturez les preuves dans le journal d'accès et attribuez un propriétaire pour chaque modèle afin d'accélérer la correction. Cette approche aide la direction à voir l'impact actuel et à prioriser les correctifs sur l'ensemble des étendues de site.

Exportez les 200 dernières entrées 404 du journal d'accès pour le site. Pour chaque entrée, enregistrez l'heure, l'adresse IP du client, le nom d'hôte, l'URL demandée, le référent, l'agent utilisateur, le statut et la taille de la réponse. Si vous observez des ressources manquantes sous les chemins associés, cela indique des modèles plutôt que des cas isolés. Créez une liste de tests concise à partir de ces signaux pour passer aux étapes suivantes.

Variations des chemins de test : demandez les URL manquantes connues avec et sans barre oblique finale ; modifiez la casse des segments ; ajoutez ou supprimez les chaînes de requête ; comparez les réponses pour les ressources statiques avec les itinéraires dynamiques. Incluez les méthodes GET et HEAD pour confirmer que le serveur renvoie une erreur 404 avant que des redirections ou des réécritures involontaires ne se produisent.

Utilisez le traçage des demandes ayant échoué (FRT) lorsqu'il est disponible et croisez-le avec le journal d'accès pour les mêmes horodatages. Ces traces indiquent quelle règle ou quel module a bloqué la ressource, ou si la ressource est réellement manquante. Liez les résultats à une métrique de tableau de bord : nombre d'erreurs 404 par itinéraire, par hôte et par compte. Cette excellente corrélation accélère l'analyse et révèle les points chauds actuels.

Pour les ressources derrière une couche de réécriture ou de routage, vérifiez web.config, les règles de réécriture d'URL et toutes les configurations de type htaccess associées qu'IIS pourrait respecter via les modules de réécriture. Si l'erreur 404 indique un problème de mappage, ajustez la règle ou le chemin du fichier, puis réexécutez les tests pour confirmer le correctif avant de passer à la production. Dans les cas où l'erreur 404 pointe vers une ressource bloquée, vérifiez la liste de blocage ou les restrictions d'accès et assurez-vous qu'elles correspondent aux modèles d'accès prévus.

Documentez les résultats dans le tableau de bord et partagez le résumé avec le propriétaire du site et la direction. Si nécessaire, publiez des informations sur LinkedIn pour la visibilité inter-équipes. Le processus doit être répétable : enregistrez les entrées de test, capturez les réponses et joignez les journaux associés à partir du journal d'accès afin qu'ils puissent être examinés par le propriétaire du compte ou l'équipe de sécurité.

Méthodes pour améliorer la résilience : créez un petit harnais de test qui itère dans la liste de tests, enregistre les codes de statut et signale les pics. Utilisez ces signaux pour agir sur les ressources manquantes, mettre à jour les inventaires de contenu et bloquer les probes bruyantes par adresse IP uniquement lorsque cela est justifié. Veillez toujours à ce que la suite de tests actuelle soit alignée sur l'inventaire du site et les mappages de type MIME pour éviter les régressions.

Avant toute modification, assurez-vous d'avoir l'approbation du propriétaire et un plan de restauration. Le tableau de bord de surveillance continue doit indiquer si le taux de 404 est stable, en hausse ou revient à la base de référence. Un régime de test bien géré accélère la réponse aux incidents et aide l'équipe à offrir une expérience utilisateur plus fluide.