After getting my Arch laptop to connect to my phone's hotspot, I was having trouble connecting to any websites that were't cached (for the most part, anything but Google).

I looked a little, and found that even though it was deprecated, ntpdate worked to update my time correctly:

sudo ntpdate -u time.nist.gov

That gave me the correct time. But I was still having issues connecting, this time supposedly with DNS, or so Chromium was telling me. Still couldn't connect to anything other than Google, but at least the date issue had been fixed... or not.

I looked back at my clock and the time was back where it was before, two hours ahead. I checked systemctl and ntpd was still running, and it evidently thought it was the correct time.

Why does ntpd think the time is correct, and why would I still be having DNS issues?


It turns out, in my case, that because my phone was maintaining a connection to a proxy in a timezone two hours ahead, when my laptop (that 'didn't know' it was connected to a proxy server) was trying to connect to websites, it was sending the wrong time for my timezone.

Upon disconnecting from PIA (the proxy service) on my phone, everything went back to normal.

  • This seems very strange. If I connect to an office of ours the other side of the world and use that as my egress point, I don't have any issues accessing websites (apart from latency, that is). Was your proxy aggressively rewriting every HTTP header? – roaima Nov 15 '17 at 14:27
  • To be honest, I'm not sure. I didn't want to follow it all the way back from Chromium -> Linux -> Mobile Hotspot -> Proxy. It's entirely possible though. I used the Private Internet Access Android app if anyone is interested in checking/can replicate the issue. – Trevor Sears Nov 15 '17 at 15:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.