Skip to content

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

@Eric-Terminal

Description

@Eric-Terminal

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions