Troubleshooting network problems
Last updated: November 8th 2022
Introduction
This article outlines some of the most common network issues you may face when connecting/working with your server. This guide helps you troubleshoot the issue.
Prerequisites
- You have a server running on Webdock
- Your client machine has internet access.
Finding your local machine’s public IP
To troubleshoot the issue we are going to do traceroute tests in both ways, i.e. from your local machine to your Webdock server and from your Webdock server to your local machine. This helps pinpoint where exactly the problem lies.
To find your local machine’s public IP address please visit WhatIsMyIPAddress online tool in your browser.
Server is unreachable
When you server is not reachable the first thing you need to check is if your local machine has internet access. Do a ping test by pinging IP of Google or Cloudflare DNS servers or simply visit google.com to see if everything is working. Most likely you have internet access, otherwise you would be hard pressed to even read this article :)
Next, try pinging or reaching your server using both the server IPv4 address and the Webdock alias. If it turns out you cannot reach your server on a domain you added yourself, please make sure the DNS entries for your domain are correct, read more on how to manage DNS here.
Next, try using our WebSSH feature. If that works, this tells you that the Webdock SSH terminal server could reach your server without issues and log in with SSH. This really indicates that there is an issue on your end or somewhere on the path between you and your Webdock server.
Please note: If you are on our smalles Nano profile and WebSSH works but you cannot reach your server from your PC, this tells you that your local network does not support IPv6 as Nano profiles are IPv6 only. In which case, you need to upgrade to a Webdock profile that provides you with an IPv4 address.
If nothing works, try restarting your Webdock server from the dashboard and try reaching it again using ping or WebSSH.
To restart your server, just simply click on the restart icon (the one beside the red stop button). Hopefully, this should resolve your network issue. If restarting your server does not help, read on to discover what the underlying cause may be.
Slow Network Speeds
Slow network speed can be caused by a number of issues. However, if you are determining your network speed is slow using some sort of network speed testing tool, please make sure you are testing your network speed correctly. Please read our article on how to correctly test network speeds.
Network speed can also be affected by an issue with our infrastructure or the path between you and your Webdock server, of course. In which case, please perform an MTR test as shown below in order to discover if there is a lot of packet loss on your connection and send the MTR report to us if you decide to contact Webdock Support.
Identifying Packet loss issues
If you are seeing packet loss (when pinging your server’s IP), then we need some additional information to do further investigation and in many cases you can identify the problem yourself using the instructions below.
We recommend you perform a traceroute test (in both directions) with at least 1000 packets using a tool like mtr or WinMTR. Depending on the OS running on your local machine:
- Linux: Install mtr using your linux distro package manager, eg.
sudo apt install mtr. - Windows: You can download WinMTR program from here.
- Mac: Install with brew using
brew install mtr
You should run the following commands to perform traceroute test in both directions.
From local machine to your Webdock server:
This command has to be run on your local machine.
$ mtr -s 1000 -r -c 1000 <YOUR-WEBDOCK-SERVER-IPv4>
From your Webdock server to your local machine:
This command has to be run on your Webdock server. Replace the IP field with the one you got from visiting whatismyipaddress.
$ mtr -s 1000 -r -c 1000 <YOU-CLIENT-PUBLIC-IPv4>
Wait for a couple of minutes for the tests to complete.
One point to remember: The hops of the MTR results show the process for the specific connection. So your MTR output may vary from what’s shown here.
The below are some of the problems you might notice once your MTR tests finish.
1. Packet loss that disappears until the target hop
- As you can see in this example, there is packet loss at hop 7 and 9-16 and on the next to last hop.
- If you see packet loss returning to 0% by the end of the last hop, then this behavior is probably caused by routers at certain hops ignoring ICMP traffic (ping requests) and is not a problem for your connection.
Host Loss% Snt Last Avg Best Wrst StDev
1. 2a01:4f8::a:14:b 0.0% 118 0.3 0.5 0.2 8.3 1.0
2. core24.fsn1.hetzner.com 0.0% 118 0.4 6.5 0.3 45.7 9.4
3. core11.nbg1.hetzner.com 0.0% 118 2.7 2.7 2.6 5.7 0.4
4. ae12-500.nbg40.core-backbone.com 0.0% 118 3.0 2.8 2.6 3.0 0.1
5. ae3-2011.nbg30.core-backbone.com 0.0% 118 2.8 2.9 2.8 3.2 0.1
6. ae1-2001.fra10.core-backbone.com 0.0% 118 5.4 5.5 5.4 5.7 0.1
7. ffm-b5-link.ip.twelve99.net 86.3% 118 6.1 6.0 5.9 6.5 0.1
8. ffm-bb2-v6.ip.twelve99.net 0.0% 118 6.2 6.1 6.0 6.5 0.1
9. ffm-b11-v6.ip.twelve99.net 87.2% 118 6.2 6.2 6.0 6.5 0.1
10. be1299.rcr22.fra06.atlas.cogentco.com 65.8% 118 9.5 9.2 9.0 10.2 0.2
11. be2845.ccr41.fra03.atlas.cogentco.com 84.6% 118 9.2 9.4 9.1 10.5 0.4
12. be2813.ccr41.ams03.atlas.cogentco.com 86.3% 118 17.0 16.0 15.4 20.0 1.1
13. be2182.ccr21.lpl01.atlas.cogentco.com 79.5% 118 25.5 25.4 25.3 25.6 0.1
14. be3042.ccr21.ymq01.atlas.cogentco.com 84.6% 118 94.5 94.5 94.5 94.6 0.0
15. be3004.agr22.ymq01.atlas.cogentco.com 17.1% 117 94.7 94.7 94.5 96.0 0.2
16. te0-0-0-24.nr01.b019086-1.ymq01.atlas.cogentco.com 12.8% 117 95.1 95.1 94.9 97.8 0.3
17. 2001:550:2:5::67:2 0.0% 117 94.3 95.2 94.2 134.1 5.0
18. 2607:4300:1::10:2 0.0% 117 100.1 98.4 92.6 159.8 8.2
19. cerberus.webdock.io 12.0% 117 92.8 92.8 92.7 93.0 0.0
20. 2607:4300:1:c005::10 0.0% 117 93.2 93.1 92.9 93.5 0.1
2. Packet loss only on the last hop
In this scenario, you would see high packet loss only at the last hop. This one is probably caused by your Webdock server itself. It can be due to your software firewall blocking the traffic or if your server is under high load or networking is simply broken in your server.
If you happen to see this kind of loss, please check your server first - firewall and resource consumption, and if the problem still persists, contact Webdock Support with your MTR reports. We will then investigate this further.
Host Loss% Snt Last Avg Best Wrst StDev
1. DESKTOP-BI1JPIT 0.0% 126 0.2 0.2 0.1 0.4 0.0
2. amplifi.lan 0.0% 126 0.5 0.4 0.4 0.6 0.1
3. 5.186.25.1 0.0% 126 0.6 0.7 0.5 4.7 0.4
4. 80.71.79.26 0.0% 126 0.6 0.7 0.5 3.3 0.3
5. 212.178.170.21 0.0% 126 1.3 1.4 1.1 1.9 0.1
6. 185.128.75.28 0.0% 126 1.6 1.5 1.2 2.0 0.1
7. 185.128.75.30 0.0% 126 2.3 2.3 1.9 6.2 0.4
8. 185.128.75.226 0.0% 126 2.4 2.3 1.9 5.2 0.3
9. be2.core01.taa4.fibianet.dk 0.0% 126 7.7 7.7 7.4 12.7 0.5
10. 89.150.69.66 0.0% 126 7.4 7.0 6.8 7.5 0.1
11. 217.74.211.104 0.0% 126 6.8 6.8 6.7 7.8 0.1
12. 194.182.97.132 0.0% 126 17.4 17.5 17.1 26.8 0.9
13. ae10.ham2p1de.gc-net.eu 0.0% 126 16.9 17.1 16.7 20.5 0.7
14. 194.182.97.201 0.0% 126 16.7 17.1 16.7 18.7 0.3
15. 5.179.90.239 0.0% 126 19.6 18.8 16.6 50.9 4.3
16. 213.239.245.126 0.0% 126 16.9 17.7 16.9 36.7 2.5
17. 213.239.224.154 0.0% 126 37.3 30.9 28.9 63.9 5.4
18. 213.239.252.54 0.0% 126 30.1 31.4 30.0 66.9 5.3
19. 65.108.35.202 16.0% 126 29.2 29.3 29.2 30.6 0.2
20. 45.148.30.198 100% 126 31.0 31.1 30.8 31.4 0.2
3. Packet loss on the connection
In this instance, the packet loss appears first at a specific hop and lasts until the final hop. If you see this happen this means that somewhere between you and our infrastructure there is a potential problem. If WebSSH works this further supports this. You may be able to connect if you change to another network (for example go from your wifi to your mobile network). This is often out of our control, but please send us the MTR reports and we will investigate this further for you.
Host Loss% Snt Last Avg Best Wrst StDev
1. DESKTOP-BI1JPIT 0.0% 7 0.2 0.2 0.2 0.3 0.0
2. amplifi.lan 0.0% 7 0.4 0.4 0.4 0.5 0.0
3. 5.186.25.1 0.0% 7 0.6 0.6 0.5 0.7 0.1
4. 80.71.79.26 0.0% 7 0.6 0.6 0.6 0.7 0.0
5. 212.178.170.21 0.0% 7 1.3 1.4 1.2 1.7 0.2
6. 185.128.75.28 0.0% 7 1.6 1.6 1.5 1.7 0.1
7. 185.128.75.30 0.0% 7 2.2 2.3 2.2 2.7 0.2
8. 185.128.75.226 0.0% 6 2.1 2.3 2.1 2.5 0.1
9. be2.core01.taa4.fibianet.dk 0.0% 6 7.6 7.7 7.6 7.8 0.1
10. 89.150.69.66 0.0% 6 7.0 7.0 6.9 7.1 0.1
11. 217.74.211.104 0.0% 6 6.8 6.8 6.7 7.0 0.1
12. 212.73.252.201 0.0% 6 7.5 9.8 7.0 22.4 6.2
13. 4.69.210.210 0.0% 6 7.2 7.2 7.2 7.3 0.0
14. 46.33.88.125 70.6% 6 7.1 7.1 7.0 7.3 0.1
15. 213.200.120.114 73.2% 6 97.7 97.7 97.5 97.8 0.1
16. 76.74.37.218 83% 6 108.6 108.6 108.6 108.7 0.0
17. (waiting for reply)
18. 209.127.24.114 80.0% 6 98.3 98.3 98.3 98.3 0.0
19. 45.153.48.69 93% 6 109.8 109.8 109.7 110.1 0.2
Conclusion
Hopefully this article has shown you how to diagnose what is causing network issues and how to resolve these in the most common cases.
Related articles
-
Frequently Asked Questions (FAQ)
Here we have gathered the most frequently asked questions in our support channels for quick reference and links to answers.
Last updated: October 22nd 2024
-
Diagnosing 502 Bad Gateway Error
Learn how to undersand and troubleshoot a 502 Bad Gateway error
Last updated: August 7th 2022
-
How to run network speed tests on your Webdock server
This mini-article outlines instructions on how to run and get accurate network speed test results on your Webdock servers.
Last updated: May 24th 2024
-
Common Certbot Errors
Let's Encrypt Certbot sometimes kicks up a fuss. In this article we document the most commonly encountered errors and how to solve them.
Last updated: July 6th 2022