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.