Ce que Jay voulait dire ici, c’est que vous devez utiliser le nom d’hôte configuré (DISCOURSE_HOSTNAME dans la définition de votre conteneur .yml) par opposition à tout nom d’hôte qui se résoudrait à la bonne adresse IP.
Ceci est délibéré, afin que vous ne puissiez pas facilement faire de proxy inverse d’une instance publique à partir de n’importe où, et que seul le nom d’hôte configuré soit accepté :
$ curl -I https://try.discourse.org/about.json
HTTP/2 200
server: nginx
date: Mon, 15 May 2023 16:25:05 GMT
content-type: application/json; charset=utf-8
[...]
# ce qui suit est équivalent à la création d'un enregistrement DNS à
# try.somebogusreverseproxy.com pointant vers la même adresse IP que try.discourse.org,
# puis à la demande de https://try.somebogusreverseproxy.com/about.json
$ curl -H 'Host: try.somebogusreverseproxy.com' -I https://try.discourse.org/about.json
HTTP/2 404
cache-control: no-cache
content-length: 1427
content-type: text/html
cdck-proxy-id: app-router-tiehunter02.sea1
cdck-proxy-id: app-balancer-tieinterceptor1b.sea1
Inversement, si vous essayez ceci :
curl -H 'Host: VOTRE_NOM_HOTE_CONFIGURE' -I https://discourse_app/metrics
cela devrait fonctionner, mais c’est une solution de contournement. L’attente est que vous configuriez le DNS comme requis afin que Discourse puisse être atteint à son nom d’hôte configuré de manière transparente :
curl -I https://VOTRE_NOM_HOTE_CONFIGURE/metrics
Comment faire cela dépend grandement de vos besoins, mais l’option la plus simple est de configurer un alias dans /etc/hosts à partir d’où vos requêtes HTTP proviennent.