Rate limits are about where you are, not how fast
Content discovery, subdomain brute force and port scanning all fail the same way, and it is not speed. Here is what actually gets a large authorized scan finished, and the part of it we cannot do for you.
Contents
Every brute-force stage of recon has the same shape. Thousands of requests, nearly all of them wrong, walking a list. Content discovery does it with paths, subdomain enumeration with hostnames, port scanning with ports. Different engines, one behaviour.
They also die the same way, and the reason is usually misdiagnosed. You did not get blocked for being fast. You got blocked because one address was doing something that only a scanner does.
Authorized targets only. Everything below is about finishing a large scan you have permission to run. None of it is a way around a control on something you were not invited to touch.
Turning the speed down does not fix it
The standard advice is to drop the concurrency and be patient. It works in the narrow sense that a four-day scan does eventually finish. What it does not do is make the traffic look like anything other than what it is.
A single source walking a wordlist is recognisable at any speed. Slow it down enough and you have not escaped the problem, you have just agreed to be blocked more politely. The thing being detected is the source, not the rate.
So we stopped using one source
A workflow does not run as one long process on one box. It gets cut into small units of work that sit on a queue, and each of your machines pulls what it can handle. Five machines means the list gets walked five times faster, with no machine working harder than a single box would have.
The important word there is yours. The machines are ones you enrolled, on networks you chose, and the scan leaves from your address. That is not a detail. A hosted scanner that probes from its own address pool hands every customer the same reputation, and the first person to get that pool blocked breaks it for everyone else. We wrote about why we hold ourselves to that in whose IP address is your scanner using?
Pacing you do not sit and tune
There is no correct number of concurrent requests for every target, which is why hand-tuning is such miserable work. You guess, you watch, you get throttled, you guess again, and the number you land on is wrong for the next host.
The platform watches how the target is answering and adjusts as the run goes. Not magic, and not a promise that nothing will ever block you. It just means the failure mode is a scan that slows down for a while instead of a scan that quietly stops finding things.
A scan that has been blocked does not raise an error. It returns a clean result, and a clean result is what everybody was hoping for anyway. That is the actual danger, not the lost time.
Nothing gets walked twice
Long runs get interrupted. A cheap instance is reclaimed, a laptop lid closes, a target starts tarpitting. Every engine keeps its own state, so rerunning continues from where it stopped rather than starting the wordlist again.
Across several machines it is automatic. Work stays on the queue until whichever machine took it says it finished, so a box that dies mid-run has its share handed to a healthy one and nothing already done is repeated. The mechanics are in how scans survive a crashed node.
The part we cannot do for you
None of this rescues a bad wordlist, and a bad wordlist is the most common reason a run is enormous.
A list that fits the target finds more in a tenth of the requests. If passive enumeration already told you the organisation names things api-staging and jenkins-old, that is the pattern to feed the brute force, not a generic top-100k list you downloaded once. Keep the list you tuned and use it again next time. Fewer requests is the only approach that reduces load and improves results at the same time, and it is entirely on you.
Which engine does which part
Five engines ship, and they chain into one pipeline: voyage finds hostnames, pulse finds open ports and services, mach discovers content and crawls each web app, scout fingerprints the tech and versions, and cortex checks the result for actual vulnerabilities. Each one also runs standalone from a terminal with no account at all, because they are open source.
Flags, sources and tuning for each are in the engine reference, which is a better place for them than a blog post you would have to search for later.
Enrol a couple of machines and run something big enough that one box would have given up. Run something big