Rate Limiting for a wildcard-subdomains in Caddy

Help
1

I’m looking to configure Caddy to handle rate-limiting for a wilcard configured domain, with a single reverse-proxy.

Our application requires subdomains for each tenant. Because of higher traffic volume to one of the subdomains (tenants), we want to block excessive traffic on a specific subdomain. This block is temporary, and should be unblocked automatically.

Q: Is this possible to have an TLS-ASK style endpoint that will suggest if the request is to be accepted OR not?

*.api.myapp.com {
	reverse_proxy localhost:5100 {
		header_up X-Real-IP {remote_host}
	}

	tls {
		dns <provider> <token>
		resolvers 8.8.8.8
	}
}

Any guidance on setting this up effectively would be appreciated.

Using: Caddy 2, Ubuntu 20x.

2

Yes, you can do that with forward_auth. This does increase the load/latency though cause your server would then need to do an extra roundtrip before actually proxying to your app. Forward auth is great for low-pressure apps, but has downsides for more performance-critical applications.

You could use GitHub - mholt/caddy-ratelimit: HTTP rate limiting module for Caddy 2 for rate limiting, you could match based on hostname to only apply it for specific tenants I guess. You could implement a matcher plugin which loads and caches your list of rate limited hostnames from your database or whatever (maybe refreshing the list on some interval) which would keep it fast.

1 Like
3

thanks for the suggestion. However, Forward_auth will be overkill.
looking forward to the decision to server the given domain falling under the wildcard configuration.

so, when my configuration says *.api.myapp.com, should I allow serving tenant 1 with a request on tenant1.api.myapp.com? If this decision can be made by making an API/HTTP call to my app, that will simplify the tenant rate limits for me. Obviously, some kind of caching should happen (instead of making a call always).

If nothing works, I may resort to writing a custom module.

4

That’s literally what forward_auth is. It makes an HTTP request to your app. (GET request with the same headers as the original request). Your app returns 2xx to say “yep keep going” or any other status code to mean “nah it’s no good” and Caddy will write that non-2xx response back to the client.

In that case, you’ll probably want to write your own plugin to do this. Caching behaviour can get complex (where it’s stored, how the key is constructed, the TTLs, eviction policy, etc), best if you decide how you want that done yourself.

Writing plugins is easy: Extending Caddy — Caddy Documentation

5

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.