Proxy inverse

Votre serveur web se place devant tout : il sert votre site publié comme simples fichiers et transmet les quelques chemins dynamiques (formulaires, documents, l'interface admin) au démon du CMS. Cette page explique les exemples de configuration fournis, comment les ports et les langues se mappent, et comment les certificats TLS sont gérés.

Les exemples fournis

Le dossier deploy du projet contient des configurations prêtes à copier :

• Caddy (recommandé) : un exemple complet avec HTTPS automatique : le site du produit, le domaine admin, et des vhosts statiques par langue construits à partir d'un snippet réutilisable.
• nginx (complet) : le motif à deux vhosts : un vhost statique par langue plus le proxy de l'interface admin, avec mise en cache et en-têtes de sécurité.
• nginx (minimal) : un template à domaine unique avec des placeholders (domaine, chemin de sortie, port du CMS) couvrant l'agencement courant.

Les trois encodent les mêmes règles ; les différences sont le binaire du serveur et le degré d'accompagnement.

Les ports et le flux du trafic

• Chaque instance du CMS écoute sur son propre port loopback : la convention est 3001 pour l'instance 1, 3002 pour l'instance 2, et ainsi de suite (l'installeur les attribue ; vous pouvez les remplacer).
• Le vhost du site public sert le répertoire de sortie statique directement depuis le disque. C'est juste un serveur de fichiers plus trois petites règles de proxy (ci-dessous).
• L'interface admin (par ex. admin.example.com) est un reverse proxy complet vers le port de l'instance : chaque requête va au CMS.

Trois règles de proxy dont vous pourriez avoir besoin

Copiez celles-ci dans le(s) vhost(s) du site public ; chacune est requise par une fonctionnalité spécifique, et les exemples fournis les signalent tous :

1. /forms/ : chaque formulaire de votre site envoie en POST vers /forms/<slug>, ce qu'aucun serveur de fichiers statique ne peut gérer. Sans ce bloc, chaque soumission de formulaire échoue. (Requis si vous utilisez des formulaires de contact ou de newsletter.)
2. /documents/ : les téléchargements de documents (avec suivi et contrôle d'accès) sont servis en direct par le CMS. Requis seulement si vous utilisez la fonctionnalité Documents, avec la réserve qu'un des deux exemples nginx fournis est antérieur à celle-ci ; si votre fichier d'exemple n'a pas le bloc /documents/, ajoutez-le quand vous utilisez les documents.
3. Honeypots de scanner : une courte liste d'URL de sondes connues (/.env, /wp-login.php, wp-admin, phpmyadmin, …) est transmise au CMS pour que ces visites soient journalisées et ralenties au lieu d'être répondues par un simple 404 statique.

Le vhost admin transmet tout : c'est le but : l'interface admin est le CMS.

La loopback est une décision de sécurité

• Écoutez le CMS sur 127.0.0.1:<port> et laissez le proxy faire face à internet. Le CMS ne fait confiance aux IPs client transmises que depuis les connexions loopback : écoutez sur une interface publique et vos limites de débit et verrouillages de connexion peuvent être usurpés.
• Si votre proxy atteint le CMS sur un réseau non-loopback (comme Docker), ajoutez ce réseau via CHINASKI_TRUSTED_PROXIES dans le fichier env de l'instance.
• Comportement des en-têtes : les exemples transmettent X-Real-IP/X-Forwarded-For/X-Forwarded-Proto de façon cohérente. Caddy v2 les gère lui-même ; les exemples nginx les définissent explicitement sur chaque bloc de proxy.

La mise en cache (ce que les exemples définissent)

• Pages (HTML) : en cache 5 minutes : délibérément court pour que les builds atteignent rapidement les lecteurs.
• Service worker : jamais en cache ; une copie périmée bloquerait les mises à jour du site.
• Fonts : hachées par contenu, en cache un an (elles ne changent jamais de nom).
• Autres assets (CSS/JS/images) : un jour.
• L'application elle-même envoie déjà les bons en-têtes ; les règles de proxy sont une ceinture et des bretelles pour que de mauvaises réponses ne puissent pas se glisser, même depuis des pages d'erreur périmées.

En-têtes de sécurité

Les exemples de vhost admin ajoutent la protection contre les frames, la protection contre le sniffing de content-type, et une referrer policy à la couche proxy, explicitement en secours au cas où une page d'erreur statique serait servie avant que le CMS puisse répondre. Le CMS reproduit chacun d'eux lui-même sur chaque réponse, donc les deux couches concordent ; l'exemple minimal de nginx ajoute aussi HSTS au proxy.

TLS avec Let's Encrypt

• Caddy : fait tout automatiquement : demande et renouvelle les certificats dès que votre DNS pointe vers l'hôte et que les ports 80/443 sont joignables. Aucune ligne de configuration dans l'exemple : c'est le but.
• nginx : les templates sont fournis en HTTP seul et attendent une commande (certbot --nginx -d YOUR_DOMAIN) qui injecte pour vous les lignes listen 443 et les certificats.
• Pas d'internet ? Le mode offline (« EOTW ») fonctionne délibérément en HTTP simple sans certificats à renouveler : l'alternative documentée quand Let's Encrypt n'est pas joignable. Utilisez un VPN ou des règles de pare-feu pour protéger l'admin dans ce mode.
• Le TLS est terminé au proxy ; le CMS voit toujours le trafic chiffré se terminer là et émet un HSTS d'un an.

Les sites multi-langues

Les exemples complets Caddy et nginx donnent tous les deux un vhost par langue (chacun enraciné dans le répertoire output/<lang> de cette langue). Si votre mode de langue de permalien change plus tard, le script de déploiement re-synchronise automatiquement les racines document du serveur web : la configuration du proxy n'a jamais besoin d'être éditée à la main pour cette bascule.

Le mode de langue par sous-domaine se combine avec un hôte par langue ; les URL canoniques sont alors construites par sous-domaine, en correspondance avec l'agencement.

Une liste de contrôle avant la mise en ligne

1. Deux blocs de proxy existent : /forms/ (si des formulaires sont utilisés) et /documents/ (si des documents sont utilisés).
2. Le démon admin écoute sur la loopback ; seul le proxy est exposé.
3. nginx -t (ou la validation Caddy) passe et le service a été rechargé proprement.
4. Certificats émis (ou mode EOTW choisi délibérément).
5. Un passage rapide avec un scanner externe touche le bloc honeypot, et non un 404 nu, visible dans les logs admin.