Cloudron Forum

its essentially just a sign of an app serving many requests, and thereby hammering the db? Or not?

@james The host is the app though, or?

May 30 20:34:50 2026-05-30T18:34:50Z
May 30 20:34:50 Error Code:
May 30 20:34:50 Error Code:
May 30 20:34:50
May 30 20:34:50
May 30 20:34:50 Host '[REDACTED_IPV6]' is blocked because of many connection errors; unblock with 'mysqladmin flush-hosts'
May 30 20:34:50 Host '[REDACTED_IPV6]' is blocked because of many connection errors; unblock with 'mysqladmin flush-hosts'
May 30 20:34:50
May 30 20:34:50
May 30 20:34:50 ----------------------------------------
May 30 20:34:50 ----------------------------------------
May 30 20:34:50 ER_HOST_IS_BLOCKED
May 30 20:34:50 ER_HOST_IS_BLOCKED
May 30 20:34:50 Error: Host '[REDACTED_IPV6]' is blocked because of many connection errors; unblock with 'mysqladmin flush-hosts'
May 30 20:34:50 Error: Host '[REDACTED_IPV6]' is blocked because of many connection errors; unblock with 'mysqladmin flush-hosts'
May 30 20:34:50

Got some fairly popular projects on cloudron. With stuff getting more popular, I run more and more into problems where databases lock up because of "too many connections" Whats happening there?

I'm running Ghost (v6.22) on Cloudron behind a reverse proxy. I noticed that Ghost's ActivityPub endpoints (.ghost/activitypub/*) return response headers that
don't come from Ghost or Cloudron's nginx — they come from an upstream Google service:

via: 1.1 google
x-cloud-trace-context: ...
alt-svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000

Regular Ghost endpoints (e.g. /ghost/api/admin/site/) return the expected headers — X-Powered-By: Express, no Google trace, no alt-svc:

server: nginx
x-powered-by: Express
content-version: v6.22

But any request to /.ghost/activitypub/* gets proxied by Ghost to an external Google Cloud-hosted service (Ghost's managed ActivityPub backend), and the response
headers from that upstream are passed through unfiltered — including alt-svc: h3=":443"; ma=2592000.

The problem: This alt-svc header tells browsers/clients that HTTP/3 is available on port 443 of my server. If a client honors this, it will attempt a QUIC/H3
connection to my server, which may not support H3 at all — leading to failed connections or degraded behavior. The alt-svc is meant for Google's infrastructure,
not mine.

Expected behavior: Ghost (or Cloudron's nginx) should strip upstream alt-svc headers before returning responses to clients, since they refer to the upstream's
capabilities, not the server actually facing the client.

How to reproduce:
curl -sI https://your-ghost-instance/.ghost/activitypub/ | grep -i alt-svc

Compare with a regular Ghost endpoint:
curl -sI https://your-ghost-instance/ghost/api/admin/site/ | grep -i alt-svc

The first returns alt-svc, the second does not.

Ghost returns an alt-svc header for the route /.ghost/activitypub/inbox/index causing upgrade to h3. Since cloudron nginx does not support h3 the upgrade fails causing weird delays in the public proxy to cloudron.

But that points to how important the e2e read back step is.

Has to be a cifs problem related to large backups. NFS works, Otherwise same setup.

I think it has something to do with bigger backups like upwards 20GB of data

Yes, smb3. recreating the site config does not help. Then errors out as Password/Mac mismatch on restoration.

Interesting part is -> I tested with another cloudron instance that runs on another company account, but uses the same Synology backup target -> that one works. Really strange. Yet there is another user in the linked thread that has the same problem...

The only reason I can think of, why this is not done already by default would be bandwidth and s3 egress cost, otherwise it should be the default tbh, to at least read back what was stored.

@girish -> The question is: How many people using CIFS actually try to use backups? And how many are complaining? I'll write an email, just one quick question -> Would it be possible to have an option to read back the file after backup to compare it with the hash then? How else would one detect a backup problem at scale? Cause my understanding is, right now the hash does nothing, except show wether a backup is broken when I need it (which is too late to do anything about it, causing potential data loss)

@joseph @girish If you guys need help, want to hop on a call to see whats going on, let me know. I love Cloudron, but this kind of thing needs to work. Given the indications above it seems clear to me, that Cloudron can be improved on this front.

To put it bluntly: Working Backups are more important than a refined UI, new features, or a new app. If mismatching hashes are not even detected automatically, there is work to be done before doing anything else. Otherwise this in my view is unresponsible negligence for a product like this.

Even for my usecase, mostly gitea instances, it would be shitty to loose data. Good thing I save everything on various levels...

Like take invoiceninja: What do you tell someone who relies on your cloudron solution and who has not taken appropriate measures to save financial data otherwise, because he thought: "I have backups."

Its like you roll the dice with your customers.

So essentially, you are not even comparing backup hashes by reading back the file you just stored, or why is there no warning prior to needing a backup? How can this be considered "verifying" backups?

I needed exactly 2 backups to work from 2 different apps in the last 3 month. Both did not work. The question is: What exactly are you hashing? Where are you creating the hash? How are you creating the hash? A hash is simply a function that can tell you with a certain probability, that a certain input is equal to another input if the hash matches. It tells you nothing about wether the backup works or not. It might increase your odds, but nothing more.

Just tested with another app -> also failing. And yes, there are hash mismatches. Just tested a few. Hashes do not match.