All containers 'green', but getting "ERR_CONNECTION_REFUSED"

[iGadget]

As per topic title, I'm getting "ERR_CONNECTION_REFUSED" when trying to access my Nextcloud AIO instance, even though all containers have status 'green' in the AIO control panel (which I was able to access after manually stopping the nextcloud-aio-apache container).
Not sure when this problem first occurred (I'm on the road currently and have not used Nextcloud for a couple of days) or if some update caused it, but it was working before and had been running without this issue for several months.

I'm running Caddy reverse proxy on a different host and figured perhaps some update caused a misconfiguration. So I added the reverse proxy's IP in config.php as per this article under 'trusted_domains' and 'trusted-proxies' (where, to my suprise, the IP of the reverse proxy wasn't present). This did not fix the issue, even after stopping and starting all containers.

What else could be causing this / how do I debug this?

[iGadget]

Well, seems I fixed it by editing the original docker-compose.yml file I used to set up my AIO instance last year. Here I replaced the IP of my old Nginx proxy server (which I was still using back then) with the one of my current Caddy reverse proxy. I then stopped the nextcloud-aio-mastercontainer, removed it and ran the command docker-compose up -d && docker-compose logs -f.
Voilà, Nextcloud AIO back up and running.

How this problem was caused in the first place is still a mystery to me.

[iGadget]

Ok, seems I cried victory too soon - this problem just manifested itself AGAIN.
Same symptoms - ERR_CONNECTION_REFUSED. State of Apache container in the AIO control panel is 'green' (running), but when using lazydocker, it says it's status is 'unhealthy'.
Stopping all containers and then stopping, removing and rebuilding the nextcloud-aio-mastercontainer DOES NOT solve this issue this time :-(
One thing I noticed when looking at the (running) nextcloud-aio-mastercontainer config via lazydocker, it shows the following at "NEXTCLOUD_TRUSTED_DOMAINS=": \003c <my-nextcloud-fqdn> \003e \003c <ip-of-my-caddy-proxy> \003e.
Same goes for "TRUSTED_PROXIES=": \003c <ip-of-my-caddy-proxy> \003e.
Apparently, those are unicode escapes, caused by using the symbols '<' and '>' in the YAML file. Removing them and then repeating the whole procedure doesn't solve the issue, however.

What else can I do to debug this?

[iGadget]

Ok, this is interesting... On 2 different webbrowers on my laptop (connected to local network via VPN) AND my mobile (connected externally via 5G) I'm getting "ERR_CONNECTION_REFUSED" when trying to access my AIO instance via the domain name.

Running curl -vvv 10.0.0.1:11000/login on my laptop or from the proxy machine however, I get the Nextcloud login page. Same if I try http://10.0.0.1:11000/login in a browser (of course, only on my local network).

So at least Nextcloud itself seems to be running properly and somehow things go bad when using the domain name and/or SSL.
I have not touched the proxy machine's config after (successfully) setting it up months ago, so I'm hesitant to be pointing fingers that way. But how to be sure?

[szaimen]

Can you check that the dns config id still correct and port 443 cotrrectly forwarded?

[iGadget]

When I type host my-nextcloud-aio.domain it resolves to the IP of my proxy host, so that seems correct.
How do I know if port 443 is correctly forwarded?
curl -vvv https://my-nextcloud-aio.domain results in

*   Trying 10.0.0.2:443...
* connect to 10.0.0.2 port 443 failed: Connection refused
* Failed to connect to my-nextcloud-aio.domain port 443 after 117 ms: Connection refused
* Closing connection 0
curl: (7) Failed to connect to my-nextcloud-aio.domain port 443 after 117 ms: Connection refused

[iGadget]

While trying to add a test config to my sites.caddy file an messing around with it a bit, suddenly my setup started working again?!
I'm completely clueless on what caused (and solved) this issue, but something tells me this will not be the last time I'm going to run into it :-\

At any rate, thanks for all your suggestions so far, @szaimen . Fingers crossed it'll keep working now...