429 请求过多

支持 安装
1

大家好，我知道之前有很多关于“请求过多”的帖子，但这个情况似乎不完全符合。

我在 Discourse 中遇到了间歇性的 429 错误（而且整体速度也相当慢），错误回溯如下：

Error: Too Many Requests
    at s (https://discourse.looker.com/assets/ember_jquery-d430881a3fb1403871256e5a02423c4b20a78793685e92088613ca9a701baf88.js:9:9188)
    at a (https://discourse.looker.com/assets/ember_jquery-d430881a3fb1403871256e5a02423c4b20a78793685e92088613ca9a701baf88.js:9:9045)
    at o (https://discourse.looker.com/assets/ember_jquery-d430881a3fb1403871256e5a02423c4b20a78793685e92088613ca9a701baf88.js:9:8936)
    at Object.trigger (https://discourse.looker.com/assets/ember_jquery-d430881a3fb1403871256e5a02423c4b20a78793685e92088613ca9a701baf88.js:18:7223)
    at https://discourse.looker.com/assets/ember_jquery-d430881a3fb1403871256e5a02423c4b20a78793685e92088613ca9a701baf88.js:18:9212
    at t.invoke (https://discourse.looker.com/assets/ember_jquery-d430881a3fb1403871256e5a02423c4b20a78793685e92088613ca9a701baf88.js:16:9729)
    at e.t.flush (https://discourse.looker.com/assets/ember_jquery-d430881a3fb1403871256e5a02423c4b20a78793685e92088613ca9a701baf88.js:16:8732)
    at e.t.flush (https://discourse.looker.com/assets/ember_jquery-d430881a3fb1403871256e5a02423c4b20a78793685e92088613ca9a701baf88.js:16:10782)
    at e.n._end (https://discourse.looker.com/assets/ember_jquery-d430881a3fb1403871256e5a02423c4b20a78793685e92088613ca9a701baf88.js:16:15440)
    at e.n.end (https://discourse.looker.com/assets/ember_jquery-d430881a3fb1403871256e5a02423c4b20a78793685e92088613ca9a701baf88.js:16:12110)

总是指向那个 .js 链接，这是一段非常庞大的 JS 代码，对我来说没什么实际意义。运行 Discourse 的实例似乎负载很低——CPU 使用率仅为 10%，其他一切看起来也都很正常，所以我有点困惑为什么会出现 429 错误。

是否有我可以调整的设置来更改全局速率限制？该实例能够处理的负载远大于 Discourse 似乎认为的，或者我是否忽略了由插件或 Bug 引起的更严重的问题。

谢谢！

2 个赞
2

Is your site behind a reverse proxy or anything else that would mess with real incoming IP addresses?

1 个赞
3

No, I don’t believe so (and the logs capture IP addresses normally) but it does sit behind an ELB. It definitely did correlate with a significant increase in traffic (looks kind of like a DDOS attack or something)
image

But if my understanding of rate limiting is correct, that shouldn’t have affected every user— Only the user trying to visit a million times, right?

I’ll verify re: the network architecture. Thanks!

4

I believe the nginx inside the Discourse container is using the ELB IP for the rate limiting bucket instead of the original client IP.

1 个赞
5

That sounds quite possible. Just verified that we do have an ELB setup in aws with nothing particularly special about it— Is is the result of something that I have misconfigured on my end?

Not 100% sure what next steps would be. If you point me in the right direction, I can probably work with my ops team to figure it out. Thanks much!

1 个赞