[dawiegriesel]

Stacks on #279 (its two commits are included here); the new change is the last commit.

Problem

With --ip-from x-forwarded-for (or x-real-ip), a request that carries no such header is rejected before any response is written, so the client sees a dropped connection. On Azure App Service the platform's own startup probe reaches the container from a link-local address (169.254.x.x) with no X-Forwarded-For:

DEBUG faucet] Accepted TCP connection from 169.254.137.1:17829
ERROR faucet] Error extracting IP, verify that proxy headers are set correctly: Missing header: X-Forwarded-For
ERROR faucet] Connection error: hyper::Error(User(Service), Missing header: X-Forwarded-For)

The container is therefore never marked ready and the site serves 503, even though every real user request does carry the header. Other platforms whose health checks bypass the edge proxy will behave the same way.

Change

When the configured header is absent, use the peer address (the same value --ip-from client would use) and log it at debug level. It is still a stable key for ip-hash. A header that is present but malformed is still an error, and a missing header with no peer address is still an error, so nothing becomes silently permissive.

Tests

Four new unit tests: missing X-Forwarded-For falls back to the peer, missing X-Real-IP falls back to the peer, missing header with no peer is an error, malformed header is still an error. cargo test passes (90 tests). The two clippy -D warnings findings on this branch are in websockets.rs and telemetry/mod.rs and are present on main.

Verified on a live App Service slot: with this build the probe is answered, the container is marked ready, and sessions are served by the workers.

🤖 Generated with Claude Code