-
Notifications
You must be signed in to change notification settings - Fork 3.6k
Description
Summary
When Nginx Proxy Manager is deployed with Docker Compose and extra_hosts defines host.docker.internal, proxy host validation can still fail with:
host.docker.internal could not be resolved (3: Host not found)
This happens even though the hostname is present in the container's /etc/hosts.
Version
- Reproduced on:
v2.13.7 - The upstream resolution path appears unchanged in newer templates.
Environment
- Docker Compose deployment
extra_hostsconfigured for NPM container, e.g.:host.docker.internal:host-gateway(or an explicit host IP)
Steps to Reproduce
- Deploy NPM with
extra_hostscontaininghost.docker.internal. - Create a Proxy Host with:
- Forward Hostname/IP:
host.docker.internal - Forward Port:
<your service port>
- Forward Hostname/IP:
- Save/apply the host config.
Actual Behavior
NPM/Nginx config test fails with:
host.docker.internal could not be resolved (3: Host not found)
Expected Behavior
If host.docker.internal is available via system resolver path (/etc/hosts), the proxy host should be accepted and work.
Why this happens
NPM proxy templates use variable-based proxy_pass (e.g. $server), which relies on Nginx runtime DNS resolver behavior. That resolver does not use /etc/hosts, so extra_hosts entries are not honored in this path.
Proposed Fix (backward-compatible)
Add an optional NPM-side pre-resolution step (disabled by default), for example:
- New env flag:
NPM_PRE_RESOLVE_UPSTREAM_HOSTS=true - During config generation:
- pre-resolve eligible upstream hostnames via system resolver (
dns.lookup) - write resolved IP into generated upstream target
- if resolution fails, keep original hostname
- pre-resolve eligible upstream hostnames via system resolver (
This preserves current default behavior while providing a compatible path for Docker setups relying on extra_hosts.
Notes
I can open a PR with implementation and docs updates. Default behavior remains unchanged unless the new env flag is enabled.