Port Check – Complete Guide to Testing Open TCP Ports from the Internet

You have set up port forwarding for a game server, opened a firewall rule for SSH, or moved a mail server, and the question is the same each time: can someone on the internet actually connect? Testing from inside your own network does not answer that, because those connections never cross your router or perimeter firewall the way outside traffic does.

The NetTools.tech Port Check answers it for a single TCP port. Our server tries to open a TCP connection to the host and port you enter and tells you whether it was accepted, refused or silently dropped.

What is a port check?

In simple terms

A port is a numbered door on a computer. A web server waits behind door 443, SSH behind door 22, a mail server behind door 25. A port check knocks on one door from the outside: if someone opens it, the port is open; if the computer says "nobody here", it is closed; if nothing happens at all, something in front of it, usually a firewall, ignores the knock.

Technical background

TCP connections start with the three-way handshake described in the TCP specification (RFC 9293): the client sends a SYN, the server answers with SYN-ACK, and the client confirms with ACK. The answer to the first SYN reveals the port's state:

• SYN-ACK — a process is listening and the connection is accepted: open.
• RST (reset) — the host is reachable but nothing listens on the port: closed. Operating systems report this as "connection refused".
• No answer — the SYN or the reply was dropped, typically by a firewall configured to drop rather than reject: filtered.
• ICMP unreachable — a router or the host reports that the network or host cannot be reached, which is also treated as filtered.

Port numbers are assigned by IANA in the Service Name and Transport Protocol Port Number Registry, but nothing forces a service to use its registered port.

Why use a port check?

• Verify port forwarding. Confirm that the NAT rule on your router actually delivers outside connections to the internal server.
• Validate firewall changes. After opening or closing a rule, see the result from outside.
• Separate network from application problems. If the port is open but the application fails, the network is not the problem.
• Check exposure. Confirm that a port you meant to close, such as RDP 3389, really is no longer reachable.
• Work around ICMP filtering. When Ping gets no reply, a TCP check on a service port shows whether the host is actually up.

Who should use it?

• System administrators opening services to the internet or locking them down.
• Home users and gamers setting up port forwarding for game servers, cameras or NAS devices.
• Network and firewall engineers verifying rule changes from outside.
• Support teams confirming whether a customer's service is reachable before digging into the application.

How port check works

1. Validation. You enter a Host (hostname or public IP address) and a Port (a number from 1 to 65535). A pasted URL is reduced to its host name.
2. Resolution and address check on the server. The hostname is resolved on the NetTools server. If any resolved address is private, loopback, link-local or reserved, the request is refused. Names with an IPv4 address are tested over IPv4; IPv6 targets are refused because the probe server has no IPv6 connectivity yet.
3. One connection attempt. The server opens exactly one TCP connection to the resolved IP and port, with a 5-second timeout, and closes it immediately. No data is sent to the service.
4. Classification:
   • connection established → open, with the connect time in milliseconds;
   • connection refused → closed, with the time until the refusal;
   • no answer within 5 seconds → filtered;
   • host or network unreachable → filtered, with the error code;
   • any other socket error → error, with the error code.
5. Limits. One port per request, no ranges. Each target address can be checked at most 20 times per 10 minutes across all users, and each client has its own request budget.

The connection comes from the NetTools.tech server in Latvia. It is equivalent to a single nc -vz -w 5 203.0.113.10 443 from that server.

How to use the NetTools.tech port check

1. Open Port Check.
2. Enter the Host, for example example.com or a public IP address. Enter only the host here, not host:port.
3. Enter the Port, for example 443. Example chips under the form fill common ports such as 443, 80, 22, 25 and 3389.
4. Select Run Port Check. The answer arrives within about 5 seconds at most.
5. Use Copy to paste the result into a ticket.

In the web terminal the same check is /portcheck example.com 443 (alias /port).

Understanding the results

The result is one status line and one explanatory sentence.

"Filtered" does not distinguish between a firewall dropping packets and a host that is completely offline. Both look the same from outside.

Example: debugging port forwarding for a home server

A user runs a web server on a NAS at home on port 8443 and has forwarded TCP 8443 on the router. Values are illustrative.

First check, Host home.example.net, Port 8443:

home.example.net (203.0.113.45) port 8443: FILTERED "No answer within 5 s: a firewall is probably dropping the connection."

The resolved IP 203.0.113.45 matches the router's WAN address shown by What Is My IP, so DNS is fine. The user finds that the forwarding rule pointed at the NAS's old internal address. After fixing it:

home.example.net (203.0.113.45) port 8443: OPEN · 31 ms "The TCP connection was accepted."

If the WAN address had been in the 100.64.0.0/10 range or different from the public IP, the connection would sit behind carrier-grade NAT, and port forwarding on the home router could not work at all.

Common use cases

• Checking that HTTPS (443) or HTTP (80) is reachable after deploying a web server.
• Confirming that SSH (22) is reachable, or deliberately not reachable, from the internet.
• Testing SMTP port 25 on a mail server; many residential and cloud networks block it.
• Verifying port forwarding for game servers, VPN endpoints, cameras or NAS devices.
• Proving that a port you closed, such as 3389, no longer accepts connections.

Troubleshooting

Filtered, but the service runs

Work from the outside in: is the DNS name pointing at the right public IP? Does the cloud security group, host firewall (iptables, nftables, Windows Defender Firewall) or perimeter firewall allow the port from any source? For home connections, does the router forward the port to the correct internal IP, and is the device's address fixed?

Closed, but the service runs

The host is reachable and answers, but nothing listens on that port. Check the listen address with ss -ltnp (Linux) or netstat -ano (Windows). A service bound to 127.0.0.1 or to a different port shows as closed. Some firewalls also send resets on purpose, which looks the same.

Open from inside, filtered from here

Your test from inside did not cross the router's WAN side. Check NAT loopback assumptions, firewall rules that allow only certain source addresses, and whether your ISP uses carrier-grade NAT. Compare your router's WAN IP with the address shown by What Is My IP.

Port 25 is always filtered

Many ISPs and cloud providers block outbound and sometimes inbound TCP 25. This is a provider policy, not a fault in your server. Mail submission for clients usually runs on 587 or 465 instead.

"resolves to a private or reserved address"

The DNS name points at an internal address. The tool refuses such targets. Check your public DNS records with DNS Lookup.

"This target has been tested many times"

The target has had 20 port checks in the last 10 minutes. Wait a few minutes, or use the Port Scanner & Firewall Test for several ports on your own IP or a verified server.

Common mistakes

• Typing host:port in the host field. Use the separate Port field; the host field only accepts a hostname or IP.
• Testing your own public IP from inside your network and trusting the result. The NetTools check is the outside view.
• Reading "open" as "the application works". It only proves the TCP handshake.
• Assuming filtered means offline. It usually means a firewall drop.
• Expecting UDP results. Only TCP is checked.

Limitations

• TCP only; UDP services such as DNS over UDP, WireGuard or many game protocols cannot be checked.
• One port per request and at most 20 checks per target per 10 minutes; it is not a scanner.
• One vantage point: the NetTools.tech server in Latvia. Firewalls that allow or block by source region or address can show different results to other users.
• IPv4 only for now.
• Filtered cannot distinguish a dropping firewall from a host that is down.
• No data is exchanged with the service, so banners, TLS and application behavior are not tested.

Security & privacy

• What is sent: the host and the port. The connection attempt comes from the NetTools server; the target sees our address and a connection that is closed immediately.
• Scope: private, loopback, link-local and reserved addresses are refused, including names that resolve to them.
• No scanning: one port per request, per-target and per-client limits.
• Responsible use: only check hosts you operate or are allowed to test.
• What not to enter: nothing sensitive is required.

Related tools

• Port Scanner & Firewall Test — scans a fixed set of ports on your own IP or a DNS-verified server. Guide: port scanner guide.
• Ping — ICMP reachability when you want to know whether the host answers at all. Guide: Ping guide.
• SSL Certificate Checker — checks the certificate and TLS on an open HTTPS or mail port. Guide: SSL checker guide.
• What Is My IP — your public address for comparing with the router's WAN IP. Guide: what is my IP guide.
• Traceroute — where the path ends when a port is filtered.
• Category overview: Network diagnostics guide.

Summary

A port check attempts one TCP connection and reports open (handshake completed), closed (connection refused) or filtered (no answer within 5 seconds or unreachable). The NetTools.tech check runs from our server in Latvia, tests one port per request on public IPv4 targets and is limited per target. Use it to verify port forwarding and firewall rules from the outside, and follow up with an application-level check when the port is open.

Frequently asked questions

Why does my port show as closed when the service is running?

Closed means the host answered but nothing accepted the connection on that port. Check that the service listens on a public interface or 0.0.0.0 rather than only on 127.0.0.1, that it uses the port you think, and that port forwarding points at the right internal address.

What is the difference between closed and filtered?

Closed means the host actively refused the connection with a TCP reset, so it is reachable but nothing listens there. Filtered means no answer arrived within 5 seconds or the network was unreachable, which usually means a firewall silently drops the packets.

Can I check UDP ports?

No. UDP is connectionless, so an open UDP port cannot be confirmed reliably without a protocol-specific reply. The NetTools.tech port check tests TCP only.

Can I check several ports at once?

No. Each request checks exactly one TCP port, and each target address can be checked at most 20 times per 10 minutes across all users. To test a set of ports on your own IP or a verified server, use the Port Scanner & Firewall Test.

Why does the port look open from my network but filtered here?

A test from inside your network never crosses your router from the outside, and some firewalls allow local or specific source addresses only. The NetTools.tech check connects from our server on the internet, which is the view outside users have.

Does an open port mean my service works?

It means a TCP handshake completed, nothing more. The application may still reject the request, require TLS or be misconfigured; check HTTPS services with the SSL certificate checker or an HTTP status check.