Si votre site Web soudainement n'est plus accessible, cela peut avoir des causes très différentes. Sont possibles par exemple des problèmes DNS, une mauvaise attribution de domaine, des problèmes SSL, des erreurs PHP, un dysfonctionnement .htaccess, des problèmes avec WordPress ou des limites de ressources atteintes.
Il est donc crucial de ne pas modifier immédiatement les attitudes, mais de déterminer d'abord, à quel niveau technique l'erreur se produit.
Ce guide vous guide pas à pas à travers les vérifications les plus importantes dans l'hébergement web CURIAWEB et vous aide à en cerner la cause.
Important : „ Site web inaccessible “ n'est d'abord que le symptôme visible. Notez le message d'erreur exact avant d'apporter des modifications au DNS, à PHP, à WordPress ou à votre hébergement.
Que signifie „ Site Web inaccessible “ au juste ? #
Pour les visiteurs, de nombreux problèmes techniques se ressemblent : le site web souhaité ne s'affiche pas.
Cependant, techniquement, cela peut cacher des erreurs totalement différentes :
Le domaine ne se résout pas
↓
Problème DNS
Le domaine pointe vers le mauvais serveur
↓
Problème DNS / de configuration
La connexion HTTPS échoue
↓
Problème SSL / de certificat
403 Forbidden
↓
Accès refusé
404 Not Found
↓
Ressource introuvable
500 Internal Server Error
↓
Échec du traitement côté serveur
503 Service Unavailable
↓
Service temporairement indisponible
508 Resource Limit Is Reached
↓
Limite de ressources CloudLinux atteinteC'est pourquoi nous ne commençons pas le diagnostic par une réparation, mais par une classification.
1. Noter le message d'erreur exact #
Visite le site web et note exactement ce qui s'affiche.
Exemples :
Serveur introuvable
DNS_PROBE_FINISHED_NXDOMAIN
ERR_NAME_NOT_RESOLVED
ERR_CONNECTION_TIMED_OUT
ERR_CONNECTION_REFUSED
ERR_TOO_MANY_REDIRECTS
403 Interdit
404 Non trouvé
500 Erreur interne du serveur
503 Service indisponible
508 Limite de ressources atteinteTu ne devrais pas non plus simplement résumer un avertissement de certificat par „ site Web hors ligne “.
Plus le message est précis, plus il est rapide d'en cerner la cause.
2. Noter l'URL concernée #
Notez également l'URL complète.
Par exemple :
ou
ou
C'est important car c'est le domaine principal, wwwque le nom d'hôte et les sous-domaines puissent utiliser des enregistrements DNS ou des configurations différentes.
3. Vérifier si l'ensemble du site web est concerné #
Testez plusieurs zones du site web.
Par exemple :
https://example.ch/
https://example.ch/kontakt/
https://example.ch/wp-admin/Vérifier :
- Aucune URL n'est accessible ?
- Est-ce que la page d'accueil fonctionne, mais pas une sous-page ?
- Est-ce que le front-end fonctionne, mais pas la zone d'administration ?
- Un seul sous-domaine est-il concerné ?
- Est-ce qu'une seule fonction particulière est concernée ?
Si une seule page échoue, une panne complète de l'hébergement est beaucoup moins probable.
4. Vérifier si vous êtes le seul concerné #
Testez le site Web dans une fenêtre de navigation privée et, si possible, via une autre connexion Internet.
Un exemple de comparaison simple peut être le suivant :
WLAN → Site Web inaccessible
Données mobiles → Le site Web fonctionneTu dois alors tenir compte du fait que le problème concerne peut-être uniquement ta connexion, ton résolveur DNS ou ton adresse IP publique.
Conseil pratique : Un test sur réseau mobile est particulièrement utile car il vous permet généralement d'utiliser une autre connexion Internet et une autre adresse IP publique.
5. Vérifier si cPanel est accessible #
Si votre site Web ne fonctionne pas, mais que cPanel est toujours accessible, vous pouvez y commencer immédiatement le diagnostic.
Un accès cPanel fonctionnel ne prouve certes pas que le site web est correctement configuré, mais il montre que votre compte d'hébergement est globalement accessible.
Cela aide à affiner.
6. Vérifier le domaine et le DNS comme premier niveau technique #
Avant qu'un site Web ne puisse être consulté, le nom de domaine doit être résolu.
Simplifié :
example.ch
↓
DNS
↓
Adresse IP
↓
Serveur web
↓
Site webSi la résolution DNS échoue déjà, la requête n'atteint même pas encore le site web.
Signes typiques d'un problème DNS #
Des messages tels que :
DNS_PROBE_FINISHED_NXDOMAIN
ERR_NAME_NOT_RESOLVED
Serveur introuvableindiquent plutôt la résolution de noms que PHP ou WordPress.
Dans ce cas, tu ne devrais pas commencer par désactiver des plugins ou modifier les paramètres PHP.
Prendre en compte les modifications DNS récentes #
Si des enregistrements DNS ou des serveurs de noms ont été modifiés immédiatement avant le problème, cette relation temporelle est particulièrement importante.
Les modifications DNS peuvent ne pas être visibles partout en même temps en raison des caches.
Vérifiez par conséquent :
- Les serveurs de noms ont-ils été modifiés ?
- Un enregistrement A ou AAAA a-t-il été modifié ?
- Un CNAME a-t-il été modifié ?
- Le domaine a-t-il été récemment migré vers un autre hébergement ?
- Une sous-domaine a-t-elle été nouvellement configurée ?
Nous vous expliquons comment contrôler les enregistrements DNS dans cPanel sur Utilisation de l'éditeur de zones DNS dans cPanel.
8. Vérifier si cPanel est réellement responsable du DNS #
La zone DNS de votre cPanel n'est déterminante que si le domaine utilise effectivement les serveurs de noms autoritaires correspondants ou cette infrastructure DNS.
Si la gestion DNS est assurée par un fournisseur externe, vous devez y effectuer les modifications.
Important : Une modification dans l'éditeur de zones cPanel n'a aucun effet sur la résolution DNS publique si une autre infrastructure DNS fait autorité pour le domaine.
9. Contrôler l'attribution des domaines dans cPanel #
Si le domaine pointe correctement vers le serveur d'hébergement, il doit également être configuré correctement dans le compte d'hébergement.
Ouvrir :
Domaines → Domaines
Vérifiez si le domaine concerné existe et quel document root est utilisé.
Vous trouverez le mode d'emploi complet sur Ajouter et gérer un domaine dans cPanel.
10. Vérifier la racine du document #
Le répertoire racine (Document Root) détermine le répertoire à partir duquel le serveur web fournit le site Internet pour un domaine.
Exemple :
Domaine :
example.ch
Racine du document :
/public_html/example/Si le site Web réel se trouve dans un autre répertoire, le domaine risque de diffuser des contenus incorrects ou de n'en diffuser aucun.
Vérifiez par conséquent si la racine de document configurée contient bien les fichiers du site web.
11. Contrôler le fichier de démarrage #
Ouvrir :
Fichiers → Gestionnaire de fichiers
Passez à la racine du document du domaine concerné.
Vérifiez s'il y a un fichier de démarrage approprié, par exemple :
index.php
index.htmlSi les fichiers du site Web sont manquants ou se trouvent dans un sous-répertoire incorrect, le serveur Web ne peut pas afficher correctement le site Web attendu.
Nous expliquons le fonctionnement sous Utiliser le gestionnaire de fichiers cPanel.
12. Vérifier si des fichiers ont été récemment déplacés ou supprimés #
Si le site Web est tombé en panne immédiatement après des travaux dans le gestionnaire de fichiers, vérifiez en particulier :
- Des fichiers ont-ils été déplacés ?
- Un répertoire a-t-il été renommé ?
- A-t-elle été
index.phpSupprimé ? - Une archive a-t-elle été décompressée dans le mauvais répertoire ?
- A-t-il été / A-t-elle été
.htaccessmodifié ?
Commencez toujours le dépannage par la dernière modification effectuée.
13. Vérifier HTTPS et SSL séparément #
Si le domaine est fondamentalement accessible, mais que le navigateur affiche un avertissement de certificat, il s'agit d'une autre classe d'erreur qu'une erreur 500 ou 503.
Les indications typiques sont par exemple :
- Certificat expiré
- Le certificat ne correspond pas au nom d'hôte
- Le certificat n'est pas reconnu comme de confiance
- La connexion HTTPS ne peut pas être établie correctement
Dans ce cas, vérifiez spécifiquement la configuration SSL et non PHP, WordPress ou CloudLinux par simple suspicion.
14. Tester www et le domaine sans www séparément #
Test :
et
Si une seule variante fonctionne, vous devez vérifier le DNS, SSL et les redirections pour le nom d'hôte concerné.
Un domaine principal fonctionnel ne prouve pas automatiquement que www correctement configuré.
15. Détecter les boucles de redirection #
Si le navigateur affiche un message tel que :
ERR_TOO_MANY_REDIRECTS
affiché, la requête est redirigée à plusieurs reprises entre des URL.
Simplifié :
URL A → URL B
↓
URL A
↓
URL B
↓
...Vérifiez dans ce cas les redirections dans cPanel, le .htaccess et le cas échéant au sein de ton application web.
Nous expliquons comment configurer les transferts cPanel sous Configurer une redirection de domaine dans cPanel.
Utiliser les codes d'état HTTP comme guides #
Lorsque le domaine est résolu et que le serveur web renvoie un message d'erreur HTTP spécifique, vous devez orienter la suite du diagnostic en fonction du code d'état.
| Statut | Diagnostic complémentaire |
|---|---|
403 | Droits d'accès et règles de sécurité |
404 | URL, fichier ou configuration de réécriture/permalien |
500 | Journal des erreurs, PHP, application et .htaccess |
503 | Service, application, processus et ressources |
508 | Limites des ressources CloudLinux |
17. 403 Interdit #
Un 403 Interdit signifie que l'accès à une ressource est refusé.
Les domaines de contrôle typiques sont :
- Autorisations de fichiers
.htaccess- Blocages IP
- ModSecurity
- Fonctions de sécurité
Utilisez pour cela Résoudre l'erreur 403 Forbidden.
18. 404 Non trouvé #
Un 404 Non trouvé signifie généralement que la ressource demandée n'a pas été trouvée.
Si la page d'accueil fonctionne mais que certaines pages WordPress renvoient une erreur 404, cela peut être dû, par exemple, aux règles de permaliens ou de réécriture.
Vous trouverez les instructions correspondantes pour WordPress sous Résoudre l'erreur 404 de WordPress.
19. 500 Erreur interne du serveur #
Un 500 Erreur interne du serveur indique une erreur lors du traitement côté serveur.
Le code d'état lui-même ne mentionne pas encore la cause.
Vérifie en particulier :
- Journal des erreurs de cPanel
- Erreurs fatales PHP
.htaccess- Version PHP
- Extensions PHP
- Extensions et thèmes
- Limites PHP
Vous trouverez le diagnostic complet sur Résoudre l'erreur interne du serveur 500.
20. Service indisponible #
Un 503 Service indisponible signifie qu'un service ne peut pas traiter la demande avec succès pour le moment.
Ce qui est particulièrement important en cas d'erreurs 503 récurrentes :
- Journal des erreurs
- Ressources CloudLinux
- Processus PHP
- Tâches cron
- Tâches d'arrière-plan WordPress et WooCommerce
- États de maintenance
Utilisez pour cela Résoudre l'erreur 503 Service Unavailable.
21. La limite des ressources est atteinte #
Lorsqu'un message tel que :
508 Limite de ressources atteinte
affiché, vous devez analyser l'utilisation des ressources CloudLinux.
Vous trouverez les instructions correspondantes sous Limite de ressources atteinte : identifier et corriger les limites CloudLinux.
22. Vérifier le journal des erreurs cPanel #
En cas d'erreurs côté serveur, le journal des erreurs est l'un des points de diagnostic les plus importants.
Ouvrir :
Valeurs mesurées → Erreur
Reproduisez l'erreur et comparez ensuite le moment avec les dernières entrées pertinentes.
Vous trouverez notre guide détaillé sur Lire le journal des erreurs cPanel et trouver les erreurs du site Web.
Conseil pratique : La dernière entrée de journal ne correspond pas forcément automatiquement à votre problème. Comparez l'horodatage, l'URL, le chemin d'accès au fichier et le message d'erreur.
23. Utiliser les modifications récentes comme outil de diagnostic #
Si un site Web fonctionnait auparavant, demandez-vous :
Qu'a-t-il été modifié immédiatement avant la panne ?
Exemples :
- WordPress se met à jour
- Plugin mis à jour
- Thème modifié
- Version PHP changée
.htaccessmodifié- DNS modifié
- Domaine redirigé
- Fichiers déplacés
- Site Web migré
- Tâche cron configurée
Un lien temporel étroit est souvent plus précieux qu'une longue liste de causes théoriquement possibles.
24. Vérifier le fichier .htaccess #
Un défectueux .htaccess peut provoquer divers problèmes, notamment des boucles de redirection, des erreurs 403 ou 500.
Si le problème a commencé immédiatement après une modification de ce fichier, vérifiez d'abord précisément cette modification.
Nous vous expliquons comment procéder en toute sécurité sur .htaccess expliqué et modifié en toute sécurité.
25. Vérifier les autorisations de fichiers #
Si les fichiers ou répertoires ne disposent pas des autorisations appropriées, il se peut que le serveur Web ne puisse pas y accéder correctement.
Sur les sites web typiques, on rencontre souvent les valeurs suivantes :
Fichiers : 644
Répertoires : 755Cependant, ces valeurs ne doivent pas être appliquées aveuglément à l'ensemble des contenus.
Vous trouverez le mode d'emploi complet sur Définir correctement les autorisations de fichiers 644 et 755 dans cPanel.
Attention : Ne définissez pas systématiquement les fichiers et répertoires sur
777, juste parce que le site Web ne fonctionne pas. Ce n'est pas un dépannage propre et cela peut engendrer des risques de sécurité.
26. Vérifier la version de PHP #
Si un site web basé sur PHP ne fonctionne plus après un changement de version de PHP, contrôlez la version utilisée et la compatibilité de l'application.
Sur CURIAWEB, vous gérez généralement la version de PHP via :
Logiciel → MultiPHP-Manager
Vous trouverez les instructions sur Modifier la version PHP dans cPanel.
Ne changez pas les versions de PHP au hasard. Vérifiez d'abord le journal des erreurs et les exigences de votre application.
27. Prendre en compte les extensions PHP #
Après un changement de version de PHP ou une migration, une application peut avoir besoin de fonctionnalités qui ne sont pas disponibles dans l'environnement PHP utilisé.
Les messages d'erreur typiques sont par exemple :
Appel à une fonction non définie ...
Classe ... introuvable
nécessite l'extension ...Tu trouveras plus d'informations sur Activer et gérer les extensions PHP dans cPanel.
Vérifier les limites de PHP #
Si une erreur ne se produit que lors de certaines actions complexes, les limites de PHP peuvent être pertinentes.
Les exemples sont :
memory_limit
upload_max_filesize
post_max_size
max_execution_time
max_input_timeSi le journal des erreurs, par exemple :
Taille de mémoire autorisée épuisée
signale, c'est un indice concret de la limite de mémoire PHP.
Nous expliquons les paramètres sous Définir la limite de mémoire PHP, la taille de téléchargement et le temps d'exécution.
29. Contrôler les ressources CloudLinux #
Si le site Web n'est accessible que par intermittence, vous devez vérifier l'utilisation des ressources au même moment.
Ouvrir :
Valeurs mesurées → Utilisation des ressources
Vérifiez en particulier s'il y a des défauts ou des valeurs anormales.
Nous expliquons comment interpréter les données sous Comprendre l'utilisation des ressources CloudLinux dans cPanel.
30. Vérifier l'espace de stockage #
Un compte d'hébergement entièrement saturé peut perturber diverses opérations d'écriture.
Cela peut par exemple inclure, selon l'application :
- Téléchargements
- Mises à jour
- Fichiers cache
- fichiers temporaires
- Journaux
- Sauvegardes
- Stockage des e-mails
Vous pouvez vérifier l'utilisation de l'espace de stockage sous :
Fichiers → Utilisation de l'espace de stockage
Tu trouveras plus d'informations sur Vérifier l'espace disque et la bande passante dans cPanel.
31. Isoler WordPress comme source d'erreur potentielle #
Si d'autres contenus ou domaines fonctionnent sur l'hébergement, mais qu'une installation WordPress spécifique ne fonctionne pas, vous devriez examiner l'application elle-même.
Les domaines typiques sont :
- Extensions
- Thèmes
- Cœur WordPress
.htaccess- Compatibilité PHP
- Base de données
- code individuel
Erreur critique WordPress #
Si WordPress signale :
Il y a eu une erreur critique sur votre site Web.
il y a souvent une erreur PHP dans WordPress, un plugin, un thème ou du code personnalisé.
Utilisez pour cela Résoudre l'erreur critique WordPress ou la page blanche.
33. Vérifier les plugins et thèmes WordPress #
Si le problème a commencé immédiatement après l'installation, l'activation ou la mise à jour d'un plugin ou d'un thème, cette corrélation temporelle est importante.
Vérifiez le journal des erreurs pour des chemins tels que :
/wp-content/plugins/...
/wp-content/themes/...Nous expliquons le diagnostic systématique sous Détecter et résoudre les conflits de plugins et thèmes WordPress.
Utiliser le débogage WordPress #
Si le journal des erreurs normal ne fournit pas suffisamment d'informations, un enregistrement de débogage WordPress contrôlé peut fournir des indices supplémentaires.
WordPress peut générer des erreurs, par exemple sous :
wp-content/debug.log
consigner.
Nous expliquons la configuration sécurisée sur Utiliser le débogage et les journaux d'erreurs de WordPress.
Tester la connexion WordPress séparément #
Si seulement l'inscription sur :
ou
ne fonctionne pas, mais que le site web public est accessible, il ne s'agit pas d'une panne complète du site web.
Utilise dans ce cas La connexion WordPress ne fonctionne pas.
36. Prendre en compte les tâches cron et les tâches d'arrière-plan #
Si le site Web présente régulièrement des problèmes à la même heure, tu devrais vérifier les processus planifiés.
Ouvrir :
Options avancées → Tâches Cron
Comparez le moment avec :
- Tâches cron
- Important
- Exporter
- Sauvegardes
- Synchronisations
- Tâches d'arrière-plan WordPress
En cas de problème avec une tâche cron, vous trouverez le mode d'emploi correspondant sous La tâche cron ne fonctionne pas : causes et solutions.
37. Site web temporairement inaccessible #
En cas de pannes sporadiques, l'heure exacte est particulièrement importante.
Documentez plusieurs événements :
09:14 → injoignable
11:37 → injoignable
15:02 → injoignableComparez ensuite ces moments avec :
- Journal des erreurs
- Ressources CloudLinux
- Tâches cron
- Tâches d'arrière-plan
- trafic inhabituel
Sans repères temporels, les problèmes sporadiques sont nettement plus difficiles à diagnostiquer.
Site web inaccessible toujours à la même heure #
Un motif temporel récurrent indique souvent un processus planifié ou régulier.
Par exemple :
02:00 → Sauvegarde
02:00 → Importation
02:00 → Synchronisation
02:01 → Le site web ne répond pasCela ne prouve pas encore quel processus en est la cause, mais fournit un point de départ concret.
39. Site Web inaccessible après la mise à jour #
Si le problème commence immédiatement après une mise à jour, vérifiez d'abord le composant mis à jour.
Cela vaut en particulier pour :
- WordPress
- Extensions
- Thèmes
- Version PHP
- composants d'application individuels
Vérifiez également le journal des erreurs pour détecter une erreur correspondante.
40. Site web inaccessible après la migration #
Après une migration, plusieurs niveaux peuvent être en cause.
Vérifiez dans un ordre logique :
Domaine
↓
DNS
↓
Bon serveur
↓
Domaine dans cPanel
↓
Racine du document
↓
Fichiers
↓
SSL
↓
Version de PHP
↓
Extensions PHP
↓
Application
↓
Base de donnéesNe sautez pas directement aux plugins WordPress si le domaine pointe encore vers l'ancien serveur.
41. Vérifier la connexion à la base de données #
De nombreux systèmes de gestion de contenu et applications web ont besoin d'une base de données.
Si l'application signale explicitement une erreur de base de données, vérifie :
- Nom de base de données
- Utilisateur de base de données
- Attribution de l'utilisateur à la base de données
- Autorisations
- Fichier de configuration de l'application
Nous expliquons comment associer des utilisateurs et des bases de données dans cPanel sur Créer un utilisateur MySQL et l'attribuer à une base de données.
Ne pas modifier la base de données au hasard #
Une panne générale de site Web n'est pas une raison pour supprimer, vider ou modifier manuellement des tables.
Modifiez la base de données uniquement en cas d'indice concret d'un problème de base de données.
Vérifier si un seul domaine est concerné #
Si plusieurs domaines sont hébergés sur le même compte d'hébergement, une comparaison peut s'avérer très utile.
Exemple :
domain-a.ch → fonctionne
domain-b.ch → fonctionne
domain-c.ch → inaccessibleUne panne complète du compte d'hébergement est alors moins probable.
Concentrer le diagnostic sur :
- DNS du domaine c.ch
- Association de domaine
- Racine du document
- SSL
- Fichiers
- Application de ce domaine
43. Vérifier si tous les domaines sont concernés #
Si l'ensemble des sites Web d'un compte d'hébergement ne fonctionne pas en même temps, le diagnostic s'élargit.
Vérifie ensuite en particulier :
- si cPanel est accessible
- quel message d'erreur les domaines renvoient
- si tous les domaines utilisent les mêmes serveurs de noms
- Ressources CloudLinux
- Espace de stockage
- modifications communes de PHP ou de configurations
Si plusieurs sites Web indépendants présentent le même problème en même temps, vous devez impérativement le mentionner lors d'une demande de support.
44. Bien classer le délai d'expiration de la connexion #
Un message tel que :
ERR_CONNECTION_TIMED_OUT
ce n'est pas la même chose qu'une erreur HTTP 500.
Dans le cas d'une erreur HTTP 500, une réponse HTTP a déjà été reçue du serveur. En revanche, lors d'un dépassement de délai de connexion, la connexion ou la requête n'a pas pu être achevée à temps.
Notez par conséquent l'erreur exacte du navigateur.
45. Classer correctement l'erreur « Connexion refusée » #
Un message tel que :
ERR_CONNECTION_REFUSED
se distingue également d'une erreur d'application normale.
Le navigateur n'a pas pu établir la connexion souhaitée comme prévu.
Ici aussi, la règle s'applique : ne modifiez pas les plugins WordPress ou les paramètres PHP avant d'être sûr que la requête atteint effectivement l'application web correspondante.
46. Isoler le cache du navigateur comme source d'erreur #
Testez également le site web dans une fenêtre de navigation privée.
Si nécessaire, utilise un deuxième navigateur ou un autre appareil.
Cela vous permet d'exclure certains effets locaux.
Cependant, un cache de navigateur ne provoque pas de véritable erreur fatale PHP côté serveur et ne lève pas de restriction d'accès côté serveur.
47. Tenir compte du cache DNS local #
Suite à des modifications DNS, votre appareil ou votre résolveur DNS peut encore avoir mis en cache des informations plus anciennes.
Si le site Web atteint déjà le nouveau serveur via le réseau mobile, mais pas encore via votre connexion Internet normale, un cache DNS peut jouer un rôle.
Dans ce cas, n'attendez pas automatiquement un nombre fixe d'heures quelconque. La durée réelle du cache dépend, entre autres, de l'enregistrement DNS concerné et de son TTL.
48. Ne pas changer immédiatement le DNS lorsqu'une erreur HTTP s'affiche #
Par exemple, si votre site Web possède déjà :
500 Erreur interne du serveur
s'affiche, un serveur web a été atteint.
Bien qu'après une migration, le DNS puisse pointer vers le mauvais serveur, une véritable erreur HTTP doit d'abord être diagnostiquée sur le serveur effectivement atteint.
49. Ne pas modifier immédiatement PHP si le DNS ne fonctionne pas #
Inversement :
Si le domaine ne se résout pas du tout, le passage de PHP 8.x à une autre version de PHP n'aura aucun impact sur ce problème DNS.
Par conséquent, l'ordre du diagnostic fait gagner beaucoup de temps.
50. Ne pas désactiver toutes les fonctions de sécurité #
Si l'accès est refusé, vous ne devez pas désactiver globalement ModSecurity, les plugins de sécurité ou d'autres mécanismes de protection.
Dans le cas d'une erreur 403, il convient d'abord de déterminer quelle règle spécifique ou quel contrôle d'accès est impliqué.
51. Ne pas modifier plusieurs choses en même temps #
Un mauvais dépannage typique ressemble à ceci :
Site web inaccessible
↓
Modifier le DNS
Changer de version PHP
Supprimer le fichier .htaccess
Désactiver les plugins
Modifier les permissions
Installer le cacheSi le site Web fonctionne à nouveau par la suite, vous ne savez pas quelle modification était pertinente – et vous avez peut-être créé de nouveaux problèmes.
La meilleure méthode :
Déterminer précisément l'erreur
↓
Délimiter le niveau technique
↓
Vérifier les logs et les mesures
↓
Formuler une hypothèse concrète
↓
Effectuer une modification
↓
Tester à nouveauRègle de base : Travaille de l'extérieur vers l'intérieur : d'abord le domaine et la connexion, puis le serveur web et le statut HTTP, et enfin PHP et l'application. Tu éviteras ainsi de faire des modifications sur un plan technique qui n'a rien à voir avec le vrai problème.
Site Web inaccessible : diagnostic dans le bon ordre #
- Notez l'URL complète et le message d'erreur exact.
- Vérifiez plusieurs pages ou sections du site web.
- Testez dans une fenêtre de navigation privée.
- Testez si possible via une deuxième connexion Internet.
- Vérifiez si cPanel est accessible.
- Classez une erreur DNS potentielle.
- Tenez compte des modifications récentes apportées au DNS ou aux serveurs de noms.
- Vérifiez le domaine sous Domaines → Domaines.
- Vérifiez la racine du document.
- Vérifiez dans le gestionnaire de fichiers si les fichiers du site web sont présents.
- Distinguez les problèmes SSL des erreurs HTTP.
- Vérifie le code d'état HTTP réel.
- Ouvrir en cas d'erreurs côté serveur Valeurs mesurées → Erreur.
- Comparez l'erreur aux modifications récentes.
- Vérifiez si nécessaire
.htaccesset les autorisations de fichiers. - Vérifiez la version de PHP, les extensions et les limites des applications PHP.
- Vérifiez les plugins WordPress, les thèmes et les journaux de débogage.
- En cas de problèmes sporadiques, vérifiez les ressources CloudLinux.
- Prenez en compte les tâches cron et les tâches d'arrière-plan.
- Vérifiez l'espace de stockage.
- Modifiez toujours une seule cause possible à la fois.
- Testez ensuite exactement le même profil de dysfonctionnement à nouveau.
Diagnostic rapide : par où commencer ? #
| Symptôme | Premier point de contrôle |
|---|---|
DNS_PROBE_FINISHED_NXDOMAIN | Vérifier le domaine et le DNS |
| Le site Web affiche un contenu incorrect après la modification du DNS | Vérifier la destination DNS et la racine du document |
| Alerte de certificat | Vérifier le certificat SSL et le nom d'hôte |
ERR_TOO_MANY_REDIRECTS | Vérifier les redirections et .htaccess |
403 Interdit | Vérifier les autorisations et les règles de sécurité |
404 Non trouvé | Vérifier l'URL, les fichiers ou les règles de réécriture |
500 Erreur interne du serveur | Vérifier le journal des erreurs et les erreurs PHP/application |
503 Service indisponible | Vérifier le journal des erreurs, l'application et les ressources |
508 Limite de ressources atteinte | Vérifier les ressources CloudLinux |
| seule la zone d'administration WordPress est endommagée | Vérifier WordPress, les extensions et le journal des erreurs |
| injoignable seulement à certaines heures | Vérifier les ressources et les tâches en arrière-plan |
| inaccessible uniquement via sa propre connexion Internet | vérifier le réseau local, le DNS et un éventuel blocage IP |
Ce qu'il ne faut pas faire en cas de panne de site web #
Évitez en particulier :
- Modifier les enregistrements DNS par précaution
- Changer de version PHP au hasard
.htaccesssupprimer sans sauvegarde- Autorisations de fichiers par lot sur
777mettre - désactiver toutes les fonctions de sécurité
- supprimer plusieurs extensions en même temps
- Modifier les tables de base de données par suspicion
- Reconfigurer les certificats SSL malgré une erreur PHP
- effectuer plusieurs modifications techniques simultanément
Quelles informations aident le support de CURIAWEB ? #
Si vous ne pouvez pas déterminer la cause vous-même, des informations aussi précises que possible aident lors de l'analyse technique.
Note :
- domaine concerné
- URL complète concernée
- message d'erreur exact
- Date et heure exactes
- si le site Web est inaccessible en permanence ou de manière sporadique
- si une seule page ou l'ensemble du site web est concerné
- si d'autres domaines fonctionnent sur le même hébergement
- si le site Web est accessible via une autre connexion Internet
- entrées de journal des erreurs pertinentes
- valeurs ou erreurs CloudLinux anormales
- modifications récentes
En cas d'erreur reproductible, vous devez également indiquer les étapes exactes permettant de déclencher le problème.
Résumé #
Si un site Web est inaccessible, vous ne devez pas modifier immédiatement WordPress, PHP ou DNS. Il faut d'abord déterminer à quel niveau technique se produit l'erreur.
Commencez par le message d'erreur exact et l'URL concernée. Vérifiez ensuite si vous êtes le seul concerné, ou si une seule page, un domaine ou l'ensemble du compte d'hébergement l'est.
En cas d'erreurs DNS, il faut d'abord examiner la résolution de noms. Si le serveur web est atteint, les codes d'état HTTP tels que 403, 500, 503 ou 508 servent de guides pour la suite du diagnostic.
En cas de problèmes côté serveur, le journal d'erreurs cPanel et – pour les erreurs sporadiques – l'utilisation des ressources CloudLinux comptent parmi les outils de diagnostic les plus importants. Pour les applications PHP, il faut y ajouter la version de PHP, les extensions et les limites. Pour WordPress, vous devez également prendre en compte les extensions, les thèmes et les journaux de débogage.
Le contexte temporel est toujours particulièrement précieux : si le site Web change juste après une modification DNS, un changement de PHP, une mise à jour de plugin ou une modification de .htaccess est tombée en panne, commence l'enquête exactement là.
La règle la plus importante est : D'abord déterminer où la requête échoue, puis examiner précisément ce niveau technique.
