New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Slow connection with my VPS
There is an issue that is driving me crazy, it happens randomly and when I open a ticket they say that they cannot see any anomaly because they reply after hours when the problem is gone.
I have a Wireguard VPN on this VPS and everything is so slow when connected to it. These are some reports straight from the VPS:
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=58 time=39.5 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=58 time=40.9 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=58 time=52.5 ms
64 bytes from 1.1.1.1: icmp_seq=4 ttl=58 time=47.9 ms
64 bytes from 1.1.1.1: icmp_seq=5 ttl=58 time=44.6 ms
64 bytes from 1.1.1.1: icmp_seq=6 ttl=58 time=44.7 ms
64 bytes from 1.1.1.1: icmp_seq=7 ttl=58 time=49.8 ms
64 bytes from 1.1.1.1: icmp_seq=8 ttl=58 time=46.7 ms
64 bytes from 1.1.1.1: icmp_seq=9 ttl=58 time=57.6 ms
64 bytes from 1.1.1.1: icmp_seq=10 ttl=58 time=41.4 ms
64 bytes from 1.1.1.1: icmp_seq=11 ttl=58 time=41.3 ms
64 bytes from 1.1.1.1: icmp_seq=12 ttl=58 time=51.3 ms
64 bytes from 1.1.1.1: icmp_seq=13 ttl=58 time=49.3 ms
64 bytes from 1.1.1.1: icmp_seq=14 ttl=58 time=48.1 ms
64 bytes from 1.1.1.1: icmp_seq=15 ttl=58 time=46.1 ms
64 bytes from 1.1.1.1: icmp_seq=16 ttl=58 time=40.1 ms
64 bytes from 1.1.1.1: icmp_seq=17 ttl=58 time=54.2 ms
64 bytes from 1.1.1.1: icmp_seq=18 ttl=58 time=52.6 ms
64 bytes from 1.1.1.1: icmp_seq=19 ttl=58 time=43.9 ms
64 bytes from 1.1.1.1: icmp_seq=20 ttl=58 time=46.7 ms
64 bytes from 1.1.1.1: icmp_seq=21 ttl=58 time=39.8 ms
64 bytes from 1.1.1.1: icmp_seq=23 ttl=58 time=56.2 ms
64 bytes from 1.1.1.1: icmp_seq=24 ttl=58 time=49.2 ms
64 bytes from 1.1.1.1: icmp_seq=25 ttl=58 time=50.6 ms
64 bytes from 1.1.1.1: icmp_seq=26 ttl=58 time=47.5 ms
64 bytes from 1.1.1.1: icmp_seq=27 ttl=58 time=51.8 ms
64 bytes from 1.1.1.1: icmp_seq=28 ttl=58 time=49.4 ms
64 bytes from 1.1.1.1: icmp_seq=29 ttl=58 time=50.1 ms
64 bytes from 1.1.1.1: icmp_seq=30 ttl=58 time=30.4 ms
^C
--- 1.1.1.1 ping statistics ---
30 packets transmitted, 29 received, 3.33333% packet loss, time 29046ms
rtt min/avg/max/mdev = 30.371/47.038/57.616/5.737 ms
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=118 time=6.93 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=118 time=10.4 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=118 time=7.67 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=118 time=7.52 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=118 time=7.17 ms
64 bytes from 8.8.8.8: icmp_seq=6 ttl=118 time=8.05 ms
64 bytes from 8.8.8.8: icmp_seq=8 ttl=118 time=9.39 ms
64 bytes from 8.8.8.8: icmp_seq=9 ttl=118 time=6.66 ms
64 bytes from 8.8.8.8: icmp_seq=10 ttl=118 time=9.12 ms
64 bytes from 8.8.8.8: icmp_seq=11 ttl=118 time=5.86 ms
64 bytes from 8.8.8.8: icmp_seq=12 ttl=118 time=2.78 ms
64 bytes from 8.8.8.8: icmp_seq=13 ttl=118 time=5.85 ms
64 bytes from 8.8.8.8: icmp_seq=14 ttl=118 time=7.96 ms
64 bytes from 8.8.8.8: icmp_seq=15 ttl=118 time=5.56 ms
64 bytes from 8.8.8.8: icmp_seq=16 ttl=118 time=6.39 ms
64 bytes from 8.8.8.8: icmp_seq=17 ttl=118 time=7.69 ms
64 bytes from 8.8.8.8: icmp_seq=18 ttl=118 time=5.90 ms
64 bytes from 8.8.8.8: icmp_seq=19 ttl=118 time=7.25 ms
64 bytes from 8.8.8.8: icmp_seq=20 ttl=118 time=6.82 ms
64 bytes from 8.8.8.8: icmp_seq=21 ttl=118 time=5.91 ms
64 bytes from 8.8.8.8: icmp_seq=22 ttl=118 time=7.98 ms
64 bytes from 8.8.8.8: icmp_seq=23 ttl=118 time=10.0 ms
64 bytes from 8.8.8.8: icmp_seq=24 ttl=118 time=10.2 ms
64 bytes from 8.8.8.8: icmp_seq=25 ttl=118 time=9.17 ms
64 bytes from 8.8.8.8: icmp_seq=26 ttl=118 time=10.3 ms
64 bytes from 8.8.8.8: icmp_seq=27 ttl=118 time=8.49 ms
64 bytes from 8.8.8.8: icmp_seq=28 ttl=118 time=6.66 ms
64 bytes from 8.8.8.8: icmp_seq=29 ttl=118 time=3.05 ms
64 bytes from 8.8.8.8: icmp_seq=30 ttl=118 time=0.821 ms
^C
--- 8.8.8.8 ping statistics ---
30 packets transmitted, 29 received, 3.33333% packet loss, time 29062ms
rtt min/avg/max/mdev = 0.821/7.156/10.436/2.210 ms
traceroute to 1.1.1.1 (1.1.1.1), 64 hops max
1 * * *
2 146.70.0.46 0.226ms 0.294ms 0.167ms
3 37.120.220.92 0.745ms 0.631ms 0.602ms
4 * 37.120.128.248 8.634ms *
5 193.239.118.138 34.703ms 33.758ms 33.407ms
6 172.70.240.3 17.356ms 17.202ms 17.141ms
7 1.1.1.1 22.623ms 22.007ms *
traceroute to 8.8.8.8 (8.8.8.8), 64 hops max
1 * * *
2 146.70.0.46 0.207ms 0.170ms 0.136ms
3 * 37.120.220.90 14.220ms 13.836ms
4 * 37.120.128.248 0.835ms 0.693ms
5 185.206.226.71 3.321ms 3.411ms 4.687ms
6 * * *
7 8.8.8.8 9.820ms 9.783ms 9.707ms
In the past, when I opened the tickets ping to 8.8.8.8 was as high as about 300ms!
Do you see anything wrong here? Thank you very much for your help!
Comments
Can you post a MTR report with -c 30 instead? Preferably a report when you're experiencing issues and once when you're not. Also for me personally, most "noticeable" network lag usually has to do with DNS lookup or something with IPv6.
Thanks @black I'm currently experiencing issues.
Here you go with the MTR report to 1.1.1.1:
And here a report to google.com
This VPS has IPv6 enabled. Might this be the issue?
I'd try to turn off IPv6 and see what happens, preferably both on the PC connecting to the VPN server and the VPN server itself.
Nothing, I opened again the ticket with the provider, these are the results now
It seems that the ping is even higher than before.
This is just M247's network, unfortunately. Nothing they can do about it.
Could it be related to an excessive load caused by other VPSs that belong to abusive customers on the same physical server?
Is the provider known for ultra low cost, overloaded, or oversold VPSs?
No idea, the provider is Virtono. They just replied me that the main server has no issues, well... my VPS in this moment is not affected either and I changed nothing.
It's definitely an issue with whatever their using to keep your VPS Connected. But it may have not been in their control. It may have been something behind the scenes.