Common Port Checker

A port checker shaped by browser security

This common port checker tests whether a browser can reach HTTP or HTTPS services at a hostname on a short, fixed list of ports. It is deliberately not a raw TCP port scanner. Web pages cannot create arbitrary TCP sockets, complete an SSH handshake, send an SMTP greeting, or inspect a MySQL banner. The distinction matters: “reachable” here means a browser fetch was able to initiate a web request, not that a general-purpose scanner completed protocol detection.

The table includes common names for ports 21, 22, 23, 25, 53, 80, 110, 143, 443, 445, 3306, 3389, 5432, 6379, 8000, 8080, 8443, and 27017. Only ports 80, 443, 8000, 8080, and 8443 have an HTTP or HTTPS scheme in the implementation and are probed. Every FTP, SSH, Telnet, SMTP, DNS, POP3, IMAP, SMB, database, RDP, and cache row is marked Not testable in browser without contacting that port.

Use it as a web reachability triage step

Enter a hostname such as staging.example.com. Supply only the host: the component constructs its own URLs, so https://staging.example.com/path would create an invalid target. After a 400 ms pause, it launches the five web probes concurrently. The Scan button repeats the checks. The timeout for each attempted request is 2.5 seconds.

For the default-style target, requests have forms such as:

http://staging.example.com:80
https://staging.example.com:443
http://staging.example.com:8000
http://staging.example.com:8080
https://staging.example.com:8443

The fetch uses mode: "no-cors" and cache: "no-store". No-CORS lets the browser send certain simple cross-origin requests without granting JavaScript access to the response. The tool therefore cannot read a status code, response headers, body, certificate details, server banner, redirect chain, or application error. It records Open (reachable) when fetch resolves and Unreachable when it rejects or the abort timer expires.

What the statuses do and do not prove

Open (reachable) is best read as “the browser completed enough of an HTTP(S) fetch for its promise to resolve.” An opaque no-CORS response can represent 200 OK, 404 Not Found, 401 Unauthorized, 500 Internal Server Error, or another HTTP result. Any of those still demonstrates a responding web path. The label does not attest that the application is healthy, authenticated, correctly routed, or safe.

Unreachable is ambiguous. The port may be closed, filtered, timed out, blocked by browser policy, unavailable over the selected IP family, rejected because of TLS, or prohibited as mixed content. DNS failure and invalid hostname syntax lead to the same displayed outcome. Because the code maps every fetch exception to one label, it cannot distinguish ECONNREFUSED from a firewall drop or certificate failure.

Not testable in browser is not a scan result and must never be reported as closed. It means the component intentionally made no request because that row lacks an HTTP/HTTPS scheme. Port 22 could be open for SSH while its table row still says not testable. Verify non-web ports with an authorized TCP tool from an appropriate network location.

Example: finding a misplaced admin service

Assume a staging dashboard should listen on HTTPS 8443. Enter staging.example.com. If 443 and 8443 are reachable, open the exact URLs in a separate browser tab and check certificates, authentication, and application behavior. If 8443 is unreachable but 8080 is reachable, the deployment may be serving plain HTTP on the wrong port, a reverse proxy may be misconfigured, or browser mixed-content restrictions may be affecting the result.

Run a controlled command from an authorized machine to confirm:

curl -vkI https://staging.example.com:8443/

Unlike this page, curl can expose TLS and HTTP diagnostics. For raw TCP reachability, an administrator might use nc -vz staging.example.com 8443; for service discovery across owned infrastructure, a carefully scoped nmap -sV test is more appropriate. Those commands can generate security alerts and must follow organizational policy.

Now consider port 3306. The page will always label MySQL not testable. That is a browser limitation, not evidence of exposure or protection. Check a cloud security group, host firewall, listening socket, or authorized internal probe instead.

Browser policies that affect the test

A page loaded over HTTPS generally cannot fetch an insecure http:// subresource. Mixed-content rules may block ports 80, 8000, and 8080 before useful network behavior occurs. Browsers differ in how they upgrade or block requests, and target classification can matter. Thus an HTTP service that works from curl may appear unreachable from this HTTPS page.

