If you intend for this instance to be available on the internet, using a .local domain in app.yml is going to break things. Maybe this is something you’re only intending to use at home or only for testing, just thought it was worth mentioning.
Assuming your docker networking works correctly, making the container reachable on that IP address from outside the host machine, you would also need DNS to point discourse.simonz.local to that IP address.
It sounds like what’s happening is that the domain is resolving to the host machine and you aren’t specifying the port (e.g. discourse.simonz.local:1234) when trying to access it, so it’s just reaching nginx instead of the docker container.
If you want Discourse available on a different port, you probably don’t need it on a different IP address. If you want it available on the standard port, as well as nginx on the standard port, you need DNS to direct you to the correct IP or you need nginx to proxy Discourse.
.local domains are typically announced by the system based on its configured hostname. Discourse doesn’t really have any need to do that normally, so the container might not have anything to do it.
If you want to go the standard port, different IP, DNS route, that’s really outside the scope of Discourse and setting it up will depend on various factors in your network.
If your goal is just to have something available in nginx as well as Discourse on the same host, I would recommend the proxy approach linked above. While also technically an unsupported install, it’s a more common setup and one more people will be able to help with.