What Jay meant here is that you need to use the configured hostname (DISCOURSE_HOSTNAME in your container .yml definition) as opposed to any hostname that happens to resolve to the correct IP.
This is deliberate, so that you can’t trivially reverse proxy a public instance from just anywhere, and so that only the configured hostname is accepted:
$ 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
[...]
# the following is equivalent to creating a DNS record at
# try.somebogusreverseproxy.com pointing to the same IP address as try.discourse.org,
# and then requesting 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
Conversely, if you try this:
curl -H 'Host: YOUR_CONFIGURED_HOSTNAME' -I https://discourse_app/metrics
it should work, but it’s a hack. The expectation is that you’ll set up DNS as required so that Discourse can be reached at its configured hostname transparently:
curl -I https://YOUR_CONFIGURED_HOSTNAME/metrics
How to do that depends greatly on your requirements, but the simplest option is to set up an alias in /etc/hosts from where your HTTP requests originate.