If you have Cloudflare Pro or higher plans, the Firewall analytics Analytics · Cloudflare Web Application Firewall (WAF) docs will show more details including CF DDOS/WAF mitigation triggers that are native to CF including DDOS managed rules Managed rulesets · Cloudflare DDoS Protection docs
i.e. HTTP DDOS Protection Managed Ruleset
- HTTP DDoS Attack Protection managed ruleset · Cloudflare DDoS Protection docs
- Configure HTTP DDoS Attack Protection in the dashboard · Cloudflare DDoS Protection docs
For my load testing I’ve sometimes tripped CF’s DDOS HTTP attack managed rulesets so had to disable them temporarily to see how much my CF setup can handle 
If you’re doing any type of CF testing, CF Pro or higher plan would be useful as the Web, Cache and Firewall analytics and info available is much better for troubleshooting.
But @cscharff is correct 524 is an entirely different matter origin side from CF 429 errors from edge. Once your origin stops responding to requests in a timely manner, CF edge trying to contact your origin will also throw a lot of errors.
I don’t use Jmeter myself so not sure if that is a factor. I’m currently using k6 benchmarking tool i.e. https://github.com/centminmod/k6-benchmarking/blob/master/bench-ramping-vus.sh-3.md
EDIT: also https://support.cloudflare.com/hc/en-us/articles/115001635128-Configuring-Cloudflare-Rate-Limiting
HTTP 429 includes 429 responses returned from the origin if the origin web server also applies its own rate limiting.
Maybe this applies to your situation as you mentioned you are also doing rate limiting on origin Nginx server side?