## TL;DR
Ffuf aborts when too many requests fail: usually connection resets from an overloaded target or a WAF pushing back. Slow down with `-rate`, raise `-timeout`, confirm the target is healthy by hand, and get allowlisted if a WAF is resetting you.

```text
ERROR: too many errors
```

## Use this when
- Ffuf stops with `ERROR: too many errors` before finishing the wordlist.
- Manual requests to the target work fine.
- The engagement allows rate tuning.

## Not for this skill when
- The run completes but finds nothing. That is a filtering problem.
- The target is down for everyone. Confirm with the client contact.
- The engagement caps your request rate below what ffuf needs. Respect the cap.

## Steps
1. Hand-check the target: `curl -s -o /dev/null -w "%{http_code}" YOUR_TARGET_HOST/` several times. Verify: the app responds consistently.
2. Slow the run: `ffuf -u YOUR_TARGET_HOST/FUZZ -w wordlist -rate 50 -timeout 10 -t 10`. Verify: the error count drops.
3. Check for WAF resets: look for connection resets vs clean HTTP errors in `-v` output. Verify: you know whether it is resets (WAF/network) or HTTP errors (app).
4. If a WAF is resetting connections, ask the client to allowlist your egress IP. Verify: manual requests stop resetting.
5. Rerun at the sustainable rate and let it take longer. Verify: the run completes the wordlist.

## Variant phrasings
### ffuf too many errors abort
Compact phrasing.
### ffuf error rate threshold
The mechanism-oriented search.
### ffuf connection reset fuzzing
The network-flavored search.

Compatibility: ffuf v1/v2. `-rate`, `-timeout`, `-t` flags are stable across versions.

## Why it happens
Ffuf treats repeated request failures as a signal that something is deeply wrong (dead target, aggressive WAF, exhausted file descriptors) and aborts rather than burning the whole wordlist into errors. The threshold is doing its job; the fix is to remove the cause of the errors.

## Edge cases / pitfalls
- Raising the error threshold instead of fixing the rate just produces a longer, junkier run. Fix the rate.
- File descriptor exhaustion on the tester box looks like target errors. Check `ulimit -n` on long runs.
- A WAF that resets only fuzz-looking requests will pass your hand checks and fail the run. Compare `-v` output carefully.
- Document the sustainable rate in your notes; the client may ask why the scan took that long.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_1kUVXDd6fbPE3fWCMAwQ2g