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

hermes vhost: dial netavark's host address, not the LAN IP (fixes the 502)

Browse Source 
hermes-webui is Network=host, so 8787 is a bare host-netns bind, and netavark
DNATs only *published* ports. From Caddy's bridge netns 192.168.0.143:8787 and
10.89.1.1:8787 are both refused, while host.containers.internal:8787
(169.254.1.2) answers 200 — measured live 2026-09-16 from inside the Caddy
container. The dashboard's published 9119 answers on that same LAN IP, which is
what made the old upstream look sound.

The vhost comment asserted "192.168.0.143:8787 is open" from that bridge; it is
not, so the claim is replaced with the measurement, and the hermes-webui quadlet
comment carries the same correction. The seam guarding this invariant accepted
any numeric upstream, so the LAN IP passed it; it now pins the measured-working
form and fails on the LAN IP (teeth verified by substitution).
This commit is contained in:
Frank
2026-09-16 19:28:34 -07:00
parent 65fbef63dc
commit d14e0a94eb
3 changed files with 30 additions and 15 deletions
Download Patch File Download Diff File Expand all files Collapse all files
dankclaw/Caddyfile
+8 -5
View File
@@ -176,12 +176,15 @@ pihole.franksdank.cloud {
# here enters the http://:8016 auth chain. Internal-only by DNS absence: there is
# no public Porkbun A record for this name, so only LAN clients (Pi-hole
# addn-hosts → 192.168.0.143) can resolve it at all; DNS-01 issuance via the
# Porkbun module needs no public record. Upstream is the host LAN IP rather than
# localhost because Caddy itself lives on dankclaw_default: from that bridge the
# gateway address 10.89.1.1 has nothing serving 8787 (connection refused), while
# 192.168.0.143:8787 is open.
# Porkbun module needs no public record. Upstream is `host.containers.internal`
# — netavark's host address, 169.254.1.2 — NOT the host LAN IP: hermes-webui is
# `Network=host`, so 8787 is a host-netns bind and not a published port, and
# netavark DNATs only published ports (192.168.0.143:9119, the dashboard below,
# answers from this bridge; 192.168.0.143:8787 does not). Measured live
# 2026-09-16 inside the Caddy container: 192.168.0.143:8787 and 10.89.1.1:8787
# both REFUSED, host.containers.internal:8787 → 200.
hermes.franksdank.cloud {
reverse_proxy 192.168.0.143:8787
reverse_proxy host.containers.internal:8787
}
# --- Hermes dashboard (admin UI; published 9119 on dankclaw_default) --------
dankclaw/hermes/quadlet/hermes-webui.container
+6 -4
View File
@@ -16,10 +16,12 @@
# can drive the browser; a bridge-network client could not reach it at all.
# The server binds 0.0.0.0:8787 of the host netns, and that is deliberate:
# this unit is host-networked (the CDP daemon above needs a shared loopback), so
# Caddy cannot reach it by container name and fronts the guarded vhost
# hermes.franksdank.cloud with `reverse_proxy 192.168.0.143:8787` (see the
# hermes block in dankclaw/Caddyfile, which records the same constraint). A
# loopback bind was tried on 2026-09-16 for a tighter posture and broke that
# Caddy cannot reach it by container name and fronts the vhost
# hermes.franksdank.cloud with `reverse_proxy host.containers.internal:8787`
# (netavark's host address, 169.254.1.2) — not the host LAN IP, which Caddy's
# bridge netns cannot reach for a bare host-netns bind; the measured asymmetry
# with published ports is recorded in the hermes block of dankclaw/Caddyfile.
# A loopback bind was tried on 2026-09-16 for a tighter posture and broke that
# vhost, because a bind is also the only way an off-host process can reach a
# host-networked container: the LAN address and the tunnel's localhost hop are
# both served by the wildcard, and a loopback-only bind serves only the latter.