How to Use Naabu: The Beginner's Guide (First Install, First Scan, the SYN-vs-Connect Lesson, and the Rate-Limit Rule)
CodexFuse Team · 2026-11-06T21:48:29.116Z · 20 min read min read
What Is Naabu, and What Does It Actually Do?
Learning how to use naabu means learning to run one fast Go binary that lists the open ports on a host, then hand those results to the next tool in your recon pipeline. Naabu is ProjectDiscovery's open-source port scanner, written in Go, and it answers a single question quickly: which ports on this host reply. It does not fingerprint services by default, it does not exploit anything, and it does not replace a full vulnerability scan.
The naabu port scanner was built to sit inside a pipeline, so its output feeds httpx for live-host probing and nuclei for vulnerability checks. Naabu scans from a port list instead of guessing, so a default run checks nmap's top 100 ports and a full run checks all 65,535. That pipeline habit is the whole point, and it is why bug-bounty hunters and recon teams reach for naabu before heavier tools.
If you already read the OSV-Scanner beginner guide, you know the other half of the job: OSV-Scanner checks known software for known vulnerabilities, while naabu discovers which ports are open in the first place. Discovery comes first, and vulnerability checks come second, so this guide opens the port-scan lane of the same security cluster. The two tools answer different questions, and neither one replaces the other.
The project is small and actively kept: the repository holds 6,351 stars and 737 forks, with 1 open issue, and the last code push landed 1 day ago. It began on 2020-01-21, which makes the repository 2,482 days old, or 6.8 years, and it still gains about 2.56 stars a day. The current release is v2.7.0, published 10 days ago, and the vendor docs were updated 4 days ago, so this guide is pinned to a moving target that is still moving.
The fork ratio works out to 11.6 percent, or 8.62 stars per fork, and the single open issue is 0.02 open issues per 100 stars.
from datetime import date
today = date(2026, 11, 7)
created = date(2020, 1, 21)
v270 = date(2026, 10, 28)
v261 = date(2026, 5, 5)
v260 = date(2026, 4, 23)
pushed = date(2026, 11, 6)
docs = date(2026, 11, 3)
kali = date(2026, 5, 25)
gfg = date(2024, 9, 10)
stars, forks, issues = 6351, 737, 1
repo_days = (today - created).days
v270_days = (today - v270).days
gap_261_270 = (v270 - v261).days
gap_260_261 = (v261 - v260).days
pushed_days = (today - pushed).days
docs_days = (today - docs).days
kali_days = (today - kali).days
gfg_days = (today - gfg).days
stars_per_fork = round(stars / forks, 2)
fork_ratio = round(forks / stars * 100, 2)
issues_per_100 = round(issues / stars * 100, 2)
stars_per_day = round(stars / repo_days, 2)
full_vs_top100 = round(65535 / 100, 2)
full_scan_seconds = round(65535 / 1000, 1)
top1000_seconds = round(1000 / 1000, 1)
top100_seconds = round(100 / 1000, 1)
years = round(repo_days / 365.25, 2)
print("repo_days", repo_days)
print("repo_years", years)
print("v270_days", v270_days)
print("gap_261_270", gap_261_270)
print("gap_260_261", gap_260_261)
print("pushed_days", pushed_days)
print("docs_days", docs_days)
print("kali_days", kali_days)
print("gfg_days", gfg_days)
print("stars_per_fork", stars_per_fork)
print("fork_ratio", fork_ratio)
print("issues_per_100", issues_per_100)
print("stars_per_day", stars_per_day)
print("full_vs_top100", full_vs_top100)
print("full_scan_seconds", full_scan_seconds)
print("top1000_seconds", top1000_seconds)
print("top100_seconds", top100_seconds)
print(f"# Output: {repo_days} {years} {v270_days} {gap_261_270} {gap_260_261} {pushed_days} {docs_days} {kali_days} {gfg_days} {stars_per_fork} {fork_ratio} {issues_per_100} {stars_per_day} {full_vs_top100} {full_scan_seconds}")
# Output: 2482 6.8 10 176 12 1 4 166 788 8.62 11.6 0.02 2.56 655.35 65.5
What Do You Need Before You Install Naabu?
Naabu needs two things before the install command can run: a Go toolchain for the go install route, and the libpcap packet-capture library for every route. The README states the libpcap requirement plainly, and the vendor install page repeats it, so treat it as a prerequisite rather than an optional extra. On Windows the same job is done by Npcap, which you install from npcap.com.
| Requirement | What it does | Install command |
|---|---|---|
| Go toolchain | Required only for the go install route | Latest version, per the vendor install page |
| libpcap | Packet capture for SYN scans | Linux: sudo apt install -y libpcap-dev |
| Root or elevated privileges | Unlocks SYN scans; without it naabu falls back to CONNECT | Run with sudo, or accept CONNECT scans |
| Nmap (optional) | Supplies the service-probe database for the new -sV flag | Only needed if you want version fingerprinting |
| A target you own | The only lawful scan target | Your own server, lab host, or authorized scope |
sudo apt install -y libpcap-dev apk add libpcap brew install libpcap
Root access deserves its own line, because it changes how naabu scans rather than whether it scans. With root privileges naabu sends raw SYN packets, and without them it falls back to full CONNECT scans, so a beginner on a shared machine can still learn the tool. The capability name CAP_NET_RAW is not named in the README or the vendor docs, so this guide says root or elevated privileges and nothing more specific.
How Do You Install Naabu?
This naabu tutorial installs the current release, v2.7.0, and nothing older, because the new service-fingerprinting flag only exists in that release. The naabu install takes a minute once Go and libpcap are ready, and the binary lands in your Go bin directory. Pick one route below, run it, and confirm the install with the version flag before you scan anything.
- Install libpcap for your system, using the commands in the previous section.
- Install the latest Go toolchain if you plan to use the go install route.
- Run the go install command below, or download the v2.7.0 binary for your system.
- Add the Go bin directory to your PATH if the shell cannot find naabu.
- Run naabu -version and confirm it reports v2.7.0.
- Run naabu -h once and read the flag list for your own system.
- Run your first scan on a host you own, using the next section.
go install -v github.com/projectdiscovery/naabu/v2/cmd/naabu@latest
naabu -version naabu -up
| Route | Command | Best for |
|---|---|---|
| Go install | go install -v github.com/projectdiscovery/naabu/v2/cmd/naabu@latest | Developers who already use Go |
| Binary release | Download v2.7.0 from the GitHub releases page | Any system, no Go needed |
| Homebrew | brew install naabu | Mac and Linux Homebrew users |
| Docker | projectdiscovery/naabu image, tag v2.7.0 | Isolated runs and CI jobs |
| Kali Linux | sudo apt install naabu | Kali users who want the packaged build |
Two honest notes belong here. Homebrew and Docker routes are not on the vendor install page, and both were verified separately this run through the Homebrew formula API and the Docker Hub tags API. The Docker image and the Homebrew formula both report stable version 2.7.0, so the routes are current even though the vendor page does not list them.
If Docker is your route, the Docker beginner guide on this site walks through containers from zero, and the same container habits apply here. The Kali package is the oldest route on this page, with its tools page updated 166 days ago, so check its version before you trust it. The binary route is the simplest choice when you want exactly v2.7.0 and nothing else.
How Do You Run Your First Scan?
A first scan needs one flag and one host you own, and naabu fills in the rest with its defaults. The command below scans the top 100 ports on the example host, which is the default port list when you give no -p flag. Read the output, note which ports reply, and only then start changing flags.
naabu -host hackerone.com [INF] Running SYN scan with root privileges [INF] Found 4 ports on host hackerone.com (104.16.100.52) hackerone.com:80 hackerone.com:443 hackerone.com:8443 hackerone.com:8080
The sample above is the README's own first run, and it shows the shape of every naabu result: one line per open port, host and port together, nothing else. A host with no open ports in the scanned list prints nothing for that host, which is a result in itself. Save results with -o when you want them, because the terminal output scrolls away fast on bigger scans.
| Flag | What it scans | When to use it |
|---|---|---|
| (none) | nmap top 100 ports | First scan, quick check |
| -p 80,443 | Only the listed ports | Checking known services |
| -p 80,443,21-23 | Listed ports and ranges | A mixed known-port check |
| -top-ports 1000 | nmap top 1000 ports | A wider first pass |
| -p - | All ports, 1 to 65,535 | A full sweep before deeper tools |
| -p - -exclude-ports 80,443 | All ports except the listed ones | Skipping ports you already know |
naabu -p 80,443,21-23,u:53 -host hackerone.com naabu -p - -exclude-ports 80,443 naabu -top-ports 1000 -host hackerone.com
The full range is 655.35 times the size of the default top-100 list, so a full sweep is a different job from a first scan. At the default rate of 1000 packets per second, sending 65,535 packets takes about 65.5 seconds of pure sending time, before replies and retries. Start narrow, learn the output shape, and widen the port list only when you have a reason.
What Do the Results Mean?
Naabu reports ports that reply, and silence is the rest of the story. An open port means a service answered the probe, a closed port means the host actively refused it, and a filtered port means no answer came back at all. Most beginners only need the open list, because the next tools in the pipeline work from open ports alone.
Read the host line first, then the port list, and treat the count as your attack-surface sketch. Four open ports on a web host usually means a web server, a secure web server, and two extra services worth a look. One open port on a database host means something else entirely, and that difference is the judgment naabu cannot make for you.
Verification is built in, and the -verify flag re-checks found ports with a TCP connection before it reports them. The -retries flag defaults to 3 attempts, and the -timeout flag defaults to 1 second per probe, so a slow host gets a fair chance before naabu moves on. These defaults keep naabu's results steady rather than jumpy, even on noisy networks.
The SYN-vs-CONNECT Lesson
A naabu syn scan needs root privileges, because sending raw SYN packets means crafting packets by hand instead of asking the operating system to open a connection. Without root, naabu falls back to CONNECT scans, which complete the full TCP handshake through the normal socket path. Both modes find open ports, and the difference is speed, stealth, and privilege, not correctness.
| SYN scan | CONNECT scan | |
|---|---|---|
| How it works | Sends a SYN packet and reads the reply | Completes the full TCP handshake |
| Privilege needed | Root or elevated privileges | None, works as a normal user |
| Speed | Usually faster, fewer packets per port | Slower, a full handshake per port |
| What the target sees | A half-open connection attempt | A complete connection in its logs |
| When to use it | Your own lab, your own servers, authorized tests | Shared machines, quick checks, no root |
The surprise is that SYN is not always faster in practice. Dana Epp ran 100 scan tests against an API server and found every single one took longer with a SYN scan through naabu, because tearing down half-open sockets costs more time than the saved packets are worth. That result is one author's anecdote from a single methodology post, not a measured benchmark, and it is worth knowing before you assume SYN always wins.
Do not assume a single fixed default for the scan type, because the current README help lists the default as CONNECT while the 2024 guide described SYN as the default. What the current README sample outputs do show is consistent: SYN with root privileges, CONNECT without them. Run naabu as root when you want SYN, run it as a normal user when CONNECT is enough, and check the banner line, which names the scan type on every run.
How Do You Control Scan Speed and Stay Polite?
Naabu defaults to 1000 packets per second with 25 worker threads, and those defaults are tuned for a virtual private server rather than a home connection. The README says so directly, and it recommends keeping the rate reasonable because a higher rate raises false positives. Your first scan should use the defaults, and you should only raise the rate when you understand what the target can absorb.
naabu -host scanme.example -rate 500 -c 25 -retries 3 naabu -host scanme.example -p - -exclude-ports 80,443 -rate 1000
Exclusions keep a scan polite: -exclude-hosts skips hosts, -exclude-ports skips ports, and -exclude-cdn limits CDN and WAF addresses to ports 80 and 443. The -warm-up-time flag defaults to 2 seconds between scan phases, which gives the network a breath before the next wave. These knobs are the difference between a careful recon pass and a noisy blast, and careful is the only kind that belongs in a beginner guide.
The VPS hosting guide on this site explains the server setup naabu assumes, and a small virtual server is the usual home for scheduled recon work. Only scan systems you own or have written permission to test, because a port scan against someone else's system is unauthorized access in most places, not a harmless probe. CodexFuse offers no Naabu tool, so this guide teaches the open-source binary and nothing else.
What Output Formats Does Naabu Support?
Naabu prints results to the terminal by default, and every other format is one flag away. JSON lines suit scripts, CSV suits spreadsheets, and the nmap-compatible XML and greppable formats suit tools that already speak nmap. Pick the format your next tool wants, not the one that looks nicest on screen.
| Flag | Format | Best for |
|---|---|---|
| (none) | Plain text, one host:port per line | Reading results yourself |
| -o results.txt | Plain text saved to a file | Keeping a record of the scan |
| -json | JSON lines, one object per port | Scripts and pipelines |
| -csv | Comma-separated values | Spreadsheets and reports |
| -oX results.xml | Nmap-compatible XML | Tools that parse nmap XML |
| -oG results.gnmap | Nmap-compatible greppable text | Grep workflows |
| -oA results | JSON, XML, and greppable together | Keeping every format at once |
naabu -host hackerone.com -json
{"ip":"104.16.99.52","port":443}
The JSON form carries more than an address and a port when version detection runs, adding service name, product, version, banner, and CPE fields to each line. A live metrics page also runs on localhost port 63636 while naabu scans, and the -metrics-port flag moves it when that port is busy. Save output from the start, because re-scanning a target just to recover lost results wastes the target's time and yours.
How Do You Pipe Naabu Into httpx and Nmap?
Naabu is a discoverer, not a finisher, and its real power shows when its output becomes another tool's input. The ProjectDiscovery pipeline runs subfinder for subdomains, httpx for live hosts, naabu for open ports, and nuclei for vulnerability checks, with each tool handing results to the next. Learn this pipeline once, and every recon job after it follows the same shape.
echo hackerone.com | naabu -silent | httpx -silent naabu -p - -rate 2000 -c 50 -retries 2 -warm-up-time 1 -silent -host crapi.apisec.ai -nmap-cli 'nmap -sV -oX scan.xml'
The subdomain finder guide on this site covers the first step of that pipeline, finding subdomains before any port is scanned. The Nuclei beginner guide covers the last step, turning open ports and live hosts into checked findings. Naabu sits between those two steps, and a scan that skips the subdomain step is guessing at targets instead of enumerating them.
The -nmap-cli flag runs nmap on the ports naabu finds, which keeps nmap for the deep work it does best: service versions, script checks, and fingerprinting. The bare -nmap flag is deprecated, so use -nmap-cli with an explicit command and keep nmap installed for it to call. A full 65,535-port naabu pass followed by a targeted nmap pass is the workflow Dana Epp settled on, and it is the workflow this guide recommends.
What Is New in Naabu v2.7.0?
Version 2.7.0 arrived on 2026-10-28, which makes it 10 days old as of November 2026, and it is the release this guide is pinned to. The gap from v2.6.1 was 176 days, while v2.6.0 to v2.6.1 took only 12 days, so the project ships in bursts rather than on a schedule. The last code push landed 1 day ago, so the repository is active well beyond the release itself.
The headline addition is native service fingerprinting with the -sV flag, which names the service and version on an open port without a separate nmap run. The probe database behind -sV comes from a local nmap install, because naabu does not ship the nmap-service-probes file for license reasons, and the -sV-probes flag points at a custom copy. The -sD flag is the lighter sibling, naming services by port number alone with no probing at all.
UDP scans gain opt-in protocol probes with the -uP flag, sending a DNS query to port 53, an NTP request to port 123, and an SNMP request to port 161. Without -uP, UDP scans send zero-length datagrams, and a user-supplied connect payload always wins over the automatic probe for that port. Dead-host reporting, faster scanning, musl archives for Alpine, and a Go toolchain fix for CVE-2026-111943 round out a release with fixes that favor accuracy as much as speed.
The naabu projectdiscovery repository lists the full v2.7.0 changelog, including the Windows SYN fix and the scan-resource-leak fixes. The README banner samples still show old versions, so trust the flag list and the release notes rather than the banner screenshots.
Naabu vs Nmap: Which Tool Does What?
Naabu vs nmap is the wrong contest, because the two tools do different jobs and the best recon runs use both. Naabu finds open ports fast across many hosts, and nmap digs into the ports naabu found with service detection, scripting, and fingerprinting. The question is not which tool wins, but which tool runs first.
| Naabu | Nmap | |
|---|---|---|
| Main job | Fast port discovery across hosts | Deep service and version analysis |
| Input style | Host lists, CIDRs, ASNs, stdin | Single hosts, ranges, scripts |
| Scan engine | SYN, CONNECT, and UDP port probes | SYN, CONNECT, UDP, scripts, OS detection |
| Service versions | New in v2.7.0 with -sV | Mature -sV with the NSE script engine |
| Output habit | Pipes into httpx and nuclei | Detailed reports and XML output |
| Best moment | First pass, finding the surface | Second pass, understanding the surface |
Dana Epp's 2024 methodology post is the clearest field report, and it says naabu cut his port-scan time by more than half before nmap took over for service discovery. The Undercode Testing trifecta piece from about February 2026 frames the same split three ways: nmap as the depth king, RustScan as the speed demon, and naabu as the simplified discoverer. Both sources agree on the shape, and neither one treats the tools as rivals.
RustScan earns one mention here as the raw-speed option, and it is the right call when a permissive environment rewards pure speed above all else. Naabu earns its place through integration, because its output feeds the ProjectDiscovery pipeline without conversion work. Nmap stays for the heavy detection logic once a port is discovered, and that division of labor is the whole lesson.
What Are the Seven Mistakes Beginners Make?
| Mistake | What to do instead |
|---|---|
| Scanning a target you do not own | Confirm ownership or written authorization before the first packet |
| Running a full 65,535-port scan as a first scan | Start with the top 100 ports and widen only when the question needs it |
| Forgetting libpcap before the install | Install libpcap first and read the error as a missing prerequisite |
| Assuming SYN works without root | Check the banner line, which names the scan type on every run |
| Raising the rate to finish faster | Keep the default 1000 packets per second until you have a reason and permission to change it |
| Scanning without saving output | Pass -o or -json from the start and keep every result file |
| Copying flags from stale guides | Check every flag against the current README help list before you trust a tutorial, including this one |
Sources
The repository facts in this guide come from the GitHub API record for projectdiscovery/naabu and its releases API, both fetched on 2026-11-07, plus the raw README from the master branch and the ProjectDiscovery docs pages for install, running, and overview, with the running and overview pages updated on 2026-11-03. The Homebrew formula API and the Docker Hub tags API confirmed the brew and Docker routes at stable version 2.7.0, and the Kali Linux tools page, updated on 2026-05-25, confirmed the packaged route. The Linux Command Library man page and the pkg.go.dev module pages supplied the command reference, while the GitHubHelp README mirror supplied the current flag list.
The comparison material comes from Dana Epp's March 2024 Security Boulevard post on improving port scans against API servers, read through search excerpts because the page itself returned HTTP 403 this run, and from the Undercode Testing trifecta piece on combining nmap, naabu, and RustScan, dated to about February 2026 by search metadata. The pipeline framing comes from ProjectDiscovery's own recon blog on finding a first subdomain takeover, published in February 2023, and from the company's March 2026 press material describing subfinder, httpx, and naabu as its recon core. The GeeksforGeeks Windows install guide, last updated on 2024-09-10 and 788 days old, is cited only as evidence that no current Windows walkthrough exists.
Every number in this guide was computed from the fetched API values with a Python script run this run, including the 2,482-day repository age, the 8.62 stars per fork, the 11.6 percent fork ratio, the 0.02 open issues per 100 stars, the 2.56 stars per day, and the 65.5-second full-range sending time. No testbed outputs were executed for this guide, and no scan was run against any live target while writing it. Search volume is unknown, and star and fork counts are a 2026-11-07 snapshot that will drift.
Frequently Asked Questions
Do I need to install Go before I install Naabu?
Only the go install route needs Go, and the binary, Homebrew, Docker, and Kali routes install naabu without it. Every route still needs libpcap for packet capture, so install that library first whatever route you pick. The version flag confirms the install, and it should report v2.7.0.
Why does Naabu run a SYN scan on one machine and a CONNECT scan on another?
The scan type follows privilege: root runs SYN scans, and a normal user runs CONNECT scans, because raw packet crafting needs elevated privileges. The banner line on every run names the scan type, so read it instead of guessing. The -s flag sets the type explicitly, with s for SYN and c for CONNECT.
Which ports does Naabu scan if I do not specify any?
Naabu scans nmap's top 100 ports by default, which covers the most common services in a single quick pass. The -top-ports 1000 flag widens that to the top 1000, and -p - scans the full range of 1 to 65,535. Start with the default and widen only when the question needs it.
How do I send Naabu results into httpx or Nmap?
Pipe naabu's standard output into httpx with a single pipeline, and httpx will probe only the ports naabu found. Nmap takes over through the -nmap-cli flag, which runs a nmap command on the discovered ports after naabu finishes. The README's own example pipes naabu into httpx, and Dana Epp's workflow adds nmap service discovery as the second pass.
Is Naabu free to use?
Naabu is free and open source under the MIT license, and the binary, the source, and the docs cost nothing. The project is maintained by ProjectDiscovery, and its releases, issues, and changelog are public on GitHub. Free does not mean consequence-free, so scan only systems you own or have written permission to test.
