HttpProtect.verify() method
Counts a request against its client IP and decides whether to serve it.
Signature:
verify(req: Request): Promise<VerificationResponse>;
Parameters
|
Parameter |
Type |
Description |
|---|---|---|
|
req |
Request |
the incoming request, from which the client IP is resolved with HttpProtect.getClientIp |
Returns:
Promise<VerificationResponse>
The verdict and its matching HTTP status code.
Exceptions
Error 'Redis connection is not established!' when there is no client — that is, after HttpProtect.destroy() — and the address is neither unidentifiable nor exempt.
Remarks
This is the whole decision, and it has side effects: it increments the address's counter, refreshes that counter's TTL to HttpProtect.ttl, and adds the address to HttpProtect.blockListKey once it passes HttpProtect.banLimit. Calling it twice counts twice, so the middlewares call it exactly once per request and you should too.
The order matters. A request whose client cannot be named at all — the resolver returned null, or a custom one returned something that is not an address — is answered LIMITED immediately, before Redis is touched: it cannot be counted, so it is refused rather than served, and it is kept out of the shared state entirely. An address in HttpProtect.safeNetworks then returns SAFE, also without touching Redis, so exempt traffic is served even when Redis is down. A banned address returns BANNED before the counter is read, so a ban costs one SISMEMBER and nothing accumulates behind it.
Read this page as plain markdown — no HTML, no navigation. For pasting into an LLM, or for an agent to fetch.