Rate Limiting Relativity web sites (Non-Kepler)

This topic describes how to set up Rate Limiting for web sites within Relativity. These instructions apply to Relativity Server 2024 and later, and are intended for Relativity administrators and infrastructure teams. You will need access to Windows Server / IIS admin access on the Relativity web servers, and optionally a reverse proxy or Web Application Firewall (WAF).

What this guide covers, and why it is needed

Relativity's Kepler-hosted REST APIs already have their own, built-in rate limiting — an administrator can turn it on through an instance setting. See the companion Kepler Rate Limiting guide. That protection only applies to calls that go through the Kepler pipeline and identify themselves with a special header. It does not cover:

• Requests that do not identify a calling application.
• Endpoints outside the Kepler pipeline — for example, legacy ASP.NET pages such as native file download endpoints, or other IIS-hosted applications that ship alongside Relativity Server, such as Relativity.Distributed.

To close that gap, and to add a layer of protection that doesn't rely on the caller cooperating, we recommend enforcing rate limiting at the web server or network layer instead. Done this way, the limit applies uniformly to every request an IIS site receives, no matter which application or endpoint is being called.

This guide walks through two approaches:

1. IIS Dynamic IP Restrictions — a built-in Windows/IIS feature. No extra infrastructure required.
2. A reverse proxy or Web Application Firewall (WAF) in front of Relativity — more capable, but requires standing up and maintaining additional infrastructure.

These aren't either/or. A common setup uses IIS Dynamic IP Restrictions as a baseline everywhere, and adds a WAF or reverse proxy for internet-facing environments that need finer control.

Before you begin: determine the right threshold

There's no single correct number of requests-per-second that works for every environment. It depends on how many users you have, how many workspaces, and how much of your traffic is things like bulk exports or automated integrations. A limit that's safe for a small environment could throttle real users in a larger one. Instead of picking a number from this guide, measure your own traffic first.

To measure it using logs you already have:

1. IIS already logs every request, including client IP, timestamp, and URL, under %SystemDrive%\inetpub\logs\LogFiles by default.
2. Pull logs from a busy, representative period, such as a large production or export cycle or a month-end peak — not a quiet week.
3. Filter to the specific URL you want to protect.
4. Group requests by client IP and by a short fixed time window, for example every 10 seconds, and count them.
5. The highest count you see is your real legitimate peak. Set your threshold comfortably above that, so normal activity is never throttled.

If your organization already forwards IIS logs to a platform like Splunk, Elastic, or Azure Monitor, this is usually just a quick query against data you already have.

Always validate before enforcing. Both options below support a logging-only mode that reports what would be blocked without actually blocking anything. Use it first to sanity-check your threshold against real traffic before turning on enforcement.

Option 1: IIS Dynamic IP Restrictions

What it does

Dynamic IP Restrictions (sometimes called DIPR) is a built-in IIS feature that automatically blocks a client IP address once it crosses a threshold you configure. It supports two independent triggers:

• Concurrent request limiting — blocks an IP once it has more than a set number of requests in flight against the server at the same time.
• Request rate limiting — blocks an IP once it makes more than a set number of requests within a time window, for example more than 50 requests in 5 seconds. This is the direct equivalent of application-level rate limiting, done entirely at the web server.

Step 1: Install the feature

Dynamic IP Restrictions isn't installed by default on most Windows Server builds.

1. Open Server Manager > Add Roles and Features.
2. Under Web Server (IIS) > Web Server > Security, select IP and Domain Restrictions.
3. Complete the wizard and install.

Step 2: Configure it through IIS Manager

1. Open IIS Manager.
2. Select either the server node (to apply the policy to every site) or a specific site (for example, just the site hosting legacy download endpoints), depending on how broadly you want it to apply.
3. Double-click IP Address and Domain Restrictions.
4. In the Actions pane, click Edit Dynamic Restriction Settings and configure:
   • Deny IP address based on the number of concurrent requests — select this and set a maximum.
   • Deny IP address based on the number of requests over a period of time — select this and set a maximum request count and a time window, in milliseconds.
5. In the Actions pane, click Edit Feature Settings to choose what happens to a blocked request (the Deny Action Type):
   • Unauthorized (HTTP 401)
   • Forbidden (HTTP 403)
   • NotFound (HTTP 404)
   • AbortRequest (drops the connection with no response at all)

Step 2 alternative: Configure it through web.config

The same settings can be applied directly in a web.config file, either server-wide (applicationHost.config) or scoped to one site or application:

<system.webServer>
    <security>
        <dynamicIpSecurity enableLoggingOnlyMode="true" denyAction="Forbidden">
            <denyByConcurrentRequests enabled="true" maxConcurrentRequests="20" />
            <denyByRequestRate enabled="true" maxRequests="50" requestIntervalInMilliseconds="5000" />
        </dynamicIpSecurity>
    </security>
