There are in fact many tools which can help with this task, some of which will be familiar to those on *nix systems, but Windows users who've been around a while (or who learned from such folks) may try to rely on the good ol' telnet command (as in telnet [machine] [port]). Unfortunately, they often find out how Microsoft has disabled that tool by default for over a decade (since Windows Vista), and while it can be easily enabled, they may be prevented or understandably reluctant to do that.

In this post, I want to show a couple of command-line alternatives which can do the job easily, one best suited for powershell users (Test-NetConnection), and and two of which would suit those who prefer the command line (cmd) and which are now built-into Windows (the past few years): ssh and curl. No, this is not their primary job but they will suit for this task and it may surprise some to learn they're even built-in options. I'll conclude with still other options available to those on *nix environments (who of course can also use ssh and curl), especially nc (netcat).

Topics:

• Option 1) Powershell's nifty Test-NetConnection
• Yes, Windows has included ssh and curl for a few years!
• Option 2) Using curl to test connectivity to a port, including how the curl command responds if the port CANNOT or CAN be reached
• Option 3) Using ssh to test connectivity to a port, including how that command responds in those cases
• Using other cli tools on Linux, Unix, MacOS
• On understanding WHY the port being checked could not be reached

Option 1) Powershell's nifty Test-NetConnection

Update: this first section has been added since my original post. Thanks to Mark Gregory for his kind comment suggesting it.

If you're a powershell user (or are ok using it, even if you favor still using the traditional Windows CMD for the command line), there's a nice cmdlet that can do this task of testing a connection to a port, Test-NetConnection, as in:

Of course, machine can be an ip address, domain name, machine name, etc., and it need not be a machine other than yours: it can be your own.

So for instance, someone might test if their SQL Server was reachable on the machine "dbserver" at port 1433 using:

The UI of the tool will appear as it tries to connect, and regardless of its results, in the end it will report true or false, as in:

For some readers, that's really all you need to hear and you can stop. For those interested to learn more (who may want to propose other alternatives), please do read on.

What about the long delay if the port is NOT open

You may notice that this Test-NetConnection cmdlet will hang if the port on the machine trying to be reached is not available. That hang-time is as much about your a TCP timeout set at the OS level for your machine (from which you're running the test.) I discuss this more later with regard to curl and ssh (which offer options to override that timeout).

Sadly, at this writing, there's no option to override that timeout for Test-NetConnection. (Others have noticed and raised the concern. See this post for a couple of powershell approaches addressing this issue.)

Other ways do exist to test connectivity to such specific apps

Update: I previously had these few paragraphs in the next section, but I am moving them up to here because they're natural questions following the example I've offered, which I also use for the other variants below.

And yes, I'm well aware that there are other means by which one could test connectivity to something like SQL Server (or mysql or redis, etc.) from the commandline, using dedicated tools offered for each. The point of this post was to present approaches that works with ANY service whose port accessibility you're checking.

Finally, I'm also aware that there are other ways to find what ports are open on a given machine (port scanning tools) as well as whether and what ports are open on your machine, such as via good ol' netstat or UI tools like curports, to the more modern tool built into Windows (since Vista) called Resource Monitor. The focus here is again on a cli approach to test the accessibility of a port on any machine--versus finding if its one of many open ports, valuable though that info may be.

Anyway, moving on, for those who may still favor CMD (the command prompt) over powershell, you won't find it offering that nifty Test-NetConnection (though again you can call powershell commands from cmd). Instead, you may find some comfort in using curl or ssh, instead, which are covered in the remainder of this post.

Yes, Windows has included ssh and curl for a few years!

So as for ssh and curl, let me point out first some news which may have been missed by many (including those who try to help others or who write about IT matters). You don't NEED to "install putty" anymore: Windows has included ssh (an openssh client) for a few years, since later versions of Windows 10 and Server 2019. And the same is true of curl (a command-line browser).

If you want to confirm this, just open a Windows command prompt and type ssh (it should be found within your Windows path, and so should run), which will return brief help for the command. Same with curl!

Now granted, I realize that using curl or ssh to test the availability of a port (especially on another server) is not the real purpose of those tools--any more than it was the purpose of telnet. But the point is that these generally do "work" well, so they're tools to consider for one's arsenal. And again, I'll cover other tools that you may be able to obtain or find in some Linux distros (or MacOS or Unix) at the end of this post.

Considering also that you find either curl or ssh to suit you better for some situations, I will discuss them both. And I could have presented either one first. I offer curl first as some may be more comfortable with that, if they don't have much experience with ssh. Again the key point is that both these tools should be available to everyone reading this, unless they're on very old deployments of Windows.

Option 2) Using curl to test connectivity to a port

So let's look first at using curl to test if a port can be reached (though really, I'd recommend option 1 above or option 3 below, for reasons which will become clear):

Note there's a colon between the machine and the port. Again, machine could be an ip address, domain name, machine name, etc.

So for instance, someone might test if their SQL Server was reachable on the machine "dbserver" at port 1433 using:

So let's talk about what one may see depending on whether the connection via curl can or cannot be made. Of course, normally one uses curl to visit a given page on a given site, but again we're just "hacking" it to have it try to merely connect.

How the curl command responds if the port CANNOT be reached, and dealing with hang time

If somehow that machine (or ip address or domain name) cannot be reached, the request will hang (more on that in a moment) and then the curl command will respond with this error:

The key is that this tells us that that the port could not be reached. (As for "why not", neither curl nor ssh can help with that. I discuss that at the end.)

As for this "hang time" waiting to connect, this is something telnet did also. The amount of time it will wait is technically defined by your OS, and is known generically as the TCP timeout time. A difference with curl versus telnet is that you CAN control how long you're willing for the curl command to await using the command's optional connect-timeout flag, as in the following example to set a 1-second timeout:

Finally, if you find it does not stop trying to connect within the number of seconds indicated, do beware that the curl tool may be attempting different additional connections than you may realize. Add the -v arg to the command, to see more verbose output, including details of the connections it's attempting.

So that's how the tool can tell us (or be tweaked regarding) the failure to connect. Let's move on to what it may show if it CAN connect.

How the curl command responds if the port CAN be reached

Remembering that curl is first and foremost a command-line http client, if the connection is successful AND there's a web server on the other end (with a default web page to satisfy this request), the command will respond showing us the output of the page, whatever it is. :-) Or if it does not exist, it will perhaps show the content returned in the form of some sort of 404 error page. (And yes, there are ways to pipe its output to a file or the bit bucket, but I leave you to check out the docs for that.)

If instead the port being tested could be reached but it is NOT for a web server (which may be more common for folks seeking to "test a port's accessibility"), then the curl command will respond (immediately) with an error:

And given that our goal again is just to know if the port can be reached, there's value in getting that immediate error: the port CAN be reached.

(Another beneficial difference of this over the old telnet approach is that with that, a successful connection would show a blank screen if the connection, awaiting commands. You'd have to know telnet keystrokes and commands to break out of that, or you might close the terminal window if testing the port was your only reason for opening it.)

But maybe you feel itchy about using curl for this task. Well, if you can be persuaded, there is again the alternative of using ssh...

Option 3) Using ssh to test connectivity to a port

As for using ssh to test if a port can be reached, you could do something like this:

Again, machine could be an ip address, domain name, machine name, etc. (And those two values of machine and port are indeed the reverse order of both the curl above and the traditional telnet.)

How the ssh command responds if the port CANNOT be reached, and dealing with hang time

If the port CANNOT be reached, then (like with curl and telnet) the command will hang for an extended period of time before failing with an error like:

So with my example above, I'd receive this if SQL Server was not listening or inaccessible:

And as in the case of curl, if you want to override that long TCP timeout time for your OS, you can do that with the command's optional ConnectTimeout flag. The following to set a 1-second timeout:

(And as with curl, if you find it does not stop trying to connect within the number of seconds indicated, do beware that the ssh tool may be attempting different connections than you realize. add the -v arg to the command, to see more details of the connections it's attempting.)

Again, as for "why" it can't be reached, see the end of this port for ideas to consider.

How the ssh command responds if the port CAN be reached

If on the other hand the port CAN be reached, the ssh command will respond immediately, which is nice. And that's what makes this (like curl) indeed a helpful tool (.

That said, note that if the port you're checking is technically not an ssh port, the command will also report an "error":

In the case of using the command for this test of port connectivity, we can ignore that error. Again, at least this confirms that the port could be reached, which was our primary goal.

Using other cli tools on Linux, Unix, MacOS

Before wrapping up this post, I mentioned at the open how this this technique may appeal to Windows users more than those on *nix OS's, as they not only already have long had the two tools above, but they have still other tools they can use for this task of testing for whether a port can be reached, such as netcat/nc, which could handle this just as simply:

And as for port-scanning (the broader process of determining what ports are open on a given machine), there is the classic (and powerful) nmap command, but it's beyond the scope of this post (as its related tool ncat, which is not the same as netcat above).

On understanding WHY the port being checked could not be reached

Finally, I realize some may wonder how to know WHY a port can't be reached, but neither of these tools can help with that: they merely respond one way if the port CAN be reached and another if it cannot.

As I noted at the opening, the reach a port may not be open is that the service you're trying to reach is not enabled. Or maybe there's a firewall blocking access to it (which blocking could be specific to your machine from you are attempting to make the connection). There may be a firewall in the OS of the machine you're talking to, or one that's been installed there as software, or there may be one on the network you're connecting to, etc.

Or you may simply have the wrong value for the port you are testing, or the ip address, domain name, machine name, etc.

Before we wrap up, note that sometimes you may find that a given machine can be identified any of many different ways--such that a port may be "open" to you if you try a way that's different from what you're trying (so try an ip address if you have a domain name, or vice-versa, or perhaps try a subdomain if you know of one, and so on).

Often, you will need to get on the server itself (which you can't reach) and attempt these or other tools THERE, to find out if the port is correct in the first place.

Conclusion

I hope I've helped you see how curl and ssh (and nc) can be handy tools to have in your arsenal, when you just want to quickly test port accessibility from the commandline. For those on Windows, you can stop trying to install telnet to do a quick port test: just use curl or ssh! :-) That was really the primary motivation of my post here.

And let me know how it goes.

Indeed, this is one of those topics where there may be dark corners, edge cases, and unexpected situations where results differ. I'm sure some people have more experience to share, whether other gotchas or tips, or still other tools that may be built-in to Windows or *nix. As for other tools one might obtain, those are less interesting as again the post here is about built-in tools, because often people are working in environments (especially on servers or containers) where they're not necessarily free to/wanting to install software.

As always I welcome comments.

For more content like this from Charlie Arehart:

• Signup to get his blog posts by email:
• Follow his blog RSS feed
• View the rest of his blog posts
• View his blog posts on the Adobe CF portal

Need more help with problems?

• If you may prefer direct help, rather than digging around here/elsewhere or via comments, he can help via his online consulting services
• See that page for more on how he can help a) over the web, safely and securely, b) usually very quickly, c) teaching you along the way, and d) with satisfaction guaranteed