redzilla
All tools

IP Addressing

Layer 2

Cabling

Performance

Wireless

CCTV

Optical fiber

Power

Datacenter

AV

Voice

Diagnostics

Calculation

Security

Diagnostics

Port Checker

Check whether your TCP/UDP ports are open from the internet — ideal for validating firewall rules and port forwarding.

Port Checker in progress
in progress

This tool will be available very soon: it needs a service that tests ports over TCP, and we are setting it up.

Admin: enable it by deploying backend/port-check/ and setting site.portCheckApi in config.js.

The port check uses our own backend · the rest of the site runs locally.

How it works

The tester checks whether one or several ports (up to 16 per query, comma-separated) are open, closed or filtered on a host or IP, as seen from the internet. Since a browser cannot open arbitrary TCP connections, the test is performed by a redzilla backend: it is the same perspective any external client would have, which is exactly what matters when validating firewall rules and port forwarding (NAT).

For TCP the result distinguishes three states: open (the service accepted the connection), closed (the host replied with a rejection) and filtered (no answer within the timeout, typical of a firewall silently dropping packets). For UDP the test is best-effort: with no connection handshake, the lack of a reply is reported as open|filtered. It also shows the latency of each attempt and the usual service on the port (22 ssh, 443 https, 3389 rdp, etc.).

Example: verifying a port forward for remote access

  1. You configured a router forward of port 3389 (RDP) to an internal machine and want to confirm it works.
  2. Enter your domain or public IP, port 3389 over TCP, and press Check.
  3. If it shows open, the rule works; if it shows filtered, the firewall or the ISP is dropping the traffic; if it shows closed, the forward reaches the machine but no service is listening there.

Frequently asked questions

What is the difference between a closed port and a filtered port?
Closed means the host replied by rejecting the connection (a TCP RST): the path works but no service is listening. Filtered means there was no answer at all within the timeout: usually a firewall silently dropping packets. For diagnosing firewall rules, that distinction is key.
Why does the port show closed from the internet if the service works on my local network?
Because the test runs from outside: if the service answers on the LAN but not from the internet, the router is missing the port forward, the firewall blocks it, or your ISP uses CG-NAT and you do not have your own public IP. Testing from inside the same LAN does not validate external access.
Why does UDP report open|filtered instead of open?
UDP has no connection setup, so an open port that stays quiet and a firewall dropping the packet look identical: silence. That is why the honest answer is open|filtered. Closed can only be asserted when the host returns an ICMP port-unreachable error.
Can I scan any server with this tool?
No. The tool is meant for hosts and services you own or are expressly authorized to test, for example to verify your own firewall rules. Scanning third-party ports without permission can violate terms of service and local laws. The query is sent to the redzilla backend, which runs the test and returns the result.
Was this tool useful?
Disclaimer We take great care to keep every tool accurate and review it thoroughly; even so, we can't guarantee it is free of errors or take responsibility for how the results are used. We recommend double-checking anything critical.
Found an error? Let us know →