Le scan Wordfence s’arrête : identifier l’étape et reprendre un diagnostic ciblé

Distinguer un scan incomplet d’un écran qui ne se rafraîchit plus

Wordfence annonce Scan Failed, s’arrête sur une étape ou cesse d’afficher de nouveaux éléments. Le problème peut concerner le lancement du travail, une étape qui s’interrompt ou seulement l’affichage de progression. Un onglet resté longtemps sans activité ne permet pas de distinguer ces situations.

Le scanner effectue plusieurs traitements et peut relancer des processus pour poursuivre son travail. Une réponse HTTP 200 à l’une de ses requêtes ne prouve pas que tout le scan s’est achevé. De même, quelques fichiers contrôlés avant l’arrêt ne couvrent pas nécessairement tout le périmètre attendu.

Le résultat recherché est une exécution qui atteint son terme, ou une preuve précise de l’étape qui échoue pour permettre une correction ciblée. Nous conservons d’abord l’état existant, puis choisissons un seul parcours de diagnostic. Relancer plusieurs scans, augmenter toutes les limites ou effacer les données du plugin ferait perdre de la précision et pourrait ajouter de la charge sans expliquer l’arrêt.

Vérifier le produit et le périmètre de l’intervention

Ce parcours suppose Wordfence Security déjà installé et un compte autorisé à consulter ses diagnostics. La version vérifiée est 9.0.2 de Mark Maunder, avec WordPress 4.7 et PHP 7.0 minimum et des essais déclarés jusqu’à WordPress 7.1.4. Il n’est pas nécessaire d’installer un second scanner pour comprendre ce premier échec.

Repérez si le scan appartient à la production, à une copie ou à un site d’un réseau. Une copie peut avoir une protection d’accès et un trajet réseau différents. Son résultat aide à reproduire un problème, mais il ne décrit pas automatiquement les possibilités de connexion de la production.

Le dépannage d’un scanner n’est pas un nettoyage de site. Si des signes d’intrusion existent, préservez les preuves et préparez une prise en charge distincte pendant l’analyse. Ne supposez pas que le scan arrêté a causé ces signes, ni qu’un scan ensuite terminé établira à lui seul l’intégrité du site. Nous allons ici rétablir ou documenter l’exécution du contrôle, sans supprimer de fichier signalé ni modifier du contenu pour tester le scanner.

Conserver le journal et la dernière étape avant de relancer

Dans Wordfence > Scan, relevez le message final, le dernier horodatage et le nombre d’éléments examinés. Conservez le journal d’activité déjà disponible, avec quelques lignes précédant l’arrêt. Une capture du seul pourcentage ne dit pas quel traitement était en cours.

Notez les versions, le créneau, les réglages particuliers et les changements récents. Gardez ces éléments dans un dossier privé ; les journaux peuvent contenir des chemins ou des informations sur l’architecture. Il n’est pas nécessaire de publier un rapport complet ni d’envoyer des identifiants pour commencer ce relevé.

Si le message exact est « Scan rate limit reached for this license key », vérifiez en privé si la même clé a été réutilisée sur le site et une copie. C’est un problème distinct d’un délai PHP. Faites confirmer les affectations par le responsable des licences ; ne publiez pas la clé et ne modifiez pas les limites d’exécution pour contourner ce message.

1. Confirmez qu’aucun autre scan n’est encore en cours avant de proposer une nouvelle tentative.
2. Notez si l’arrêt précède le premier élément contrôlé ou survient pendant une analyse précise.
3. Sauvegardez l’état des options que vous envisagez de modifier.
4. Préparez un créneau et une copie adaptée pour les essais possibles.
5. Si une opération réelle est déjà en cours ou déjà planifiée, conservez les preuves disponibles et faites décider sa reprise par le responsable. Une collecte documentaire ne demande pas de relancer le site.

Lire les contrôles sans interpréter chaque échec comme une cause

Ouvrez Wordfence > Tools > Diagnostics et examinez les contrôles liés aux connexions, au retour vers le site et aux ressources utiles au créneau concerné. Un test positif maintenant ne décrit pas nécessairement l’état lors du scan précédent. Un avertissement isolé n’est pas non plus une explication automatique de l’arrêt.

La rubrique Log Files peut proposer des journaux PHP découverts par le produit. Sinon, consultez ceux du domaine dans le panneau d’hébergement. Recherchez le même instant : erreur fatale, mémoire épuisée, requête SQL refusée ou interruption du service demandent des corrections différentes.

Conservez le premier message significatif et son contexte. Les valeurs affichées dans un terminal peuvent différer du PHP Web qui exécute le scan ; faites confirmer la version et les limites de ce contexte. N’ajoutez pas une page publique de configuration pour compléter le relevé. Le résultat attendu de cette étape est une hypothèse appuyée par une trace, ou l’identification précise des informations manquantes. Une série de cases vertes ne remplace pas le journal du processus qui s’est réellement arrêté.

Traiter un lancement qui n’atteint pas le scanner

Si aucun élément n’est examiné, le lancement ou la reprise du processus mérite d’être vérifié avant les limites d’analyse de fichiers. Wordfence utilise normalement une requête du serveur vers le site pour déclencher son travail. Une authentification d’environnement, une règle serveur ou une résolution incorrecte peut interrompre ce trajet.

Faites rechercher la requête exacte au créneau relevé, son adresse, son statut et la couche qui répond. Une page de protection renvoyée avec un statut 200 peut rester différente de la réponse attendue. Le seul statut ne démontre donc pas que le processus a reçu ce qu’il fallait.

Corrigez l’intégration du déclenchement avec la protection existante. N’ouvrez pas tout wp-admin au public et ne retirez pas le mot de passe d’une copie contenant des données privées. Le responsable doit prévoir un accès interne légitime qui conserve la protection. Si la requête n’atteint pas PHP, modifier la mémoire du scanner n’est pas le bon premier levier. Après correction, une tentative autorisée doit montrer que le lancement dépasse son point de blocage ; elle ne valide pas encore toutes les étapes suivantes.

Tester le lancement distant seulement pour ce besoin

Wordfence propose un mécanisme distant lorsque le serveur ne parvient pas à déclencher le scan par sa connexion habituelle. Le site contacte alors le service Wordfence, qui revient lancer le travail avec un jeton prévu pour cet usage. Ce réglage change le trajet de démarrage, pas le budget de toutes les étapes.

Cette voie convient si la destination est accessible selon la politique de l’hébergement et si le diagnostic indique un problème de lancement. Une copie entièrement privée peut ne pas accepter ce retour externe ; il ne faut pas l’exposer uniquement pour faire passer le test.

1. Notez l’état initial de Wordfence > Tools > Diagnostics > Debugging Options.
2. Dans le créneau autorisé, activez uniquement Start all scans remotely puis enregistrez.
3. Lancez une seule tentative préparée et relevez si le démarrage franchit l’étape précédente.
4. Si cela ne change rien, remettez le réglage initial avant un autre essai.
5. Si le démarrage fonctionne, vérifiez la suite du scan et documentez la cause réseau restante. Ne désactivez pas la vérification SSL ni une protection entière pour conserver ce résultat.

Adapter la durée des étapes quand une limite est confirmée

Dans Wordfence > Scan > Scan Options and Scheduling > Performance Options, Maximum execution time for each scan stage contrôle le travail avant sa reprise par une nouvelle requête. Ce réglage n’est pas la durée totale autorisée pour tout le scan.

Si le journal ou le prestataire confirme une interruption liée à la durée d’un processus, choisissez un budget d’étape inférieur aux limites effectives. La documentation propose notamment un essai à 15 secondes ; cette valeur n’est pertinente que si l’environnement lui laisse cette marge. Une valeur très basse multiplie les reprises et peut elle-même ajouter du travail.

