Port Scanner — Detect Open TCP Services on Any Domain
Scans 18 common TCP ports against any domain or IP and identifies which services are exposed — SSH, HTTP, HTTPS, RDP, MySQL, MongoDB, and more. Server-side TCP connect scan, results in under 5 seconds.
The Port Scanner runs a TCP connect scan against 18 of the most common ports on any domain or IPv4 address: 21 (FTP), 22 (SSH), 23 (Telnet), 25 (SMTP), 53 (DNS), 80 (HTTP), 110 (POP3), 143 (IMAP), 443 (HTTPS), 445 (SMB), 993 (IMAPS), 995 (POP3S), 3306 (MySQL), 3389 (RDP), 5432 (PostgreSQL), 8080 (HTTP-Alt), 8443 (HTTPS-Alt), and 27017 (MongoDB). For each port the tool attempts a TCP connection with a 2-second timeout and reports OPEN if the handshake succeeds.
What is different about this tool: it scans server-side from our infrastructure, not from your browser. Browser-based port scanners are technically impossible (the browser sandbox prohibits raw TCP sockets), so any free "port scanner" you find online is doing the scan from somewhere else. This means the target sees scans coming from our hosting provider's IP, not yours — useful for privacy but means you can't scan internal/private networks, and the target's firewall sees a SecurityElites-attributable connection. Use it for public-internet auditing of services you own or are authorised to scan.
How it works under the hood
When you submit a target, the tool extracts the registrable hostname or accepts a raw IP, then resolves the hostname to an IP via gethostbyname() if needed. For each of the 18 ports in the scan list, it calls PHP's fsockopen() with a 2-second timeout. If the TCP handshake completes, the port is reported OPEN; if it times out or returns an error, the port is reported as closed/filtered.
The 18-port shortlist. The list covers the services that matter most for security analysis without scanning the full 65,535-port range (which would take much longer and almost always returns the same answers). Web (80, 443, 8080, 8443), mail (25, 110, 143, 993, 995), remote access (22 SSH, 23 Telnet, 3389 RDP), file sharing (21 FTP, 445 SMB), databases (3306 MySQL, 5432 PostgreSQL, 27017 MongoDB), and DNS (53). If you find unexpected exposed services on this list, you have a finding worth investigating; if you need a full-range scan, use Nmap from a machine you control.
TCP connect scan only. This is the simplest scan technique: complete a full TCP three-way handshake with each port. It's reliable for detecting open ports but slow (the handshake adds round-trip time per port) and easily logged (every scan attempt appears in the target's connection logs). Nmap's SYN scan (faster, stealthier) requires raw socket access that PHP doesn't have on most shared hosts. UDP scanning, OS detection, and service-version detection also require raw sockets and aren't supported here.
Closed vs filtered ambiguity. A port that doesn't respond within the 2-second timeout shows as closed — but it might actually be filtered (a firewall dropped the SYN packet without responding) or just slow. The tool can't distinguish these cases without raw socket access. For investigative work where the distinction matters (firewall vs no-service), use Nmap with -sS to see the actual TCP response state.
Caching and rate. Results cache for one hour via WordPress transients keyed by target. Repeat scans return the cached HTML, which prevents accidentally hammering a target if a tool result page goes viral. Note that this means rapidly-changing port states won't appear during the cache window — re-query after 60 minutes for fresh data.
Legality and ethical scope. Use this tool against your own infrastructure, against systems where you have explicit authorisation (bug bounty programmes with port-scanning in scope, contracted pentests), or against public services you legitimately need to interact with. Unauthorised scanning of systems you don't own sits in a legal grey zone in most jurisdictions — see the FAQ for full detail.
Five real-world use cases
Audit your own attack surface
Run this against every public IP your organisation owns. The expected open ports for a typical web property are 80 and 443. Anything else (SSH, RDP, MySQL, MongoDB, RDP, SMB) exposed to the public internet is a finding worth investigating — those services should normally be reachable only via VPN, bastion host, or IP-allowlisted firewall rule. If you find one exposed, your immediate fix is firewall it off; your second fix is figure out why nobody noticed.
yourdomain.com
Verify a firewall change actually applied
You closed a port at the firewall — or you think you did. Run the scanner before and after the change. If the port was previously OPEN and now shows closed, the change applied correctly. If it's still OPEN, your firewall rule didn't take effect (wrong direction, wrong interface, rule order issue, applied to the wrong host). This is a fast sanity check that catches configuration mistakes before they become incidents.
Identify exposed admin services on production servers
RDP (3389), SSH (22), MySQL (3306), PostgreSQL (5432), MongoDB (27017), and SMB (445) are the high-value targets attackers scan for at internet scale. If any of these are open on your production IPs and you haven't explicitly chosen to expose them via firewall rules, your servers are visible to brute-force credential-stuffing campaigns running 24/7 from botnets. The fix is firewall-level lockdown to known-good source IPs (your office, your VPN concentrator) — never "open to anywhere on the internet" for admin services.
Bug bounty: discover services on subdomains beyond HTTP
When recon expands a target's surface area, port scanning each discovered subdomain reveals services beyond just the web tier. A subdomain that returns a normal HTTPS page on 443 might also be running an exposed Redis on 6379 (not in our default list — use Nmap for that), an unauthenticated MongoDB on 27017, or a forgotten development RDP on 3389. These adjacent services are often where the real findings live, because they have less testing coverage than the main web app.
Incident response: confirm an unauthorised service appeared
A SOC alert fires suggesting a server may have been compromised. One quick triage step is comparing current open ports to your baseline. Did port 4444, 5555, 6666, 8888, or some other unusual port suddenly become reachable? Reverse shells, miner C2, and webshell control panels often listen on non-standard ports. The 18-port default list won't catch these (they're not common services), so for IR work, use Nmap's full-range scan from inside your network rather than this tool — but the principle is the same: deviation from baseline is the signal.
Common mistakes & edge cases
Treating closed as proof a port is firewalled
A port reported as closed could be: actually closed (no service listening), filtered (firewall dropped the SYN), or just slow (target overloaded, congested route, 2-second timeout was too short). The TCP-connect scan can't distinguish these. For investigative work where the distinction matters, use Nmap with -sS from a machine you control to see whether the target sent RST (closed) or nothing (filtered).
Scanning systems you don\u2019t own without authorisation
Unauthorised port scanning is in a legal grey zone in most jurisdictions and at minimum a TOS violation on most cloud providers. Stick to systems you own, systems you're explicitly authorised to test, and bug-bounty targets with port-scanning in their scope.
Missing services on non-standard ports
This tool scans 18 ports. Real-world services run on whatever ports their operators chose, and attackers often deliberately put services on non-standard ports to avoid casual scanning (SSH on 2222 instead of 22, RDP on 33890 instead of 3389, web admin on 8000 instead of 80). For a full audit, use Nmap from your own machine: nmap -p- target.com scans all 65,535 ports. Slower but catches what custom-port-only scans miss.
Confusing open TCP with running service
OPEN means the TCP handshake completed — but the service behind that listener might be in a degraded state, mid-startup, configured to refuse non-authenticated connections, or even a honeypot. To confirm what's actually running, use Nmap with -sV for service version detection or probe with the actual protocol client (curl, openssl s_client, etc.).
Reading a single scan as definitive
Load balancers route different connections to different backends, DDoS protection may temporarily block scan-pattern traffic, and intrusion-prevention systems can throttle your scan source IP. For high-stakes determinations, scan multiple times from different source IPs over a longer window.
Forgetting that UDP services exist
This tool is TCP-only. UDP services (DNS on 53, NTP on 123, SNMP on 161, IPMI on 623, various game servers, VoIP on 5060) are invisible to TCP-connect scans. UDP scanning is harder to do reliably (no handshake, so probes have to be service-specific) and PHP doesn't easily support it from a shared host. If your audit scope includes UDP, use nmap -sU from a machine with raw socket access.
Frequently Asked Questions
Paste the domain or IP into the scanner above. The tool checks 18 common TCP ports in about 5 seconds and reports which are open. The scan happens server-side from our infrastructure — useful for privacy but means you can't scan internal networks, and the target sees connections from our IP rather than yours.
18 common TCP ports: 21 (FTP), 22 (SSH), 23 (Telnet), 25 (SMTP), 53 (DNS), 80 (HTTP), 110 (POP3), 143 (IMAP), 443 (HTTPS), 445 (SMB), 993 (IMAPS), 995 (POP3S), 3306 (MySQL), 3389 (RDP), 5432 (PostgreSQL), 8080 (HTTP-Alt), 8443 (HTTPS-Alt), 27017 (MongoDB). For full-range scans, use Nmap from a machine you control.
Scanning your own systems and authorised targets (bug bounty programmes with scanning in scope, contracted pentests, public services you legitimately interact with) is unambiguously legal. Unauthorised scanning of systems you don't own is in a legal grey zone — minimum a TOS violation, potentially criminal under laws like the UK Computer Misuse Act and US CFAA, though prosecution for non-disruptive connect scans of common ports is rare in practice.
Closed means a service responded that nothing was listening on that port. Filtered means a firewall silently dropped the packet. From this scanner's perspective both look the same (no successful connection within the timeout). Nmap with -sS can distinguish them by examining the exact TCP response.
No — TCP only. UDP scanning is harder to do reliably (no handshake, so probes have to be service-specific) and isn't supported here. For UDP scanning use nmap -sU from a machine you control.
No. The scan runs from our server-side infrastructure on the public internet, so it can't reach RFC 1918 private addresses (10.x, 172.16-31.x, 192.168.x) or other non-routable ranges. For internal scanning use Nmap or a similar tool from a machine inside your network.
Most common reason: a firewall or DDoS protection is blocking our scanning IP specifically (cloud security groups, fail2ban-style rate limiters). The port may be open to the world but our IP is blocked. To verify, scan from a different source — for ongoing monitoring, use a scanner running from inside your environment.
Not with this tool — it's limited to the 18-port shortlist for performance. For full-range scanning use Nmap: nmap -p- target.com scans every TCP port. For faster results limited to commonly-scanned ports use nmap target.com with no -p flag (defaults to the top 1,000 ports).
Yes. TCP connect scans complete a full handshake, which means the target's connection logs will show our scanning IP. The target cannot see your IP through this tool — they see ours. If you need to scan from your own IP (for legitimate authorised testing where attribution matters), use Nmap or another scanner running on your machine.
Internet-exposed services are the most direct attack surface a target has. Misconfigured exposed databases (MySQL, PostgreSQL, MongoDB, Redis), forgotten admin services (SSH, RDP, web admin panels), and abandoned development infrastructure are among the most common breach causes. Regular port-scanning audits of your own public IPs catch these exposures before attackers do.