My Port XXX is closed. Can you open it?

What this is#

The short answer: there's almost certainly nothing for us to open. We don't filter arbitrary ports, inbound traffic to your VPS is allowed on every port by default, with one exception: a short, deliberate list of high-risk application ports (databases, caches, and similar) blocked at our network edge, which you can open to chosen IPs yourself via the Per-Application Whitelist. The full list and how-to is in the VPS firewall guide. SSH, web, mail, game servers, VPNs, and every custom port: untouched by us.

So when a port "is closed", the cause is on the VPS, and it's nearly always the next section.

A port is only "open" if something is listening#

This is the part every port-checker website quietly assumes and never explains: "open" means a program accepted the connection. There is no switch that makes a port open on its own, a port with no service listening on it reports closed even with every firewall in the world turned off. Checker tools don't test "is this port allowed", they test "did anything answer".

So before any firewall thinking, confirm a listener exists:

ss -tulnp | grep :25565

You want a LISTEN line, and on 0.0.0.0 (or a public address), a service bound to 127.0.0.1 is invisible from outside by design (that's usually correct, make sure it's wrong before changing it). No LISTEN line? Start the service; that is the fix. And test from outside the VPS (your machine, not localhost), a localhost test passes things the internet can't reach.

Closed vs filtered: what the checker is really telling you#

Here's the technical distinction that turns a checker result into a diagnosis. When a TCP connection attempt arrives at a port, three things can happen:

• Nothing is listening → the kernel answers immediately with a RST ("go away"). Checkers report closed, clients say "connection refused", and crucially, the answer is instant. An instant refusal means your packet reached the machine, no firewall ate it; there's simply no service there.
• A firewall REJECTs → the packet is refused with an active response (RST or an ICMP unreachable). Looks nearly identical to the above: instant, "refused", nmap says closed. Polite, fast, and it tells scanners the host exists.
• A firewall DROPs → the packet is silently discarded, no answer at all. The client waits and eventually times out; nmap reports filtered. Silence is the signature of a firewall.

The rule of thumb that falls out: "refused" = reachable but nothing listening; "timeout/filtered" = something is dropping packets. A drop is either a firewall inside your VPS (most default-deny setups DROP, see default input policy) or, for the ports on our blocked list only, our edge firewall awaiting a whitelist entry.

The 60-second checklist#

1. Is anything listening? ss -tulnp | grep :<port>, LISTEN on a public address. If not, start/fix the service (a proxy answering for a dead app is its own story).
2. Your own firewall. If you run ufw/firewalld/iptables, allow the port, and remember the default-deny policy blocks everything you haven't allowed.
3. On our blocked list? Only then does our firewall apply, add your source IP to the Per-Application Whitelist.
4. Test from outside: nmap -Pn -p <port> YOUR.VPS.IP from your own machine, and read the result with the closed-vs-filtered rule above.

Still need help?#

You can open a support ticket. So we can help on the first reply, it's worth mentioning:

• the VPS hostname or IP and the port,
• the ss -tulnp line for that port (or that there isn't one),
• whether the outside test is refused instantly or times out.

Related questions#

• "Can you open port XXX for me?"
• "Do you block any ports?"
• "The port checker says my port is closed even though the firewall is off."
• "What's the difference between connection refused and connection timed out?"
• "What does filtered mean in nmap?"
• "Why is my port closed when nothing is blocking it?"