bogus alt-svc header causing h3 upgrades

[philkunz]

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.

[philkunz]

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.