Live TCP reachability utility
Check whether TCP ports are reachable from the PeopleAreGeek server, load practical service profiles, read exposure notes and build a compact report for firewall or server troubleshooting. The checker tests reachability, not authentication or vulnerability status, so an open result should always be interpreted with the service role in mind.
Each connection is attempted from the site backend over TCP. Firewalls may intentionally drop a check, and a reachable port still needs secure configuration.
What an online port checker can and cannot tell you
A port checker answers a narrow but important question: can a TCP connection reach this host and port from an outside network? That makes it useful after firewall changes, server migrations, mail setup, reverse proxy work, router changes or security reviews. If HTTPS is supposed to be public, port 443 should normally answer. If a database is meant to stay private, an unexpected public result on its port deserves attention.
The result is not a vulnerability scan and it is not a guarantee that a service is healthy. An open port can sit in front of a secure, patched and restricted service. A closed or timed-out port can be intentional because a firewall drops probes from unknown addresses. The practical value comes from comparing reachability with your intended design.
How to interpret common TCP ports
- 80 and 443 are normal public web ports for HTTP and HTTPS.
- 22 and 3389 are remote administration ports and should be exposed deliberately.
- 25, 465 and 587 are mail transport or submission ports when a host really handles email.
- 3306, 5432, 1433, 6379 and 27017 are common data service ports that often belong behind a private network or allowlist.
- 21, 23 and 445 call for careful review because legacy or lateral-movement risks are common around them.
A useful firewall workflow
Start with the role of the server. Public web server, mail server, VPN gateway and database node do not need the same exposure. Check the ports that should be open, then check a short list of sensitive ports that should not be open. If a management service must remain public, prefer source-IP restrictions, VPN access, multi-factor authentication and strong logging. If a port is closed but the application should work, confirm local service binding, cloud security groups, host firewall rules, NAT and provider filtering.
Port checker results and security context
Reachability is only the first layer. For a web service, use HTTP headers, SSL and redirect checks next. For a mail server, inspect DNS records, TLS policy and reputation concerns. For admin ports, confirm patching, key-based access, rate limiting and monitoring. The best port report is one that matches a documented exposure plan, not one with the largest number of open services.
Common questions
Why does my port show closed when the service works locally?
The service may listen only on localhost or a private interface, or a firewall, cloud security group, router or upstream provider may block the external connection.
Can this tool test UDP?
No. This checker uses TCP connection attempts. UDP reachability is harder to interpret because many UDP services do not answer unsolicited probes.
Should every closed port be opened?
No. Closed is often the desired state. Open only the services that have a real public purpose and a security plan.
What does it mean when a port is open or closed?
Open means a service is listening and reachable; closed means nothing is listening or a firewall is rejecting it. Filtered means a firewall is silently dropping the probe.
Why should I not leave database ports open to the internet?
Ports like 3306, 5432, 6379 and 27017 are constantly scanned. Exposed databases get brute-forced or hit by known exploits within minutes. Put them behind a VPN or SSH tunnel.
Can I check ports on any host?
Only check hosts you own or are authorised to test. Port scanning systems you do not control can violate terms of service or local law.
