Related to #20136 (WebSocket proxy peer/origin validation with config-based allowed_hosts). This PR takes a narrower approach: accept WS peers matching the explicitly bound non-loopback host. #20136 adds a full config-based allowlist. Both address the same class of issue (WS rejected behind reverse proxy/Tailscale).

Thanks for the pointer — that overlap is real.

This PR was intentionally kept narrow because it came out of a specific production deployment issue with Hermes Dashboard behind Tailscale Serve on a tailnet-only host.

In that setup we saw /api/events, /api/ws, and /api/pty fail their WebSocket upgrades even after the dashboard boundary had already been accepted via Host/Origin validation, because the peer check still only allowed loopback clients.

This change was meant as the smallest fix for that case:

• keep loopback/default binds strict
• accept non-loopback WS peers only when they match the explicitly bound host/IP
• avoid introducing broader proxy configuration surface area

So I agree #20136 is addressing the same class of problem, but with a more general config-driven shape. I’m happy for maintainers to choose whichever direction fits Hermes best.

If the broader trusted_proxy_hosts approach is preferred, I’m also happy to treat this PR as a narrower validated alternative / deployment datapoint rather than pushing both independently.

Landed in PR #35386 (merge commit 234ac00), now on main. Your PR identified the real gap the earlier wildcard fix left open — binding directly to an explicit non-loopback host (Tailscale/LAN IP) still failed the WS handshake. The merged version simplifies the peer-gate logic (it defers to the existing exact-Host guard rather than resolving the bind via getaddrinfo at request time), and you're credited as co-author via the commit trailer. Thanks for the fix and the clear repro.