Run nmap server.example.com for a quick TCP check. For an inventory of every TCP port, use sudo nmap -sS -p- server.example.com; without raw-packet privileges, use nmap -sT -p- server.example.com. Add -Pn if discovery probes make the host appear down, scan UDP separately with sudo nmap -sU --top-ports 100 server.example.com, and use -sV on discovered ports when you need application and version details. Scan only systems and ranges you own or are explicitly authorized to assess.
Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.
Start with authorization and a defined target
Nmap sends network probes to the address you specify. Before running it, confirm that the hostname or IP belongs to your server or is inside a written assessment scope. A scan of a third-party host, a provider-wide address range, or an address you cannot administer can violate policy or law even when the command is technically simple.
As an Amazon Associate I earn from qualifying purchases.
Write down the exact target, protocol coverage, ports, and time window. A hostname can resolve to more than one address, and a server may be reachable through both IPv4 and IPv6. If the owner uses monitoring, rate limits, or an intrusion-prevention system, coordinate the scan so an expected assessment is not mistaken for an attack.
What you need
- Nmap installed on a machine that can route to the server.
- The server’s approved hostname or IP address.
- Permission to test the target and, where required, credentials or approval from the network owner.
- A plan for recording results, including the date, source machine, scan options, and target.
What an Nmap port scan actually measures
Nmap’s port table reports a port number, transport protocol, state, and a service name. Version information appears when you request version detection and the probes obtain a match. A service label is a hint from Nmap’s service database; it is not proof that the application really running on that port is the one named in the table.
#1 Best Overall
- Used Book in Good Condition
| State | Meaning | How to use it operationally |
|---|---|---|
| open | An application on the target is listening for connections or packets on that port. | Identify the listener, decide whether it is intended, and verify its access controls. “Open” alone does not mean the service is insecure. |
| closed | Nmap reached the port, but no application is listening at the time of the scan. | It may become open later if a service starts, so treat this as a point-in-time observation. |
| filtered | A firewall, packet filter, or another network obstacle prevented Nmap from deciding whether the port is open or closed. | Check filtering on the server, cloud security controls, and intervening networks before drawing conclusions. |
| unfiltered | Nmap received a response but could not determine whether the port is open or closed. | Use a scan method or follow-up test that can distinguish the two states. |
| open|filtered | The available responses do not distinguish an open port from a filtered one. | This is common with some UDP checks; follow up on ports that matter. |
| closed|filtered | Nmap cannot distinguish a closed port from a filtered one. | Review firewall behavior and repeat from an appropriate network location. |
“Open means that an application on the target machine is listening for connections/packets on that port.” — Nmap Reference Guide
Run the right scan for the question
1. Quick default TCP scan
nmap server.example.comThis is the useful first pass when you need a fast view of commonly used TCP services. It gives you a port state and, when available, a service name. It does not answer every question: a quick scan is not an inventory of every TCP port, does not include UDP, and does not reliably identify the exact application version.
2. Inventory every TCP port with a SYN scan
sudo nmap -sS -p- server.example.com-p- requests the full TCP port range instead of only the default common set. -sS uses a SYN scan and is the normal choice when the scanning account has the raw-packet privileges it needs. This combination is appropriate when the question is “which TCP ports are exposed at all?” rather than “are the three services I already expect reachable?”
A full range takes longer and produces more traffic than a small, explicitly selected list. Keep the target and timing within the approved scope, especially on production systems or links with monitoring and rate limits.
3. Use a TCP connect scan when raw privileges are unavailable
nmap -sT -p- server.example.com-sT performs the scan by making the operating system’s normal TCP connections. It is the practical fallback when you cannot run with the privileges required by -sS. The coverage remains all TCP ports because of -p-, but the connection behavior and resulting traffic differ from a SYN scan. Record which method you used so later scans are comparable.
4. Skip host discovery when the server appears down
sudo nmap -Pn -sS -p- server.example.comNmap normally performs host-discovery probes before scanning ports. Firewalls and other controls can block those probes even while the server accepts connections on a permitted port. -Pn tells Nmap to treat the target as available and proceed with the port scan. Use it only for an approved target: it removes a useful safety check and can make scans of unavailable addresses take longer.
Free tools Windows power users keep installed
One-click scans. No signup required.
5. Check common UDP ports
sudo nmap -sU --top-ports 100 server.example.comTCP and UDP are separate transport protocols. A TCP result does not tell you whether a UDP service is exposed, so run a UDP scan when the server’s role or policy requires it. The command checks the 100 most common UDP ports rather than every UDP port. UDP responses are often sparse, so a result of open|filtered means Nmap cannot tell whether a service is listening or a filter is suppressing the evidence.
UDP scans can take substantially longer than a focused TCP check. Start with the common set, then expand coverage or investigate specific ports that matter to the server’s function.
6. Identify the application and version
nmap -sV -p 22,80,443 server.example.comUse -sV after you know which ports deserve closer examination. Nmap sends service-specific probes to open or open|filtered ports and compares the responses with its identification data. This provides more evidence than inferring an application from a port number alone. A web service can run on a nonstandard port, and an SSH-like service name in the table is not conclusive until version detection obtains a response.
Limit -sV to the relevant ports when you want a focused follow-up. Include the ports you discovered in the first pass, such as 22, 80, and 443, rather than rescanning an unnecessarily broad range.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Choose coverage deliberately
| Goal | Command | Coverage and trade-off |
|---|---|---|
| Fast check of common TCP services | nmap server.example.com |
Quick starting point; not every TCP port and no UDP inventory. |
| All TCP ports with raw-packet access | sudo nmap -sS -p- server.example.com |
Complete TCP-port range; requires suitable privileges and creates more traffic. |
| All TCP ports without raw privileges | nmap -sT -p- server.example.com |
Complete TCP-port range using ordinary connects; behavior differs from SYN scanning. |
| Known services only | nmap -p 22,80,443 server.example.com |
Efficient when the question concerns specific ports; it cannot reveal an unexpected service elsewhere. |
| Host discovery is blocked | sudo nmap -Pn -sS -p- server.example.com |
Skips the up/down check and proceeds; use only on an authorized address. |
| Common UDP exposure | sudo nmap -sU --top-ports 100 server.example.com |
Checks common UDP ports; slower and more likely to report open|filtered. |
| Application and version evidence | nmap -sV -p 22,80,443 server.example.com |
Probes selected ports for service details; more intrusive than a state-only check. |
Read the output without over-interpreting it
Separate port state from service identification
For each row, first note the numeric port and protocol, then the state, and only then the service and version columns. The state answers whether Nmap could establish a listening or filtering condition. The service field is a classification aid. Treat a version string as useful evidence from a probe, not as a guarantee that every process behind a load balancer, proxy, or container has been identified.
Check TCP and UDP independently
Port numbers are reused across protocols. “53/tcp” and “53/udp” are different endpoints, and finding one does not establish the state of the other. Keep protocol in your notes and in exported reports so an apparent discrepancy is not a bookkeeping error.
Use network location as context
A scan from inside the server’s private network can see a different firewall path from a scan made across the public internet. If your security question is about internet exposure, run the authorized scan from a location that actually represents that exposure, and document the source location. A filtered result can describe the path between scanner and server rather than the server’s local listener alone.
Save evidence for review and comparison
Terminal output is convenient for a one-off check, but saved files let you review results, share them with another operator, and compare later scans.
nmap -oN report.txt server.example.com
nmap -oX report.xml server.example.com
nmap -oG report.gnmap server.example.comNormal output: -oN
-oN writes the human-readable report to report.txt. It is suitable for an operator’s notes and preserves the same table and summary you would see in the terminal.
XML output: -oX
-oX writes structured XML to report.xml. Use it when another tool or an internal process needs to parse scan details rather than screen-scrape formatted text.
Grepable output: -oG
-oG writes a line-oriented format to report.gnmap. It records port, state, protocol, service, and version-related fields when version detection was requested and succeeded. Keep the command line and scan date alongside the file; a report without its scope and options is difficult to interpret months later.
A repeatable server-audit workflow
- Confirm scope. Verify the hostname or IP, authorization, source network, and approved time window.
- Run a quick TCP pass. Use the default scan to establish whether the target responds and to identify immediately visible common services.
- Expand TCP coverage. Run
-p-with-sSwhen raw privileges are available, or-sTotherwise. - Handle discovery failures. If a permitted server is reported as down because probes are blocked, repeat with
-Pn. - Assess UDP where relevant. Start with
-sU --top-ports 100, then investigate important results rather than assuming an unanswered UDP probe is closed. - Identify selected services. Apply
-sVto the ports that require application or version evidence. - Save the result. Choose normal, XML, or grepable output and retain the exact command.
- Validate every unexpected opening. Check the server’s service manager, listener configuration, host firewall, and upstream filtering to determine whether the exposure is intentional.
- Record remediation. For an unwanted listener, disable or reconfigure the service and adjust filtering according to the owner’s change process, then rescan from the same relevant network position.
Troubleshoot common results and failures
Nmap says the host is down
First confirm DNS resolution, routing, and that the target is powered on. If the server is known to be available but discovery probes are blocked, use -Pn for the authorized follow-up. Do not treat the absence of a discovery response as proof that every port is closed.
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →The scan reports “permission denied” or cannot use the intended method
Run the SYN command with the privileges approved for your system, or switch to -sT when elevated access is unavailable. Keep the method in the report because a later comparison should distinguish a SYN scan from a connect scan.
Everything is filtered
Filtering means Nmap could not decide, not that no service exists. Check host-based firewalls, cloud or perimeter rules, security groups, routing, and the scanner’s network location. A scan from an allowed management network may produce different evidence from one made externally.
UDP results remain open|filtered
That state is an explicit uncertainty. Follow up on business-critical UDP ports, use version detection where it is appropriate, and consult the service owner or firewall logs. Do not convert open|filtered into either “open” or “closed” in a report.
The scan is taking too long
Reduce scope first: scan known ports instead of -p-, use the common UDP set rather than every UDP port, and apply version detection only after you have selected ports. Avoid treating a faster scan as automatically better; the narrower result may not answer an inventory question.
Turn an open-port list into a security decision
An open port is an exposure to investigate, not a vulnerability verdict. For each open result, identify the owning application, whether the listener should be reachable from the scanner’s network, and which authentication and access controls protect it. Compare the observed list with the server’s intended role and approved change records.
- Unexpected service: determine which process owns the listener and remove or restrict it through the normal administration process.
- Expected service with excessive reachability: keep the service if needed, but review host and upstream filtering so only intended networks can connect.
- Version information that needs action: verify the identified application and version with the system owner before scheduling an update; Nmap’s identification is evidence, not a substitute for local inventory.
- Closed or filtered result where access is required: confirm that the test originated from the correct network and that the firewall path permits the intended clients.
After a change, repeat the same scan type, port scope, protocol coverage, and source location. Matching methodology makes the before-and-after comparison meaningful.
Quick Recap
Key points to retain
- Use the default command for a quick common-TCP check,
-p-for every TCP port, and-sUwhen UDP is in scope. - Choose
-sSwith the required raw-packet privileges or-sTwhen you must use ordinary TCP connects. - Use
-Pnwhen discovery probes are blocked but the target is authorized and known to be reachable. - Add
-sVwhen a port number and service label are not enough to identify the application. - Interpret
filteredandopen|filteredas limits on the available evidence, not as synonyms for closed. - Save reports with
-oN,-oX, or-oGand preserve the command, scope, date, and source location.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
