Créer un virtual host Apache sur Ubuntu 22.04 : guide complet pour héberger votre site facilement

Un virtual host Apache Ubuntu 22.04, ce n’est pas du décor. C’est la brique qui permet à Apache de distinguer vos sites à partir du nom demandé par le client, puis de servir le bon dossier sans mélanger les projets. En pratique, vous gagnez un hébergement multiple sites propre, lisible, et surtout maintenable.

Le vrai sujet, ce n’est pas de réciter des commandes au hasard. C’est de comprendre la logique : un nom d’hôte, un dossier racine, un fichier de configuration, puis un test de syntaxe avant le rechargement. Faites ça dans cet ordre, et vous évitez 80 % des erreurs classiques, surtout celles qui donnent une page par défaut au lieu de votre site.

Comment Apache choisit-il le bon virtual host ?

Apache sélectionne le vhost en fonction de l’en-tête Host envoyé par le navigateur. Si le ServerName ou le ServerAlias correspond, Apache pointe vers le bon DocumentRoot. Sinon, il tombe sur le site par défaut. C’est simple, mais un mauvais nom casse tout.

La conséquence est directe : si votre nom de domaine, votre entrée /etc/hosts ou votre DNS ne correspond pas à la configuration, Apache sert le mauvais site. Voilà pourquoi un vhost bien écrit peut quand même échouer en apparence. Le moteur fait son travail ; c’est l’adresse qui ne colle pas.

Quels prérequis vérifier avant de commencer ?

Avant de créer un fichier de configuration Apache, vérifiez qu’Apache2 est installé, que vous avez sudo, et que vous savez quel nom le site doit répondre. Pour un test local, un nom comme monsite.test est plus propre qu’un bricolage approximatif. Pour un domaine réel, il faut aussi un enregistrement DNS valide.

• Apache2 installé et actif sur Ubuntu 22.04.
• Accès administrateur via sudo.
• Nom local de test ou vrai nom de domaine.
• Arborescence du projet définie à l’avance.
• Si UFW est actif, autorisation du trafic HTTP/HTTPS.

Créer la structure de dossiers du site

Le dossier du site doit exister avant la configuration du vhost. C’est là que vous placez vos fichiers web, généralement dans /var/www/. Pour un projet clair, je conseille une arborescence du type /var/www/monsite.test/public_html. Vous gardez ainsi un DocumentRoot Apache net et sans ambiguïté.

Sur le terrain, l’erreur la plus fréquente n’est pas spectaculaire : un dossier mal attribué, un propriétaire incohérent, puis Apache renvoie un 403. Ce n’est pas “magique”, c’est juste une question de permissions et de traversée de répertoires. Le compte www-data doit pouvoir lire et entrer dans le chemin jusqu’au contenu servi.

sudo mkdir -p /var/www/monsite.test/public_html
sudo chown -R $USER:www-data /var/www/monsite.test
sudo find /var/www/monsite.test -type d -exec chmod 750 {} \;
sudo find /var/www/monsite.test -type f -exec chmod 640 {} \;

echo '<h1>monsite.test fonctionne</h1>' | sudo tee /var/www/monsite.test/public_html/index.html

Cette combinaison reste lisible : vous gardez la main sur les fichiers, tandis que www-data lit ce qu’il doit servir. Si vous serrez trop les droits avec un dossier inaccessible, Apache ne devine rien. Il échoue. Proprement, mais il échoue quand même.

Où créer le fichier de configuration Apache ?

Le fichier du virtual host va dans /etc/apache2/sites-available/. C’est là qu’on déclare le site, avant de l’activer dans sites-enabled. Le nom du fichier doit rester explicite : monsite.test.conf vaut mieux qu’un test1.conf sorti du néant. Plus vous êtes précis, moins vous perdez du temps plus tard.

Voici un exemple complet, prêt à copier. Il fonctionne pour un site local ou un site de préproduction, tant que le nom est cohérent avec votre DNS ou votre fichier /etc/hosts. Ajoutez le bloc, adaptez le nom, puis enregistrez.

<VirtualHost *:80>
    ServerName monsite.test
    ServerAlias www.monsite.test

    DocumentRoot /var/www/monsite.test/public_html

    ErrorLog ${APACHE_LOG_DIR}/monsite.test-error.log
    CustomLog ${APACHE_LOG_DIR}/monsite.test-access.log combined

    <Directory /var/www/monsite.test/public_html>
        Options FollowSymLinks
        AllowOverride All
        Require all granted
    </Directory>
</VirtualHost>

Le trio à surveiller, c’est ServerName, DocumentRoot et le bloc <Directory>. Si le nom ne correspond pas, le vhost ne sera pas sélectionné. Si le chemin est faux, Apache cherchera un dossier inexistant. Si les droits sont trop serrés, vous hériterez d’un 403. Oui, la routine habituelle.

Comment activer et valider le virtual host sans casser Apache ?

Activez le site avec a2ensite, testez la syntaxe avec apache2ctl configtest, puis rechargez Apache. Pas besoin de redémarrer brutalement si un simple rechargement suffit. Ce réflexe évite de couper des connexions pour rien et vous force à valider la config avant de la pousser en service.

sudo a2ensite monsite.test.conf
sudo apache2ctl configtest
sudo systemctl reload apache2

Si la page par défaut reste affichée, le problème n’est presque jamais “Apache qui n’écoute pas”. Il s’agit plutôt d’un ServerName incorrect, d’un site non activé ou d’un vhost qui passe après le défaut dans la hiérarchie. Le moteur ne lit pas vos intentions, seulement la configuration.

