proxy host upstream `host.docker.internal` cannot be resolved when `extra_hosts` is used (variable `proxy_pass` + resolver path)

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_hosts configured for NPM container, e.g.:
  • host.docker.internal:host-gateway (or an explicit host IP)

Steps to Reproduce

1. Deploy NPM with extra_hosts containing host.docker.internal.
2. Create a Proxy Host with:
   • Forward Hostname/IP: host.docker.internal
   • Forward Port: <your service port>
3. 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

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.

No specific files or tests are named. Start by tracing the proxy templates' variable-based proxy_pass and the configuration-generation path, then inspect how system resolver lookup interacts with extra_hosts. Done means an optional pre-resolution path works without changing default behavior and preserves the hostname when lookup fails.