TCP & UDP Port Checker
Check TCP and UDP port reachability and status. Test if specific ports are open, closed, or filtered on remote hosts.
Test TCP and UDP port connectivity to verify firewall rules, troubleshoot network issues, and check service availability. Our comprehensive port checker helps network administrators, developers, and security professionals ensure proper network configuration.
Common Ports
What is a Port Checker?
A port checker is a network diagnostic tool that tests whether specific TCP or UDP ports on a remote host are accessible (open), blocked (closed), or filtered by a firewall. Ports are numbered endpoints used by network applications to send and receive data, ranging from 0 to 65535.
Port checking is essential for troubleshooting network connectivity issues, verifying firewall configurations, ensuring proper port forwarding setup, and conducting security audits to identify potentially vulnerable services.
TCP vs UDP: Understanding the Difference
TCP (Transmission Control Protocol)
- Connection-oriented: Establishes a connection before data transfer
- Reliable: Guarantees delivery and order of packets
- Error checking: Includes acknowledgments and retransmission
- Common uses: Web (HTTP/HTTPS), email (SMTP, IMAP), file transfer (FTP), SSH
- Testing method: Attempts to establish a three-way handshake
UDP (User Datagram Protocol)
- Connectionless: Sends data without establishing a connection
- Best-effort: No guarantee of delivery or order
- Faster: Lower overhead, suitable for real-time applications
- Common uses: DNS, streaming media, VoIP, online gaming, VPN
- Testing method: Sends probe packet and waits for ICMP response
How to Use the Port Checker
- Enter target host: Type the IP address or domain name of the server you want to test (e.g., example.com or 192.168.1.1)
- Enter port number: Specify the port number you want to check (1-65535) or select from common ports
- Select protocol: Choose TCP or UDP depending on the service you're testing
- Run the test: Click "Check Port" to initiate the connectivity test
- Review results: The tool will display whether the port is open, closed, or filtered
- Test multiple ports: Repeat the process for different ports or use batch scanning if available
Common Ports and Services Reference
| Port | Protocol | Service | Description |
|---|---|---|---|
| 80 | TCP | HTTP | Web traffic (unencrypted) |
| 443 | TCP | HTTPS | Secure web traffic (SSL/TLS) |
| 22 | TCP | SSH | Secure shell remote access |
| 21 | TCP | FTP | File transfer protocol |
| 25 | TCP | SMTP | Email sending |
| 53 | UDP/TCP | DNS | Domain name system |
| 3306 | TCP | MySQL | MySQL database |
| 3389 | TCP | RDP | Remote desktop protocol |
| 1194 | UDP | OpenVPN | VPN connections |
| 5060 | UDP/TCP | SIP | VoIP signaling |
Understanding Port Status Results
✅ Open/Accessible
The port is reachable and a service is listening on it.
- TCP: Successfully completed three-way handshake (SYN → SYN-ACK → ACK)
- UDP: Service responded or no ICMP "port unreachable" received
- Meaning: Service is running and accepting connections
- Use case: Normal operation for intended services (e.g., port 80 for web server)
❌ Closed
The port is reachable but no service is listening on it.
- TCP: Received RST (reset) packet in response to connection attempt
- UDP: Received ICMP "port unreachable" message
- Meaning: Host is reachable but service is not running on this port
- Troubleshooting: Start the service or check if it's running on a different port
🚫 Filtered
The port is blocked by a firewall or security device.
- TCP: No response to SYN packet (connection timeout)
- UDP: No response and no ICMP message (packets dropped)
- Meaning: Firewall or router is blocking access to the port
- Troubleshooting: Check firewall rules, NAT configuration, or ISP restrictions
❓ Timeout/Unknown
Unable to determine port status due to network issues.
- Possible causes: Network congestion, packet loss, or extremely slow response
- UDP specific: Common for UDP since it doesn't guarantee responses
- Troubleshooting: Retry the test, check network connectivity, or test with TCP instead
Common Use Cases for Port Checking
🔧 Network Troubleshooting
- Diagnose connectivity issues
- Verify service availability
- Test after configuration changes
- Identify network bottlenecks
🛡️ Security Auditing
- Identify open ports
- Detect unauthorized services
- Verify firewall effectiveness
- Assess attack surface
⚙️ Server Configuration
- Verify port forwarding setup
- Test NAT configuration
- Confirm service deployment
- Validate load balancer rules
🎮 Gaming & VoIP
- Check game server ports
- Verify VoIP connectivity
- Test P2P connections
- Troubleshoot NAT issues
Troubleshooting Common Port Issues
Port Shows as Filtered or Closed
- Check firewall rules: Ensure the port is allowed in your firewall (Windows Firewall, iptables, UFW, etc.)
- Verify service is running: Confirm the application/service is actually listening on that port
- Review router configuration: Check port forwarding rules in your router's admin panel
- ISP restrictions: Some ISPs block common ports like 25, 80, 443; contact them if needed
- Cloud security groups: If using cloud hosting (AWS, Azure, GCP), check security group rules
- Binding address: Ensure service is listening on 0.0.0.0 (all interfaces) not just 127.0.0.1 (localhost)
UDP Port Testing is Unreliable
UDP is inherently connectionless and doesn't send acknowledgments, making it difficult to determine if a port is truly open:
- Lack of response doesn't necessarily mean the port is closed
- Many UDP services don't respond to arbitrary probes
- Use application-specific tools when possible (e.g., dig for DNS, nslookup)
- Consider testing from multiple locations to rule out network issues
Testing from Inside vs Outside Your Network
Remember that results may differ based on where you test from:
- Local network: Tests from inside bypass external firewall/NAT rules
- External testing: Tests from the internet show real public accessibility
- Loopback (127.0.0.1): Only tests if service is running, not network accessibility
- Best practice: Test both internally and externally for complete validation
Frequently Asked Questions
What's the difference between a port scanner and a port checker?
A port checker tests individual specified ports one at a time, while a port scanner automatically tests multiple or all ports in a range (e.g., scanning ports 1-1024). Port checkers are typically used for specific troubleshooting, whereas port scanners are used for comprehensive security audits and discovery.
Is port scanning legal?
Scanning your own systems or systems you have explicit permission to test is legal and often part of routine security maintenance. However, scanning systems without authorization may be illegal in many jurisdictions and could be considered unauthorized access or reconnaissance for an attack. Always obtain proper authorization before scanning third-party networks.
Why do some ports show as "filtered" instead of "closed"?
"Filtered" means a firewall, router, or security device is actively blocking or dropping packets to that port without sending a rejection response. "Closed" means the port is reachable but no service is listening. Firewalls often filter ports to avoid revealing information about the network structure to potential attackers (security through obscurity).
Can I test ports on any domain or IP address?
Technically yes, but ethically and legally you should only test systems you own or have explicit permission to test. Many organizations consider unauthorized port scanning as hostile reconnaissance and it may trigger security alerts or be reported to law enforcement.
Why might port 80 be open but my website isn't accessible?
An open port only means something is listening on that port, not that it's functioning correctly. Your web server process might be crashed or misconfigured, there could be DNS issues preventing your domain from resolving to the correct IP, the web server might be configured to only serve certain virtual hosts, or there might be proxy/load balancer issues between the port and your application.
What's the difference between well-known, registered, and dynamic ports?
Well-known ports (0-1023) are reserved for common services like HTTP (80), HTTPS (443), and SSH (22), requiring root/admin privileges. Registered ports (1024-49151) are assigned to specific services by IANA. Dynamic/private ports (49152-65535) are used for temporary or private services and often assigned automatically by the OS for client-side connections.
How long should a port check take?
TCP port checks are usually very fast (< 1 second) because they either get an immediate connection or rejection. UDP checks can take longer (10-30 seconds) because they rely on timeout to determine if a port is filtered. If a check is taking unusually long, it often indicates network congestion, high latency, or aggressive rate limiting by intermediate firewalls.
Can firewalls detect that I'm checking ports?
Yes, most modern firewalls and intrusion detection systems (IDS) can detect port scanning activity, especially if you're checking multiple ports rapidly. They may log your IP address, temporarily block your connection, or alert administrators. Single port checks are usually less conspicuous than full port scans.
Why does my port show as open locally but closed externally?
This typically means your router's NAT or firewall is blocking incoming connections from the internet. You may need to configure port forwarding on your router to map external requests to your internal IP address. Also ensure your service is bound to all interfaces (0.0.0.0) and not just localhost (127.0.0.1), and check that your ISP isn't blocking the port.
What should I do if I find unexpected open ports?
First, identify what service is using the port using commands like `netstat -tuln` (Linux) or `netstat -ano` (Windows). If it's a legitimate service you don't need exposed, close the port in your firewall. If it's an unknown or suspicious service, it could indicate malware or unauthorized access—run antivirus scans and review recent system changes. For servers, close unnecessary ports following the principle of least privilege.
Security Considerations
⚠️ Important Security Notes
- Minimize open ports: Only expose ports that are absolutely necessary for your services
- Use firewalls: Implement both host-based and network-based firewalls
- Regular audits: Periodically scan your own systems to identify unexpected open ports
- Stay updated: Keep services running on open ports updated with security patches
- Use non-standard ports: Consider running services on non-default ports to reduce automated attacks
- Implement authentication: Don't rely solely on port filtering; use strong authentication
- Monitor logs: Regularly review logs for unusual connection attempts
- VPN for sensitive services: Use VPNs to access sensitive ports instead of exposing them publicly