Le soucis est multiple :
D'une part « add_header » ne transmet pas au serveur final le header. Il ne fait que l'ajouter à la réponse en direction du client. Cf http://nginx.org/en/docs/http/ngx_http_headers_module.html#add_header :
Adds the specified field to a response header
Donc clairement dans notre cas les nombreux add_header X_FORWARDED_PROTO https;
trouvés dans la conf sont inutiles.
D'autre part il y a eu méprise sur le fonctionnement de proxy_set_header
. On en retrouve un peu partout dans la conf, à différents niveaux de blocs. Or, la doc d'nginx précise :
Allows redefining or appending fields to the request header passed to the proxied server. The value can contain text, variables, and their combinations. These directives are inherited from the previous level if and only if there are no proxy_set_header directives defined on the current level.
C'est écrit subtilement mais de fait c'est à prendre au sens strict : il n'y a pas d'héritage comme on pourrait l'attendre intuitivement.
Nous ne sommes pas les seuls à nous être fait avoir, cf par exemple http://serverfault.com/questions/777363/inherit-proxy-set-header-when-using-it-in-location-block
J'ai donc centralisé le proxy_set_header X-Forwarded-Proto $scheme;
dans conf.d/local.conf et retiré tous les proxy_set_header inutiles (et sources de bugs) des blocs des sites.
La conf fonctionne pour le drupal (les logs http et https mentionent bien la bonne ip), le icinga est au vert, et au passage ça a résolu le bug #1350.