Le champ Time limit that a scan can run in seconds fixe la durée totale du scan ; il est distinct du maximum par étape. Si le journal dit que le scan a dépassé sa durée totale, le réglage de quinze secondes par étape ne traite pas à lui seul cette cause. Relevez le champ total, le volume parcouru et les limites de l’hébergement avant de convenir d’une valeur adaptée. Gardez le réglage initial pour le retour arrière.

1. Relevez la valeur initiale et les limites du contexte PHP Web ainsi que celles du service.
2. Dans le créneau préparé, changez uniquement la durée par étape vers une valeur justifiée, par exemple 15 secondes lorsque les limites confirmées sont supérieures.
3. Enregistrez avec Save Changes et autorisez une seule tentative.
4. Comparez l’étape atteinte, la fin du scan et les ressources utilisées.
5. Si le test n’apporte rien, remettez la valeur initiale. Ne rendez pas les processus illimités et n’ajoutez pas une directive serveur générale pour empêcher leur interruption sans analyse de son périmètre.

Réduire les pointes de charge sans masquer des contrôles

Use low-resource scanning répartit le travail sur une durée plus longue. Ce mode peut convenir lorsque le scan crée des pointes de ressources ; il n’est pas une réparation universelle d’une connexion ou d’un processus qui ne démarre pas. Conservez sa valeur initiale et testez-le séparément d’un changement de durée d’étape.

Dans Scan Options and Scheduling > Performance Options, activez cette option sur le périmètre préparé puis observez une tentative autorisée. Vérifiez que le budget total du scan reste adapté : étaler le travail ne garantit pas qu’il finira avant une limite globale déjà trop courte. Ne déclarez pas le problème résolu parce que le site paraît moins chargé pendant quelques minutes.

Si le journal indique une mémoire épuisée, le champ How much memory should Wordfence request when scanning ne réserve pas automatiquement cette mémoire et ne peut pas dépasser toutes les contraintes du prestataire. Faites confirmer une valeur compatible avec les ressources réellement disponibles. Ne retirez pas arbitrairement des catégories de détection pour obtenir un message de fin. Toute réduction du périmètre doit être explicite, justifiée et mentionnée dans le résultat du contrôle.

Activer un journal détaillé pour une seule enquête préparée

Quand l’état existant ne permet pas d’identifier l’arrêt, Wordfence propose une collecte plus détaillée. Elle augmente les écritures et la charge ; elle ne doit pas devenir un réglage permanent ni être activée en parallèle d’une série d’autres changements.

Préparez le créneau et le moyen de récupérer le journal en privé. Conservez aussi les journaux PHP et serveur disponibles, car le scanner peut ne pas enregistrer sa propre interruption. Une absence de message dans son activité n’exclut pas une limite appliquée en dehors du plugin.

1. Dans Tools > Diagnostics > Debugging Options, notez l’état d’Enable debugging mode.
2. Activez temporairement ce seul réglage et enregistrez.
3. Effectuez une unique tentative autorisée dans le contexte préparé.
4. Conservez l’activité détaillée de la page Scan avec son heure et sa dernière étape.
5. Rétablissez immédiatement le réglage initial et rangez l’extrait utile en privé.
6. Transmettez seulement les informations nécessaires au diagnostic. N’envoyez pas le rapport complet par un bouton d’email sans avoir identifié le destinataire et vérifié son contenu.

Isoler un conflit seulement si une trace le justifie

Si une erreur cite un composant précis, comparez sa version et sa configuration sur une copie avant de changer toute l’installation. Une extension active au moment de l’échec n’est pas automatiquement responsable. Le premier message pertinent, le fichier cité et la chronologie orientent l’isolement.

Une copie doit conserver les caractéristiques nécessaires au problème : même contexte PHP, mêmes fichiers utiles et, lorsque le lancement est en cause, un trajet réseau comparable. Neutralisez ses effets externes et protégez ses données. Ne copiez pas simplement une production sensible vers un domaine ouvert pour faciliter le scan.

