Hamish Moffatt

The server at the other end (somehost:8123) is reporting that it got the connection on IPv6, and tcpdump confirms it. I see what you mean about the log though.

These run and ignore the tcp4/tcp6 specifier, despite being nonsense: ``` :9002 { reverse_proxy tcp4/[fd5d:61f5:a84a:42::18]:8123 } :9003 { reverse_proxy tcp6/192.168.42.18:8123 } ```

> to see what you get? Is the `network` as expected? What address does the conn report as having connected to? If you're not sure how, I can follow up...

I think the problem is the same as the one described in the comments for unix socket upstrams at https://github.com/caddyserver/caddy/blob/9338741ca79a74247ced86bc26e4994138470852/modules/caddyhttp/reverseproxy/httptransport.go#L208 - the standard library HTTP transport has passed the network...

> It appears that Go stdlib overwrites the value here. Tracking and fixing this might be tricky. That's where I traced it to as well. https://github.com/caddyserver/caddy/blob/9338741ca79a74247ced86bc26e4994138470852/modules/caddyhttp/reverseproxy/httptransport.go#L208 already seems to be...

You can actually just configure two tunnels with the same config and the same `tunnel_id` etc and it works. Just don't set the routes on the second one. Possibly there...

It might be enough to set https://developers.cloudflare.com/cloudflare-one/connections/connect-networks/configure-tunnels/tunnel-run-parameters/#grace-period so that cloudflared itself takes longer to wind down. As long as the systemd unit doesn't get impatient and kill it. Although there...

Another issue with having two named tunnels referring to the same tunnel id is that the authentication file is rewritten every time due to the two different tunnel names. There...

Sorry, this was wrong it works with or without the `shoutrrr` in the URL. It would be clearer if the URL was just pushover://__`apiToken`__@__`userKey`__ though - this would be consistent...

I also see this in 4.0.2.