Port Checker
Use this port checker to confirm a TCP port is actually reachable from outside your network before you start debugging credentials, headers, or application logic. It tells you whether the port is listening and accessible, or whether a firewall, cloud security group, DNS misconfiguration, or private host is silently dropping the connection. Particularly useful for verifying proxy ports, API endpoints, dashboards, SSH bastions, and test services.
A port checker helps separate an application problem from a network problem. If the host responds but the port is closed, the cause may be a firewall rule, a service bound to the wrong interface, or an outdated tunnel configuration. Check the port before changing code, especially for proxies, admin panels, webhooks, and services running on non-standard ports.
Run the result against the exact browser, device, proxy protocol, and target country you plan to use in production. A clean result here is not a ranking promise, but it catches the configuration mistakes that usually create blocked sessions, wrong geo signals, DNS leaks, or inconsistent fingerprints.
For repeat workflows, record the visible IP, ASN, DNS route, latency, and warning state before and after each proxy change. That gives QA, scraping, SEO, ads, and account teams a comparable baseline instead of relying on a single one-off check.
When troubleshooting a blocked session or unexpected platform response, work through the stack in order: confirm the port is reachable, verify the exit IP and ASN, check DNS resolver, inspect request headers, and then compare browser fingerprint and timezone. Skipping layers leads to misdiagnosis — a timeout at the port level looks similar to a cookie checkpoint at the application layer but the fix is completely different.
Mobile proxy workflows behave differently from datacenter ones because CGNAT means multiple physical users share the same outbound IP range. Platforms treat these IPs with higher inherent trust, but that trust can erode if the same session triggers unusual behavior like very high request rates, mismatched timezones, or browser fingerprints that do not match a real mobile device. Use these diagnostic tools to verify the whole configuration, not just the IP.
Test whether public TCP ports are reachable from the open internet — not just from your own network.
Public hosts only
Private IPs, localhost, and RFC-1918 ranges are rejected. This prevents server-side request forgery (SSRF) abuse.
TCP reachability only
A successful TCP connect means the port is open and accepting connections — it does not mean the service behind it is healthy or that your credentials will work.
Debug proxy connections first
When a proxy connection fails, run the port checker before anything else. If the port is closed or timing out, there is nothing wrong with your auth — the port is simply unreachable.
Frequently asked questions
Open-port verification, firewall behavior, and what the result actually means.
What does a port checker do?+
It opens a TCP connection from a public internet host to the IP and port you specify, then reports whether the port accepted the connection, refused it, or timed out. Use it to verify a server is actually reachable from outside your network.
What's the difference between port checker and port scanner?+
A port checker tests one (or a few) ports you already know. A port scanner sweeps a range of ports trying to find which are open. Checker = answer one specific question; scanner = enumerate.
Why does my port show closed when my service is running?+
Three common causes: your router/firewall blocks inbound connections (no port forward), your ISP is on CGNAT and the public IP isn't yours, or the service binds to `127.0.0.1` instead of `0.0.0.0`. The checker connects to the public IP — it can't reach a local-only socket.
Can I check ports behind CGNAT or mobile carrier IP?+
Generally no. CGNAT (typical on mobile carriers and many ISPs) hides hundreds of users behind one IP, and inbound port forwarding is unavailable. Use a tunnel (Cloudflare Tunnel, Tailscale, ngrok) or a VPS with a public IP if you need inbound access.
Does it support TCP and UDP?+
TCP only. UDP "open vs closed" is unreliable from a single probe because UDP is connectionless — "no response" can mean the port is open or that the firewall silently dropped the packet. For UDP testing, send actual application traffic and look for an answer.
Are common proxy ports (1080, 3128, 8080) safe to expose?+
Exposing them is safe only if the service on the port enforces authentication and rate limits. An open SOCKS5 on 1080 with no auth becomes a public proxy in minutes — bots scan that range constantly. Always require user/password and consider IP whitelisting.
How do I open a port on my router?+
In your router admin: NAT/Port Forwarding → add a rule from external port X to internal IP:port of your machine. Set the firewall to allow inbound on port X. If you're on CGNAT this won't work — see the CGNAT question above.
Why are some ports always blocked by my ISP?+
Many residential ISPs block 25 (SMTP), 80, 443, 135, 139, 445, 3389 inbound to prevent open relays and spam. Business or static-IP plans usually don't. The checker shows these as filtered or closed even when the service is up.
Can I check ports on someone else's IP?+
Single-port reachability checks are normal — exactly what monitoring services and customers do every day. What is NOT okay is bulk scanning, brute-forcing services, or any probe intended to find vulnerabilities. Stay in single-shot territory.
What does "filtered" mean as a status?+
The probe got no answer at all — no SYN-ACK and no RST. Usually means a firewall is silently dropping packets. Different from "closed" (firewall sent a RST) or "open" (service answered with SYN-ACK).
Where does the port check originate from?+
From Proxy Poland servers, public Polish IPs. The IP your target sees is ours — useful when you want to verify your service is actually reachable from outside your own network and not just from inside it.
Can I expose a port for a Proxy Poland mobile proxy?+
Proxy Poland mobile proxies already expose HTTP and SOCKS5 ports — that's the product. You connect from your client to our public host:port. There is nothing to forward on your side.