Port Checker

Introduction

The DeviceHub Port Checker is a free online TCP connect probe that asks DeviceHub’s Cloudflare Pages Function at POST /api/port-check to attempt a TCP connection from the Cloudflare edge toward the hostname and port you specify, without installing nmap, without running scans from your laptop that trigger ISP abuse desks, and without pretending to grab service banners or fingerprint daemons on the remote host. Site reliability engineers verifying that port 443 accepts connections from outside their datacenter, developers debugging why SaaS webhooks fail, students learning the difference between edge-origin probes and home LAN tests, and support staff confirming a host accepts TCP from Cloudflare’s network all enter a host, pick a port, and read open or closed style outcomes plus timing hints when available. DeviceHub states limits plainly: port checker TCP probes run from Cloudflare edge via /api/port-check, NOT from the user’s LAN; results describe reachability along that edge path, not whether your home router forwarded port 8080 to a Raspberry Pi, and this is not a banner grabber that reads SMTP greetings or SSH keys. Local astro preview without Pages Functions shows API unavailable, deploy to Cloudflare Pages for live probes. Pair with HTTPS Reachability Check when the question is HTTPS reachability and response headers rather than raw TCP alone. Pair with HTTP Headers when you need echoed client request metadata from DeviceHub edge. Pair with IP Address when correlating egress context for unrelated tickets. Misunderstanding edge-origin scope causes most false bug reports, read honesty copy before escalating to hosters. DevOps teams validating webhook receivers use edge-open on 443 before HTTPS Reachability Check confirms TLS handshakes. Game server admins learn quickly that open from Cloudflare does not mean open from every residential ISP, geo IP allowlists differ. University lab networks blocking outbound student scans appreciate that probes never originate from student laptops, only from Cloudflare. SaaS status pages citing regional outages benefit from edge-path language in tickets instead of ambiguous works-for-me replies.

What this tool does

You supply hostname and port; the browser POSTs JSON to /api/port-check; the Pages Function initiates TCP connect from Cloudflare infrastructure and returns structured success or failure, elapsed timing when measured, and error messages suitable for tickets. The UI labels API path and Cloudflare edge origin explicitly. It does not UDP scan, does not SYN-flood, does not read application-layer banners, and does not probe from the user’s residential IP. Invalid ports are rejected client-side. Empty host blocks the request with validation messaging. Results render in a summary panel and sync to DeviceHub browser diagnostic rows for copy workflows. Failures distinguish missing API deployment from target refusal when HTTP status allows. Permissions stay none. Repeated checks rate-limit at Cloudflare according to deployment policy, users should not hammer production hosts unnecessarily. Timing rows when present help distinguish slow accepts from immediate refusal, attach milliseconds in tickets. Error strings from the function surface DNS failure separately from connection refused when the API maps errno clearly. Host validation rejects empty strings client-side before POST to reduce junk function invocations.

When to use it

Use Port Checker when you need a quick TCP connect smoke from Cloudflare’s network toward port 443, 22, 587, or custom services, when validating that a firewall allows Cloudflare egress, and when teaching that online port tools differ from LAN port-forward tests. Prefer HTTPS Reachability Check for HTTPS-specific reachability, certificate timing, and HSTS header glimpses, not full chain audit. Prefer running nmap or your hoster’s panel from contexts that match your threat model when you need banner version strings DeviceHub deliberately omits. Avoid using this tool to scan third-party hosts without permission, responsible use only. Avoid expecting open here to mean open from your office ISP, edge path only. Run after deploying DeviceHub to Cloudflare when local preview showed API unavailable. Run when webhook docs say port 443 must be reachable from the internet and you want an independent edge viewpoint. Run when your CDN allows only Cloudflare IPs and you need proof the origin accepts TCP from that range. Run after firewall rule changes that whitelist Cloudflare egress blocks, closed here means your rule still blocks edge probes. Compare with HTTPS Reachability Check when TCP open but TLS handshake fails, layer separation clarifies tickets.

How it works

Browser JavaScript cannot open arbitrary TCP sockets to remote hosts for security reasons; DeviceHub delegates connect attempts to a serverless function running on Cloudflare Workers or Pages Functions. The function resolves the target hostname, attempts TCP connect with a bounded timeout, records success or errno-style failure, and returns JSON to the page. Probes originate from Cloudflare’s egress IP space, not from the user’s browser IP and not from the user’s LAN gateway. That design enables CORS-safe checks from static pages while making scope honesty essential: a closed result means Cloudflare could not connect, not necessarily that every client worldwide sees closed. NAT hairpinning on home routers is invisible to this tool. IPv6 versus IPv4 target resolution follows Cloudflare resolver behavior on the function side. No Permissions API prompts appear. GET /api/port-check is not used, POST carries host and port JSON body. Cloudflare POP selection means consecutive probes might egress from different cities, both remain edge-origin, not user LAN. Corporate allowlists that permit only office IPs will show closed from Cloudflare even when your laptop on VPN connects, expected split horizon behavior.

Step-by-step instructions

1. Deploy DeviceHub to Cloudflare Pages if local preview shows port-check API unavailable, Functions are required for live probes.
2. Open Port Checker, enter the target hostname or IP and TCP port, avoiding unsolicited scans of hosts you do not manage.
3. Click Check port and wait for POST /api/port-check to return before screenshotting partial states.
4. Record open or closed outcome with explicit note that the probe originated at Cloudflare edge, not your LAN.
5. If HTTPS matters, continue to HTTPS Reachability Check on the same hostname for reachability and header hints beyond raw TCP.
6. Do not treat results as service banner confirmation, DeviceHub does not read application protocols on open ports.

Common problems

Users expect home LAN port-forward validation and file tickets against DeviceHub when edge open/closed does not match their router UI, scope misunderstanding. Local dev without Functions yields 404, deploy first. Targets blocking Cloudflare IP ranges show closed while office laptops connect fine. Aggressive scanning of third-party hosts violates acceptable use, probe only hosts you manage or have permission to test. Confusing TCP open with TLS valid requires HTTPS Reachability Check instead. Entering host with scheme prefix fails validation, use bare hostname. Timeouts on slow hosts may look like closed, retry once and note timing row. Probing mail port 25 from edge often fails because many hosts block datacenter egress, failure is target policy, not DeviceHub regression. IPv6-only targets may resolve differently on Cloudflare than on your laptop resolver, note A versus AAAA ambiguity in tickets.

Privacy explanation

Port checks run from Cloudflare infrastructure; the target host sees Cloudflare egress IPs, not your home browser IP as the TCP source. Your browser sends the hostname and port you typed to DeviceHub /api/port-check, do not enter secrets in host fields. DeviceHub does not upload unrelated browsing data during checks. Permissions stay none. Hostnames you probe may be logged in Cloudflare function observability according to your deployment, operators should treat logs as operational data. Responsible disclosure: only scan systems you are authorized to test. Your browser still sends the hostname you typed to DeviceHub, treat host fields like operational data in shared screen recordings. Target firewalls may log Cloudflare probe IPs separately from your home IP, good for webhook debugging, confusing if you expected your residential address to appear on their logs.