Available settings for global rate limits and throttling

[Discourse]

Discourse ships with 3 different global rate limits that can be configured by site admins.

Global per-ip rate limits

These limits apply to every unique IP address that hits the Discourse application. (files that are served directly from the filesystem or the CDN are excluded)

By default this rate limit is enabled, you may disable it or set it to a reporting mode.

DISCOURSE_MAX_REQS_PER_IP_MODE : default block, this rate limit applies out of the box. (other options are warn, warn+block, and none)

DISCOURSE_MAX_REQS_PER_IP_PER_MINUTE: number of requests per IP per minute (default is 200)

DISCOURSE_MAX_REQS_PER_IP_PER_10_SECONDS: number of requests per IP per 10 seconds (default is 50)

DISCOURSE_MAX_ASSET_REQS_PER_IP_PER_10_SECONDS: number of asset (avatars/css) requests per IP per 10 seconds (default is 200)

DISCOURSE_MAX_REQS_RATE_LIMIT_ON_PRIVATE: should the rate limit apply to private IPs accessing Discourse? default is false.

DISCOURSE_SKIP_PER_IP_RATE_LIMIT_TRUST_LEVEL: use per user rate limits vs IP rate limits for users with this trust level or more (default 1)

User API rate limits

The mobile applications acquire a user API key per device to access Discourse on behalf of a user (using an open protocol). These API keys are very tightly limited.

DISCOURSE_MAX_USER_API_REQS_PER_MINUTE: default 20
DISCOURSE_MAX_USER_API_REQS_PER_DAY: default 2880

Admin API rate limits

The administrative API keys can be generated via the yoursite.com/admin/api/keys page. These keys can operate on behalf of users, but require administrative privileges to generate. There is a limit of 60 requests per minute, shared between all keys.

Self-hosted users can change this in their app.yml file. Hosted customers will need to contact their hosting provider.

DISCOURSE_MAX_ADMIN_API_REQS_PER_MINUTE : 60

Data Explorer Plugin API rate limits

DISCOURSE_MAX_DATA_EXPLORER_API_REQ_MODE: default warn , this rate limit applies out of the box. (other options are block , warn+block , and none )

DISCOURSE_MAX_DATA_EXPLORER_API_REQS_PER_10_SECONDS: 2

Note: The requests made via the Data Explorer UI do not count towards the rate limit.

What should I do if I hit a rate limit and get throttled?

If you are consuming the API programmatically and receive back a 429 status code throttle reply you should respect it and slow down.

As an end user you should not really experience rate limits if you do, slow down. You could trigger it by opening 50 tabs real quick or doing something like that.

Firewall and proxy warning!

If you are running a reverse proxy which is mis-configured Discourse may think all the requests are coming from a single IP address, it is very likely you will hit rate limits early. Be sure to configure your reverse proxy to forward the IP correctly.

How do I amend these limits?

To amend the limits add the desired change into your app.yml file in the env section.

If you are hosted by Discourse, and on an Enterprise plan, contact team@discourse.org it you need to adjust any of these limits.

Global Rate Limits are not adjustable on starter, pro, or business plans.

Last edited by @MarkDoerr 2025-07-21T23:14:15Z

Last checked by @MarkDoerr 2025-07-21T23:14:23Z

Check document

Perform check on document:

[pfaffman (Jay Pfaffman)]

Il me semble que si vous avez le web.ratelimited.template.yml installé, alors ceux-ci n’ont pas d’importance puisque les choses sont limitées par NGINX avant d’atteindre Discourse, n’est-ce pas ?

C’est ce qu’il semble ressortir de mes journaux nginx.

Ma solution à court terme est d’ajouter mon adresse IP à la liste des IP locales, afin qu’elle passe NGINX. Je suppose que la chose à faire est de supprimer le modèle ratelimited pour que ceux-ci aient un sens ?

[guidoleenders]

Concernant le texte suivant :

Avertissement concernant le pare-feu et le proxy :warning :

Si vous utilisez un proxy inverse mal configuré, Discourse peut penser que toutes les requêtes proviennent d’une seule adresse IP, il est très probable que vous atteigniez rapidement les limites de débit. Assurez-vous de configurer votre proxy inverse pour qu’il transmette correctement l’IP.

Dans notre configuration, nous tunnelisons tous les appels API via un proxy. Ce proxy gère l’authentification et de nombreuses autres choses avant de parfois interroger Discourse.

Quelle est la méthode recommandée (en-tête spécifique ?) pour transmettre l’adresse IP du demandeur d’origine ?

Lié

Rate Limiting w/ Reverse Proxy

Had a question on what header is being used for rate-limiting. For context we have an nginx.conf w/ set_real_ip and we’re using a provider that sends us traffic with the client’s actual IP in Some-Client-IP header. sendfile on; set_real_ip_from ...; set_real_ip_from ...; set_real_ip_from ...; set_real_ip_from ...; real_ip_header Some-Client-IP; real_ip_recursive on; Some-Client-IP is what we get from upstream w/ the actual user’s IP. In the current discourse.conf in conf.d for nginx. We ha…

[Richie (Richie Rich)]

Quelqu’un pourrait-il m’aider à comprendre ce paramètre de configuration, s’il vous plaît ?

@Discourse

DISCOURSE_SKIP_PER_IP_RATE_LIMIT_TRUST_LEVEL : utilise les limites de débit par utilisateur plutôt que les limites de débit par adresse IP pour les utilisateurs ayant ce niveau de confiance ou plus (par défaut 1)

Ai-je raison de penser que ce paramètre est déjà défini sur 1 et que les limites de débit sont par défaut déjà définies par utilisateur plutôt que par adresse IP (si l’utilisateur est TL1 ou supérieur) ?

[Ethsim2 (Ethan)]

@j.jaffeux

où est le 429 ?

il n’existait en fait pas pour me faire spécifier un ou plusieurs de ces paramètres.

mon script respectait toujours l’en-tête Retry-After, comme nous pouvons le voir à partir de la ligne 101 d’origine ;

retry_after = r.headers.get("Retry-After")

cependant, cet en-tête devenait inutilement volumineux car je planifie différentes unités de service pour que ce même script s’exécute à différents moments de la journée.

Par conséquent, les multiples de certains de ces paramètres par défaut ont amélioré la délivrabilité des e-mails via mail-receiver, ce qui reste important.