Port Scanner Online attempts a TCP connection to each requested port on the target IP or hostname, measures whether it's open, closed, or filtered, identifies the service likely running based on port number and banner-grab where available, and presents the results in a clear list. Supports single-port checks, common-port presets (web, mail, database, remote-admin), and custom ranges. Real connections, real-time results, no signup.
Six independent classes of output per port scan. The per-port open/closed status is the table-stakes output; the service identification, the banner grab, and the firewall behavior detection are the differentiators.
Attempts an actual TCP three-way handshake to each port. If the SYN-ACK returns, the port is open. If RST comes back, the port is closed (service not listening). If nothing returns within timeout, the port is filtered (firewall dropping packets).
Maps the port number to the IANA-registered service (port 80 → HTTP, 443 → HTTPS, 22 → SSH, 25 → SMTP, 3306 → MySQL, etc). For ports where the service responds on connection, captures the banner (e.g. `SSH-2.0-OpenSSH_8.9p1`) for finer-grained identification.
Pre-built scan lists for common scenarios. 'Web' scans 80, 443, 8080, 8443. 'Mail' scans 25, 110, 143, 465, 587, 993, 995. 'Database' scans 3306, 5432, 1433, 27017, 6379, 9200. 'Remote admin' scans 22, 23, 3389, 5900.
Scan a single port, a comma-separated list, or a range (`8000-8100`). Useful for verifying specific services or checking for unexpected listeners on non-standard ports.
Per-port response time. A 5ms response from an open port is normal; a 1000ms response signals network congestion, geographic distance, or a load-balanced backend. Filtered ports return the full timeout duration.
Distinguishes three outcomes: open (service is listening), closed (host responds with RST, no service), filtered (no response — firewall is silently dropping). The distinction matters: closed means the host is reachable but the port isn't used; filtered means a firewall is between you and the host.
Port scanning isn't just for security pentesters. Five places it's useful in everyday operations:
A port scan is a sequence of TCP connection attempts. The scanner sends a SYN packet to each target port and observes what comes back. Three possible outcomes; the tool surfaces all three with the right interpretation.
Knowing which port runs what service helps interpret a scan result. The most common public-facing ports:
Per-port status, service identification, banner, and response time are available as JSON. Useful for deployment verification, firewall-rule testing, attack-surface monitoring, and incident-investigation automation.
curl 'https://api.domainscan.in/v1/ip/port?host=scanme.nmap.org&ports=22,80,443'const res = await fetch(
'https://api.domainscan.in/v1/ip/port?host=example.com&ports=80,443,22'
);
const scan = await res.json();
console.log(scan.target); // 'example.com (93.184.216.34)'
console.log(scan.summary.openCount); // 2
console.log(scan.summary.filteredCount); // 1
scan.ports.forEach(p => {
console.log(`${p.port} (${p.service}): ${p.status} — ${p.banner || 'no banner'}`);
});
// Deployment-verification gate
const expected = new Set([80, 443]);
const openSet = new Set(scan.ports.filter(p => p.status === 'open').map(p => p.port));
const missing = [...expected].filter(p => !openSet.has(p));
if (missing.length) {
console.error('Expected ports not open:', missing);
process.exit(1);
}{
"target": "scanme.nmap.org",
"resolvedIp": "45.33.32.156",
"summary": {
"totalScanned": 3,
"openCount": 2,
"closedCount": 0,
"filteredCount": 1
},
"ports": [
{
"port": 22,
"status": "open | closed | filtered",
"service": "ssh",
"banner": "SSH-2.0-OpenSSH_8.9p1 Ubuntu-3ubuntu0.6",
"responseMs": 42
}
]
}Six patterns we see most often:
After deploying a service, verify it's actually reachable on the expected port. Faster than waiting for the first customer complaint to surface a misconfigured load-balancer rule.
Changed a security group or firewall policy. Scan to verify the rule does what you intended — open ports actually open, closed ports actually closed, internal-only ports actually filtered from outside.
Scan your own public IPs to know what's exposed. Most environments have at least one forgotten service running on a non-standard port. Common-ports preset plus targeted custom-port scans cover most realistic exposure.
Customer can't connect. Is the port open from outside? Filtered? Closed? A scan from a different network rules out client-side issues fast.
Before paying for a pen test, scan your hosts for unexpected open ports. Close the obvious findings yourself; let pen-testers spend their hours on application-layer issues.
Spinning up a new VPS or cloud instance. Scan the assigned IP before deploying to verify nothing unexpected is already listening (sometimes happens with cloud-provider default images or recycled IPs).