403 When Accessing Site Through URL (Cloudflare)

[Heph]

Here's a strange one, I could not find anybody else having it using the search function.
My Chevereto website is kicking out 403 Forbidden for anybody accessing it through the URL that's being proxied by Cloudflare.
This may have happened after a user had tried to log in to their account unsuccessfully many times.
I can access the website using my external IP and my internal IP.
I don't see any banned IPs in the dashboard.

My version of Chevereto is installed with a docker in Unraid that I installed through community apps, I did not load the image in docker myself.
I had noticed some oddities, all users are logged as coming from the IP of 192.168.1.1 unless using my IP : Port to access the website. I'm wondering if this is making the site or the DB handle all traffic from the URL as the same user.

And I noticed that any time an update is available, my version of Chevereto is automatically kicked out of pro and into free version until I upgrade it using the dashboard, which is not exactly desired behavior but I just assumed this was intended.

Error log

AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 172.17.0.10. Set the 'ServerName' directive globally to suppress this message
AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 172.17.0.10. Set the 'ServerName' directive globally to suppress this message
[Sun Jun 29 04:15:20.005357 2025] [mpm_prefork:notice] [pid 1:tid 1] AH00163: Apache/2.4.62 (Debian) OpenSSL/3.0.16 configured -- resuming normal operations
[Sun Jun 29 04:15:20.005409 2025] [core:notice] [pid 1:tid 1] AH00094: Command line: 'apache2 -D FOREGROUND'
[Sun Jun 29 09:07:33.572552 2025] [mpm_prefork:notice] [pid 1:tid 1] AH00170: caught SIGWINCH, shutting down gracefully
AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 172.17.0.10. Set the 'ServerName' directive globally to suppress this message
AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 172.17.0.10. Set the 'ServerName' directive globally to suppress this message
[Sun Jun 29 09:07:37.615182 2025] [mpm_prefork:notice] [pid 1:tid 1] AH00163: Apache/2.4.62 (Debian) OpenSSL/3.0.16 configured -- resuming normal operations
[Sun Jun 29 09:07:37.615279 2025] [core:notice] [pid 1:tid 1] AH00094: Command line: 'apache2 -D FOREGROUND'
[Sun Jun 29 09:14:34.629058 2025] [mpm_prefork:notice] [pid 1:tid 1] AH00170: caught SIGWINCH, shutting down gracefully
AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 172.17.0.10. Set the 'ServerName' directive globally to suppress this message
AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 172.17.0.10. Set the 'ServerName' directive globally to suppress this message
[Sun Jun 29 09:15:02.465798 2025] [mpm_prefork:notice] [pid 1:tid 1] AH00163: Apache/2.4.62 (Debian) OpenSSL/3.0.16 configured -- resuming normal operations
[Sun Jun 29 09:15:02.465835 2025] [core:notice] [pid 1:tid 1] AH00094: Command line: 'apache2 -D FOREGROUND'
[Sun Jun 29 10:20:37.890051 2025] [mpm_prefork:notice] [pid 1:tid 1] AH00170: caught SIGWINCH, shutting down gracefully
AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 172.17.0.10. Set the 'ServerName' directive globally to suppress this message
AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 172.17.0.10. Set the 'ServerName' directive globally to suppress this message
[Sun Jun 29 10:20:39.524837 2025] [mpm_prefork:notice] [pid 1:tid 1] AH00163: Apache/2.4.62 (Debian) OpenSSL/3.0.16 configured -- resuming normal operations
[Sun Jun 29 10:20:39.524879 2025] [core:notice] [pid 1:tid 1] AH00094: Command line: 'apache2 -D FOREGROUND'

 

[Rodolfo]

1. Read: https://developers.cloudflare.com/s...g-visitor-ips/restoring-original-visitor-ips/

Chevereto uses CHEVERETO_HEADER_CLIENT_IP

Docs: https://v4-docs.chevereto.com/application/configuration/environment.html#proxy

2. That happens because in Docker when you start a container it reverts any change on the application filesystem to the stock image. You are pulling the free edition, that's why it reverts to that one.

The Dashboard upgrade process was never meant or designed for Docker, is for users running either in shared hosting or "root server" infra.

The ideal upgrade process for Docker is to re-build the image. This is because the persistent app volume approach only updates the app filesystem and it doesn't carry the infrastructure updates we ship on the container.

 

[Heph]

A lot of this is above me.
But from

Chevereto uses CHEVERETO_HEADER_CLIENT_IP

Docs: https://v4-docs.chevereto.com/application/configuration/environment.html#proxy

I added the variable


And I have access again! Thanks!

For the point that I have a docker based on the free version, this all is a bit of a minor hobby of mine and I've only dipped my toes in a few times to figure out how to build a container myself, I'll try to return to it later. All of this is just for people who want to post videos and photos that are too large and wont fit in the size requirement for Discord, so upgrading it back to Pro when I notice the website it showing my profile as the main landing page is not that big of a deal, not mission critical.

 

[Rodolfo]

I think we could publish an infra-only (no app files) container image, that way when updating the image it won't conflict with the app filesystem at all, preventing the "free downgrade loop" issue we have on every consecutive update.