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.