← Dokumentace WAF / rate-limiting-rules

Řešení problémů s pravidly omezení frekvence požadavků

Cloudflare může podřízené požadavky (subrequests) Workers ve stejné zóně počítat jako samostatné požadavky, což způsobí, že se pravidlo omezení frekvence požadavků spustí dříve, než byste čekali. K tomuto chování dochází, když je pravidlo omezení frekvence požadavků nakonfigurováno s Použít omezování frekvence požadavků i na aktiva v mezipaměti nastavené na false.

Chcete-li tomuto chování předejít, musíte ve svém pravidle omezení frekvence požadavků vyloučit veškeré subrequesty Workers pocházející ze stejné zóny, a to pomocí cf.worker.upstream_zone pole. Můžete například přidat následující dílčí výraz do svého výraz pravidla omezení frekvence požadavků:

and (cf.worker.upstream_zone == "" or cf.worker.upstream_zone != "<YOUR_ZONE>")

První podmínka (test na prázdný řetězec) odpovídá přímým požadavkům návštěvníků, zatímco druhá podmínka odpovídá dílčím požadavkům, které nepocházejí z vaší zóny, čímž z pravidla omezení frekvence požadavků efektivně vylučuje dílčí požadavky ze stejné zóny.

Pokud používáte Origin Rules, abyste přepsali Host hlavičku a vaše pravidlo omezení frekvence požadavků obsahuje http.host ve svém výrazu nebo v charakteristikách pro počítání, pravidlo sice může příchozím požadavkům odpovídat, ale nemusí u nich dojít ke zvýšení čítače.

Děje se to proto, že výraz pravidla omezení frekvence požadavků se vyhodnocuje ve dvou fázích:

1. Fáze požadavku (shoda pravidla): Výraz se vyhodnocuje vůči původnímu požadavku, kde http.host obsahuje původní hostname. Pravidlo se shoduje podle očekávání.
2. Fáze odpovědi (přírůstek čítače): Pokud pravidlo používá výraz pro počítání nebo má Použít omezování frekvence požadavků i na aktiva v mezipaměti vypnuto, ke zvýšení čítače dochází až po odpovědi. V tu chvíli už Origin Rules přepsala Host hlavičku na novou hodnotu, takže výraz obsahující původní název hostitele již neodpovídá.

Výsledkem je, že pravidlo požadavkům odpovídá, ale nikdy nezvýší čítač, a limit frekvence požadavků se tak nikdy neuplatní.

Chcete-li to opravit, proveďte jedno z následujícího:

• Odebrat http.host podmínky z výrazu pro počítání a použijte jiná pole (například http.request.uri.path) k omezení rozsahu čítače.
• Aktualizujte výraz pro počítání tak, aby používal přepsaný hostname místo původního hostname.
• Do výrazu pro počítání přidejte původní i přepsané hostname pomocí or podmínka.

Pravidla Cloudflare pro omezení frekvence požadavků fungují v režim fail-open (propouštění požadavků namísto jejich blokování) při přetížení infrastruktury. Pokud podkladová infrastruktura zaznamená vysokou zátěž, Cloudflare může u dotčených požadavků přeskočit aktualizace čítačů rychlosti a vynucování omezení rychlosti, aby nedošlo k zablokování legitimního provozu.

Pro události fail-open neexistuje žádný signál viditelný pro zákazníka. Pokud pravidlo omezení frekvence požadavků neblokuje provoz, který by mělo zachytávat (jde o falešně negativní výsledek), a konfigurace pravidla je přitom v pořádku, příčinou může být zatížení infrastruktury v postiženém datacentru.

Počítání podle datacentra: Čítače omezení frekvence požadavků se udržují samostatně pro každé datacentrum Cloudflare. U provozu rozloženého mezi mnoho datacenter tak může frekvence v jednotlivých datacentrech zůstat pod prahovou hodnotou, i když celková frekvence tuto hodnotu překročí. Při nastavování prahových hodnot pro globálně rozložený provoz na to pamatujte.