From 5892416aa4363ad8b14d29cc31d843c4ec75e932 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 af7f7c5..972448d 100644
--- a/README.md
+++ b/README.md
@@ -2689,9 +2689,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