Résolution du problème de landing page tekdhi.dev (2026-05-27)¶

Problème rencontré¶

La landing page principale de tekdhi.dev ne chargeait plus du tout (timeout/connection refused). Les sous‑domains (psycho., autopaie., boutiques., gestfinclair.) étaient également inaccessibles.

Analyse¶

Vérification du service Caddy : le conteneur n'était pas en cours d'exécution.
Le fichier Caddyfile situé dans /home/kanmaber/shared_infra/Caddyfile était correct et définissait les reverse‑proxy vers les différents services locaux (psycho sur 127.0.0.1:3901, landings sur les dossiers partagés, etc.).
Le pare‑feu UFW autorisait déjà le trafic 80/tcp et 443/tcp uniquement vers Caddy, les autres ports (bases de données, Redis) étaient bloqués.
Aucun changement récent n'avait été appliqué au DNS ou au VPS (Hetzner) ; le domaine tekdhi.dev résolvait correctement l'IP du VPS.

Solution appliquée¶

Redémarrage du conteneur Caddy :
```
cd /home/kanmaber/shared_infra
docker compose down   # arrêt propre si nécessaire
docker compose up -d  # relance en mode détaché
```
Le conteneur utilise le mode réseau host (network_mode: host) pour pouvoir atteindre les services écoutant sur 127.0.0.1 du host (notamment l'application PsychoEnLigne sur le port 3901).
Vérification du déploiement :
Les logs du conteneur montrent que Caddy a chargé le Caddyfile sans erreur et a commencé à servir les sites sur les ports 80 et 443.
Aucun erreur de TLS (les certificats sont gérés automatiquement par Caddy via son stockage interne).

Re‑test des URLs :

curl -I https://tekdhi.dev
curl -I https://psycho.tekdhi.dev
curl -I https://autopaie.tekdhi.dev
curl -I https://boutiques.tekdhi.dev
curl -I https://gestfinclair.tekdhi.dev

Tous renvoient HTTP/2 200.

Mesures de sécurité en place¶

UFW : seules les portes 80/tcp et 443/tcp sont autorisées entrant ; tout le reste est refusé par défaut.
Caddy comme unique point d'entrée : aucun autre service n'est exposé directement sur l'interface publique ; les bases de données (PostgreSQL, Redis) ne sont accessibles que depuis le host ou via le réseau Docker partagé (shared_infra).
Conteneur Caddy en mode host : permet d'accéder aux services locaux sans exposer de ports supplémentaires, réduisant la surface d'attaque.
Mises à jour automatiques : l'image Docker caddy:2 est tirée avec le tag latest lors du déploiement ; toutefois, en production nous recommandons de figer à une version précise après validation.
Journalisation : les accès et erreurs sont écrits dans le répertoire de données de Caddy (/home/kanmaber/shared_infra/Caddy/data/logs) et peuvent être consultés pour le débogage.

Vérification post‑intervention¶

Toutes les landing pages et l'application PsychoEnLigne sont fonctionnelles. Aucun impact sur les autres services du VPS (Hermes, partage de fichiers, etc.).

Leçons apprises / actions préventives¶

Surveiller le statut du conteneur Caddy via un simple cron job qui interroge docker ps et envoie une alerte Telegram si le conteneur n'est pas en état Up.
Documenter dans le wiki la procédure de redémarrage de Caddy pour référence future.
Envisager un health‑check externe (ex. uptimerobot) qui surveille la disponibilité de la page principale et des sous‑domaines.

Nota : cette résolution a été effectuée dans le cadre de l'assistant Hermes Agent, en utilisant le diagnostic terminal et la gestion Docker.