Firewall Port Tester
Test if your firewall configuration allows or blocks specific ports from different geographic locations.
About Port Checker
Test if specific TCP ports are open and accessible from multiple global locations. Check common ports like HTTP (80), HTTPS (443), SSH (22), and more.
Key Features
Multi-region port check
Common port presets
Single port verification
TCP connectivity test
Firewall testing
Firewall port testing verifies whether firewall rules are correctly allowing or blocking traffic to specific ports. Misconfigured firewalls are a leading cause of "it works locally but not from outside" issues—testing from external locations confirms your firewall behaves as expected.
Our multi-region firewall tester checks port accessibility from 6+ global locations, revealing inconsistencies in firewall rules, security groups, or ISP-level blocking. This is invaluable for validating cloud security group configurations, troubleshooting VPN access, and auditing server exposure.
For complete security validation, also run SSL checker on HTTPS ports and use traceroute to verify the network path if ports appear blocked.
**Methodology:** TCP connect from 6 external regions testing firewall pass-through, with clear open/closed/filtered status per region.
Common Errors & How to Fix Them
3 relevant issuesNo response received—a firewall is silently dropping packets to this port. The port may or may not have a service listening.
1) Check local firewall: ufw status, iptables -L -n. 2) For cloud: check security groups (AWS), firewall rules (GCP), NSG (Azure). 3) Check host-level firewall (Windows Firewall). 4) Verify ISP isn't blocking: test from different network. 5) Add firewall rule: ufw allow PORT/tcp.
The port actively refused the connection. Either no service is listening on this port, or it's configured to reject connections.
1) Verify service is running: systemctl status service-name. 2) Check service is on correct port: netstat -tlnp | grep PORT. 3) Ensure service binds to 0.0.0.0, not 127.0.0.1. 4) Check service configuration for listen address/port. 5) Restart service: systemctl restart service-name.
The connection attempt timed out. Server may be overloaded, port may be filtered, or there's network congestion.
1) Try with longer timeout: nc -vz -w 10 host port. 2) Check if server is overloaded: verify other services respond. 3) Test from different location to rule out network issues. 4) Check server resources: CPU, memory, connection limits. 5) Review firewall logs for dropped packets.
Frequently Asked Questions
4 relevant questionsCommon causes: 1) Firewall blocking the port (check iptables/ufw/Windows Firewall), 2) Service bound to localhost only (127.0.0.1) instead of 0.0.0.0, 3) Security group rules (AWS/cloud), 4) ISP blocking the port, 5) Service crashed after starting. Check with: netstat -tlnp | grep PORT or ss -tlnp | grep PORT.
"Open" means a service is listening and accepting connections. "Closed" means no service is listening—the port actively rejects connections. "Filtered" means a firewall is blocking access—no response is received. From a security perspective, filtered is better than closed, as it doesn't confirm the port exists.
A port might be accessible from one region but blocked from another due to: geo-restrictions, ISP-level blocking, cloud security groups configured per region, or CDN/proxy rules. Multi-region port checking reveals access inconsistencies and helps diagnose "works locally but not from X" issues.
Open ports themselves aren't insecure—the services behind them might be. Only expose necessary ports. Use firewalls to restrict access by IP when possible. Keep services updated to patch vulnerabilities. For admin services (SSH, databases), use non-default ports and require VPN/bastion access. Regularly audit which ports are open.
Related Tools
View All Tools →Related Tools
Global Infrastructure Verification
Verify SSL certificates, DNS records, and connectivity from 6+ regions worldwide. Get automated monitoring, expiry alerts, and full API access.