Greptile Summary

This PR adds a well-structured per-IP fixed-window request rate limiter to the gateway, mirroring the existing auth-rate-limit.ts API. The module itself (request-rate-limit.ts) is clean and well-tested, but the integration in server-http.ts has a critical flaw: the rate-limit check is performed using req.socket?.remoteAddress before the trusted-proxy configuration is loaded.

Key findings:

• Critical: requestRateLimiter.check(req.socket?.remoteAddress) runs before trustedProxies / allowRealIpFallback are read from config. In a reverse-proxy deployment (nginx → gateway), req.socket?.remoteAddress is the proxy's own IP (often 127.0.0.1), which triggers the loopback exemption and silently bypasses rate limiting for every request. This defeats the stated goal for the reverse-proxy scenario.
• The fix is to move the rate-limit check to after the config snapshot and client IP are resolved, using resolveRequestClientIp(req, trustedProxies, allowRealIpFallback) as the IP source.
• The underlying createRequestRateLimiter implementation, test coverage, and plumbing through server-runtime-state.ts are all correct.

Confidence Score: 2/5

• Not safe to merge without addressing the proxy-IP bypass that silently disables rate limiting for all reverse-proxy deployments.
• The rate limiter module is well-implemented and tested, but the integration point in server-http.ts uses the raw socket address instead of the resolved client IP. For any deployment behind a local reverse proxy — the most common production setup — the loopback exemption causes the rate limiter to be completely bypassed, making the feature ineffective precisely where flood protection is most needed.
• src/gateway/server-http.ts — the rate-limit check must be moved to after the config snapshot loads and the client IP is resolved via resolveRequestClientIp.

This is a comment left during a code review.
Path: src/gateway/server-http.ts
Line: 772

Comment:
**Rate limiter bypassed entirely when behind a reverse proxy**

The limiter is called with `req.socket?.remoteAddress`, which is the TCP peer address — the IP of the reverse proxy, not the actual client. For the most common "reverse proxy" deployment scenario mentioned in the PR description, this means:

1. If the proxy runs on loopback (`127.0.0.1`), `isLoopbackAddress` returns `true` and every request is exempted from rate limiting.
2. If the proxy is at any other private address, all clients share that single counter, so the first client to hit 120 req/min blocks everyone.

The true client IP must be resolved first (reading `X-Forwarded-For` / `X-Real-IP` against the configured `trustedProxies`). The helper `resolveRequestClientIp` already does this correctly, but it requires the config snapshot. Moving the rate-limit check to after the config is loaded and the client IP is resolved would fix this:

```typescript
// After loading configSnapshot and resolving trustedProxies / allowRealIpFallback:
const clientIp = resolveRequestClientIp(req, trustedProxies, allowRealIpFallback);
if (requestRateLimiter) {
  const result = requestRateLimiter.check(clientIp);
  if (!result.allowed) {
    const retryAfter = result.retryAfterMs > 0 ? Math.ceil(result.retryAfterMs / 1000) : 1;
    res.setHeader("Retry-After", String(retryAfter));
    sendText(res, 429, "Too Many Requests");
    return;
  }
}
```

Without this fix, the feature only works correctly for direct (non-proxied) connections.

How can I resolve this? If you propose a fix, please make it concise.

_{Last reviewed commit: 5cc6be7}