dank/serverAppConfigs
1
0
Fork 0
Code Issues 6 Pull Requests Actions Packages Projects Releases Wiki Activity

docs(caddy): record the h2c-transport gotcha behind the jellyfin vhost 502

Browse Source 
Kestrel rejects the h2c upgrade preface; Caddy surfaced that as a 502 per
request while the backend answered 200 on plain HTTP/1.1 from Caddy's network.
Contrast recorded: Plex PMS needs the TLS transport, Jellyfin needs none.
This commit is contained in:
Frank
2026-08-29 04:26:37 -07:00
parent 7e900f6400
commit eb7448815b
1 changed files with 5 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
serverAppConfigs-docs/Infrastructure/Caddy.md
+5
View File
@@ -103,6 +103,11 @@ Certificates and ACME state live in the caddy data volume. Back it up with the s
- A new vhost needs three things: a Pi-hole `addn-hosts` line, a Porkbun A record, and the Caddyfile block. See [[LAN-DNS]].
- The G36 has no NAT loopback, so LAN clients must resolve the name to the LAN IP. That is the Pi-hole role in [[LAN-DNS]].
- Caddy serves HTTPS on 443 and HTTP on 80 (redirects). The router needs no 80/443 port forward for LAN use.
- `transport http {versions h2c 1.1}` on a vhost makes Caddy send an h2c
upgrade preface; .NET/Kestrel backends (Jellyfin) reject it and Caddy turns
the failure into a 502 while the same port answers 200 over plain HTTP/1.1.
Match the transport to what the backend speaks: Jellyfin = default HTTP/1.1,
Plex PMS = TLS (PMS drops plain HTTP off-loopback, see the test suite).
## See Also