Comment by Bender
Packet loss over ICMP can be artificial based on the backplane load of routers, ACL's and artificial rate limits. They will de-prioritize responding to ICMP and fail to respond if CPU load is high but that does not mean the packets are not being forwarded 100%. Linux and BSD also have knobs for this behavior as well. HN is BSD.
Are you seeing TCP retransmits to port 443?
for i in $(seq 69);do nc -vz -w1 news.ycombinator.com 443;sleep 2;done
Do that at the same time as watching watch -d -n4 --no-title 'nstat -a|grep -Ei "ret|los"'
It would be most useful to do this from your location and also from VM's on a few different providers in different locations to find which thing is not like the other. The 'nc' I am using is part of the nmap distribution. To force IPv6 replace the name with the IPv6 address.
> Packet loss over ICMP can be artificial based on the backplane load of routers.
This doesn't generally apply to the end host; note the last hop in the trace I posted is the web server itself. Also, the second last hop having very similar loss% makes it likely that neither of the two systems is hitting rate limits (as they would be different).
> Are you seeing TCP retransmits to port 443?
If the webpage loaded normally, I wouldn't have investigated to begin with ;).
Right now, the loss on TCP SYNs is about 70%. (mtr -T -P 443) Second to last hop still has roughly the same loss. Something's h0rked at americanis.net.