Lire le journal des erreurs cPanel et trouver les erreurs du site Web

Lorsqu'un site web affiche une erreur, le message visible dans le navigateur n'est souvent qu'un symptôme. Le problème réel peut par exemple être causé par PHP, une application, des chemins de fichiers incorrects, des autorisations ou une configuration de serveur erronée.

Dans CURIAWEB-cPanel, vous trouverez sous Valeurs mesurées → Erreur les entrées actuelles du journal des erreurs du serveur web. Ces messages peuvent fournir des indices cruciaux sur, quand, où et pourquoi une erreur s'est produite.

Dans ce guide, nous vous montrons comment accéder au journal des erreurs cPanel, lire les messages d'erreur typiques et en déduire les prochaines étapes utiles pour le dépannage.

Important : Un message d'erreur ne doit pas seulement être analysé pour des termes individuels. L'horodatage, le chemin du fichier, le numéro de ligne et le texte de l'erreur vont ensemble. Seul le contexte complet révèle souvent quel fichier ou quelle application est réellement concerné.

Qu'est-ce que le journal d'erreurs cPanel ? #

Les serveurs Web et les applications enregistrent certaines erreurs qui surviennent lors du traitement d'un site Web.

Dans l'espace cPanel Erreur Pouvez-vous consulter les entrées actuelles du journal des erreurs du serveur web ?.

De telles entrées peuvent par exemple contenir des indications sur :

• Erreur PHP
• fichiers non trouvés
• chemins de fichiers incorrects
• Problèmes d'autorisation
• configurations erronées
• Problèmes avec les scripts PHP
• certains messages d'Apache / serveur web

Le journal des erreurs est par conséquent l'un des outils les plus importants lors du diagnostic d'un site Web qui ne fonctionne soudainement plus correctement.

Ce que le journal d'erreurs n'est pas #

Le journal des erreurs cPanel n'est pas un historique complet de toutes les opérations au sein de votre compte d'hébergement.

Il ne montre pas non plus automatiquement :

• chaque erreur de chaque application
• toutes les erreurs WordPress
• toutes les erreurs de base de données
• toutes les sorties des tâches cron
• tous les accès à ton site web

Selon le type d'erreur, d'autres journaux ou outils de diagnostic peuvent être pertinents.

En bref : Le journal des erreurs est un point de départ important – mais tout problème technique n'y est pas nécessairement consigné.

1. Ouvrir le journal des erreurs cPanel #

Connectez-vous à votre cPanel CURIAWEB.

Ouvrez ensuite :

Valeurs mesurées → Erreur

cPanel vous y affiche les entrées récentes du journal des erreurs.

2. Reproduire d'abord l'erreur #

Si une erreur spécifique est reproductible, vous devez réafficher la page concernée immédiatement avant de consulter le journal.

Exemple :

13:42
→ afficher la page d'erreur

13:43
→ cPanel → Métriques → ouvrir Erreurs

Cela vous permet ainsi d'associer beaucoup plus facilement les entrées de journal actuelles à l'erreur qui vient de se produire.

Conseil pratique : Note l'heure exacte à laquelle tu as provoqué l'erreur. Sur les sites Web très fréquentés en particulier, de nombreux messages différents peuvent être générés en peu de temps.

3. Ne pas considérer automatiquement la dernière entrée comme la cause #

L'entrée de journal la plus récente chronologiquement ne fait pas nécessairement partie de votre problème.

Par exemple, un site web peut être consulté simultanément par :

• visiteurs
• Moteurs de recherche
• Bots
• Systèmes de surveillance
• autres applications

être appelé.

Par conséquent, vérifiez toujours en plus de l'horodatage le chemin concerné ou le fichier spécifié.

Comment est structuré un message d'erreur ? #

La structure exacte dépend du type d'erreur. Cependant, une entrée de journal peut contenir des informations telles que :

Horodateur
Type d'erreur
Texte de l'erreur
Chemin du fichier
Numéro de ligne
informations techniques supplémentaires

Un exemple schématique en PHP pourrait ressembler à ceci :

Erreur fatale PHP :
Erreur non interceptée : ...
dans /home/CPANELUSER/public_html/example.php
à la ligne 125

Plusieurs éléments sont pertinents pour la recherche d'erreurs.

Horodatage #

L'horodatage vous aide à déterminer si le message a effectivement été généré au moment où vous avez observé le problème.

Un rapport d'hier n'est normalement pas la preuve d'une erreur que tu viens tout juste de déclencher.

Type d'erreur #

Le type d'erreur donne une première indication sur la gravité et la catégorie du problème.

Exemples :

Erreur fatale PHP
Avertissement PHP
Notice PHP
Permission refusée
Fichier introuvable

Ces messages ne signifient pas la même chose et doivent donc être traités différemment.

Texte d'erreur #

Le texte d'erreur proprement dit décrit ce qui a échoué lors du traitement.

Des exemples peuvent être :

Appel à une fonction non définie ...
Classe ... introuvable
Échec de l'ouverture du fichier requis ...
Permission refusée
Taille de mémoire autorisée ... épuisée

Le texte d'erreur est souvent la partie la plus importante pour le classement technique.

Chemin d'accès #

Le chemin de fichier indiqué montre souvent quel fichier était impliqué dans l'erreur.

Par exemple :

/home/CPANELUSER/public_html/wp-content/plugins/example/plugin.php

Un tel chemin permet déjà de voir que le fichier concerné se trouve dans un plugin WordPress.

Important : Un chemin de fichier indique où l'erreur a été déclenchée ou détectée. Cela ne signifie pas nécessairement que c'est précisément ce fichier seul qui est la cause réelle.

Numéro de ligne #

Les messages d'erreur PHP peuvent également inclure un numéro de ligne :

sur la ligne 125

Cela permet de localiser l'endroit concerné dans le fichier.

Le numéro de ligne est particulièrement utile pour les développeurs ou pour votre propre code. S'il s'agit d'un plugin ou d'un thème tiers, vous ne devriez pas simplement supprimer ou modifier la ligne de code en question.

Comprendre une erreur fatale PHP #

Un

Erreur fatale PHP

signifie que PHP n'a pas pu poursuivre l'exécution concernée en raison d'une erreur grave.

Cela peut par exemple entraîner :

• une page ne se charge pas
• seule une page blanche apparaît
• WordPress signale une erreur critique
• une erreur HTTP 500 se produit

Le texte déterminant est celui qui suit Erreur fatale PHP suit.

„Comprendre “Uncaught Error“ #

Un message tel que :

Erreur non interceptée : ...

indique qu'une erreur non interceptée par l'application s'est produite lors de l'exécution de PHP.

Par exemple, une fonction ou une classe requise peut faire défaut.

Le message doit toujours être examiné conjointement avec le chemin de fichier suivant et le numéro de ligne.

„Appel à une fonction non définie“ #

Un message tel que :

Appel à la fonction non définie example()

signifie que PHP ne connaît pas une fonction appelée ou qu'elle n'est pas disponible au moment de l'appel.

Les causes possibles peuvent être :

• extension PHP manquante
• fichier d'application non chargé
• code incompatible
• plugin ou thème défectueux
• Conflit de versions

Si la fonction appartient à une extension PHP, l'article Activer et gérer les extensions PHP dans cPanel aider.

„Classe introuvable“ #

Un message tel que :

Classe "Example" introuvable

signifie qu'une application souhaite utiliser une classe PHP qui n'est pas disponible à ce moment-là.

Cela peut se faire, par exemple, par

• fichiers manquants
• mises à jour incomplètes
• dépendances défectueuses
• extensions incompatibles
• code individuel défectueux

être causé.

Sur un site web WordPress, le chemin d'accès au fichier peut souvent indiquer quel plugin ou thème est impliqué.

„Échec de l'ouverture du fichier requis“ #

Un message tel que :

Échec de l'ouverture requise de '/pfad/datei.php'

indique que PHP n'a pas pu charger avec succès un fichier requis.

Vérifie en particulier :

• La date existe-t-elle ?
• Le chemin est-il correct ?
• Le fichier a-t-il été déplacé ou supprimé ?
• Une mise a jour etait-elle incomplete ?
• Est-ce que les autorisations sont correctes ?

Avec le Gestionnaire de fichiers cPanel peux-tu vérifier le chemin indiqué.

„Aucun fichier ou dossier de ce type“ #

Un message tel que :

Aucun fichier ou dossier de ce nom

signifie fondamentalement qu'un fichier ou un répertoire attendu n'a pas été trouvé sous le chemin spécifié.

Cela peut se produire, par exemple, après une migration, un déplacement manuel de fichiers ou une mise à jour défectueuse.

„Accès refusé“ #

Un message tel que :

Accès refusé

indique qu'un accès requis n'a pas été possible en raison des autorisations existantes.

Vérifiez d'abord dans ce cas :

• quel fichier ou répertoire est concerné
• quel accès a été tenté
• si les autorisations de fichiers existantes sont plausibles

Vous trouverez les bases sous Définir correctement les autorisations de fichiers 644 et 755 dans cPanel.

Attention : Ne définissez pas les autorisations de fichiers de manière globale sur 777, uniquement pour faire disparaître un message d'erreur. Cela ne résout pas la cause proprement et peut compromettre la sécurité du site web.

„Taille de mémoire autorisée dépassée“ #

Un message d'erreur PHP courant est le suivant :

Taille de mémoire autorisée de ... octets épuisée

Dans ce cas, PHP a atteint la limite de mémoire disponible pour le processus.

Le message contient souvent en outre :

• la limite de stockage disponible
• la quantité de mémoire supplémentaire demandée
• le fichier concerné
• un numéro de ligne

Nous vous expliquons comment évaluer la mémoire PHP et d'autres limites sur Définir la limite de mémoire PHP, la taille de téléchargement et le temps d'exécution.

Ne pas simplement augmenter indéfiniment la limite de mémoire #

Si une application nécessite une quantité inhabituelle de mémoire, une limite plus élevée peut certes s'avérer nécessaire, mais elle peut aussi simplement masquer un problème sous-jacent.

Des exemples de consommation de mémoire anormalement élevée peuvent être :

• plugin défectueux
• très grand volume de données
• Boucle infinie
• importation problématique
• configuration d'application inadaptée

Vérifiez par conséquent également le contexte de l'erreur.

„Temps d'exécution maximal dépassé“ #

Un message tel que :

Temps d'exécution maximal de ... secondes dépassé

signifie qu'un processus PHP a duré plus longtemps que ce qui est autorisé pour cet environnement PHP.

C'est le cas par exemple de :

• importations importantes
• exportations complexes
• connexions externes lentes
• opérations de base de données étendues
• code d'application problématique

survenir.

Ici aussi, la limite ne doit pas être augmentée aveuglément. Vérifiez d'abord quel processus est concerné.

Comprendre un avertissement PHP #

Une :

Avertissement PHP

n'est fondamentalement pas la même chose qu'une erreur fatale.

PHP peut poursuivre le traitement en cas de nombreuses alertes.

Néanmoins, les avertissements peuvent signaler des erreurs ou une programmation obsolète ou problématique.

De plus, si le même avertissement se produit très fréquemment, il peut faire grossir inutilement les fichiers journaux.

Avis et messages de dépréciation PHP #

Des messages tels que :

Avis PHP

ou

PHP obsolète

doivent également être distingués d'une erreur fatale.

Un message de dépréciation indique généralement que le code utilise une fonction ou une méthode considérée comme obsolète et qui pourrait ne plus être prise en charge à l'avenir.

De tels messages apparaissent plus fréquemment avec des applications, plugins ou thèmes plus anciens, par exemple après le passage à une version plus récente de PHP.

Nombreux messages de dépréciation après le changement de version PHP #

Si de nombreux messages d'obsolescence (deprecated) apparaissent immédiatement après un changement de version de PHP, vous devez vérifier si l'application concernée est entièrement compatible avec la nouvelle version de PHP.

Vous gérez généralement la version PHP de votre domaine sur CURIAWEB via le MultiPHP-Manager.

N'installez pas plusieurs versions de PHP au hasard les unes après les autres. Vérifiez d'abord les exigences système du logiciel utilisé.

Le message d'erreur indique un plugin WordPress #

Un chemin WordPress peut par exemple ressembler à ceci :

/home/CPANELUSER/public_html/wp-content/plugins/example-plugin/file.php

Le domaine :

/wp-content/plugins/example-plugin/

indique que le fichier appartient à un plugin.

Si une erreur fatale s'y déclenche, ce plugin fait partie des premiers composants que tu devrais examiner.

Cependant, cela ne signifie pas automatiquement que le plugin est seul responsable. Un conflit avec un autre plugin, un thème, PHP ou WordPress lui-même peut également être en cause.

Le message d'erreur pointe vers un thème WordPress #

Un chemin tel que :

/wp-content/themes/example-theme/...

indique que le fichier concerné se trouve dans un thème.

Vérifie ensuite en particulier :

• Le thème vient-il d'être mis à jour ?
• Est-ce que PHP a changé ?
• Est-ce que WordPress a été mis à jour ?
• L'erreur est-elle apparue immédiatement après une modification de thème ?
• S'agit-il de code personnalisé ?

Le message d'erreur pointe vers wp-content, mais la cause peut venir d'ailleurs #

Sous WordPress, le noyau, les extensions et les thèmes interagissent constamment.

Une erreur peut ainsi, par exemple, apparaître dans le plugin A, bien qu'une modification provoquée par le plugin B ait déclenché l'état problématique.

Considérez donc le chemin d'accès comme un indice important, et non comme une preuve automatique de culpabilité.

Comprendre la trace de la pile #

En cas de certaines erreurs PHP, un soi-disant Trace de la pile consigné.

Ceci montre de manière simplifiée quelles fonctions ou quels fichiers ont été appelés avant que l'erreur ne se produise.

Schématiquement :

#0 Fichier A → Fonction X
#1 Fichier B → Fonction Y
#2 Fichier C → Fonction Z
#3 Appel principal

Une trace de pile peut s'avérer très précieuse, car elle montre le chemin menant à l'erreur proprement dite.

Ne pas lire seulement la dernière ligne d'une trace de pile #

Une trace de pile contient plusieurs appels impliqués.

La premièreFichier visible ou dernière ligne n'est donc pas automatiquement la cause.

Sous WordPress, par exemple, une extension peut appeler une fonction principale de WordPress dans laquelle l'erreur finit par devenir visible.

Pour le diagnostic, toute la chaîne d'appels est pertinente.

„lancé dans … sur la ligne …“ #

Dans le cas des erreurs fatales PHP, la fin du message peut par exemple indiquer :

lancée dans /home/CPANELUSER/public_html/example.php à la ligne 125

Cette indication montre à quel endroit l'exception ou l'erreur a finalement été déclenchée.

Documentez cette ligne ainsi que le texte d'erreur précédent.

Fichier manquant après une mise à jour de plugin ou de thème #

Si, immédiatement après une mise à jour, des messages concernant des fichiers manquants apparaissent, la mise à jour peut être incomplète ou une installation peut être endommagée.

Dans ce cas, ne supprime pas de fichiers individuels au hasard.

Vérifie d'abord :

• quelle composante est concernée
• si la mise à jour a été entièrement effectuée
• s'il existe une sauvegarde récente
• si le composant peut être proprement réinstallé ou restauré

Erreur HTTP 500 et journal des erreurs #

En cas de problème côté serveur, un navigateur peut afficher uniquement :

500 Erreur interne du serveur

Cette seule notification n'indique pas encore ce qui a provoqué l'erreur.

Le journal des erreurs peut contenir, par exemple, une erreur fatale PHP spécifique, une configuration erronée ou une erreur de permission.

Nous traitons le diagnostic complet sous Résoudre l'erreur interne du serveur 500.

HTTP 403 et journal des erreurs #

À un :

403 Interdit

Le journal des erreurs peut également fournir des indices, par exemple en lien avec des autorisations ou des restrictions d'accès.

Cependant, une erreur 403 peut également être causée par d'autres niveaux de sécurité.

Nous abordons le dépannage systématique sous Résoudre l'erreur 403 Forbidden.

HTTP 503 et journal des erreurs #

Un

503 Service indisponible

peut avoir différentes causes.

Outre des problèmes d'application, des ressources ou des services temporairement indisponibles peuvent également jouer un rôle à cet égard.

Vous trouverez de plus amples informations sur Résoudre l'erreur 503 Service Unavailable.

.Détecter les erreurs .htaccess #

Un défectueux .htaccess-La configuration peut empêcher un site Web d'être traité correctement.

Selon l'erreur, le journal peut contenir des indications sur une directive non valide ou une configuration non autorisée.

Si le problème survient immédiatement après une modification de .htaccess a commencé, tu devrais d'abord vérifier ce changement.

Tu trouveras plus d'informations sur .htaccess expliqué et modifié en toute sécurité.

„Commande invalide après modification de .htaccess #

Un message peut par exemple indiquer qu'une directive n'est pas reconnue ou n'est pas autorisée dans ce contexte.

Si tu as brièvement récupéré du code d'un tutoriel externe dans .htaccess que tu as inséré, rétablis l'état précédent et vérifie la directive utilisée.

Attention : N'ajoutez pas d'instructions Apache ou PHP aléatoires dans .htaccess un. Toutes les directives ne sont pas autorisées dans chaque configuration d'hébergement et de PHP.

Ne pas définir les valeurs PHP aveuglément via .htaccess #

Dans les configurations PHP modernes, les anciennes instructions contenant des directives telles que :

php_value ...
php_flag ...

ne pas convenir et, sous certains gestionnaires PHP, provoquer même une erreur HTTP 500.

Chez CURIAWEB, vous gérez les paramètres PHP via les outils cPanel prévus à cet effet.

Nous expliquons la procédure sous Modifier les paramètres PHP dans cPanel.

Distinguer "File not found" et 404 #

Ce n'est pas parce qu'un fichier est introuvable que l'ensemble de votre site web est en panne.

Websites erhalten regelmäßig Anfragen nach nicht vorhandenen Ressourcen.

Cela peut être par exemple :

• alte URLs
• gelöschte Bilder
• fehlerhafte Links
• Bot-Anfragen
• automatisierte Scans

Ein einzelner Eintrag zu einer nicht vorhandenen Datei ist deshalb nicht automatisch kritisch.

Bot-Anfragen richtig einordnen #

Öffentlich erreichbare Websites werden regelmäßig automatisiert aufgerufen.

Dabei können Bots URLs anfordern, die auf deiner Website niemals existiert haben.

Beispiele können ungewöhnliche Pfade zu Administrationsoberflächen, Skripten oder bekannten Schwachstellen anderer Systeme sein.

Solche Einträge sind nicht automatisch ein Hinweis darauf, dass die betreffende Datei auf deinem Hosting vorhanden war.

Important : Ein Logeintrag kann lediglich zeigen, dass jemand eine bestimmte URL angefordert hat. Daraus folgt nicht automatisch, dass die angeforderte Datei existiert oder deine Website kompromittiert wurde.

Wiederkehrende Fehler sind wichtiger als zufällige Einzelmeldungen #

Bei der Priorisierung solltest du darauf achten, ob eine Meldung:

• bei jedem Seitenaufruf erscheint
• nur einmal aufgetreten ist
• immer dieselbe Datei betrifft
• mit einem sichtbaren Website-Problem zusammenfällt
• erst seit einer bestimmten Änderung auftritt

Eine reproduzierbare Fehlermeldung, die exakt beim Aufruf der defekten Seite entsteht, ist meist wesentlich relevanter als ein zufälliger älterer Logeintrag.

Ursache und Folgefehler unterscheiden #

Ein einzelnes Problem kann mehrere weitere Fehlermeldungen auslösen.

Par exemple :

benötigte Datei fehlt
        ↓
Klasse kann nicht geladen werden
        ↓
Funktion kann nicht ausgeführt werden
        ↓
Seite bricht mit Fatal Error ab

Wenn du nur die letzte Meldung behandelst, kann die ursprüngliche Ursache bestehen bleiben.

Prüfe deshalb bei mehreren zeitgleichen Meldungen, welche zuerst entstanden ist und wie die Meldungen zusammenhängen.

Was wurde unmittelbar vor dem Fehler geändert? #

Eine der wertvollsten Fragen bei der Diagnose lautet:

Was hat sich unmittelbar vor dem ersten Auftreten des Fehlers geändert?

Exemples :

• WordPress se met à jour
• Plugin mis à jour
• Thème mis à jour
• Version PHP modifiée
• PHP-Einstellung geändert
• .htaccess modifié
• Fichiers déplacés
• Site Web migré
• nouveau plugin installé

Der zeitliche Zusammenhang ist kein endgültiger Beweis, aber ein sehr wertvoller Ausgangspunkt.

Immer nur eine Änderung zurücknehmen #

Wenn der Fehler nach einer konkreten Änderung begonnen hat, solltest du möglichst zuerst genau diese Änderung überprüfen beziehungsweise kontrolliert zurücknehmen.

Ändere nicht gleichzeitig:

PHP-Version
.htaccess
Dateiberechtigungen
Plugins
Theme
PHP-Limits

Sonst lässt sich später kaum noch feststellen, welche Maßnahme relevant war.

Fehler nach PHP-Wechsel #

Wenn eine Website unmittelbar nach einem PHP-Wechsel nicht mehr funktioniert, prüfe das Error Log auf Meldungen wie:

• Fatal Errors
• fehlende Funktionen
• fehlende Klassen
• Messages obsolètes
• Probleme mit Erweiterungen

Wenn die Anwendung mit der neuen PHP-Version nicht kompatibel ist, kann ein kontrollierter Wechsel auf die zuvor funktionierende Version ein sinnvoller Diagnoseschritt sein.

Fehler nach Änderung der PHP-Einstellungen #

Wenn das Problem unmittelbar nach einer Änderung im MultiPHP INI Editor entstanden ist, solltest du die zuletzt geänderte Direktive prüfen.

Die PHP-Konfiguration behandeln wir ausführlich unter Modifier les paramètres PHP dans cPanel.

Fehler nach Änderung von Dateiberechtigungen #

Wenn Dateien oder Verzeichnisse unmittelbar vor dem Fehler andere Berechtigungen erhalten haben, solltest du auch diesen Zusammenhang berücksichtigen.

Setze die Rechte nicht wahllos auf immer höhere Werte, sondern stelle eine für den jeweiligen Dateityp geeignete Konfiguration her.

Fehler nach Migration #

Nach einem Website-Umzug können Fehlermeldungen beispielsweise auf folgende Probleme hinweisen:

• alte absolute Dateipfade
• fichiers manquants
• inkompatible PHP-Version
• fehlende PHP-Erweiterungen
• unvollständige Übertragung
• abweichende Konfiguration

Gerade absolute Pfade können sich zwischen zwei Hosting-Systemen unterscheiden.

Fehler nach Wiederherstellung eines Backups #

Wenn nach einer Wiederherstellung Fehler auftreten, solltest du prüfen, ob Dateien und Datenbank zum selben Stand gehören.

Eine Anwendung kann Probleme verursachen, wenn beispielsweise neuere Dateien mit einer deutlich älteren Datenbank kombiniert werden.

cPanel Error Log und WordPress Debug Log unterscheiden #

WordPress besitzt zusätzlich eigene Debugging-Möglichkeiten.

Bei aktiviertem WordPress-Debugging kann beispielsweise eine Datei wie:

wp-content/debug.log

être utilisé.

Das WordPress Debug Log und das cPanel Error Log sind nicht dasselbe.

Sie können sich ergänzen, weil sie Fehler auf unterschiedlichen Ebenen beziehungsweise mit unterschiedlichem Kontext protokollieren können.

Die WordPress-Diagnose behandeln wir unter Utiliser le débogage et les journaux d'erreurs de WordPress.

WordPress Debugging nicht dauerhaft unnötig aktiv lassen #

Debugging-Funktionen sollten auf einer produktiven Website gezielt zur Diagnose verwendet werden.

Insbesondere Fehlermeldungen sollten nicht unnötig öffentlich im Frontend ausgegeben werden.

Logs können technische Informationen enthalten und sollten nicht öffentlich zugänglich gemacht werden.

cPanel Error Log und Cronjob-Ausgabe unterscheiden #

Ein PHP-Skript, das über einen Cronjob beziehungsweise die Kommandozeile ausgeführt wird, muss seine Fehler nicht zwangsläufig im gleichen Webserver-Log hinterlassen.

Bei Cronjob-Problemen solltest du deshalb zusätzlich die eigentliche Cron-Ausgabe und anwendungsspezifische Logs prüfen.

Nous expliquons la procédure sous La tâche cron ne fonctionne pas : causes et solutions.

Error Log und Access Log unterscheiden #

Ein Error Log protokolliert Fehler beziehungsweise relevante Fehlersituationen.

Ein Access Log protokolliert dagegen Zugriffe auf den Webserver.

Simplifié :

Access Log
→ Wer beziehungsweise was hat welche Ressource aufgerufen?

Error Log
→ Welcher Fehler ist bei der Verarbeitung aufgetreten?

Beide Logtypen können sich bei einer detaillierten Diagnose ergänzen.

Rohdaten von Zugriffen in cPanel #

Dans le domaine Valeurs mesurées stellt cPanel zusätzlich Funktionen für Zugriffs- und Statistikdaten bereit.

Wenn du beispielsweise untersuchen möchtest, ob eine bestimmte URL aufgerufen wurde, sind Zugriffsdaten unter Umständen hilfreicher als das Error Log allein.

Error Log und CloudLinux-Ressourcen unterscheiden #

Ein langsamer oder fehlgeschlagener Seitenaufruf muss nicht zwingend einen klassischen PHP-Fehler erzeugen.

Wenn Hosting-Ressourcen ausgeschöpft werden, solltest du zusätzlich die CloudLinux-Ressourcennutzung prüfen.

Nous expliquons comment cela fonctionne sur Comprendre l'utilisation des ressources CloudLinux dans cPanel.

Wann Ressourcen und Error Log gemeinsam interessant sind #

Angenommen, eine Website fällt sporadisch aus und das Error Log enthält keine eindeutige wiederkehrende PHP-Ursache.

Dann kann ein Vergleich sinnvoll sein:

Zeitpunkt des Website-Problems
        ↓
Error Log prüfen
        ↓
CloudLinux-Ressourcen zum selben Zeitraum prüfen

Damit lässt sich beispielsweise erkennen, ob der Fehler mit einer Lastspitze zusammenfällt.

Alte Fehler nicht mit aktuellen Problemen verwechseln #

Ein Error Log kann Meldungen enthalten, deren Ursache längst behoben wurde.

Wenn beispielsweise gestern ein Plugin einen Fatal Error erzeugt hat und heute wieder korrekt funktioniert, bleibt die alte Meldung zunächst ein historischer Hinweis.

Entscheidend ist deshalb immer der zeitliche Zusammenhang mit dem aktuellen Problem.

Fehler gezielt erneut auslösen #

Bei einem reproduzierbaren Problem ist folgende Vorgehensweise besonders effektiv:

1. cPanel Error Log kurz kontrollieren.
2. Aktuelle Uhrzeit notieren.
3. Betroffene Seite oder Funktion genau einmal aufrufen.
4. Error Log erneut öffnen beziehungsweise aktualisieren.
5. Nach neuen Einträgen zum entsprechenden Zeitpunkt suchen.
6. Dateipfad und Fehlertext prüfen.

Damit reduzierst du die Wahrscheinlichkeit, einen völlig anderen Logeintrag zu analysieren.

Fehler tritt nur bei einer bestimmten URL auf #

Wenn nur eine einzelne Seite betroffen ist, prüfe:

• welcher Code speziell auf dieser Seite ausgeführt wird
• welches Plugin beziehungsweise Theme daran beteiligt ist
• ob die Seite besondere Funktionen verwendet
• ob unmittelbar beim Aufruf ein neuer Logeintrag entsteht

Eine funktionierende Startseite beweist nicht, dass sämtliche PHP-Funktionen der Website fehlerfrei sind.

Fehler tritt nur im WordPress-Adminbereich auf #

Wenn das Frontend funktioniert, aber beispielsweise eine bestimmte Verwaltungsseite einen Fatal Error erzeugt, solltest du genau diesen Adminbereich aufrufen und anschließend die neuen Logeinträge prüfen.

Plugins können beispielsweise Code nur innerhalb des Administrationsbereichs ausführen.

Fehler tritt nur bei Formularen auf #

Ein Formular kann beim normalen Anzeigen der Seite funktionieren und erst beim Absenden einen Fehler erzeugen.

Reproduziere deshalb genau die Aktion, bei der das Problem auftritt.

Bei der Fehlersuche zählt nicht nur die URL, sondern der konkrete Ablauf.

L'erreur ne se produit que de temps en temps #

Sporadische Fehler sind schwieriger zu diagnostizieren.

Dokumentiere möglichst:

• Date et heure
• betroffene URL
• ausgeführte Aktion
• sichtbare Browsermeldung
• gleichzeitige Logeinträge
• mögliche Ressourcenwerte

Je genauer der Zeitpunkt bekannt ist, desto leichter lassen sich verschiedene Diagnosequellen miteinander vergleichen.

Fehlermeldung nicht öffentlich weitergeben #

Error Logs können interne Dateipfade, Benutzernamen, technische Konfigurationen oder andere Informationen über die Hosting-Umgebung enthalten.

Veröffentliche vollständige Logs deshalb nicht unüberlegt in öffentlichen Foren oder sozialen Netzwerken.

Consigne de sécurité : Prüfe Logauszüge vor dem Weitergeben auf Passwörter, Tokens, API-Schlüssel, personenbezogene Daten und andere vertrauliche Informationen.

Nicht komplette riesige Logs senden #

Für eine Supportanfrage ist ein relevanter Ausschnitt rund um den konkreten Fehler häufig hilfreicher als tausende unzusammenhängende Logzeilen.

Wichtig sind:

• Moment
• message d'erreur complet
• betroffene Datei
• gegebenenfalls Stack Trace
• Beschreibung der Aktion, die den Fehler auslöst

Fehlermeldung vollständig kopieren #

Schneide bei einer technischen Meldung nicht nur einen einzelnen Begriff heraus.

Par exemple, au lieu de simplement :

Fatal error

weiterzugeben, sollte die relevante Meldung mit Fehlertext, Dateipfad und Zeilennummer dokumentiert werden.

Gerade diese Details unterscheiden zwei völlig verschiedene Ursachen voneinander.

Typische Meldungen und erste Prüfschritte #

Meldung	Erster Prüfschritt
Erreur fatale PHP	vollständigen Fehlertext, Datei und Zeile prüfen
Erreur non interceptée	Fehlertext und Stack Trace auswerten
Appel à une fonction non définie	PHP-Erweiterung, Anwendung und PHP-Version prüfen
Classe ... introuvable	betroffene Anwendung und fehlende Abhängigkeit prüfen
Failed opening required	Dateipfad und vorhandene Dateien prüfen
Aucun fichier ou dossier de ce nom	Pfad, Dateiname und Migration prüfen
Accès refusé	Datei- und Verzeichnisberechtigungen prüfen
Taille de mémoire autorisée ... épuisée	Speicherbedarf und PHP Memory Limit prüfen
Maximum execution time ... exceeded	betroffenen Prozess und Laufzeit prüfen
PHP obsolète	Software-Kompatibilität mit PHP-Version prüfen
Invalid command	Konfiguration beziehungsweise .htaccess prüfen

