[SOLVED] Websites won't load completely/won't load at all

wvk · 2024-04-11 20:26:12

Hello,

I resorted to post my issue here because I cannot seem to find anything already online which describes the problem - or I missed it - and I cannot begin to pinpoint the cause of it at all due to my lack of knowledge. I encountered the problem already several times in the past and i kinda solved it "randomly", but this time this strategy doesn't seem to be working, and now I am getting really curios to get to the bottom of it.

The problem
I turn on my laptop, everything seems to be working fine like every other day, but this particular day I open the browser, I type something, the search engine (in this case Duckduckgo) loads the results, and
- if i click on the images tab, only a few - about ten - will load, and the rest won't. Similar result with something like YouTube, it will keep hanging on the homepage, won't load any thumbnail, and won't let me play any video.
- some websites will work just fine (I am typing and posting this post on my laptop right now)(EDIT: everything worked fine until here, but the connection wouldn't let me post the post. Connected to a phone hotspot and worked fine)
- some websites will take a lot of time to load, and load completely broken
- occasionally loading will start to take more and more time
- some websites won't load at all (for example Reddit)
- I experience some issues in other applications as well (for example Thunderbird won't sync properly, cannot send emails, Bitwarden hangs)

How I solved the issue in the past
Somehow restarting the router and/or the laptop - sometimes only after several restarts - solved the problem, and everything started to work fine again. I believe I had this issue now five or six times in the course of a year or so. The problem is I have no idea why what I did solved the issue and in which way.

What I tried this time
Restarting the router, and the laptop, many times.
Using Wifi or Ethernet connection (or a docking station) does not make a difference, I experience the same issues.
Starting the laptop on battery or on AC does not make a difference.
Using a VPN or not does not make a difference.
If I connect the laptop to another network - in my test to my phone set as a hotspot - browsing works fine.
My phone and other devices work fine on the same network which gives me issues.
Using different browsers doesn't make any difference.

Hardware
Dell XPS 9560 (XFCE, NetworkManager), up to date at the time of writing, since pacman and updates download just fine.
I never applied any particular network settings like custom DNS.
LTE Router TP-Link TL-MR6400 basically with stock settings.

I know that the problem could lay in the router, but also I cannot explain why I get issues only with the laptop. Before I post random outputs since in this case I have no idea where to look for cues, I hope somebody can point me in the right direction.

Many thanks in advance for the feedback!

Last edited by wvk (2024-04-14 18:34:32)

seth · 2024-04-11 21:49:51

So you've a spotty internet connection, but:

- Wifi or Ethernet connection (or a docking station) does not make a difference
=> It's not the physical layer, you're also not roaming between 2.4 & 5 GHz

- different browsers doesn't make any difference
=> ideally, when the situation exists, see whether you get a stable "ping 8.8.8.8" or timeouts, package losses or weird TTL shifts

- phone and other devices work fine on the same network
=> is this only based on browser behavior or did you run ping stats on those?

- If I connect the laptop to another network … browsing works fine
=> Can you run a ping-test on the router?

- pacman and updates download just fine
=> do you use a https mirror?

Wild guess, lower the MTU.

sudo ip link set eth0 mtu 1280 # replace eth0 w/ the relevant NIC

Ceterum censeo: in case there's a parallel windows installation, 3rd link below. Mandatory.
Disable it (it's NOT the BIOS setting!) and reboot windows and linux twice for voodo reasons.

wvk · 2024-04-12 14:48:38

Thank you for your reply.

- different browsers doesn't make any difference
=> ideally, when the situation exists, see whether you get a stable "ping 8.8.8.8" or timeouts, package losses or weird TTL shifts

I already ran ping to see if I could notice anything standing out, but couldn't see anything abnormal, at least to my eye.

- phone and other devices work fine on the same network
=> is this only based on browser behavior or did you run ping stats on those?

This was based on browser and app behavior alone.

- If I connect the laptop to another network … browsing works fine
=> Can you run a ping-test on the router?

Here are some outputs while connected to the router and experiencing the issue:

Ethernet + VPN

XPS9560% ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=119 time=38.5 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=119 time=34.6 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=119 time=39.5 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=119 time=64.4 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=119 time=41.6 ms
64 bytes from 8.8.8.8: icmp_seq=6 ttl=119 time=42.0 ms
64 bytes from 8.8.8.8: icmp_seq=7 ttl=119 time=38.2 ms
64 bytes from 8.8.8.8: icmp_seq=8 ttl=119 time=54.1 ms
64 bytes from 8.8.8.8: icmp_seq=9 ttl=119 time=59.9 ms
64 bytes from 8.8.8.8: icmp_seq=10 ttl=119 time=40.5 ms
64 bytes from 8.8.8.8: icmp_seq=11 ttl=119 time=40.3 ms
64 bytes from 8.8.8.8: icmp_seq=12 ttl=119 time=43.5 ms
64 bytes from 8.8.8.8: icmp_seq=13 ttl=119 time=66.1 ms
64 bytes from 8.8.8.8: icmp_seq=14 ttl=119 time=43.6 ms
64 bytes from 8.8.8.8: icmp_seq=15 ttl=119 time=41.8 ms
^C
--- 8.8.8.8 ping statistics ---
15 packets transmitted, 15 received, 0% packet loss, time 14022ms
rtt min/avg/max/mdev = 34.579/45.902/66.082/9.718 ms

Ethernet

XPS9560% ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=113 time=45.9 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=113 time=41.5 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=113 time=41.4 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=113 time=40.8 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=113 time=40.4 ms
64 bytes from 8.8.8.8: icmp_seq=6 ttl=113 time=38.9 ms
64 bytes from 8.8.8.8: icmp_seq=7 ttl=113 time=38.3 ms
64 bytes from 8.8.8.8: icmp_seq=8 ttl=113 time=40.5 ms
64 bytes from 8.8.8.8: icmp_seq=9 ttl=113 time=41.2 ms
64 bytes from 8.8.8.8: icmp_seq=10 ttl=113 time=40.7 ms
64 bytes from 8.8.8.8: icmp_seq=11 ttl=113 time=40.9 ms
64 bytes from 8.8.8.8: icmp_seq=12 ttl=113 time=41.6 ms
64 bytes from 8.8.8.8: icmp_seq=13 ttl=113 time=37.2 ms
64 bytes from 8.8.8.8: icmp_seq=14 ttl=113 time=39.3 ms
64 bytes from 8.8.8.8: icmp_seq=15 ttl=113 time=41.3 ms
^C
--- 8.8.8.8 ping statistics ---
15 packets transmitted, 15 received, 0% packet loss, time 14020ms
rtt min/avg/max/mdev = 37.180/40.660/45.890/1.877 ms

Wifi + VPN

XPS9560% ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=119 time=57.9 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=119 time=52.7 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=119 time=43.4 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=119 time=67.2 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=119 time=46.9 ms
64 bytes from 8.8.8.8: icmp_seq=6 ttl=119 time=70.1 ms
64 bytes from 8.8.8.8: icmp_seq=7 ttl=119 time=59.0 ms
64 bytes from 8.8.8.8: icmp_seq=8 ttl=119 time=64.3 ms
64 bytes from 8.8.8.8: icmp_seq=9 ttl=119 time=59.7 ms
64 bytes from 8.8.8.8: icmp_seq=10 ttl=119 time=75.8 ms
64 bytes from 8.8.8.8: icmp_seq=11 ttl=119 time=46.6 ms
64 bytes from 8.8.8.8: icmp_seq=12 ttl=119 time=68.4 ms
64 bytes from 8.8.8.8: icmp_seq=13 ttl=119 time=77.6 ms
64 bytes from 8.8.8.8: icmp_seq=14 ttl=119 time=79.7 ms
64 bytes from 8.8.8.8: icmp_seq=15 ttl=119 time=61.3 ms
^C
--- 8.8.8.8 ping statistics ---
15 packets transmitted, 15 received, 0% packet loss, time 14021ms
rtt min/avg/max/mdev = 43.422/62.022/79.737/10.993 ms

Wifi

XPS9560% ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=113 time=76.2 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=113 time=46.9 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=113 time=47.6 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=113 time=49.2 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=113 time=49.6 ms
64 bytes from 8.8.8.8: icmp_seq=6 ttl=113 time=50.9 ms
64 bytes from 8.8.8.8: icmp_seq=7 ttl=113 time=56.8 ms
64 bytes from 8.8.8.8: icmp_seq=8 ttl=113 time=47.7 ms
64 bytes from 8.8.8.8: icmp_seq=9 ttl=113 time=42.6 ms
64 bytes from 8.8.8.8: icmp_seq=10 ttl=113 time=42.2 ms
64 bytes from 8.8.8.8: icmp_seq=11 ttl=113 time=42.9 ms
64 bytes from 8.8.8.8: icmp_seq=12 ttl=113 time=43.8 ms
64 bytes from 8.8.8.8: icmp_seq=13 ttl=113 time=43.7 ms
64 bytes from 8.8.8.8: icmp_seq=14 ttl=113 time=40.6 ms
64 bytes from 8.8.8.8: icmp_seq=15 ttl=113 time=44.5 ms
^C
--- 8.8.8.8 ping statistics ---
15 packets transmitted, 15 received, 0% packet loss, time 14021ms
rtt min/avg/max/mdev = 40.644/48.348/76.171/8.462 ms

Here are some outputs while connected to the hotspot

Hotspot + VPN

XPS9560% ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=119 time=48.2 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=119 time=55.3 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=119 time=80.0 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=119 time=116 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=119 time=115 ms
64 bytes from 8.8.8.8: icmp_seq=6 ttl=119 time=152 ms
64 bytes from 8.8.8.8: icmp_seq=7 ttl=119 time=66.6 ms
64 bytes from 8.8.8.8: icmp_seq=8 ttl=119 time=91.2 ms
64 bytes from 8.8.8.8: icmp_seq=9 ttl=119 time=134 ms
64 bytes from 8.8.8.8: icmp_seq=10 ttl=119 time=53.1 ms
64 bytes from 8.8.8.8: icmp_seq=11 ttl=119 time=69.2 ms
64 bytes from 8.8.8.8: icmp_seq=12 ttl=119 time=112 ms
64 bytes from 8.8.8.8: icmp_seq=13 ttl=119 time=135 ms
64 bytes from 8.8.8.8: icmp_seq=14 ttl=119 time=71.8 ms
64 bytes from 8.8.8.8: icmp_seq=15 ttl=119 time=60.9 ms
^C
--- 8.8.8.8 ping statistics ---
15 packets transmitted, 15 received, 0% packet loss, time 14024ms
rtt min/avg/max/mdev = 48.236/90.680/151.733/32.785 ms

Hotspot

XPS9560% ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=112 time=105 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=112 time=52.7 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=112 time=47.8 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=112 time=80.0 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=112 time=104 ms
64 bytes from 8.8.8.8: icmp_seq=6 ttl=112 time=67.6 ms
64 bytes from 8.8.8.8: icmp_seq=7 ttl=112 time=44.8 ms
64 bytes from 8.8.8.8: icmp_seq=8 ttl=112 time=52.8 ms
64 bytes from 8.8.8.8: icmp_seq=9 ttl=112 time=51.3 ms
64 bytes from 8.8.8.8: icmp_seq=10 ttl=112 time=47.1 ms
64 bytes from 8.8.8.8: icmp_seq=11 ttl=112 time=72.6 ms
64 bytes from 8.8.8.8: icmp_seq=12 ttl=112 time=47.9 ms
64 bytes from 8.8.8.8: icmp_seq=13 ttl=112 time=138 ms
64 bytes from 8.8.8.8: icmp_seq=14 ttl=112 time=46.5 ms
64 bytes from 8.8.8.8: icmp_seq=15 ttl=112 time=77.6 ms
^C
--- 8.8.8.8 ping statistics ---
15 packets transmitted, 15 received, 0% packet loss, time 14024ms
rtt min/avg/max/mdev = 44.815/69.010/138.031/26.788 ms

- pacman and updates download just fine
=> do you use a https mirror?

Http I suppose, here are the first five mirrors in my mirrorlist:

Server = http://mirror.puzzle.ch/archlinux/$repo/os/$arch
Server = http://ftp.sh.cvut.cz/arch/$repo/os/$arch
Server = http://ftp.hosteurope.de/mirror/ftp.archlinux.org/$repo/os/$arch
Server = http://arch.jensgutermuth.de/$repo/os/$arch
Server = https://pkg.fef.moe/archlinux/$repo/os/$arch

Ceterum censeo: in case there's a parallel windows installation, 3rd link below. Mandatory.

I don't have a dual boot, but I have a VM running Windows 10. I already tried it and there the connection was working just fine while at the same time having issues in Linux.

Wild guess, lower the MTU.

The suggested command actually did the trick, the connection seems to be working after. The browsing experience however seems far from being as "smooth" as it used to be when I didn't experience the issue. Is this a workaround or an acceptable solution? If I turn off and on the laptop I have to re-run the command, where/how are the MTU values assigned? Any clue why this happened periodically and all of a sudden, and why in the past a laptop/router restart solved the issue for months at times?

Here a ping while connected to the router after running the mentioned command:

XPS9560% ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=119 time=39.8 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=119 time=64.1 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=119 time=62.4 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=119 time=61.6 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=119 time=54.0 ms
64 bytes from 8.8.8.8: icmp_seq=6 ttl=119 time=41.7 ms
64 bytes from 8.8.8.8: icmp_seq=7 ttl=119 time=66.5 ms
64 bytes from 8.8.8.8: icmp_seq=8 ttl=119 time=43.3 ms
64 bytes from 8.8.8.8: icmp_seq=9 ttl=119 time=70.4 ms
64 bytes from 8.8.8.8: icmp_seq=10 ttl=119 time=74.2 ms
64 bytes from 8.8.8.8: icmp_seq=11 ttl=119 time=38.2 ms
64 bytes from 8.8.8.8: icmp_seq=12 ttl=119 time=58.9 ms
64 bytes from 8.8.8.8: icmp_seq=13 ttl=119 time=47.4 ms
64 bytes from 8.8.8.8: icmp_seq=14 ttl=119 time=57.1 ms
64 bytes from 8.8.8.8: icmp_seq=15 ttl=119 time=38.6 ms
^C
--- 8.8.8.8 ping statistics ---
15 packets transmitted, 15 received, 0% packet loss, time 14022ms
rtt min/avg/max/mdev = 38.219/54.548/74.171/11.793 ms

Last edited by wvk (2024-04-12 17:15:18)

seth · 2024-04-12 15:04:51

ping looks perfectly fine, it's not the lowest latency in the world, but pretty much consistent, there're no timeouts and no package losses.
You're most likely using one of the http mirrors on the top.
…

The suggested command actually did the trick, the connection seems to be working after.

which is why I was gonna say you should really try the MTU before reading that

Ping isn't affected by the MTU because the package sizes are smaller than that (but ssh is, which is why I wondered about the http mirrors)
You'll probably also get away w/ slightly larger MTUs than 1280 (disfunctional default is 1500, 1412 is a good bet - I just suggested a really low value to reliebaly identify the problem 1280 is the IPv6 minimum MTU)

Since this is a computer and the sole purpose is to generate more manual labor, you of course have to run this everytime you boot.
One almost would need a programmable system that one could utilize to automate such silly tasks
https://wiki.archlinux.org/title/Networ … eue_length

The cause is most likely your ISP; IPv4-over-6 can cause this but it's also a frequent issue w/ VPNs - with your scenario your ISP might have transitioned their routing and w/ the previous reboot you randomly still got a real IPv4. But that's of course speculative.

wvk · 2024-04-12 17:14:06

Thanks for following up.

You'll probably also get away w/ slightly larger MTUs than 1280 (disfunctional default is 1500, 1412 is a good bet - I just suggested a really low value to reliebaly identify the problem 1280 is the IPv6 minimum MTU)

It seems to be working ok-ish between 1300 and 1350 at the moment, but in the browser the behavior is kinda weird. Website will take a while to load, then let's say all pictures will load at once, and I've already gotten this false alarm a few times (Firefox): "HTTPS-Only Mode Alert, Secure Site Not Available". But clicking on "Continue to HTTP Site will load the HTTPS website just fine. I'm just mentioning because you asked me about http/https above.

Since this is a computer and the sole purpose is to generate more manual labor, you of course have to run this everytime you boot.
One almost would need a programmable system that one could utilize to automate such silly tasks smile
https://wiki.archlinux.org/title/Networ … eue_length

Thank you for the heads up!

The cause is most likely your ISP

Is there still something I can do on the computer side to make the situation better/closer to what it has been until now?

seth · 2024-04-12 17:38:28

Reduce the MTU to 1280 again - firefox behaves normal again?

The only thing you can do about this is to ask your ISP to fix this (what they'll ignore - every ISP is the worst one…)
Bigger MTUs mean less overhead, but the least overhead doesn't help if packages get constantly dropped.

wvk · 2024-04-14 18:31:44

Reduce the MTU to 1280 again - firefox behaves normal again?

Didn't get the http/https problem again keeping it at 1280, but unfortunately website loading is still considerably delayed, it takes a while even before the page starts to get rendered.

And today it just came to my mind that I have my (really) old laptop still laying around, which is running Xubuntu and hasn't received any updates in several months. I fired it up and got the same issue.

Will try to see if I can do anything on the router or ISP side.. Thank you very much for taking the time to explain, and for the instant fix!

Last edited by wvk (2024-04-14 18:33:36)

Arch Linux

#1 2024-04-11 20:26:12

[SOLVED] Websites won't load completely/won't load at all

#2 2024-04-11 21:49:51

Re: [SOLVED] Websites won't load completely/won't load at all

#3 2024-04-12 14:48:38

Re: [SOLVED] Websites won't load completely/won't load at all

#4 2024-04-12 15:04:51

Re: [SOLVED] Websites won't load completely/won't load at all

#5 2024-04-12 17:14:06

Re: [SOLVED] Websites won't load completely/won't load at all

#6 2024-04-12 17:38:28

Re: [SOLVED] Websites won't load completely/won't load at all

#7 2024-04-14 18:31:44

Re: [SOLVED] Websites won't load completely/won't load at all

Board footer