When you deploy something via a Docker-container, you have to keep in mind that it's (normally) not-directly-connected to the rest of the world (the Internet, in your case) and that such a connection (container <=> Internet) is mediated by the Docker-host (the PC hosting the docker environment and properly running your container) resulting in a chain that looks like:
<your container> <=> <docker host> <=> <Internet>
Actually, even if you haven't provided the details, I expect a real scenario like this:
<your container> <=> <docker host> <=> <your Internet router> <=> <Internet>
Note: this is what happens "commonly". Lots of edges can be tuned by properly configuring Docker networking parameters to adapt them to your needs. But in general, you can assume the above.
So, back to your case, as your container is receiving the HTTP request from the docker-host, this is exactly the reason why you see what you see (the HTTP request coming from the IP of your HOST, and not the one of the real source, on the Internet).
In technical terms, the docker-host is acting --with respect to your container-- as a (sort-of) REVERSE PROXY. In other words:
- the real source host send the request to your docker-host (to the public IP address associated to the external interface of your docker host);
- docker-host receive the request and...
- ...it "proxy" (actually: "forward") the request to your container.
The above is really common within so-called "cloud environment" and, as such, there are several ways to solve the visibility problem you're facing (knowing the real source IP of the HTTP request you're serving).
In your case, I'd suggest going through the official document to get un understanding about the whole concept and related countermeasures.
But...
...unfortunately the above is not strightly suited to your case as the docker-host is not strictly running a REVERSE-PROXY "server", but, instead, is acting as a PORT-FORWARDER router. Without entering into details (out of scope of this answer), the problem is that you DON'T have the place to properly configure the reverse-proxy actions you need.
So, in the end, you have only two options:
change the docker configuration, asking the docker-host to logically connect your matomo container to the EXTERNAL network, exposing it exactly like any other host on your LAN. Afterwards, you only need to setup your external networking, sending the HTTP traffic to the container IP, and no more the docker-host IP. In other words, the scenario will be:
<your container> <=> <your Internet router> <=> <Internet>
on the docker-host, install a real REVERSE-PROXY (like NGINX) and configure it accordingly to matomo documentation mentioned above. In other words, the scenario will be:
<your container> <=> <NGINX Reverse-proxy running on the docker host> <=> <your Internet router> <=> <Internet>
A final note: I've heavily oversimplified the above description and I'm well aware that is NOT 100% correct. But it should be enough to help you solving your problem :-)
