The Port Check That Is Not Scary: Which Ports Should Be Closed
Ports are doors with numbers. Which ones a normal website needs open, which findings should worry you, and the five-minute routine.
The phrase port scan sounds like something hackers do in films, usually while wearing hoodies. In reality, checking which ports are open on your own server is basic hygiene, closer to walking around your house at night checking the doors than to breaking into anyone else's. This post explains what ports are, which ones deserve to be open on a typical website server, and which findings should make you sit up.
Ports are doors with numbers
A server has one address but many services: the website, the mail system, the database, the remote login. Ports are how traffic finds the right one. Each service listens on a numbered door, 443 for secure web traffic, 25 for mail delivery, 22 for SSH logins. An open port means a service is listening and will answer strangers. A closed port means nothing answers. Neither is automatically good or bad. A web server with 443 closed is broken; a web server with its database port open to the whole internet is an accident in progress.
The doors a normal website needs
For a typical site: 80 and 443 for web traffic, with 80 ideally just redirecting to 443. Mail needs its set if the same machine sends or receives: 25 for server-to-server delivery, 465 or 587 for sending from your own mail apps, 993 for reading mail securely. Remote administration needs exactly one door, 22 for SSH or 3389 for Windows remote desktop, and that door is the one to think hardest about, because it is the one the entire internet knocks on, constantly, forever. Everything else on a small server deserves a question. Run your host through the Port Checker and compare what answers with what you expected to be listening.
Findings that should worry you
Database ports top the list: 3306 (MySQL), 5432 (PostgreSQL), 27017 (MongoDB) open to the public internet. Databases are built to be talked to by your website, not by the world, and automated scanners sweep for exactly these ports within hours of a server appearing. Next, management panels and forgotten services: an FTP port (21) still listening years after everyone moved to SFTP, a test server on 8080 that became permanent. Finally, anything you cannot name. A port you do not recognise is not a curiosity, it is a task: find the service, and either justify it or close it.
What a checker can and cannot see
Honesty matters here. A connection-based check like ours reports whether a port answers from the public internet. If your server sits behind a firewall or a network that silently drops probes, a port can report as closed or filtered when the service is running but shielded, which for outside risk is what counts. One special case our checker names for you: if the host is fronted by Cloudflare, the answer comes from Cloudflare's network, not your origin server, and the page says so, because scanning a shield tells you about the shield. For the full picture of a server you own, pair an outside check like this with the listening list on the machine itself.
The five-minute routine
Once a month, or after any server change: run the common ports, read the answers against your expectations, chase anything unexplained. While you are in a checking mood, the HTTP Headers Checker covers the web layer the same way. Security for a small site is rarely about exotic defences. It is about knowing which of your doors are open, and being able to say why, out loud, for every single one.