Support intro
Sorry to hear you’re facing problems. 
The community help forum (help.nextcloud.com) is for home and non-enterprise users. Support is provided by other community members on a best effort / “as available” basis. All of those responding are volunteering their time to help you.
If you’re using Nextcloud in a business/critical setting, paid and SLA-based support services can be accessed via portal.nextcloud.com where Nextcloud engineers can help ensure your business keeps running smoothly.
Getting help
In order to help you as efficiently (and quickly!) as possible, please fill in as much of the below requested information as you can.
Before clicking submit: Please check if your query is already addressed via the following resources:
(Utilizing these existing resources is typically faster. It also helps reduce the load on our generous volunteers while elevating the signal to noise ratio of the forums otherwise arising from the same queries being posted repeatedly).
Some or all of the below information will be requested if it isn’t supplied; for fastest response please provide as much as you can. 
The Basics
- Nextcloud Server version (e.g., 29.x.x):
- Operating system and version (e.g., Ubuntu 24.04):
e.g. Debian GNU/Linux 12 (bookworm)
- Web server and version (e.g, Apache 2.4.25):
- Reverse proxy and version _(e.g. nginx 1.27.2)
- PHP version (e.g, 8.3):
- Is this the first time you’ve seen this error? (Yes / No):
- When did this problem seem to first start?
- Installation method (e.g. AlO, NCP, Bare Metal/Archive, etc.)
- Are you using CloudfIare, mod_security, or similar? (Yes / No)
Summary of the issue you are facing:
I described my issue separately (https://help.nextcloud.com/t/nextcloud-aio-with-traefik-gives-404-on-public-domain), but I have found many other reports of issues with running Nextcloud AIO behind a reverse proxy, such as Traefik. Readers are often referred to all-in-one/reverse-proxy.md at main · nextcloud/all-in-one · GitHub , which does contain a Troubleshooting section, but that section lists possible solutions to various problems, without describing how to actually identify the underlying problem. Would it be possible to provide a How-to on trouble-shooting connectivity problems, e.g. where to look for error messages arrising from the Nextcloud vs. the reverse-proxy configuration?
I defined a compose.yml file to run Docker AIO and another to run the Traefik container. While iterating through the different ways of making them talk to each other, do I need to stop and restart all the containers every time, or just the mastercontainer if changes were made to the compose.yml?
Thanks for your help!
Since my traefik is set up to write logs into a specified folder, I thought that the file traefik-access.log could be a good place to look just after a failed attempt to connect to the public domain of the nextcloud server. However, what I see every time after a failed attempt leading to 404 page not found:
... GET / HTTP/2.0" 404 19 "-" "-" 242 "-" "-" 0ms
I guess this just documents the 404 error. Independently of these attempts, traefik.log produces these suspicious lines:
2026-08-21T18:08:13Z DBG log/log.go:244 > http: TLS handshake error from <some IP>:54096: read tcp <local IP>:443-><some IP>:54096: read: connection reset by peer
2026-08-21T18:08:13Z DBG log/log.go:244 > http: TLS handshake error from <some IP>:54104: tls: no cipher suite supported by both client and server; client offered: [xx yy ...]
2026-08-21T18:08:13Z DBG github.com/traefik/traefik/v3/pkg/tls/tlsmanager.go:288 > Serving default certificate for request: "<public IP>"
2026-08-21T18:08:14Z DBG log/log.go:244 > http: TLS handshake error from <some IP>:54114: read tcp <local IP>:443-><some IP>:54114: read: connection reset by peer
Actually, when I stop the nextcloud aio masterconainer, this shows up in my traefik.log as:
[...]Provider event received {Type:container Action:die[...] com.docker.compose.service:nextcloud-aio-mastercontainer com.docker.compose.version:5.5.0 ...
When I restart it again:
[...]Provider event received {Type:container Action:start [...]nextcloud-aio-mastercontainer ...
each time followed by
...Filtering disabled container container=nextcloud-aio-apache-...
for each remaining container.
When I stop all containers through the Nextcloud admin interface, this shows up in traefik.log as:
...Provider event received {Type:container Action:die ... exitCode:0 image:ghcr.io/nextcloud-releases/aio-imaginary:latest ...
and so on for each container, followed each time by the usual Filtering disabled containermessages for each container. So Traefik is monitoring the starting and stopping of the nextcloud containers, but I am not sure what the “Filtering disabled container” messages mean. Does traefik see them as disabled? Could this be the reason why I cannot access my nextcloud domain, i.e. since traefik sees nextcloud-aio-apache as disabled, it won’t connect to it?
With docker network inspect nextcloud-aio I was able to confirm that my traefik container is connected to the same network as all the nextcloud containers.
According to @denNorske, the “Filtering disabled container” is shown for each container that is not in scope for auto-discovery, which is normal for all nextcloud-aio containers.
You can see all running containers with the command docker ps and for each of your networks, e.g. the network proxy, you can see which containers are connected by executing e.g. docker network inspect proxy.
With the help of @denNorske the problem described in https://help.nextcloud.com/t/nextcloud-aio-with-traefik-gives-404-on-public-domain was eventually solved by detailed inspection of traefik.log before and after changes to the traefik configuration, and finally by testing the domain using curl -vL [your domain]. This revealed that the domain name was misspelled in my traefik configuration, as I had replaced https by websecure in too many places.