</system.webServer>

Step 3: Watch out for shared or NAT'd IP addresses

Dynamic IP Restrictions decides based on the client IP address IIS actually sees on the connection, which creates two common surprises in real deployments:

• If Relativity sits behind a load balancer, reverse proxy, or VPN concentrator that doesn't forward the real client IP, every request looks like it's coming from that one intermediary — meaning all your users look like a single client. This can trip the limit almost instantly and block everyone.
• Conversely, many users behind a shared corporate NAT or VPN gateway can all appear as one IP address to IIS. A strict per-IP limit could throttle that entire group even though no individual user is doing anything wrong.

Before turning on enforcement, confirm whether the true client IP reaches IIS, for example via an X-Forwarded-For header. If it doesn't, do one of the following:

• Configure your load balancer or reverse proxy to forward the original client IP.
• Apply the rate limit at the load balancer or reverse proxy layer instead, where the real client IP is known. See Option 2.
• Explicitly allow known infrastructure IPs, such as load balancers and known automation or service accounts, so they're excluded from the limit.

Also account for legitimate high-volume automated clients, such as bulk import/export tools and processing agents, when choosing thresholds, so normal automation doesn't get mistaken for abuse.

Step 4: Verify it works

• Use a load-testing or scripting tool to send more requests than your configured threshold from a single test client, and confirm the expected block actually happens.
• Check IIS logs, or Failed Request Tracing if enabled, to confirm blocked requests are being logged as expected — especially while still running in logging-only mode.

Limitations to keep in mind

• One blunt threshold applies to every request on the scoped site. It can't say "10 per second is fine for this endpoint but not that one" without splitting the policy across separate sites or applications.
• No visibility into request content, so it can't distinguish a legitimate burst of activity from a malicious one beyond raw volume.

Option 2: A reverse proxy or Web Application Firewall (WAF)

What this adds beyond IIS's built-in feature

A reverse proxy or WAF placed in front of your Relativity web servers intercepts traffic before it ever reaches IIS. Compared to Dynamic IP Restrictions, it typically offers:

• Rate limiting scoped to specific URL paths, not just a whole site.
• Richer signals for spotting abusive traffic — headers, cookies, geographic origin, bot detection — not just the source IP.
• Softer responses than a hard block, such as a CAPTCHA challenge, temporary throttling, or log-only alerting.
• Broader web security benefits alongside rate limiting, including protection against SQL injection, cross-site scripting, and other common attack types.
• One single enforcement point in front of multiple web servers, useful for load-balanced, multi-server deployments.

The tradeoff is operational: you're standing up and maintaining an extra piece of infrastructure, and need to make sure it doesn't conflict with load balancing you already have. In a multi-server setup, the reverse proxy or WAF is typically placed in front of your existing load balancer, or replaces it if it also load-balances. Plan the layout so that every request reaching any Relativity web server has already passed through it.

Candidate products

Example: basic rate limiting in NGINX

This configuration limits any single client IP to 10 requests per second against a proxied Relativity site, with a small allowance for short bursts:

http {
        limit_req_zone $binary_remote_addr zone=relativity_limit:10m rate=10r/s;
        server {
            listen 443 ssl;
            server_name relativity.example.com;
            location / {
                limit_req zone=relativity_limit burst=20 nodelay;
                proxy_pass https://relativity_backend;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header X-Real-IP $remote_addr;
            }
        }
}

The proxy_set_header lines matter: they preserve the real client IP address as the request is forwarded on to IIS. This is important both for any rate limiting you also run at the IIS layer and for Relativity's own auditing and logging.

Choosing between the two options

Recommendation: start with IIS Dynamic IP Restrictions in logging-only mode as an immediate, low-effort baseline. Add a reverse proxy or WAF if you need path-specific rules, richer traffic inspection, or one enforcement point across multiple web servers.

Frequently asked questions

Does this replace Kepler's built-in rate limiting?
No. The two are complementary. Kepler rate limiting is opt-in and per-caller for Kepler API traffic. This guide covers everything Kepler rate limiting doesn't reach: requests without an identifying header, and non-Kepler IIS-hosted endpoints.

Will this affect real users?
Not if you follow the measure first, validate in logging-only mode, then enforce sequence in this guide. Skipping straight to enforcement with a guessed threshold is the main way legitimate users get blocked.

What if my environment has multiple web servers behind a load balancer?
For Option 1, make sure the true client IP is forwarded all the way to IIS, or allowlist your load balancer's IP, and combine IIS logs from all servers when measuring peak rates. For Option 2, place the reverse proxy or WAF in front of the load balancer so it sees every request before it's distributed.

Do I need both options?
Not necessarily. Many environments only need Option 1 — it's free and built in. Add Option 2 if you're internet-facing, run multiple servers, or need finer control than one threshold per site.