Docker not reachable from outside the container due to bad HOSTNAME

[mastacheata]

Describe the bug
My nighscout webinterface isn't reachable from outside the Docker container.
This problem occurs because the node.js server binds to a specific hostname as specified by the HOSTNAME variable.
I'm not sure if this was done intentional or for lack of better knowledge.
Docker sets this variable automatically to an internal hostname that's not reachable from outside the container itself, I think this might be in conflict with the intention of making the hostname optional and configurable)

By binding to the HOSTNAME variable in node.js the server only reacts when called with this exact hostname in the URL, but the Docker-Host or other containers like traefik cannot use that hostname to communicate with the container.

i.e, starting nightscout using docker-compose results in the container having the hostname c3fbef634b79
You can only open the nighscout website if the HTTP request has that hostname as the address.
The traefik container will try to connect to the nightscout container using it's internal IP address and not the hostname, so that fails. But even if you explicitly tell traefik to use the correct hostname that fails because the traefik container only knows the nightscout hostname for the other container, not it's hash-based internal hostname.

Proposed solutions

• Change the environment variable used by the lib/server/server.js to have a prefix (i.e. NIGHTSCOUT_HOSTNAME) so it doesn't conflict with the automatic variable set by Docker.
• Set a sensible default in the docker-compose.yml and document it (the only sensible default in my mind is to set it to an empty string, that leads to node interpreting it as null and the server being available on all interfaces of the system)

I'm happy to send a PR with these changes if any of that is agreed on.

[WesSec]

I can confirm this behavior is still present and causes connectivity issues when running Nightscout behind a reverse proxy (in my case, Nginx/Swag) in a Docker environment.

Because Docker automatically sets the HOSTNAME environment variable to the container ID, Nightscout binds specifically to that hostname rather than 0.0.0.0. This causes the container to reject valid HTTP requests from other containers on the same bridge network if they try to access it via its service name or internal IP.

I spent significant time debugging why my proxy returned "Connection Refused" despite correct networking.

The (temp) Fix:
overriding the variable in docker-compose.yml resolves the issue:

environment:

• HOSTNAME=0.0.0.0

I support the proposal to rename the internal variable to NIGHTSCOUT_HOSTNAME or default it to 0.0.0.0 to prevent this conflict with standard Docker behavior.