gobuster concurrent request timeout: "Maximum number of concurrent requests" exceeded on authorized scope

TL;DR

You asked for more concurrency than the build allows or the target tolerates. Lower -t to a sane value (10 is a safe start), raise --timeout for slow responses, stay under the engagement's rate caps, and scale back up gradually only if the target handles it.

Maximum number of concurrent requests

Use this when

• Gobuster errors about maximum concurrent requests.
• The target is reachable (hand checks pass).
• The engagement has rate limits you must respect.

Not for this skill when

• Requests time out with low concurrency. That is a target or network problem.
• The target is down. Confirm with the client contact.
• You need maximum speed regardless of impact. You do not; respect the scope.

Steps

1. Drop concurrency: gobuster dir -u YOUR_TARGET_HOST -w wordlist -t 10. Verify: the error disappears.
2. Raise the timeout: --timeout 10s so slow responses are not counted as failures. Verify: timeout errors shrink.
3. Check the rules of engagement for rate caps and confirm your effective rate is under them. Verify: your rate is documented and compliant.
4. Scale up gradually (-t 20, -t 40) only if the target stays healthy. Verify: no new timeouts appear at each step.
5. Record the final -t and --timeout in your notes. Verify: the run is reproducible.

Variant phrasings

gobuster concurrent requests timeout

Compact phrasing.

gobuster -t too high error

Flag-oriented search.

gobuster max concurrent requests exceeded

Alternate wording.

Compatibility: gobuster v3.x. -t (threads) and --timeout are stable flags.

Why it happens

Each concurrent request holds a connection; too many at once exhausts the target's connection pool, your file descriptors, or trips rate limiting, and the slowest requests start timing out. Gobuster surfaces this as a concurrency error rather than letting the run degrade silently.

Edge cases / pitfalls

• The "right" concurrency depends on the target, not your box. A fragile app wants -t 5; a CDN-fronted one takes -t 100.
• Raising --timeout too far on a dead target makes a bad run take forever. Tune both together.
• Engagement rate caps override performance tuning. When in doubt, go slower and note why.
• Watch for WAF rate rules that kick in after N requests; the first 500 requests succeeding does not mean the next 5000 will.
• On a shared lab network, coordinate scan windows with other testers; two aggressive scans at once look like one broken target.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_3gc8Gx4958AAJ07DYqJ-Lg