You start a game server, a web app or an SSH daemon. It works on the machine itself. A friend tries to connect and gets a timeout. You check the logs and nothing is wrong. The port looks closed from outside, and the cause is almost always one of four things.

Work through them in this order. Each step rules out a layer, so you stop at the first one that is broken.

1. Is the service listening at all?

Run this on the server, not your laptop:

ss -tlnp | grep :25565

Use your own port. If nothing comes back, the service isn't running on that port, and no firewall will fix it. Check the service's own config for the port it expects.

2. Is it listening on the right address?

Look at the address column in the same output:

  • 0.0.0.0:25565 or [::]:25565 means it accepts connections on every interface.
  • 127.0.0.1:25565 means it only accepts connections from the machine itself. This is the classic cause. Many apps default to localhost. Change the bind address to 0.0.0.0 or the server's public IP.

3. Is a firewall on the server blocking it?

Many Linux images ship with a firewall that allows only SSH by default. Check which one is active:

sudo ufw status
sudo firewall-cmd --list-all
sudo nft list ruleset | head -50

If your port isn't in the allow list, add it and reload. Also check the cloud or provider firewall in the control panel. It sits outside the server, so a rule there blocks traffic before the server sees it, and nothing in ufw will show it.

4. Is the path from outside open?

If steps 1 to 3 are clean, the block is between the internet and your server. There are three common causes:

  • Home router port forwarding. The rule points at the wrong internal IP, or the device's IP changed after a reboot. Give the machine a fixed address and check the forward targets it.
  • Carrier-grade NAT. Some home and mobile connections don't have a public IPv4 address at all. Port forwarding can't work, however the router is set up. Ask your ISP for a public address, or use a server with one.
  • Blocks on the ISP side. Some residential connections block ports such as 25, 80, 443 or 445. You can't see this from inside your network.

Test from outside, from more than one place

Use the port checker to test the port from outside your own network. It tries a TCP connection from three regions: the US, the UK and the Netherlands. The result tells you more than a single check:

  • Open from all three: the port is reachable. If your friend still can't connect, the problem is in their network or in the application's own handshake.
  • Closed from all three: the problem is on your side of steps 1 to 3, or in the path described in step 4.
  • Open from some and closed from others: a regional block, a routing problem, or an ISP filter. Re-test later before you change anything, since routing can change within a day.

Per-port pages explain what each common port is for and how to lock it down, for example SSH on 22 or Minecraft on 25565.

Two notes on what the checker can't tell you

It tests TCP only, so a service that runs on UDP needs a different check. Mail ports (25, 465 and 587) are left out on purpose. Outbound mail is restricted on most hosts, including ours, so a result there would be misleading.

If a port is open from the checker but your application still fails, the port isn't your problem. Check the application's logs and its own bind and auth settings.