使用Cloudflare时,NGINX速率限制不起作用.我可以用一个简单的`ab`命令关闭我的网站 [英] NGINX rate limiting doesn't work when using Cloudflare. I can bring down my site with a simple `ab` command

查看:46
本文介绍了使用Cloudflare时,NGINX速率限制不起作用.我可以用一个简单的`ab`命令关闭我的网站的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我根据此博客文章实施了一个非常简单但非常有效的速率限制:https://www.nginx.com/blog/rate-limiting-nginx/

I implemented a pretty simple but super effective rate limiting based on this blog post: https://www.nginx.com/blog/rate-limiting-nginx/

基本上:

limit_req_zone $binary_remote_addr zone=ip:10m rate=10r/s;

limit_req zone=ip burst=20 nodelay;

效果很好.但是,最近我尝试了Cloudflare,这不再保护我了.我可以使用以下简单命令自己关闭该网站:

It works great. However, recently I tried Cloudflare, and this doesn't protect me anymore. I can bring down the site myself with a simple command of:

ab -k -c 1000 -n 10000 site.com/

发生了什么事?

推荐答案

ab -k -c 1000 -n 10000 site.com/并行运行1000个请求,直到总数达到10000请求总数已完成.

ab -k -c 1000 -n 10000 site.com/ is running 1000 requests in parallel, until a total of 10 000 requests total have been done.

那太残酷了.可能客户端和服务器都没有被调整为在几秒钟内处理成千上万的连接.

That's too brutal. It's likely that neither the client nor the server are tuned to handle thousands of connections over a few seconds.

调整nginx配置并进行轻微测试 ab -k -c 5 -n 500 site.com/

Adjust the nginx configuration and do a gentle test ab -k -c 5 -n 500 site.com/

limit_req_zone $http_cf_connecting_ip zone=ip:10m rate=3r/s;
limit_req zone=ip;

limit_conn_status 429;
limit_req_status 429;

429请求太多

这会将nginx配置为返回标准状态代码 429太多由于速率限制而被拒绝的请求.

429 Too Many Requests

This configures nginx to return the standard status code 429 Too Many Requests when requests are rejected due to rate limiting.

nginx返回 503 错误(错误的默认值),表示应用程序发生故障,但并非失败,它受到速率的限制.适当配置状态代码以区分服务器错误和速率限制很重要.

nginx returns a 503 error by default (a bad default) meaning the application is failing, but it is not failing it is rate limited. It's important to configure status code appropriately to distinguish between server errors and rate limiting.

在cloudflare之后,nginx将看不到客户端的IP,而是cloudflare服务器的IP.有人可能会认为它打破了IP的速率限制,但那一点也没有.

When behind cloudflare, nginx will not see the IP of the client but the IP of the cloudflare server. One might think that it breaks rate limiting by IP but it does not, well, just a bit.

使用ab 在本地进行测试时,您的测试计算机只能解析少数cloudflare服务器,并且 ab 可能仅使用第一个IP.因此,没有太多的客户端IP,速率限制应该可以正常工作.

When testing locally with ab, your test computer is only resolving a handful of cloudflare servers, and ab probably only uses the first IP. So no there aren't numerous clients IP, the rate limiting should work just fine.

生产中,将有不同的客户端通过不同的cloudflare服务器进行访问.尽管如此,在一个地理区域内并没有很多cloudflare服务器和客户端很可能会解析为相同的cloudflare服务器.因此,将会有很多不同的IP在某种程度上无法达到速率限制,但可能不是那么多.

When in production, there will be different clients accessing through different cloudflare servers. Still, there aren't that many cloudflare servers and clients in a geographic area will most likely resolve to the same cloudflare servers. So there will be a bunch of different IPs somewhat defeating the rate limiting, but probably not that many.

> nslookup mycloudflaresite.com

Name:    mycloudflaresite.com
Addresses:  104.28.14.125
            104.28.15.125
            2606:4700:3037::681c:e7d
            2606:4700:3036::681c:f7d

Cloudflare将原始客户端IP放在 CF-Connecting-IP 标头中.也可以在 X-Forwarded-For 中标头或 X-Real-Ip True-Client-IP ,具体取决于设置和请求.参见 https://support.cloudflare.com/hc/zh-CN/articles/200170986-How-does-Cloudflare-handle-HTTP-Request-headers-

Cloudflare puts the original client IP in the CF-Connecting-IP header. It can also be in the X-Forwarded-For header or X-Real-Ip or True-Client-IP depending on settings and requests. See https://support.cloudflare.com/hc/en-us/articles/200170986-How-does-Cloudflare-handle-HTTP-Request-headers-

因此,以上配置确实使用 CF-Connecting-IP 标头通过客户端IP进行速率限制.Nginx变量 $ binary_remote_addr 将是cloudflare服务器IP.

Hence the above configuration does rate limiting by client IP using the CF-Connecting-IP header. The nginx variable $binary_remote_addr would be the cloudflare server IP.

X-Forwarded-For 标头可以由客户端控制.不应使用它来进行速率限制,因为这很容易绕开.

The X-Forwarded-For header can be controlled by the client. It shouldn't be used for rate limiting because it is trivial to circumvent.

具有IP 100.11.22.33 的客户端的示例:

Example with a client having the IP 100.11.22.33:

  • 在没有 X-Forwarded-For 标头的请求=> Cloudflare设置 X-Forwarded-For:100.11.22.33 CF-Connecting-IP:100.11.22.33 上的请求.
  • 在已设置 X-Forwarded-For:dummyvalue 标头的请求中=> CloudFlare设置 X-Forwarded-For:dummyvalue,100.11.22.33 根据请求> CF-Connecting-IP:100.11.22.33 .
  • On a request without a X-Forwarded-For header => Cloudflare sets X-Forwarded-For: 100.11.22.33 and CF-Connecting-IP: 100.11.22.33 on the request.
  • On a request with a X-Forwarded-For: dummyvalue header already set => CloudFlare sets X-Forwarded-For: dummyvalue,100.11.22.33 and CF-Connecting-IP: 100.11.22.33 on the request.

如您所见,客户端为每个请求放置一个随机值,并完全绕过基于 X-Forwaded-For 标头的任何速率限制,这很简单.

As you can see, it's trivial for the client to put a random value per request and totally circumvent any rate limiting based on the X-Forwaded-For header.

这篇关于使用Cloudflare时,NGINX速率限制不起作用.我可以用一个简单的`ab`命令关闭我的网站的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