MyIP.dogChecking…
Port checker
Check one TCP port or a fixed preset from our server. See connection success, refusal, timeout and probe restrictions.
Checking…
Check one TCP port or a fixed preset from our server. See connection success, refusal, timeout and probe restrictions.
Checking…
Checking…
TCP checks run from our server. No application data is sent. Only test authorized destinations; targets may log connections.
Use my IP contacts ipify and fills the target without starting a port check. One port per check; five-second connection deadline. Shared limits apply.
No port check has started.
This port checker attempts TCP connections from the site server to a public address. Choose Single port for one service or Fixed preset for a small, explicit list. Enter the destination, choose the address family, provide a whole port number from 1 to 65535, and start the check. A result describes that particular connection attempt. It does not enumerate every open service, measure your browser's route, or certify that the application behind a reachable port works correctly.
Begin with a service you intend to reach, such as your own web server or an authorized remote-access endpoint. The port checker needs the public destination and externally reachable port, which may differ from a private device's address and listening port. Keep the target service running during the check. A forwarding rule does not itself create a listening application, and a running application can still be blocked elsewhere on the path.
Use a public IPv4 or IPv6 address, or an ordinary public hostname. Do not paste a full URL, a path, or an address with a port appended. The port checker takes a single port in its separate field or shows every port in the chosen preset. Private, loopback, link-local, shared-address, documentation, and other unsupported special-use targets are rejected. This remote server cannot use your household's 192.168.1.1 address to identify your particular router.
For a hostname, the port checker queries Google Public DNS for the selected A or AAAA family. It follows the relevant alias chain, validates the matching addresses, and pins the connection attempt to one public address. The result shows the entered name and actual tested address. Your browser or another resolver might choose a different destination, so keep this distinction when comparing a successful website visit with a failed diagnostic.
The example control fills a public resolver address and TCP port 443 without making a connection. “Use my IP” asks ipify for the public address observed from this browser and fills the target and family. Neither control starts the port checker automatically. If you use a VPN or proxy, the detected address may belong to that exit instead of a server or router you control. Review the value before submitting.
Single port mode in the port checker accepts one integer port. Fixed preset mode offers four web ports or six common ports; arbitrary lists and ranges are not accepted. A familiar port number is a convention, not proof of the running application. TCP port 443 is commonly associated with HTTPS, but this tool does not perform a TLS handshake or request a web page. Check your service configuration to find the intended port, including any public-to-private port translation at the router.
Select IPv4 for an IPv4 literal and IPv6 for an IPv6 literal. For a hostname, the selection determines which DNS record family is considered. The port checker does not silently fall back to the other family. A site with working IPv4 can still have an unavailable IPv6 path, or the reverse. Compare the exact address and family actually used by the application experiencing the problem.
The web preset contains TCP ports 80, 443, 8080, and 8443. The common preset contains 22, 25, 80, 443, 3389, and 8080. These names summarize conventional uses, not detected applications. The port checker displays the complete list before submission. It checks one port at a time, reusing one validated public address selected at the start, so DNS rotation cannot silently change the destination between rows.
Each received row has its own outcome, duration, and observation time. While a connection is pending, the port checker labels that row as checking; later rows remain not tested. A complete report requires all preset rows and the server's completion confirmation. A dropped stream, exhausted budget, or stopped request leaves a partial report. Missing evidence never becomes a closed-port result, even if another row timed out or was refused.
The whole preset has a thirty-five-second server budget, including resolution. Each TCP attempt still has its five-second deadline. The port checker performs no automatic retry and shares its connection allowance with single-port mode. Changing modes starts a fresh workbench and stops local waiting. Copy report preserves received rows and lists every port without a result, which helps a colleague distinguish a finished preset from an interrupted observation.
After validation, the server initiates one TCP connection attempt per selected port and closes each socket when it obtains an outcome or reaches its deadline. The port checker sends no application payload, authentication attempt, service-identification request, or HTTP request to the target. TCP itself can retransmit connection packets during the attempt, so one connection attempt should not be described as exactly one network packet.
The destination and intervening infrastructure can observe the connection. Hostname resolution also discloses the name to Google Public DNS. Run the port checker only for a service you are authorized to diagnose. The tool's result remains in the page until cleared or the page is left, and copying is an explicit action. Target requests and network infrastructure may have their own logging behavior; a cleared browser display cannot erase their records.
The result keeps the entered target, tested address, TCP port, source, timestamp, resolution method, and connection-attempt duration together. The port checker origin is the server handling the request, not your browser. Its precise network location is not measured. Probe details expose the runtime and a limited diagnostic code to help explain operational restrictions without presenting private server-interface information as your own address.
“TCP connection established” means the probe completed TCP connection establishment at that address and port, then closed the connection. This is the positive observation an open-port check can supply. The port checker does not establish the identity of the application, the validity of a certificate, a successful login, or whether a load balancer can reach all of its backends. Those require tests at the relevant application layer.
A successful port checker result is scoped to its origin and time. Your device may face a different firewall rule, routing path, or address selection. A service might deliberately allow one source network and reject another. Include the probe scope when seeking help instead of treating one successful connection as proof that every user worldwide can reach the service through the same public address.
“Connection refused” records an active refusal returned during the attempt. A service, host, or intervening policy can be involved. The port checker keeps refusal separate from a timeout because they provide different evidence. Check whether the intended application is listening on the correct interface and port, and review narrowly relevant firewall or forwarding rules. Do not assume that the refusal identifies a particular device as the cause.
The connection deadline is five seconds. If no connection completes in that interval, the port checker reports the timeout rather than inventing an open or closed state. Filtering, dropped packets, routing problems, a missing service, and temporary network conditions can produce similar observations. The duration of a timeout is not an estimate of normal service latency, and extending a wait would not automatically reveal its cause.
An unreachable result indicates an unreachable condition on the probe's path. It may concern the destination network, the selected family, or the probe's connectivity. The port checker cannot generalize that condition to all networks. Preserve the diagnostic code and address family, then compare with the affected application's own connection behavior. Repeated checks without a specific hypothesis often add little useful evidence.
The server's hosting environment can restrict outgoing connections. Cloudflare Workers, for example, documents restrictions involving Cloudflare destination ranges, loopback connections, and SMTP port 25. When the runtime supplies a recognized restriction, the port checker reports it separately. We do not replace the TCP attempt with an HTTP fetch, because that would answer a different question while hiding a change in the measurement method.
Other unexpected failures remain “Port state not established.” A port checker that cannot perform its own operation has not demonstrated that the target is closed. If the service is busy or a request limit is reached, wait before another attempt. The interface does not automatically retry a submission, and the application limits repeated checks of the same address and port to reduce redundant connections.
Port checker limits when troubleshooting incoming access
A port checker answers a narrow reachability question. For a service hosted behind a home router, trace the intended setup from the application outward: its listening interface, device firewall, router mapping, public address, and upstream network. A problem at any of these layers can prevent an external connection. Keep records of deliberate changes so a later result can be associated with the condition you actually changed.
Ordinary NAT can require a public port mapping to the correct private device and port. A successful local connection does not test that external mapping. The port checker offers an outside observation, but it cannot inspect the router configuration. Read the port forwarding guide for the distinction between local listening, router translation, firewalls, and a provider-controlled upstream boundary.
With carrier-grade NAT, the public IPv4 address may be shared and the subscriber may not control inbound mappings at the provider's gateway. A port checker result at that shared address therefore does not automatically describe a service on your device. Compare the router's assigned WAN address with an external observation and use the CGNAT guide to interpret the difference. Do not infer subscriber identity from a public address.
IPv6 changes the addressing model but does not remove firewall policy. A globally routed IPv6 address still needs the intended service and an appropriate inbound rule. The port checker tests only the address entered or selected from DNS. Temporary device addresses, changed prefixes, and stale AAAA records can make a previously saved target irrelevant. Verify the current destination rather than opening broad rules to compensate for an incorrect address.
Connection-attempt duration is measured around the server's TCP attempt. It excludes your browser's full page load and is not a bandwidth result, an ICMP round-trip average, or a guarantee of future response times. The port checker preserves a measured zero if the timer reports one and labels an unperformed measurement as not measured. Precision in the displayed number does not imply precise knowledge of every link along the route.
Use the ping test for a short set of remote diagnostic replies and online traceroute for reported route-hop observations. Neither replaces the port checker when the question concerns TCP connection establishment to a particular port. Likewise, success on a single TCP port does not demonstrate that UDP traffic, another port, or another address family follows the same working path.
Stop waiting cancels local waiting for the result. The server also closes its socket when an abort reaches it, but a disconnected browser does not guarantee immediate cancellation at every hosting layer. An attempt already started can continue until its own deadline. The port checker explains that uncertainty instead of claiming that no packet was sent. A stopped request without a returned result establishes no new port state.
Clear result removes the displayed observation and prevents a late response from restoring it. It leaves the typed form available for review. Leaving the page resets the port checker workbench, and its page lifecycle handling clears a captured result and input. Copy report exports the currently displayed evidence, including its origin and limitations. Review targets and network information before placing that report into a public issue or forum.
No. This port checker tests TCP connection establishment. UDP does not provide the same connection handshake, and interpreting no UDP response requires an appropriate protocol-specific exchange and context. A successful TCP check of port 53 or 443 says nothing conclusive about the corresponding UDP service. Use the transport your application actually requires when planning further diagnostics.
No. The port checker observes an attempted connection and does not change firewall, router, provider, or application settings. A reachable port also does not automatically mean a configuration is desirable or secure. Decide which service needs to be available and to whom, then change the appropriate configuration deliberately. Avoid exposing unrelated services simply to make a diagnostic return a positive result.
First compare the exact target address, family, TCP port, source network, and time. A hostname can resolve to several destinations, and source-specific rules can produce different answers. Another port checker may use a different timeout or probing method. Preserve the tested literal and outcome wording so you can distinguish a refusal from a timeout instead of comparing two unexplained red badges.
Use Copy report and add the actual symptom, expected service, affected client network, and relevant time. State that the port checker ran from a remote server. Keep a timeout or environment restriction labeled accurately, and avoid presenting it as a confirmed closed port. The most useful report connects a precisely scoped observation with a reproducible problem and the next configuration or application check.
The protocol reference is TCP in RFC 9293, and common service associations are documented by IANA's port registry. The server adapter follows the Node.js socket API; Cloudflare hosting follows its TCP socket restrictions. Hostname selection uses Google Public DNS. Our methodology explains how the port checker keeps direct observations separate from broader conclusions.