From 3050c2e3b517910b7142d326826adc6f1b8e61db Mon Sep 17 00:00:00 2001
From: clawbot <35+clawbot@noreply.example.org>
Date: Tue, 29 Sep 2026 09:01:49 +0000
Subject: [PATCH] Point to the proxy's access log for a login flood's source

No log line records the client address taken from X-Forwarded-For,
so the login endpoint section no longer says the source shows in the
failure logs; it names the proxy's access log instead.

Model: opus-5-5
---
 README.md | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/README.md b/README.md
index b65b5d2..a5a2ff2 100644
--- a/README.md
+++ b/README.md
@@ -2722,9 +2722,10 @@ re-fills both verification slots on its first two requests. The
 remedies are to block the source at the reverse proxy, or to
 rate-limit `POST /pages/login` there — the one place a limit can be
 applied without reintroducing the lockout, because the proxy sees the
-real client address. `TRUSTED_PROXIES` does not stop the saturation,
-but when it covers the proxy the source is visible in the failure logs,
-and the default covers a proxy on a private network.
+real client address. `TRUSTED_PROXIES` does not stop the saturation.
+The flood's source is in the proxy's access log: webhooker's own logs
+record the proxy's address, not the client's (see
+[Deployment behind a reverse proxy](#deployment-behind-a-reverse-proxy)).
 
 Finer-grained per-webhook rate limits (configured in the web UI and
 enforced in the webhook handler) can layer on top of this env-level