Désactivez uniquement le composant confirmé comme piste sur cette copie, conservez son état initial puis comparez un essai autorisé. Si le défaut disparaît, recherchez un réglage compatible ou un correctif officiel ; cela reste un indice à confirmer avant intervention en production. Ne supprimez pas les tables Wordfence et ne réinitialisez pas tous ses paramètres pour obtenir une installation apparemment neuve. Vous perdriez la comparaison et les réglages de sécurité sans savoir quelle différence a réellement changé le comportement.

Vérifier la fin et le périmètre du scan

Après un changement utile, vérifiez que l’exécution atteint son terme et conserve les contrôles prévus. Un scan dont des catégories ont été exclues ne couvre pas le même périmètre que le scan initial. Le résultat doit mentionner cette différence plutôt que promettre que tout a été contrôlé.

Comparez la durée, les compteurs, la dernière étape et les nouveaux messages. Le journal du navigateur ou une réponse HTTP 200 ne remplace pas cet état final. Vérifiez également que le site reste disponible pendant l’essai et qu’aucune autre opération n’a été perturbée par la charge.

1. Confirmez la fin annoncée par Wordfence et l’absence d’un nouvel état d’échec.
2. Relevez les catégories et exclusions réellement actives.
3. Comparez les erreurs PHP et serveur sur le même créneau.
4. Vérifiez l’accueil et l’administration sans déclencher de paiement ou d’envoi pour ce contrôle.
5. Archivez le résultat avec le réglage modifié et son retour arrière. Les fichiers signalés demandent ensuite leur propre analyse ; ne choisissez pas une suppression automatique pour terminer le dépannage du scanner.

Annuler les essais qui n’expliquent pas l’arrêt

Remettez chaque option temporaire dans son état initial après un essai sans résultat utile. Le lancement distant, le journal détaillé, la durée d’étape et le mode de ressources ont des effets différents ; revenir sur l’un ne remet pas les autres en place. Une liste courte des changements facilite ce contrôle.

Si un fragment serveur a été modifié dans une intervention distincte, son responsable doit le restaurer avec son contrôle de syntaxe et son mécanisme d’application. Ne copiez pas un bloc générique dans .htaccess pour empêcher toute interruption de processus : la portée peut dépasser le scan concerné.

Un échec répété avec une même trace précise mérite une analyse ciblée plutôt qu’une nouvelle combinaison de réglages. Conservez le dernier état exploitable et les preuves privées, puis transmettez les limites constatées au prestataire ou à l’éditeur selon la couche concernée. Le retour arrière doit aussi rétablir les protections éventuellement affectées par un test de conflit sur la copie. Ne laissez pas un environnement moins protégé simplement parce que le scanner n’a pas fini.

Préparer un dossier utile sans conclure à un site sain

Le dossier final doit indiquer l’environnement, les versions, l’heure, la dernière étape, les compteurs et le premier message exploitable. Ajoutez les résultats des seuls essais réellement effectués, les options changées et leur état final. Séparez ce qui est observé de ce qui reste une hypothèse.

Si l’arrêt demeure inexpliqué, précisez quels journaux manquent et qui peut les fournir. Un prestataire qui voit une requête reçue peut aider à retrouver son traitement et les limites appliquées ; un statut positif isolé ne suffit pas à attribuer la cause au plugin ou au serveur. Demandez la corrélation de ce créneau et de ce processus.

Enfin, un scan terminé ne remplace pas une restauration vérifiée ni une enquête sur des modifications suspectes. Un scan incomplet ne prouve pas non plus une intrusion. Gardez les deux questions séparées pour choisir les bonnes actions. La résolution de ce guide consiste à obtenir une exécution et un périmètre maîtrisés, ou une preuve suffisamment précise pour la prochaine correction, sans relances incontrôlées ni affaiblissement général des protections.