AIO domain validation, possible bug?


I just installed Nextcloud AIO, which is working fine. However, I had trouble getting past the domain validation. Seems others have had issues too, and the official recommendation is to skip the check altogether. I believe it’s a problem with Nextcloud AIO if the domain check could fail when a reverse proxy is correctly configured. I’m suspicious about the log message when the check fails:

NOTICE: PHP message: The response of the connection attempt to "" was:

This has me wondering if the domain check is trying to use HTTP (without SSL) into port 443. This would make it finicky depending on the reverse proxy configuration. Some might only allow HTTP on 80 and HTTPS on 443.

Tagging @szaimen, the Nextcloud Master, who will probably know the answer immediately.


This is not a bug and working as designed.

So you probably need to skip the domain validation.

Isn’t it non-standard to use 443 for HTTP? Reverse proxies will be expecting SSL headers so they can route based on the SNI. If this is Nextcloud AIO’s design anyway, I think it would be appropriate to add a note somewhere in the documentation. If users know how the check is supposed to work, we can determine when to skip the check, vs. when to keep trying to fix our proxy config.

The issue is most likely your router. You might be able to fix it with GitHub - nextcloud/all-in-one: The official Nextcloud installation method. Provides easy deployment and maintenance with most features included in this one Nextcloud instance.

Sorry if my original post wasn’t clear. I already bypassed the domain validation by temporarily forwarding all traffic to my Nextcloud AIO, then re-enabled SNI routing. I’m sure the option to skip domain validation would have worked too. My install seems to be working now.

I’m trying to help make this smoother for users in the future. It is a hack to “skip domain validation” when the reverse proxy is correctly configured.

I suggest AIO use standard protocols/ports (HTTP/80, HTTPS/443). If AIO must use non-standard HTTP/443 for some reason, it ought to be documented so we can know why the check fails, or add this edge case to our proxy config.