Pay attention to the userland-proxy state and the outputs: value:

1. echo '{ "userland-proxy": true }' > /etc/docker/daemon.json
2. systemctl restart docker
3. docker network create test
4. docker run --rm -d -p 80:80 --network test --name bug traefik/whoami
5. curl -s http://192.168.1.42 | grep RemoteAddr (outputs: RemoteAddr: 192.168.1.42)
6. docker stop bug
7. echo '{ "userland-proxy": false }' > /etc/docker/daemon.json
8. systemctl restart docker
9. docker run --rm -d -p 80:80 --network test --name bug traefik/whoami
10. curl -s http://192.168.1.42 | grep RemoteAddr (outputs: RemoteAddr: 172.23.0.1)
11. echo '{ "userland-proxy": true }' > /etc/docker/daemon.json
12. systemctl restart docker
13. docker run --rm -d -p 80:80 --network test --name bug traefik/whoami
14. curl -s http://192.168.1.42 | grep RemoteAddr (outputs: RemoteAddr: 172.23.0.1)

NOTE: To reproduce:

• 192.168.1.42 should be substituted for an IP on the hosts local interfaces, I've used the router assigned IP here, but have also reproduced with public IP (v4 and v6 addresses) from a VPS too.
• 172.x.0.1 obviously being the docker network gateway connected to that container (it does not need to be a custom network, the default bridge network also exhibits this bug).
• The initial step from userland-proxy: true is only to showcase that the expected value appears by default. The bug itself is specifically the userland-proxy: false to userland-proxy: true change.
• You could alternatively use dockerd --userland-proxy=true and dockerd --userland-proxy=false to toggle instead of the daemon.json config, same issue.
• If you create a new network after all this when userland-proxy: true, then test it it will resolve the correct remote address IP, while the earlier network remains affected from the previous userland-proxy: false changes until the system restarts.

When userland-proxy: false:

• The reported remote address is that of the containers network gateway IP (expected, as similar effect to when iptables / ip6tables NAT is disabled).
• userland-proxy: false also leads to curl http://[::1] timing out (curl http://127.0.0.1 would work however), while IPv6 addresses associated to other interfaces than the loopback were at least connecting.

When userland-proxy: true:

• Despite the primary issue this bug details; - curl http://[::1] would now connect, and it will always return the expected docker network gateway IP matching that protocol (if there was an IPv6 enabled docker network + with ip6tables + experimental enabled in daemon.json, otherwise IPv4 gateway IP returned).
• It is just the other host NICs that are expected to report back their own IP instead of the gateway of the docker network used (technically --network host would also report loopback IP instead of the gateway IP, but that's not a concern here).
• The bug has only been observed when connecting from the host to a container; whereas connecting to the same public IP address of a host NIC remotely instead would still correctly report the expected remote IP (belonging to the connecting remote / client system). A remote client would only report the remote address IP as the docker networks Gateway IP only when userland-proxy: false in this case (for IPv4, and with relevant IPv6 config, the IPv6 equivalent gateway when appropriate instead of the IPv4 gateway)

/etc/docker/daemon.json used for enabling IPv6 with NAT on default docker bridge (so that containers report back the expected IPv4 / IPv6 address as remote):

{ 
  "ipv6": true,
  "fixed-cidr-v6": "fd00:cafe:babe::/48",
  "ip6tables": true,
  "experimental": true,
  "userland-proxy": true
}

NOTE: I have verified the bug without any of the IPv6 / experimental config present as well. Still affects IPv4.