I did a traceroute to github.com and several other west coast sites in NoCal and Washington State and it seems it's a Level3/CenturyLink routing/backbone handoff problem.
I'm not. Mine's getting locked up somewhere 8 hops past HughesNet.
Pinging is fine, but the response is intermittently delayed and really not representative of what you need for a contiguous stream of data.
That's not bad. Mine goes from Level3 to zayo in LA and dies somewhere in there.
When I'm on hughesnet and ask a search engine "What's my IP address" it gives me a 184.xx.xx.xx number (dynamically assigned, may be different on different days).
That's same number that the web page on github-debug dot com retrieves in its tests.
It is the same number the github-debug dot com diagnostic is trying to ping when it reports "Destination net unreachable".
If I try to ping the same number, I also get "Destination net unreachable".
That "184.xx.xx.xx" number does not appear in any tracert that I've run.
Interesting. That's actually your public IPv4. They won't be able to get to it because you're behind a double-NAT. So if they've suddenly started using that technique to verify faked IPs it's not going to get very far. Come to think of it, it might not work for people behind VPNs, either.
Ok. So this is getting weird.
I went to https://18.104.22.168, bypassing the DNS going direct to their IP. FF told me it there was a domain error with the certificate (and rightfully so). I bipassed that and was redirected to https://github.com. The page displayed normally. Cool...
Did a shift-refresh to make sure it wasn't a cached version, and it timed out.
So it's definitely not IP validation because I wouldn't have gotten thru. There's something intermittently clogging the warp engines somewhere in the path and someone needs to play Spock.
Speaking of intermittent (and sllloooooow), I let it go and got in again: