To acces a website, you need in reverse order:
- a correct TLS configuration (certificates, etc.)
- a proper HTTP server listening on port 80 and 443 for HTTPS
- a properly working firewall that let that traffic go through
- a proper IP routing from "anywhere" up to that server
- and if all starts with a name (extracted from the URL) you need correct name resolution (typically DNS but not necessarily everywhere) from that name to some IP address.
So you need to test all these things starting from bottom and going to top.
You can use the browser own internal web developer tools, or external commands (you get far better/simpler/faster/more correct troubleshooting if you can use command line tools) or at worst services on various websites.
I will only give details on command to use.
- you can use
dig
to double check the name resolution; see if the client gets proper IP address or not, using its default local resolver
- the 3 next points can all be checked by using
tcptraceroute
; it is of utmost importance to not use the default traceroute
(or even worse as so often suggested ping
) because it won't really emulate proper TCP/80 or TCP/443 traffic which is what you need; it can take time, but you should get to a final line with the IP address found on previous point and a mention akin to [open]
which means indeed you see (and can reach) a website running there, and hence no firewall impeding exchange.
- you can emulate a full HTTP(s) exchange using various tools, including
wget
, curl
or httpie
.
- specifically to debug TLS problems you can use
openssl s_client
, gnutls
or testssl.sh
UPDATE: I have got the site to load once now with Tor. Not sure what that tells me.
There may be a firewall between the server and the client. Hence if you change your source IP address, which is one of the side effect of using Tor, the access pattern changes.