Available settings for global rate limits and throttling

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! :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.

:discourse: 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 documentPerform check on document:
60 个赞

在我看来,如果你安装了 web.ratelimited.template.yml,那么这些就没有意义了,因为 NGINX 会在它们到达 Discourse 之前进行速率限制,对吗?

从我的 nginx 日志来看似乎是这样。

我的短期解决方案是将我的 IP 地址添加到本地 IP 列表中,这样它就可以绕过 NGINX。我想要做的事情是删除 ratelimited 模板,让这些设置有意义?

2 个赞

关于以下文本:

防火墙和代理警告! :warning:

如果您运行的反向代理配置不当,Discourse 可能会认为所有请求都来自单个 IP 地址,您很可能会很快达到速率限制。请务必配置您的反向代理以正确转发 IP。

在我们的设置中,我们通过代理隧道传输所有 API 调用。此代理在有时查询 Discourse 之前会处理身份验证和许多其他事务。

转发原始请求者 IP 地址的推荐方法(特定标头?)是什么?

相关

1 个赞

有人能帮我理解这个配置设置吗?

我的理解是,这个设置已经设置为 1,并且默认情况下速率限制是按用户而不是按 IP 地址设置的*(如果用户是 TL1 或更高)*?

1 个赞

它实际上并不存在,因此我不需要指定其中一个或多个设置。

我的脚本 始终遵守 Retry-After 标头,正如我们在原始第 101 行所见;

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

然而,由于我安排同一脚本在一天中不同时间运行不同的服务单元,因此此标头变得不必要地庞大。

因此,通过 mail-receiver 改进的默认电子邮件可传递性中的某些设置的倍数仍然很重要。