Why does Test-NetConnection indicate connection can be made, but I cannot visit the site?

I need to determine whether a particular site is accessible on a particular port, given that firewall restrictions exist on the network.

If I cannot access the site on a particular port, then that means I would need to modify the firewall before proceeding. Otherwise, if I can reach the site, then I would be able to proceed with what I intend to do.

I wanted to know whether I could fetch a repository from Github using the repo's https URL. An example https URL : https://github.com/git-for-windows/git.git. This can be used with clone and other tools.

To see whether I could reach Github and by extension, clone the repo, I ran the following command: Test-NetConnection -ComputerName github.com -Port 443 |findstr "TcpTestSucceeded"

On the system, this command returned the following, indicating that I was able to reach github.com over port 443 (https).

TcpTestSucceeded : True

However, I then opened up a web browser, and visited https://github.com, and the web browser indicated that a connection could not be made. https is over port 443 and the domain is github.com just like what I put in the test.

My questions are:

• Why is there this discrepancy between the two tests?
• How can I accurately test over CMD or PowerShell whether I have access to a particular domain over a particular port?

Clearly, the Test-NetConnection command did not produce accurate results, as the web browser was not able to reach github.com.

Clearly, the Test-NetConnection command did not produce accurate results, as the web browser was not able to reach github.com.

That's not an accurate statement.

Test-NetConnection did in fact make a TCP connection to port 443 of the destination server, verifying that TCP port 443 on the remote server is in the listening state. Test-NetConnection does not test what application/service is running/listening on port 443.

Essentially, Test-NetConnection can't tell you what is running/listening at Layer 7, it can only tell you that port 443 is in the listening state.

The two statements "the connection can be made" and "I am able to proceed with what I intend to do" are far from equivalent, and a simple TCP connection test like Test-NetConnection does not at all test the same thing as an actual git clone.

Being able to open a TCP connection to a port does not imply access to the service listening on that port. There are many stages after the initial connect that may fail, such as TLS negotiations, authentication, authorization or application level protocol exchanges.

Also, firewall restrictions are not the only possible reason for a TCP connection to fail, and failures of the TCP connection are not the only possible effect of a firewall restriction. So your statements:

If I cannot access the site on a particular port, then that means I would need to modify the firewall before proceeding.

and

Otherwise, if I can reach the site, then I would be able to proceed with what I intend to do.

are both wrong. This means that, instead of wondering why your Test-NetConnection test did not detect the problem that later caused your GitHub access to fail, you should analyze what that problem actually was, and then evaluate whether detecting that particular problem in advance would provide any benefit. If the answer is yes, you can then devise a test to do just that.

In practice, frequently the most efficient course of action is to just try the intended operation without any preceding tests, and handle any errors as they occur. Checking for problems in advance mostly only makes sense if they can be fixed automatically or if trying and failing the actual operation carries a substantial cost or risk.

Specifically, GitHub operations fail rather gracefully and with reasonably clear indication of the cause of failure, so I see no direct benefit in testing the connection first instead of just trying the intended operation directly.