The Digesta host added both 10.89.0.178 and ::ffff:10.89.0.178 to
trusted_proxies and host->8777 still refused. The ::ffff: hunch was right: the
internal nginx listens on 8776 AND [::]:8776, so a connection landing on the v6
socket makes $remote_addr -- and therefore X-Forwarded-For, and therefore the
peer -- the IPv4-mapped form, which a string membership test rejects even when
the plain address is listed. Nothing in the configuration explains that refusal.

Peers are now compared as addresses: a mapped v6 peer matches a plain v4 entry
and the reverse, and CIDR entries work, so a container network can be trusted as
10.89.0.0/24 instead of pinning one address in the quadlet. A non-address entry
(a socket path) is still compared literally, and a v6 peer never matches a v4
network.

Their broadened list could not have taken effect anyway -- it went into the
config.json the app is not reading, which is why `enabled` there did nothing and
the env var was needed. So that test did not rule the peer check out; the list in
force was still the default pair.

The rest of the report is answered in the doc rather than in code, because there
is no bug behind it: `Server: nginx` appears on PROXIED responses too unless
proxy_pass_header Server is set, and the missing `GET /admin` access-log line is
_PollNoiseFilter, which drops reads of /admin, /static, /login and /logout from
the front's access log while leaving /healthz alone -- exactly the asymmetry that
looked like nginx short-circuiting by source. A 302 to /coderai/login with no
Set-Cookie is what the front returns when forward-auth declines.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>