TLS errors on 443 or 8443 also reject fetch. An expired certificate, untrusted development CA, hostname mismatch, obsolete TLS version, or intercepted connection can look exactly like a closed port. The component cannot bypass certificate validation and should not; mode: no-cors relaxes response visibility, not transport security.

CORS itself is less decisive here than with ordinary fetch because no-CORS responses may resolve opaquely. However, redirects can cross into forbidden schemes or ports, Content Security Policy can restrict destinations, extensions can cancel requests, and browsers maintain a list of unsafe ports that web requests may not use. The fixed list avoids many prohibited ports for actual fetches, but environmental policy still applies.

DNS resolution happens according to the browser and operating system. A hostname with both A and AAAA records may take a path different from a command-line test. A corporate split-horizon name may resolve only on VPN. The tool has no control over address selection and does not display which address was contacted.

Authorization is required

Even a small common port scan creates outbound requests to a target. Use it only for hosts you own, administer, or have explicit permission to assess. A public hostname is not an invitation to probe it. Provider acceptable-use policies, employment rules, contracts, and local law may restrict scanning regardless of technical intensity.

Keep scope exact. Do not enter third-party customer domains to “see what is open,” and do not repeatedly modify hostnames to enumerate a network. Obtain written authorization that identifies targets, permitted techniques, timing, source networks, and contacts. Production monitoring and security testing should use approved infrastructure, rate controls, logs, and escalation procedures rather than an ad hoc browser page.

The tool runs automatically after typing, so treat entry into the field as initiating activity. There is no separate confirmation gate and no configurable rate limit. Five target requests are attempted for each settled hostname edit. Avoid pasting confidential internal hostnames when the page or network environment is not approved for them.

Privacy and target visibility

The target hostname is used directly by your browser; DevsTool does not proxy the probes. The destination, its CDN, firewall, and intermediary network services can observe your public source IP, timing, TLS handshake metadata, and HTTP request characteristics. DNS resolvers may also log the hostname. No result body is made available to the component, and the status table remains local React state.

“No-cors” does not mean no network and does not make scanning anonymous. A VPN or corporate proxy may change the visible source, but only according to its configuration. Do not rely on this tool for stealth, anonymity, compliance evidence, or an authoritative exposure inventory.

A troubleshooting ladder

1. Reduce the input to a plain hostname with no protocol, slash, port, IPv6 brackets, or path.
2. Confirm the name resolves with an approved DNS lookup.
3. Open the expected HTTP(S) URL directly and inspect the browser’s certificate or error page.
4. Check whether the DevsTool page is HTTPS and the target uses HTTP, which can trigger mixed-content blocking.
5. Review DevTools console and network entries for policy errors, TLS failures, extension blocks, and timeouts.
6. Compare from the same client with curl, then compare from the server or monitoring network.
7. Inspect load-balancer listeners, container mappings, local listening sockets, network ACLs, and host firewalls.

If every web row is unreachable, suspect malformed input, DNS, offline state, browser policy, or a blocker before concluding that five ports are closed. If results change between runs, consider load-balanced addresses, intermittent listeners, rate controls, and the short timeout.

Questions about this browser port scanner

Why can’t it check a custom port?

The interface uses a fixed array of common ports and schemes. There is no custom range or port input, and only five entries are probe-enabled.

Is an opaque response really an open port?

It is evidence of browser-level web reachability, but not a definitive TCP state classification. Proxies, service workers, redirects, and browser behavior can complicate the path. Confirm with an authorized network tool.

Why is SSH shown as not testable even when I can connect?

JavaScript fetch speaks HTTP semantics and cannot open a raw SSH socket. The row is informational only.

Can this scan localhost or private addresses?

The component does not explicitly block them, but browser private-network protections, mixed content, DNS behavior, and page policy may prevent access. More importantly, only test private systems when the page and activity are approved; use local administrative tools for reliable results.

Does reachable mean the firewall allows everyone?

No. It only describes the path from this browser at this moment. Source-based rules, geographic policy, CDN edges, IPv4/IPv6 differences, and authentication can produce different outcomes elsewhere.