Un site inaccessible, un nouveau domaine à héberger ou un serveur à administrer : dans ces situations, le nom Apache apparaît souvent dans la documentation ou les fichiers de configuration. Il désigne un logiciel serveur web, aussi appelé httpd, qui reçoit des requêtes HTTP et renvoie des pages, des fichiers ou des réponses produites par d’autres composants.
Quel rôle Apache joue-t-il entre le navigateur et le site ?
Quand une personne ouvre une adresse web, son navigateur contacte un serveur et demande une ressource. Apache HTTP Server, souvent nommé simplement Apache ou httpd, reçoit cette requête, applique la configuration prévue et renvoie une réponse : fichier statique, redirection, refus d’accès ou résultat fourni par un programme associé. Le logiciel n’est donc ni le site lui-même ni l’ordinateur qui l’héberge.
Une adresse web comporte plusieurs éléments. La documentation Apache décrit une URL à partir du protocole, du nom du serveur, du chemin demandé et, éventuellement, d’une chaîne de requête. Le chemin peut correspondre à un fichier ou à un traitement dynamique. Cette distinction aide à localiser le problème : une page absente peut relever du chemin ou des fichiers, tandis qu’un échec de traitement peut se trouver dans l’application. La présentation des requêtes et des réponses figure dans le démarrage de la documentation Apache HTTP Server.
Apache est souvent choisi parce qu’il peut servir des fichiers, organiser plusieurs sites sur un hôte et étendre ses fonctions au moyen de modules. Mais son nom seul ne garantit ni compatibilité ni performance : il faut connaître l’application, le système d’exploitation, la façon dont le serveur a été installé et les contraintes de l’hébergement. Les chemins de configuration diffèrent selon les distributions et le mode d’installation ; partez des fichiers réellement présents sur la machine, pas d’un exemple trouvé pour un autre environnement.
Quels critères examiner avant de retenir une configuration ?
Commencez par le rôle confié au serveur. S’agit-il de distribuer des pages statiques, d’héberger plusieurs domaines, de transmettre des requêtes à une application ou de faire cohabiter ces fonctions ? La réponse détermine les modules nécessaires et les éléments à surveiller. N’activez pas des composants sans besoin identifié : une configuration plus simple est généralement plus facile à relire et à maintenir.
Le second critère est le modèle de traitement des connexions. Un MPM (module de traitement multiple) détermine comment Apache organise ses processus et ses fils d’exécution. Les variantes ne fonctionnent pas toutes de la même manière : worker associe plusieurs processus à plusieurs fils, tandis que event cherche à libérer les fils de traitement lorsqu’une connexion persistante attend une nouvelle requête. Selon la documentation officielle, le réglage AsyncRequestWorkerFactor de event a une valeur par défaut de 2 ; la même page avertit que modifier ce facteur exige des mesures et des essais adaptés au trafic. Ce nombre n’est donc pas une capacité garantie ni un réglage universel. Comparez les descriptions et les paramètres dans la référence Apache du module MPM event et de son facteur de connexions.
Enfin, évaluez les ressources disponibles et les objectifs de disponibilité. Mesurez la charge réelle plutôt que de choisir des valeurs de concurrence au hasard, puis observez les temps de réponse, la mémoire et les erreurs. Si le serveur alimente un site métier, sa continuité dépend aussi du matériel et de l’alimentation électrique : un onduleur adapté à un serveur ou un NAS peut contribuer à éviter un arrêt brutal lors d’une coupure, sans remplacer les sauvegardes ni un plan de reprise.
Comment Apache distingue-t-il plusieurs sites ?
Un hôte virtuel (ou virtual host) est un bloc de configuration qui associe un nom de domaine à des réglages propres, notamment un répertoire de contenu. Apache peut ainsi servir plusieurs sites depuis une même machine. En hébergement par nom, différents domaines peuvent partager une adresse IP ; Apache utilise le nom reçu dans la requête pour sélectionner la configuration appropriée. Cette option est généralement plus simple que l’hébergement par adresse IP, qui demande une adresse distincte pour chaque hôte virtuel.
Chaque domaine doit toutefois pointer vers la bonne adresse dans le DNS, et Apache doit posséder un ServerName explicite pour chaque hôte concerné. Si aucune correspondance de nom n’est trouvée, le premier hôte virtuel configuré pour l’adresse et le port correspondants peut recevoir la requête. Un site inattendu ne signifie donc pas forcément que son contenu a disparu : l’ordre ou le nom dans la configuration peut être en cause. Les règles de sélection et la recommandation d’indiquer ServerName sont détaillées dans la documentation Apache sur les hôtes virtuels fondés sur le nom de domaine.
Pour vérifier votre configuration, comparez les domaines publiés avec les blocs <VirtualHost>, leurs noms, leurs alias et leurs DocumentRoot. Vérifiez ensuite les réponses pour chaque domaine, y compris le domaine par défaut. Si Apache se trouve entre les utilisateurs et un autre serveur, distinguez bien le rôle d’un serveur web de celui d’un serveur proxy : le second relaie les requêtes vers une autre destination selon des règles définies.
Comment appliquer un premier réglage sans perturber le site ?
Repérez d’abord le fichier principal, souvent nommé httpd.conf, et les fichiers inclus par la directive Include. Identifiez aussi le service qui lance Apache sur votre système : les commandes d’administration varient selon la distribution et la méthode d’installation. Avant de modifier quoi que ce soit, conservez une copie de la configuration et notez l’état initial du service. Pour un changement, ne modifiez qu’un point à la fois et gardez à portée de main la procédure de retour arrière.
Un premier essai peut consister à définir un hôte virtuel de test avec un nom et un répertoire de contenu distincts. Faites pointer un nom de test vers le serveur, ou utilisez une résolution locale lorsque vous ne souhaitez pas exposer le site. Contrôlez que le domaine de test renvoie le contenu attendu et que le domaine existant continue de servir le bon site. Évitez de tester directement une configuration nouvelle sur le seul domaine de production si un environnement de préproduction est disponible.
Avant de recharger le service, lancez le contrôle de syntaxe proposé par votre installation, généralement via apachectl configtest ou une commande équivalente. Une configuration syntaxiquement correcte peut néanmoins comporter une erreur de logique, par exemple un chemin erroné ou une règle qui couvre trop de requêtes. La documentation Apache indique qu’un redémarrage vérifie la syntaxe et refuse de s’effectuer si une erreur est détectée. Un rechargement gracieux permet au serveur de relire ses fichiers tout en laissant les processus terminer les requêtes en cours. Utilisez la commande correspondant à votre système et confirmez ensuite que le service fonctionne.
Comment vérifier le résultat et diagnostiquer un échec ?
Testez avec le navigateur et, si vous les maîtrisez, des commandes de requête HTTP. Vérifiez séparément le nom de domaine, le protocole, le chemin, le code de réponse et le contenu renvoyé. Un test depuis le serveur lui-même permet de distinguer un problème local de service d’un problème de DNS ou de réseau. Si plusieurs sites partagent Apache, répétez le contrôle pour chacun, y compris les variantes de nom avec et sans préfixe www lorsqu’elles sont configurées.
Les journaux complètent ces tests. Le journal d’accès indique les requêtes reçues et leurs codes de réponse ; le journal d’erreurs aide à repérer une directive invalide, un accès refusé ou un problème de ressource. Les codes de réponse commençant par 2 correspondent à une réponse réussie, ceux commençant par 3 à une redirection, ceux commençant par 4 à une erreur côté client et ceux commençant par 5 à une erreur côté serveur. Ces familles orientent l’enquête, mais ne suffisent pas à expliquer la cause.
Prévoyez également la rotation des journaux : sans limite, ils grossissent et deviennent moins pratiques à analyser. Apache donne un ordre de grandeur d’au moins 1 Mo de journal d’accès pour 10 000 requêtes sur un serveur modérément sollicité. Ses exemples montrent une rotation toutes les 86 400 secondes, soit 24 heures, ou lorsque le fichier atteint 100 Mo. Ce sont des exemples de configuration, pas des seuils obligatoires : adaptez la politique au volume, à l’espace disque et aux règles de conservation de votre organisation. Les options et les précautions liées aux journaux sont présentées dans la documentation Apache sur les journaux d’accès, d’erreurs et leur rotation.
Pour isoler un incident, rapprochez l’heure d’une requête dans le journal d’accès de l’entrée correspondante dans celui des erreurs. Si Apache transmet la requête à une application, comparez aussi avec les journaux applicatifs. Une erreur serveur 500 peut venir de cette application, d’une règle Apache ou d’un service indisponible ; attribuer la cause au seul serveur web serait prématuré. Les bases d’administration réseau et serveur s’inscrivent plus largement dans la rubrique Technologie.
Questions fréquentes
Apache HTTP Server est-il un système d’exploitation ?
Non. Apache HTTP Server est un logiciel serveur web qui s’exécute sur un système d’exploitation. Il reçoit les requêtes des navigateurs et fournit les ressources configurées. Le système d’exploitation, lui, gère notamment les processus, les fichiers et le réseau. Un serveur physique ou virtuel peut héberger Apache, mais les deux notions ne désignent pas la même chose.
Apache peut-il héberger plusieurs sites sur une même machine ?
Oui. Les hôtes virtuels permettent d’appliquer une configuration différente selon le nom de domaine demandé, par exemple en servant des répertoires distincts. Pour que cela fonctionne, les noms doivent aussi être résolus vers l’adresse adéquate et les blocs de configuration doivent identifier les domaines attendus. Vérifiez quel hôte est défini par défaut pour éviter qu’un domaine mal configuré affiche le mauvais site.
Où chercher lorsqu’un site renvoie une erreur ?
Commencez par le journal d’erreurs Apache et relevez l’heure, le chemin demandé et le message associé. Consultez ensuite le journal d’accès pour voir le code de réponse et la requête concernée. Si Apache sert de relais vers une application, vérifiez également les journaux de cette application. Une erreur HTTP 500 signale une défaillance côté serveur, mais ne désigne pas à elle seule sa cause.