Systematische Fehlersuche mit dem cPanel Error Log #

1. Notiere das sichtbare Problem und die betroffene URL.
2. Notiere die aktuelle Uhrzeit.
3. Ouvrir Valeurs mesurées → Erreur.
4. Rufe die problematische Seite beziehungsweise Funktion erneut auf.
5. Prüfe unmittelbar danach neue Logeinträge.
6. Vergleiche den Zeitstempel mit deinem Test.
7. Prüfe Fehlerart und vollständigen Fehlertext.
8. Prüfe Dateipfad und gegebenenfalls Zeilennummer.
9. Ordne die Datei einer Anwendung, einem Plugin oder Theme zu.
10. Prüfe, was unmittelbar vor dem ersten Auftreten des Fehlers geändert wurde.
11. Nimm nicht mehrere Konfigurationsänderungen gleichzeitig vor.
12. Teste nach einer gezielten Änderung erneut denselben Ablauf.

Wenn im Error Log nichts erscheint #

Wenn beim reproduzierbaren Fehler kein neuer Eintrag im cPanel Error Log erscheint, bedeutet das nicht automatisch, dass kein technisches Problem existiert.

Je nach Situation solltest du andere Diagnosequellen prüfen.

Cela peut inclure :

• anwendungseigene Logs
• WordPress Debug Log
• Cronjob-Ausgabe
• Zugriffslogs
• Ressources CloudLinux
• Browser-Entwicklerwerkzeuge bei Frontend-Problemen

Die richtige Diagnosequelle hängt davon ab, auf welcher Ebene der Fehler entsteht.

Quand devez-vous contacter le support CURIAWEB ? #

Wenn du einen reproduzierbaren Website-Fehler hast, das Error Log eine technische Meldung enthält und du die Ursache nicht eindeutig beheben kannst, dokumentiere den Fall möglichst präzise.

Pour une analyse, les informations suivantes sont notamment utiles :

• domaine concerné
• betroffene URL beziehungsweise Funktion
• Datum und genaue Uhrzeit des Fehlers
• sichtbare Fehlermeldung im Browser
• vollständiger relevanter Error-Log-Eintrag
• betroffene Datei und Zeilennummer, falls vorhanden
• was unmittelbar vor dem Problem geändert wurde
• si l'erreur est reproductible
• verwendete PHP-Version, falls relevant

Übermittle keine Passwörter, Tokens, API-Schlüssel oder andere vertrauliche Zugangsdaten.

Résumé #

Das cPanel Error Log unter Valeurs mesurées → Erreur ist eines der wichtigsten Diagnosewerkzeuge bei serverseitigen Website-Problemen. Es kann dir zeigen, wann ein Fehler aufgetreten ist, welche Datei beteiligt war und welche technische Meldung erzeugt wurde.

Analysiere einen Eintrag immer im Zusammenhang mit Zeitstempel, Fehlertext, Dateipfad und gegebenenfalls Zeilennummer. Ein einzelnes Wort wie Fatal error reicht für eine zuverlässige Diagnose nicht aus.

Typische Meldungen wie Accès refusé, Taille de mémoire autorisée épuisée, Failed opening required ou Appel à une fonction non définie weisen auf unterschiedliche Fehlerklassen hin und erfordern entsprechend unterschiedliche Maßnahmen.

Bei WordPress kann der Dateipfad häufig zeigen, ob ein Plugin oder Theme am Fehler beteiligt ist. Das ist jedoch ein Hinweis und nicht automatisch der Beweis, dass diese Komponente allein die Ursache darstellt.

Reproduziere einen Fehler möglichst kontrolliert und kontrolliere unmittelbar danach das Error Log. Dadurch kannst du aktuelle Meldungen wesentlich zuverlässiger dem konkreten Problem zuordnen.

Wenn dort keine passende Meldung erscheint, solltest du die Diagnosequelle wechseln. WordPress Debug Logs, Cronjob-Ausgaben, Zugriffslogs und CloudLinux-Ressourcen liefern Informationen über andere technische Ebenen.

La règle la plus importante est : Nicht die erste rote Fehlermeldung auf Verdacht reparieren. Reproduziere den Fehler, ordne den passenden Logeintrag zeitlich zu und arbeite anschließend anhand der konkreten Meldung.