Thanks a lot for your responses. They were really helpful 
I finally made it, but I’m still not sure if my configuration is optimal right now.
So first I added a static subnet for the caddy-network (172.16.0.0/16) and added replaced this in the trusted_proxies array in the Nextcloud configuration (as @jtr suggested).
I also removed the trusted proxies from the Caddyfile, since I thought, yes, I don’t have any reverse proxies in front of Caddy.
Then I wanted to shortcut the communication between the Notify Push container and Caddy (as @wwe suggested), because talking over the internet when the contains actually are on the same host, indeed seems suboptimal.
My Caddy compose file now:
services:
caddy:
[...]
networks:
caddy:
aliases:
- nc.example.com
networks:
caddy:
name: caddy-network
ipam:
driver: default
config:
- subnet: 172.16.0.0/16
BTW I decided to split off the Caddy configuration from my main Nextcloud compose stack, because I have other services apart from Nextcloud that are using this Caddy reverse-proxy as well.
My Nextcloud compose file:
version: '3'
services:
app (this is the nextcloud container):
[...]
networks:
- caddy-network # i can probably remove this one, right?
- default
notify_push:
[...]
environment:
- NEXTCLOUD_URL=https://nc.example.com
- SOCKET_PATH=/run/notify_push/notify_push.sock
networks:
- caddy-network
- default
networks:
caddy-network:
external : true
I noticed that I have to add the Notify Push (and the Nextcloud?) container to the Caddy network because otherwise the shortcut won’t work.
With the new configuration I tried the self-test again, and it showed a different error message (at least something 
)
./occ notify_push:self-test
✓ redis is configured
✓ push server is receiving redis messages
✓ push server can load mount info from database
✓ push server can connect to the Nextcloud server
🗴 push server is not a trusted proxy by Nextcloud or another proxy in the chain.
Nextcloud resolved the following client address for the test request: "172.16.0.4" instead of the expected "1.2.3.4" test value.
The following trusted proxies are currently configured: "172.16.0.0/16", "127.0.0.1"
The following x-forwarded-for header was received by Nextcloud: "172.16.0.4"
from the following remote: 172.16.0.4
✓ All proxies in the chain appear to be trusted by Nextcloud
One of the proxies is the chain (probably 172.16.0.4) seems to have stripped the x-forwarded-for header
Please configure the reverse proxy at 172.16.0.4 to not strip the x-forwarded-for header
If you're having issues getting the trusted proxy setup working, you can try bypassing any existing reverse proxy
in your setup by setting the `NEXTCLOUD_URL` environment variable to point directly to the internal Nextcloud webserver url
(You will still need the ip address of the push server added as trusted proxy)
172.16.0.4 is actually the IP address of the Notify Push container.
Apparently, Caddy by default strips/replaces all X-Forwarded-For headers from the request and only forwards them, if the request comes from an IP range specified in trusted_proxies.
So I added the section that I previously removed again, and et voilá the self test succeeds 
./occ notify_push:self-test
✓ redis is configured
✓ push server is receiving redis messages
✓ push server can load mount info from database
✓ push server can connect to the Nextcloud server
✓ push server is a trusted proxy
✓ push server is running the same version as the app
So at least for the case of the self test, it seems to me as Notify Push acts as a reverse proxy in front of Caddy (my real reverse-proxy/ webserver), because the self tests adds X-Forwarded-For headers to the request.
I wonder if the configuration is okay like that?
Maybe all the containers of the Nextcloud compose stack should use the Caddy network?