nginx : dimensionner les tampons d'en-tetes pour les sessions OIDC

oauth2-proxy journalisait AuthSuccess pendant que le navigateur recevait une
erreur de passerelle : le cookie de session porte le jeton d'identite, decoupe
en plusieurs Set-Cookie, et le tampon par defaut de nginx (4 Ko) ne peut pas
les contenir.

  upstream sent too big header while reading response header from upstream
  server: icinga.chezlepro.internal, request: GET /oauth2/callback

Pose sur TOUTES les expositions : c'est une propriete du proxy, pas de ce
service-la, et le prochain service derriere un IdP rencontrerait le meme mur.

Trouve grace au journal d'evenements active juste avant : LOGIN puis
CODE_TO_TOKEN reussis pour icingaweb2 ont ecarte l'identite d'un coup.

Laisse ouvert : trois upstream timed out vers Keycloak en 14 h, alors que
Keycloak repond en millisecondes depuis l'edge. Cause non etablie — et ma
sonde MTU ne valait rien, l'ICMP etant bloque par construction entre hotes.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

CHANGELOG.md

@@ -1,5 +1,39 @@
 # CHANGELOG — Set-OPS
 
+## 2026-08-08 — 502 sur Icinga : le tampon de nginx, après une authentification réussie
+
+Symptôme trompeur s'il en est : `oauth2-proxy` journalisait `AuthSuccess` — jeton, jeton
+d'identité, rafraîchissement, tout obtenu — pendant que le navigateur recevait une erreur
+de passerelle. L'authentification n'était pas en cause ; c'est la réponse qui ne passait
+plus.
+
+```
+upstream sent too big header while reading response header from upstream
+server: icinga.chezlepro.internal, request: "GET /oauth2/callback?..."
+```
+
+Le cookie de session d'`oauth2-proxy` porte le jeton d'identité, découpé en plusieurs
+en-têtes `Set-Cookie`. Le tampon par défaut de nginx (4 Ko) ne peut pas les contenir.
+`serveur_nginx` pose désormais `proxy_buffer_size` / `proxy_buffers` /
+`proxy_busy_buffers_size` sur **toutes** les expositions : c'est une propriété du proxy,
+pas de ce service-là, et le prochain service placé derrière un IdP rencontrerait le même
+mur.
+
+Trouvé uniquement parce que le journal des évènements de Keycloak venait d'être activé :
+il a montré `LOGIN` puis `CODE_TO_TOKEN` réussis pour `icingaweb2`, ce qui a écarté d'un
+coup l'identité et renvoyé l'enquête vers le chemin de retour.
+
+**Deux constats laissés ouverts, faute de pouvoir conclure.**
+
+Le journal de l'edge montre trois `upstream timed out` vers Keycloak en quatorze heures
+(console de compte deux fois, autorisation Nextcloud une fois). Mesuré depuis l'edge,
+Keycloak répond en **millisecondes** — ce n'est pas lui qui est lent. Cause non établie.
+
+Et ma sonde MTU ne valait rien : `ping -M do` annonce 100 % de perte alors que HTTP répond
+en 5 ms, parce que l'ICMP est bloqué **par construction** entre hôtes (seul `frag-needed`
+est ouvert au registre des flux). Troisième fois aujourd'hui que l'instrument est le
+problème et non le composant — après `/dev/tcp` sous `sh` et `Maildir/new/`.
+
 ## 2026-08-08 — Keycloak ne gardait aucune trace des connexions
 
 Deux services n'aboutissaient pas pour l'exploitant (Nextcloud, Icinga Web 2). Tout a été

roles/serveur_nginx/defaults/main.yml

@@ -38,3 +38,10 @@ serveur_nginx_groupe: "serveur_nginx"
 # cible>:<port>. Une exposition non resolvable (cible sans hote actif, ou sans
 # port) est ignoree (binding declare mais pas encore cablable).
 serveur_nginx_publier_expositions: true
+
+# Tampons d'en-tetes de reponse cote proxy — voir templates/expositions.conf.j2.
+# Dimensionnes pour un cookie de session OIDC (jeton d'identite decoupe en plusieurs
+# `Set-Cookie`), que le defaut de 4 Ko ne peut pas contenir.
+serveur_nginx_proxy_buffer_size: "16k"
+serveur_nginx_proxy_buffers: "8 16k"
+serveur_nginx_proxy_busy_buffers_size: "32k"

roles/serveur_nginx/templates/expositions.conf.j2

@@ -41,6 +41,21 @@ server {
         proxy_set_header X-Real-IP $remote_addr;
         proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
         proxy_set_header X-Forwarded-Proto $scheme;
+
+        # Tampons d'en-tetes de reponse. Le defaut de nginx (4 Ko) ne suffit PAS
+        # derriere une authentification OIDC : le cookie de session porte le jeton
+        # d'identite, decoupe en plusieurs `Set-Cookie`, et nginx repond alors 502
+        # « upstream sent too big header » — juste apres une authentification
+        # REUSSIE, ce qui rend le symptome trompeur. Constate le 2026-08-08 sur
+        # icinga.chezlepro.internal, ou oauth2-proxy journalisait `AuthSuccess`
+        # pendant que le navigateur recevait une erreur de passerelle.
+        #
+        # Pose pour TOUTES les expositions : c'est une propriete du proxy, pas du
+        # service, et le prochain service place derriere un IdP rencontrerait le
+        # meme mur.
+        proxy_buffer_size {{ serveur_nginx_proxy_buffer_size }};
+        proxy_buffers {{ serveur_nginx_proxy_buffers }};
+        proxy_busy_buffers_size {{ serveur_nginx_proxy_busy_buffers_size }};
 {% if expo.websocket | default(false) %}
         # Collabora & co : editeur en direct via WebSocket (upgrade + longue tenue).
         proxy_http_version 1.1;