Objectif
CloudLinux est conçu pour les environnements d’hébergement mutualisé : LVE encadre l’usage des ressources par compte, tandis que CageFS fournit à l’utilisateur une vue isolée du système de fichiers. Ces mécanismes réduisent l’impact qu’un site surchargé ou compromis peut avoir sur les autres comptes, sans constituer une garantie absolue contre toutes les attaques.[1] [2]
La prévention associe un hébergement web adapté, un certificat SSL et le guide pour renforcer la sécurité de l’hébergement.
Prérequis
Vous devez connaître le domaine concerné, le compte d’hébergement auquel il appartient et les horaires des ralentissements ou erreurs. L’accès aux indicateurs CloudLinux dans le panneau peut varier selon le forfait et les droits. Les commandes système mentionnées ci-dessous sont destinées aux administrateurs de serveur ; un client mutualisé ne doit pas les exécuter sans autorisation explicite de NovaHoster.
Procédure
1. Distinguer isolation de fichiers et limitation de ressources
CageFS isole la vue du système de fichiers et limite notamment la visibilité des fichiers de configuration et des processus d’autres utilisateurs. LVE limite, selon la configuration, le CPU, la mémoire, les entrées concurrentes, les processus, les opérations d’E/S et le débit d’E/S.[1] [2]
Ces fonctions ont des rôles différents : CageFS ne rend pas une application à jour à la place de son propriétaire, et LVE ne corrige pas une boucle PHP, une requête SQL coûteuse ou une extension vulnérable.
2. Consulter les indicateurs dans le panneau
Depuis le panneau de contrôle, ouvrez l’outil CloudLinux ou le tableau de suivi des ressources s’il est visible. Comparez la période d’erreur avec les indicateurs affichés : CPU, mémoire physique, E/S, IOPS, processus et processus entrants. Notez si la limite est atteinte ponctuellement ou de manière répétée.
Les noms et unités peuvent différer selon le panneau. Ne comparez pas directement une valeur d’un outil à une autre sans vérifier sa définition ; par exemple, la mémoire physique et la mémoire virtuelle ne décrivent pas exactement la même consommation.
3. Relier l’indicateur au symptôme
Une saturation CPU ou E/S peut ralentir le site. Une limite de processus entrants peut contribuer à des réponses HTTP 508, tandis qu’une limite mémoire ou de processus peut être associée à des erreurs 500 ou 503, selon l’application et le serveur.[1] Une erreur isolée ne prouve cependant pas qu’une limite CloudLinux est en cause : consultez les journaux et les métriques applicatives.
4. Chercher la cause applicative
Examinez les extensions récemment installées, les tâches cron, les imports, les sauvegardes, les robots, les pics de trafic et les requêtes lentes. Activez les journaux applicatifs adaptés, sans exposer de données sensibles. Pour un CMS, désactivez temporairement un composant suspect uniquement si vous disposez d’un plan de retour arrière.
5. Demander une vérification de quota ou d’isolation
Si les dépassements sont réguliers et justifiés par l’activité du site, demandez à NovaHoster si une optimisation, une augmentation de ressources ou une migration vers une formule différente est possible. Une modification de limite n’est pas automatique et peut dépendre du forfait, du serveur et des droits administrateur.
Demandez également confirmation que le compte est bien placé dans l’environnement d’isolation prévu. Ne concluez pas à une absence de CageFS uniquement parce qu’un chemin système ou une commande se comporte différemment : le support doit vérifier la configuration effective.
6. Ne pas désactiver les protections pour contourner un problème
Désactiver une isolation ou augmenter largement une limite sans diagnostic peut masquer la cause et accroître le risque pour le compte. Les changements de configuration serveur doivent être réalisés ou validés par NovaHoster.
Chez NovaHoster, concrètement
Le guide ci-dessus décrit CloudLinux en général — ce qu'il fait, comment il est conçu. Cette section dit ce que ça donne sur nos machines, avec les chiffres exacts de nos offres. « Des ressources garanties » ne veut rien dire tant qu'on ne sait pas combien, et c'est précisément ce que la plupart des hébergeurs ne publient pas.
Vos limites réelles, pack par pack
Sur nos packs e-commerce, la limite qui compte n'est pas le disque mais le nombre de requêtes PHP traitées en même temps : 40 sur START, 60 sur BUSINESS, 80 sur ULTIMATE. Elles s'accompagnent de 2, 3 ou 4 cœurs garantis et de 4, 6 ou 8 Go de mémoire, pour 100, 200 ou 300 Go de stockage NVMe. Le tableau complet est sur la page hébergement e-commerce.
« Garantis » a ici un sens précis, et c'est tout l'objet de LVE : ces cœurs vous sont réservés, et un voisin qui sature les siens ne peut pas les prendre. C'est exactement ce que la mention « ressources illimitées » de certaines offres du marché ne dit pas — illimité y signifie non garanti, donc partagé jusqu'à ce que quelqu'un se plaigne. Notre comparatif des hébergeurs web en Tunisie détaille cette différence.
Une conséquence directe pour vous : il est possible de calculer à l'avance si votre site tient. Ce n'est pas le cas sur une offre dont les limites ne sont pas publiées, où l'on ne découvre le plafond qu'en le heurtant.
Pourquoi une page en cache ne consomme presque rien
C'est le point qui change tout et que le guide générique ne peut pas dire, parce qu'il dépend de ce que vous hébergez. Une page identique pour tous les visiteurs — un article, une page de présentation, une page de tarifs — est fabriquée une fois puis resservie telle quelle. Elle ne compte pratiquement pas dans votre limite de requêtes simultanées.
Un panier, un compte client, un tunnel de commande sont différents pour chaque visiteur. Le serveur les refabrique à chaque appel, en interrogeant la base de données. Ce sont eux qui consomment, et ce sont eux qu'aucun cache ne peut absorber.
D'où une conclusion qui surprend souvent : un blog à dix mille visiteurs par jour peut tenir sur un petit pack, là où une boutique à cinq cents visiteurs quotidiens sature. Ce n'est pas le nombre de visiteurs qui décide, c'est la proportion de pages incachables. Quand on nous demande « combien de visiteurs mon pack supporte-t-il », la réponse honnête commence donc par une question sur le type de site.
Le symptôme qu'on nous décrit le plus souvent, et ce qu'il signifie ici
« Le site est lent à certaines heures et rapide la nuit. » Sur un hébergement sans ressources garanties, c'est la signature d'un voisin encombrant : quelqu'un d'autre consomme, vous subissez. Chez nous, ce diagnostic-là est exclu par construction — les cœurs sont réservés.
Ce que ça veut dire alors : c'est votre site qui atteint sa limite au moment où son trafic culmine. La distinction n'est pas théorique, parce que le remède n'est pas le même. Dans le premier cas il faut changer d'hébergeur ; dans le second, il faut soit réduire ce que le site consomme par visiteur, soit monter d'un pack.
Avant de monter, vérifiez ces trois postes, dans cet ordre. Les images téléversées en pleine résolution puis réduites à l'affichage — c'est le premier coupable, et il ne coûte rien à corriger. Les extensions accumulées, dont certaines désactivées mais toujours chargées. Et le cache : une boutique qui ne met rien en cache refabrique même sa page d'accueil à chaque visite.
Si après ça la limite reste atteinte, le changement de pack se fait en un clic depuis l'espace client, au prorata, sans coupure ni migration.
Lire une erreur 508 sans paniquer
Une erreur 508 n'est pas une panne du serveur et ne signale pas un problème chez nous. Elle dit qu'une requête a attendu son tour trop longtemps parce que votre compte avait atteint sa limite de requêtes simultanées.
Le comportement est d'ailleurs volontairement doux : au-delà de la limite, les requêtes attendent plutôt que d'être refusées. La 508 n'arrive qu'après une attente prolongée. Autrement dit, vous ne passez pas de « tout va bien » à « tout est cassé » : le site ralentit d'abord, et c'est le signal.
C'est aussi pour ça que nous regardons nos relevés et que nous vous prévenons quand le dépassement devient régulier. Nous préférons vous dire de monter d'un pack que vous laisser perdre des visiteurs sans comprendre pourquoi.
Ce que CageFS ne protège pas — et qui reste votre part
CageFS isole votre compte de ceux des voisins : vous ne voyez pas leurs fichiers, ils ne voient pas les vôtres, et un compte compromis ne contamine pas la machine. C'est solide, et c'est la raison pour laquelle nous ne le désactivons jamais, même quand un client le demande pour contourner une gêne.
En revanche, il ne vous protège pas de vous-même. Une extension WordPress vulnérable installée sur votre propre espace s'exécute avec vos droits, dans votre cage, et CageFS n'y voit rien d'anormal — parce que du point de vue du système, il n'y a rien d'anormal. Le code que vous avez installé fait ce qu'il fait.
C'est pour cette raison qu'Imunify360 tourne en plus, et que les mises à jour restent votre responsabilité. Le guide Imunify360 traite le cas de l'infection avérée, et sécuriser WordPress contre le piratage décrit la prévention côté application.
Une dernière chose que nous ne ferons pas : relever vos limites « exceptionnellement » pour faire passer un site mal optimisé. Ce n'est pas de la rigidité administrative — un compte qui consomme sans limite sur une machine partagée est précisément ce que LVE existe pour empêcher, et l'accepter pour vous reviendrait à le faire subir à quelqu'un d'autre. Quand un site a réellement dépassé le cadre du mutualisé, la réponse est un VPS, et nous le disons avant que vous n'ayez heurté le mur.
Cas d’erreur et diagnostic
| Symptôme | Piste de diagnostic | Action |
|---|---|---|
| Erreur HTTP 508 récurrente | Limite de processus entrants possiblement atteinte | Comparer l’heure des erreurs avec les indicateurs CloudLinux et les journaux ; demander confirmation au support. |
| Erreurs 500 ou 503 pendant une tâche | Limite mémoire/processus ou erreur applicative | Reproduire avec une tâche réduite, consulter le journal PHP et demander les métriques LVE. |
| Site lent sans dépassement visible | Requête SQL, I/O disque, réseau, application ou incident externe | Examiner les journaux et la base ; ne pas attribuer automatiquement le problème à CloudLinux. |
| Commande système introuvable | Commande non exposée dans l’environnement client ou accès non administrateur | Ne pas chercher à sortir de l’environnement isolé ; demander au support les données nécessaires. |
| Un site compromis semble lire des fichiers voisins | Configuration d’isolation à vérifier ou faille applicative | Isoler le site, changer les accès et contacter NovaHoster immédiatement. |
Questions fréquentes
CageFS protège-t-il contre les malwares ?
LVE rend-il les ressources illimitées ?
Pourquoi une limite peut-elle provoquer une erreur 508 ?
Puis-je modifier moi-même les limites LVE ?
CageFS isole-t-il plusieurs sites du même compte ?
Quelles sont mes limites exactes sur mon pack ?
Mon site est lent aux heures de pointe, est-ce un voisin encombrant ?
Un blog à fort trafic consomme-t-il plus qu'une petite boutique ?
Que signifie exactement une erreur 508 ?
Pouvez-vous relever mes limites exceptionnellement ?
Puis-je changer de pack sans coupure ?
Quand contacter l’Espace client NovaHoster
Contactez NovaHoster si les erreurs 508, 500 ou 503 sont récurrentes, si un compte atteint ses limites malgré une charge habituelle, si vous soupçonnez une lecture de fichiers appartenant à un autre utilisateur ou si vous avez besoin d’une confirmation sur CageFS, LVE ou l’isolation entre sites. Fournissez les horaires, le domaine, les codes HTTP et les captures d’indicateurs, sans inclure de secrets.
Guides liés
Sources techniques
Les permissions et options visibles peuvent dépendre de votre formule ou de vos droits. Faites vérifier le contexte depuis l’Espace client.
Demander une vérification