Thank you for responding. I’m sorry I disappeared; with the weekend and other things, I wasn’t available.
The experience you describe is interesting. I wonder how that worked. What I believe is happening to me is:
- Inside the container, the name is resolved from company.enterprise.server to 172.17.120.xxx
- The bridge network had an IP range rom 172.0.0.0 to 172.255.255.255 (or something like that)
- The routing table inside the container determines that IP 172.17.120.xxx must be on the local subnet and is not sent to the gateway at 172.0.0.1, but “directly” to a server that doesn’t exist at 172.17.120.xxx
It’s hard to understand how anything would be able to distinguish between a server on the company enterprise private subnet, and the docker-host-only private subnet.
Docker desktop has an option “Copy docker run”, so I recreated the container and the new one worked. I did a diff on the inspection report and it looks like the port binding listed the HostIp on the container that didn’t work as “0.0.0.0” and the container that did work as “”. It turns out I can connect to the container if I navigate to the hostname of my laptop:8081, but not localhost:8081, because the port forwarding is only bound to the external interface. I don’t know what I did that caused the change in bind setting, but I’m on a Mac and can’t get to the configuration files easily, so I’m not going to edit the container. But I can live with this, I suppose.
Thank you for your help. It definitely pointed me in the right direction.