It’s not uncommon to point your browser at a website, only for it to fail to connect. Other sites work fine, and there’s no error message telling you why the connection failed, so you don’t know where your connection is falling apart.
There are lots of ways to tackle this, but among the simplest is in Network Utility. This is one of the most useful tools in macOS, as it combines easy access to eight powerful command tools in a single app. Why Apple now hides it away in /System/Library/CoreServices/Applications I just don’t know, and one simple remedy might have been to make an alias to it. But because it’s in a folder protected by SIP, you can’t even do that in the Finder.
The first of its tabs which you should use is Lookup. Enter the name of the website, such as thissite.com, and click on the Lookup button. This will use the name service (DNS) to retrieve its IP address.
If you don’t get an IP address back, that means that the name is not recognised by the name service to which you’re connected, or you’re not connected to a fully-functional name server. Check your Network pane settings.
If you do get an IP address back, make a note of it, as you will use it in the next steps.
Then switch to the Ping tab, enter the site name, and send only 3 pings by clicking on the Ping button.
Most commercial servers and website hosting services respond to pings, although you may find the occasional one which doesn’t. You should get three successful pings back, within a reasonable length of time. How long is that? It depends on where the servers are, and how good your internet connection is, but typical figures are around 30 to 140 ms, longer if the servers are on the other side of the world, or your internet connection has a high latency (like satellite).
If you don’t get all three pings back fairly briskly, try using the IP address instead, and that again suggests a problem in the name service.
The final test is performed in the Traceroute tab, where you enter the site name and click on the Trace button. This works a bit like pinging, but identifies all the intermediate links in the connection between your Mac and the remote server, giving three times taken to reach each step on the way.
The first step is within your own network, from your Mac to the modem-router. The second takes your packets on to the first of your ISP’s servers. They often rattle around there in a few servers before heading out to the internet proper. If the website is hosted in a different country, you should see your packets switch from (for example) names containing
uk to those with
us. Eventually, you should see the packets reach the website host, finally arriving at the same IP address that you got from Lookup.
If things go wrong, you can now see roughly where they fail. With so many countries allowing ISPs to block certain types of web content, you might find that your packets go no further than your ISP’s servers, less than half a dozen steps, perhaps.
If there’s a major network problem, such as an undersea cable failure, your packets may have been rerouted through other trunk connections, or may stop dead at a border. This may explain why most sites are working fine, but some seem unreachable.
If you do think that your ISP is blocking the site which you’re trying to reach, another good test is to connect using a different service. If you have a device like an iPhone or iPad which can provide a Mobile Hotspot and act as a Wi-Fi modem, enable that and adjust your Mac’s Network settings to make that your internet connection. Then try the website. And if you think that your ISP – or anyone else – is incorrectly blocking a site, complain to them.