--- title: "How to check if a port is open on your server | StreetHosting" description: "Test ports from outside with nc, nmap and Test-NetConnection, see what listens on the server with ss, and tell closed, filtered and localhost only apart." url: "https://streethosting.com.br/en/guides/infrastructure/check-open-port-server" type: "page" language: "en-US" --- Infrastructure · 8 min · Beginner Published on Nov 13, 2026 · Updated on Nov 13, 2026 # Open, closed or filtered port: how to test from outside and diagnose from inside When a service is running but nobody can connect, the cause is almost always one of three things: the program does not listen where it should, a firewall blocks the packet, or the network along the way drops the connection. Here is how to tell them apart. By [Equipe StreetHosting](https://streethosting.com.br/en/autores#equipe-streethosting) · StreetHosting infrastructure and support team [Network, DNS and domains](https://streethosting.com.br/en/guides/topics/networking) Summarize with: [](https://chat.openai.com/?q=Summarize%20the%20key%20points%20of%20this%20StreetHosting%20guide%3A%20https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Finfrastructure%2Fcheck-open-port-server.%20Highlight%20the%20step-by-step%20instructions%2C%20the%20prerequisites%20and%20the%20most%20common%20mistakes. "ChatGPT") [](https://claude.ai/new?q=Summarize%20the%20key%20points%20of%20this%20StreetHosting%20guide%3A%20https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Finfrastructure%2Fcheck-open-port-server.%20Highlight%20the%20step-by-step%20instructions%2C%20the%20prerequisites%20and%20the%20most%20common%20mistakes. "Claude") [](https://www.google.com/search?udm=50&aep=11&q=Summarize%20the%20key%20points%20of%20this%20StreetHosting%20guide%3A%20https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Finfrastructure%2Fcheck-open-port-server.%20Highlight%20the%20step-by-step%20instructions%2C%20the%20prerequisites%20and%20the%20most%20common%20mistakes. "Google AI Mode") [](https://x.com/i/grok?text=Summarize%20the%20key%20points%20of%20this%20StreetHosting%20guide%3A%20https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Finfrastructure%2Fcheck-open-port-server.%20Highlight%20the%20step-by-step%20instructions%2C%20the%20prerequisites%20and%20the%20most%20common%20mistakes. "Grok") [](https://www.perplexity.ai/search/new?q=Summarize%20the%20key%20points%20of%20this%20StreetHosting%20guide%3A%20https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Finfrastructure%2Fcheck-open-port-server.%20Highlight%20the%20step-by-step%20instructions%2C%20the%20prerequisites%20and%20the%20most%20common%20mistakes. "Perplexity") Share: [](https://x.com/intent/tweet?text=How%20to%20check%20if%20a%20port%20is%20open%20on%20your%20server&url=https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Finfrastructure%2Fcheck-open-port-server "Share on X") [](https://www.facebook.com/sharer/sharer.php?u=https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Finfrastructure%2Fcheck-open-port-server "Share on Facebook") [](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Finfrastructure%2Fcheck-open-port-server "Share on LinkedIn") [](https://wa.me/?text=How%20to%20check%20if%20a%20port%20is%20open%20on%20your%20server%20https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Finfrastructure%2Fcheck-open-port-server "Share on WhatsApp") For agents: Copy as Markdown [.md](https://streethosting.com.br/en/guides/infrastructure/check-open-port-server.md) In this guide 8 sections * [Three places a port can fail](https://streethosting.com.br/en/guides/infrastructure/check-open-port-server#tres-camadas) * [Testing from outside](https://streethosting.com.br/en/guides/infrastructure/check-open-port-server#testar-de-fora) * [Closed, filtered or open](https://streethosting.com.br/en/guides/infrastructure/check-open-port-server#ler-resultado) * [See what listens on the server](https://streethosting.com.br/en/guides/infrastructure/check-open-port-server#ver-por-dentro) * [Service only on 127.0.0.1](https://streethosting.com.br/en/guides/infrastructure/check-open-port-server#localhost) * [Checking the firewall](https://streethosting.com.br/en/guides/infrastructure/check-open-port-server#firewall) * [The UDP case](https://streethosting.com.br/en/guides/infrastructure/check-open-port-server#udp) * [Full access to the server](https://streethosting.com.br/en/guides/infrastructure/check-open-port-server#onde-rodar) Quick answer To know whether a port is open, test from outside, from another machine: `nc -zv IP 443` on Linux and macOS or `Test-NetConnection IP -Port 443` on Windows. If the connection is accepted, it is open. If it is refused right away, it is closed and nothing listens there. If the test hangs until it times out, the port is filtered by a firewall. To see what listens on the server, run `sudo ss -tulpn`. ## Three places a port can fail[](https://streethosting.com.br/en/guides/infrastructure/check-open-port-server#tres-camadas) A connection that does not reach the service may have stopped at three different points, and each tool in this guide looks at one of them. 1. **The program does not listen:** the service crashed, never started or listens on another port. The operating system is the one answering, refusing the connection. 2. **The program listens on the wrong address:** it is up, but only accepts local connections, on 127.0.0.1. From outside, the effect is the same as a closed port. 3. **A firewall drops the packet:**it can be the system's own firewall, such as UFW, one in the provider's panel or the router at home. In that case nothing comes back, and the connection hangs. The best path is to test from outside first, because that is what your user experiences, and then look inside to find out in which of the three layers the fault is. Testing the server itself from inside with `curl localhost` proves nothing about outside access: local traffic uses the loopback interface, which the firewall usually allows, and never touches the network. ## Testing from outside[](https://streethosting.com.br/en/guides/infrastructure/check-open-port-server#testar-de-fora) Run these tests from a machine that is not the server, such as your computer, another VPS or your phone on mobile data. Testing from the server's own network can give a different result from what the world sees. **Linux and macOS, with nc (netcat):** `# tests port 443 over TCP, with a 5 second limit nc -zv -w 5 IP_DO_SERVIDOR 443` The `-z` option only tries to connect and closes right away, sending no data, `-v` shows the result and `-w 5` limits the wait. The exact message changes from one nc version to another, but the meaning is always this: succeeded or open when it connected, and refused when the server refused. **Any system, with nmap:** `# three ports at once nmap -p 22,80,443 IP_DO_SERVIDOR # skip the ping first, for servers that hide ICMP nmap -Pn -p 443 IP_DO_SERVIDOR` nmap prints a table with a state column, and it is the right tool for testing several ports at once. The `-Pn` option skips the live host check, useful when the server ignores ping. **Windows, with PowerShell:** `Test-NetConnection -ComputerName IP_DO_SERVIDOR -Port 443` In the output, the `TcpTestSucceeded : True` field confirms the connection was accepted. With `False`, Windows shows a warning that the TCP connection failed, without saying whether it was a refusal or silence. To tell the two apart, notice how long the command took: a refusal comes back much faster, and silence only ends when the wait times out. Scan only servers that are yours or that you have permission to test. Running nmap over whole ranges of other people's IPs may break the provider's rules and get your account blocked. To check one port on your own server, nc or Test-NetConnection are enough. ## Closed, filtered or open[](https://streethosting.com.br/en/guides/infrastructure/check-open-port-server#ler-resultado) The difference between closed and filtered is the most useful clue in the diagnosis. | State | What you see | What it means | Where to look | | -------- | ------------------------------------------------------- | ------------------------------------------------------ | ---------------------------------------------------------- | | Open | Connection accepted, nmap says open | A program listens and the path is clear | If the service still fails, the problem is the application | | Closed | Immediate refusal, connection refused, nmap says closed | The server was reached and nobody listens on that port | Stopped service, wrong port or listening only on 127.0.0.1 | | Filtered | Hangs and ends in a timeout, nmap says filtered | A firewall dropped the packet without answering | UFW, iptables, the panel firewall or the router | A closed port is good news for the diagnosis: the packet reached the server and a refusal came back, so the network and the firewall are letting traffic through and the fault is in the program. A filtered port is the opposite: the packet never got an answer, and the service may be perfect inside. If you want to understand the route to the server when the silence comes from the path, the guide on [using traceroute to find routing problems](https://streethosting.com.br/en/guides/infrastructure/how-to-use-traceroute) helps you see where the packets stop. ## See what listens on the server[](https://streethosting.com.br/en/guides/infrastructure/check-open-port-server#ver-por-dentro) Log in to the server over SSH and list the sockets that are listening: `sudo ss -tulpn` The letters mean: `t` for TCP, `u` for UDP, `l` for listening sockets only, `p` to show the process that owns the socket and `n` for numbers instead of names. You need sudo for the process name to appear. A typical output: `Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port Process tcp LISTEN 0 511 0.0.0.0:80 0.0.0.0:* users:(("nginx",pid=812,fd=6)) tcp LISTEN 0 128 127.0.0.1:3000 0.0.0.0:* users:(("node",pid=1544,fd=19)) tcp LISTEN 0 128 [::]:22 [::]:* users:(("sshd",pid=701,fd=4))` Look for the port you want. If it is not in the list, no program listens there, and the service is stopped or set to another port. If it shows up, look at the Local Address column, which is the subject of the next section. To filter one specific port, use `sudo ss -tulpn | grep :3000`. On Windows Server, the PowerShell equivalent is `Get-NetTCPConnection -State Listen`. ## Service only on 127.0.0.1[](https://streethosting.com.br/en/guides/infrastructure/check-open-port-server#localhost) The Local Address column shows which addresses the program accepts connections on, and it is the cause of many ports that look closed: * **127.0.0.1:3000:** only accepts connections from the machine itself. Anyone coming from outside gets a refusal, as if the port were closed. * **0.0.0.0:80:** accepts connections on any IPv4 address of the machine, including the public one. * **\[::\]:22:** the IPv6 equivalent. On many systems, listening on `[::]` also serves IPv4. * **PUBLIC\_IP:port:** listens only on that address and ignores the others. This behavior is often intentional. A database, an internal panel or an application behind Nginx should listen only on 127.0.0.1, and the proxy is what talks to the world. The fault appears when you wanted the public port and the program came up on the local default, as many development servers do. The fix is in the program's configuration: change the listen address to `0.0.0.0` and restart the service. In Node, for example, it is the second argument of `listen`. Before opening anything to the internet, ask whether that port really needs to be public. Databases, Redis and admin panels on 0.0.0.0 with no firewall are targets of constant scanning. The safe path is to keep the service on 127.0.0.1 and expose only Nginx, as the guide on [Nginx as a reverse proxy on a VPS](https://streethosting.com.br/en/guides/vps/nginx-reverse-proxy-vps) shows. ## Checking the firewall[](https://streethosting.com.br/en/guides/infrastructure/check-open-port-server#firewall) When the program listens on the right address and the port is still filtered from outside, look at the machine's own firewall rules: `# Ubuntu with UFW sudo ufw status verbose # iptables rules in command format sudo iptables -S # nftables rules sudo nft list ruleset` In UFW, look for an ALLOW rule for the port. If it does not exist and the inbound policy is deny, the packet is dropped and the port shows up as filtered. To open it, use `sudo ufw allow 443/tcp`. The full walkthrough, including how to allow SSH before turning the firewall on so you do not lose access, is in the guide on [the UFW firewall on an Ubuntu VPS](https://streethosting.com.br/en/guides/vps/ufw-firewall-ubuntu-vps). Remember that the system firewall is not the only one. If the local rule is right and the port is still filtered, also check the provider panel's firewall, if there is one, and the router's, when the server sits behind one. For servers at home, the conversation changes to [NAT and port forwarding](https://streethosting.com.br/en/guides/infrastructure/what-is-nat-port-forwarding). ## The UDP case[](https://streethosting.com.br/en/guides/infrastructure/check-open-port-server#udp) TCP has a connection: the test sends a request and gets an accept or a refusal. UDP has none of that. A packet goes out and, if the service does not answer empty data, nothing comes back, and the test cannot tell an open service from a firewall that drops traffic. nmap calls this case `open|filtered`. `# nc in UDP mode: the result is not reliable on its own nc -zvu -w 3 IP_DO_SERVIDOR 51820 # nmap over UDP, needs root and is slow sudo nmap -sU -p 51820 IP_DO_SERVIDOR` Two practical rules help. First: from inside, `ss -ulpn` is still reliable proof that the program listens. Second: to prove the whole path, use the protocol's real client, such as a `dig @IP_DO_SERVIDOR exemplo.com` query for DNS, or the game or VPN client itself. If the server answers, UDP is getting through. The difference between the two protocols explains why this happens, and it is covered in [TCP vs UDP on servers](https://streethosting.com.br/en/guides/infrastructure/tcp-vs-udp). ## Full access to the server[](https://streethosting.com.br/en/guides/infrastructure/check-open-port-server#onde-rodar) This diagnosis means touching what listens and what filters, so it needs root access. On [StreetHosting VPS](https://streethosting.com.br/en/vps) you have it, with KVM virtualization and the system firewall in your hands: install nmap on another machine, use ss on the VPS and configure UFW or nftables as you prefer. All of them are in São Paulo, with a dedicated IPv4, AntiDDoS included and activation in about 60 seconds after Pix or card approval. The Xeon VPS starts at R$ 26.00 per month, with 2 vCPU, 2 GB of RAM and 20 GB of NVMe. In this guide * [Three places a port can fail](https://streethosting.com.br/en/guides/infrastructure/check-open-port-server#tres-camadas) * [Testing from outside](https://streethosting.com.br/en/guides/infrastructure/check-open-port-server#testar-de-fora) * [Closed, filtered or open](https://streethosting.com.br/en/guides/infrastructure/check-open-port-server#ler-resultado) * [See what listens on the server](https://streethosting.com.br/en/guides/infrastructure/check-open-port-server#ver-por-dentro) * [Service only on 127.0.0.1](https://streethosting.com.br/en/guides/infrastructure/check-open-port-server#localhost) * [Checking the firewall](https://streethosting.com.br/en/guides/infrastructure/check-open-port-server#firewall) * [The UDP case](https://streethosting.com.br/en/guides/infrastructure/check-open-port-server#udp) * [Full access to the server](https://streethosting.com.br/en/guides/infrastructure/check-open-port-server#onde-rodar) ## Frequently asked questions How do I know if a port is open on a server? Test from outside with nc -zv IP PORT on Linux or Test-NetConnection -ComputerName IP -Port PORT on Windows. If the connection is accepted, the port is open. To confirm a program is listening, run ss -tulpn on the server itself. What is the difference between a closed port and a filtered port? On a closed port the server answers right away refusing the connection, which means the machine is reachable and no program listens there. On a filtered port no answer comes back and the test ends in a timeout, because a firewall dropped the packet. My service listens on 127.0.0.1. Why can't I connect from outside? The address 127.0.0.1 only accepts connections from the machine itself. To receive connections from the network, the program has to listen on 0.0.0.0, which covers every IPv4 address, or on the server's public IP. The change goes in the service's configuration, and then it needs a restart. Can I use nmap on any server? Use it only on servers that are yours or where you have permission. Scanning other people's ports may break the provider's rules and, depending on the case, the law. To test one specific port on your own server, nc or Test-NetConnection already do the job without scanning anything. Why is testing a UDP port harder? UDP has no connection and no confirmation. An open service may simply not answer an empty packet, and the test cannot tell an open port from a filtered one. The reliable way is to use the protocol's real client, such as a dig query for DNS. Next step See VPS plans Root VPS in Brazil with NVMe and Anti-DDoS. [See VPS plans](https://streethosting.com.br/en/vps) ## Related guides [VPS Beginner UFW on Ubuntu VPS: firewall rules without losing SSH UFW makes the Ubuntu firewall simpler, but one rule in the wrong order locks you out of your VPS. Learn how to enable it without losing SSH, open only what you need, deal with Docker, and get back in through the console if something goes wrong. 10 min Read guide](https://streethosting.com.br/en/guides/vps/ufw-firewall-ubuntu-vps) [Infrastructure Intermediate TCP vs UDP: which protocol to use on each server TCP guarantees everything arrives, and in the right order. UDP delivers what it can without waiting for anyone. Understanding that trade explains why games and voice use UDP, why APIs use TCP and why opening lots of ports in the firewall does not work. 9 min Read guide](https://streethosting.com.br/en/guides/infrastructure/tcp-vs-udp) [VPS Intermediate How to secure SSH on a Linux VPS: keys, passwords, fail2ban SSH is usually the first target on any VPS with a public IP. This guide walks through a practical routine that cuts the risk without complicating your day: an ED25519 key, password-free login, admin access through sudo, blocking of automated attempts and a periodic review of authorized keys. 4 min Read guide](https://streethosting.com.br/en/guides/vps/secure-ssh-linux-vps) [← Back to the Guide Center](https://streethosting.com.br/en/guides)