In the initial issue (#1537), the issue creator also run the proxy in host network mode networking.

I don't know if running the proxy in bridge network mode and the proxied containers in host network mode is a common use case in the issues related to this. I think that people are most likely to run everything in host network mode rather than just a few containers but I might be wrong.

Not sure if they particularlly wanted to run the proxy in host mode, or if it was just a way of trying to get it working with homeassistant (which has to run in a host mode container if you want it to do a load of network discovery). This is my exact use case too - I want to proxy to several containers running in a 'normal' bridge mode, and also to homeassistant running in host mode. I feel like most folks would want to keep bridge networking wherever possible, as it's part of the segregation benefits of containerisation, but I have no evidence to back up this assertion!

That does work with the proxy in bridge network mode and the container in host network mode.

It requires VIRTUAL_PORT and works in a very specific way so I think it needs to be documented.

Ideally I would also like it to be tested.

I added a minimal test.

@rhansen I'd like your advice on this, should we work a bit more on this feature (support proxy + container in host network mode, warn if (index $.globals.CurrentContainer.Networks 0).Gateway is empty because the network is private, iterate over $.globals.CurrentContainer.Networks, etc) or do you think the fix could be released in its current state with documented limitations ?

I'll take a look when I have some time next week.

I'm OK with marking this as experimental while we continue to evaluate.

@rot169 just to be sure: for a given container, host network mode and the other network modes are all mutually exclusive ?

I added the following to the PR:

• iteration over the proxy networks to find a suitable one rather than picking the first
• compatibility with the proxy running in host network mode itself
• tests for base PR scenario + proxy in host network mode
• documentation

@rhansen I'd still like your review on this, the template code might be sub optimal. Other than that I'm okay with the PR in its current state.

@rot169 could you test the PR in its current state ?

Additional related issues:

• VIRTUAL_PORT is not filled in default.conf when container uses host networking #1270
• Manually setting upstream #832

@rot169 just to be sure: for a given container, host network mode and the other network modes are all mutually exclusive ?

That's correct; as far as I understand it is not possible to have a container with both host-based network and a bridge network.

@rot169 could you test the PR in its current state ?

Sure, will probably take me a few days, but will do so and report back.

I'm tempted to use host.docker.internal / host.containers.internal like Traefik does (with the current method as a fall back) because that seems more straightforward and robust but that would require installing a DNS resolution util in the image to check if they actually resolve, and the lightest I could find (bind9-host) adds ~40MB to the image.

For my workaround with Home Assistant container being host networked, I used qoomon/docker-host. The same solution is what I suspect people are using to make nginx-proxy handle non-dockerized applications. I don't like the approach, but it has worked for me.

The proposed pull req commits looks great, and while I figure out how to build my own image based off this pull req, I will give a friendly ping to @rot169 if they've done their testing yet.

Thanks for the ping - and apologies this'd dropped off my radar. Yes, the latest code seems to work great for me, and is clearly more robust than my initial proposal.

I spotted a typo in the doc I added, I'll fix this then probably merge this PR by the end of the week.

Nice! Looks like a little oops in Markdown

https://github.com/nginx-proxy/nginx-proxy#host-networking

Fixed, thank you @prashker

Thank you - sorry for the LONG delay. I can confirm this functionality works.

My --net=host Home Assistant instance has VIRTUAL_HOST LETSENCRYPT_HOST and VIRTUAL_PORT assigned and functioning as expected.

Good riddance to my workaround!