Trouble accessing port of application running in LXD container

[oac]

Hello there!

I was tinkering with getting writefreely running within a lxd container, and I’m having trouble accessing the port opened from writefreely from the host system.

Specifically, I have various nginx reverse proxies on the host (which manage SSL certs via certbot), and I want to redirect traffic for the relevant subdomain to the lxd container.

The problem is, with writefreely listening on port 8080 and running in the container, I can curl http://localhost:8080 from within the container and get the correct content, but if I curl http://10.202.131.209:8080 (the container’s IP) from the host, I get curl: (7) Failed to connect to 10.202.131.209 port 8080 after 0 ms: Couldn't connect to server. I tried the same with writefreely running on port 80, with no improvement. I can ping that IP from the host, so it’s not a DNS problem, I think.

I tried two things to try to fix this:

1. I tried to follow this guide from Linode, which describes doing the following: lxc config device add <instance-name> myport80 proxy listen=tcp:0.0.0.0:80 connect=tcp:127.0.0.1:80 proxy_protocol=true, but the guide is old and I don’t see such a thing mentioned in the official LXD docs related to networking
2. I tried to follow the LXD docs for network forwards with ports, but this also didn’t work (but at least resulted in a 400 error instead of failure to connect), and this seems intended to be used as the reverse proxy itself, rather than the receiving end of an nginx reverse proxy.

So my question is: are there specific steps required to make an application listening on a port within a LXD container accessible from the host? That is, so the host can curl http://10.202.131.209:8080 and the application in that container gets the request and responds?

Thanks in advance for any help you can provide!

[oac]

Thanks to a suggestion from @sarnold, I tried changing the hostname to which writefreely was binding from localhost to 0.0.0.0, and after that it happily accepted traffic pointed at the 10.x.x.x address of the container.

So if you hit a similar problem, make sure you’re telling applications in the container to listen properly for connections from outside the container.