Comment tester un virtual host sans DNS ?

En local, /etc/hosts permet de faire pointer le nom vers l’IP du serveur sans toucher au DNS. C’est la méthode la plus rapide pour valider un virtual host local. Elle a une limite claire : le test reste machine par machine. Pratique, oui. Magique, non.

sudo nano /etc/hosts

Ajoutez ensuite une ligne du genre :

127.0.0.1   monsite.test www.monsite.test

Vous pouvez ensuite tester la résolution et la réponse HTTP avec des commandes simples. Si Apache répond au bon nom, votre vhost est déjà bien en place. Sinon, il faut vérifier le lien entre le nom, la configuration et le dossier servi.

ping -c 1 monsite.test
curl -I http://monsite.test
curl -H "Host: monsite.test" http://127.0.0.1/

Comment vérifier que le site répond bien dans le navigateur et dans les logs ?

Quand le navigateur affiche la bonne page, le plus dur est déjà fait. Pour ne pas vous arrêter au ressenti, contrôlez aussi les logs par site. C’est là qu’on distingue un simple oubli de permission d’un vrai problème de routage. Les logs ne mentent pas ; ils sont juste moins polis qu’un tutoriel.

Sur le serveur, surveillez les fichiers définis dans ErrorLog et CustomLog. Un 403 Forbidden pointe souvent vers les permissions ou le bloc <Directory>. Une page par défaut indique plutôt un souci d’activation ou de correspondance de nom. Un 404, lui, montre souvent un DocumentRoot bancal.

sudo tail -f /var/log/apache2/monsite.test-error.log
sudo tail -f /var/log/apache2/monsite.test-access.log

Dépannage : les erreurs qui reviennent tout le temps

Le premier déploiement rate souvent pour les mêmes raisons. Pas parce qu’Apache serait capricieux, mais parce qu’on saute une étape ou qu’on copie une configuration sans l’adapter. Le bon réflexe consiste à relire le nom, le chemin, les droits, puis l’activation du site. Dans cet ordre, pas à l’envers.

• Erreur 403 Forbidden : droits insuffisants, chemin inaccessible, ou bloc <Directory> incomplet.
• Page Apache par défaut : a2ensite oublié, ServerName incorrect, ou site par défaut encore prioritaire.
• Erreur de syntaxe : balises <VirtualHost> mal fermées, faute dans une directive, chemin inexistant.
• Le site ne répond pas en local : entrée /etc/hosts absente ou nom mal orthographié.

Que faire si vous voulez ajouter HTTPS ensuite ?

Le HTTP sur le port 80 sert souvent de base, mais en production vous finirez presque toujours par ajouter le 443. Pour cela, il faut activer mod_ssl, disposer d’un certificat valide, puis créer un second bloc <VirtualHost *:443>. Le point important : HTTPS ne remplace pas le vhost, il l’étend.

Avec Let’s Encrypt, la logique reste la même : vous gardez votre vhost HTTP pour la validation et la redirection, puis vous ajoutez la couche TLS. Le détail dépend de votre domaine réel et de votre exposition réseau. En local, vous n’allez pas vous amuser à simuler une autorité de certification pour rien.

sudo a2enmod ssl
sudo systemctl reload apache2

Bonnes pratiques pour un hébergement multiple sites propre

Si vous gérez plusieurs projets sur la même machine, gardez une règle simple : un dossier, un fichier .conf, un log, un nom. Cette discipline évite les mélanges et rend le débogage nettement plus supportable. Le jour où vous devrez relire une config six mois plus tard, vous serez content d’avoir fait ça proprement.

• Un vhost par site, jamais un dossier fourre-tout.
• Des noms de fichiers explicites dans sites-available.
• Des logs séparés pour chaque projet.
• Un configtest avant chaque rechargement.
• Une note de maintenance avec le chemin, le nom et l’objectif du vhost.

FAQ

Quelle différence entre sites-available et sites-enabled ?

sites-available contient les fichiers de configuration disponibles sur la machine. sites-enabled contient seulement les sites activés, généralement sous forme de lien symbolique. Apache ne charge que ce qui est dans sites-enabled, d’où l’intérêt de a2ensite.

Comment tester un virtual host sans nom de domaine public ?

Le plus simple consiste à utiliser /etc/hosts pour faire pointer un nom local vers 127.0.0.1 ou vers l’IP du serveur. Vous pouvez ensuite tester avec curl ou le navigateur. C’est idéal pour valider la configuration avant le DNS réel.

Pourquoi Apache affiche encore la page par défaut ?

Le plus souvent, le site n’est pas activé, le ServerName ne correspond pas au nom demandé, ou le site par défaut reste prioritaire. Vérifiez aussi que le nom résolu par le client est bien celui déclaré dans le vhost. Apache fait ce qu’on lui dit, pas ce qu’on espère.

Faut-il redémarrer Apache après chaque modification ?

Pas forcément. Quand c’est possible, un simple systemctl reload apache2 suffit et évite de couper les connexions. En revanche, testez toujours la syntaxe avec apache2ctl configtest avant de recharger. Le réflexe est plus rentable qu’un redémarrage à l’aveugle.

Pour un premier déploiement, le bon ordre reste le même : dossier, configuration, activation, test, résolution de nom, puis vérification dans le navigateur et les logs. Si vous gardez cette séquence, le virtual host Apache sur Ubuntu 22.04 cesse d’être un petit piège de débutant et devient juste un outil de plus dans votre setup.