If you are having trouble connecting to your server application, this guide has the tools you'll need to diagnose issues with your firewall, application, name servers, and connectivity.
We block several outbound ports for network security. Please review the Standard Port Blocking topic.
Server instances at Vultr may be protected by the Vultr firewall, an OS firewall, or both simultaneously. Make sure the Vultr Firewall is configured properly. For debugging purposes, if your server instance is linked to a Vultr Firewall group, try removing it from the group temporarily. See the Vultr Firewall quickstart guide for an overview.
If you are blocked from SSH, use the noVNC console in your customer portal at https://my.vultr.com/.
Click on your server instance.
Click the "View Console" icon.
The noVNC console will open.
Log in through this web-based console to perform additional diagnostic steps.
See our complete Web Console FAQ.
Vultr's standard OS image have firewalls enabled by default that block a great deal of traffic. If you are having trouble connecting to your server applications, verify your firewall configuration.
If you installed a Vultr CentOS image, firewalld is enabled by default, and blocks a great deal of traffic. If you are having trouble connecting to your server applications, verify your firewalld configuration.
If you installed from your own ISO, the default firewall installation varies between versions. These are the most common configurations, your specific server may have a different firewall installed.
CentOS 6 - See the iptables quickstart guide.
CentOS 7 - See the firewalld quickstart guide.
CentOS 8 - See the nftables quickstart guide.
CoreOS has no default firewall. The most popular choice for an OS-level firewall is
iptables. See the iptables quickstart guide.
Debian 9 and 10 may use one of several firewalls. If you installed a Vultr Debian image, UFW is enabled by default.
See the iptables quickstart guide.
See the nftables quickstart guide.
See the UFW quickstart guide.
If you installed a Vultr Fedora image, firewalld is enabled by default.
If you installed a Vultr FreeBSD image, pf is enabled by default. IPFW and IPFILTER are also available.
See the pf quickstart guide.
See the IPFW quickstart guide.
See the IPFILTER quickstart guide.
If you installed a Vultr OpenBSD image, pf is enabled by default.
If you installed a Vultr Ubuntu image, UFW is enabled by default.
The Windows Firewall is enabled by default on Vultr's Windows image. See the Windows Firewall quickstart guide.
If you have determined that your traffic isn't blocked by either a Vultr Firewall or an OS-level firewall, try some additional debugging steps.
ping is a basic debugging step to verify a server is available by sending an ICMP packet and receiving a reply.
It's possible to configure a machine to ignore ping. A ping failure doesn't prove the server is down, but a ping success does verify the server is available. This example pings 192.0.2.22 four times (using the
-c 4 option), then stops and prints statistics.
# ping -c 4 192.0.2.22 PING 192.0.2.22 (192.0.2.22) 56(84) bytes of data. 64 bytes from 192.0.2.22: icmp_seq=1 ttl=54 time=15.4 ms 64 bytes from 192.0.2.22: icmp_seq=2 ttl=54 time=15.3 ms 64 bytes from 192.0.2.22: icmp_seq=3 ttl=54 time=15.4 ms 64 bytes from 192.0.2.22: icmp_seq=4 ttl=54 time=15.4 ms --- 192.0.2.22 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3004ms rtt min/avg/max/mdev = 15.340/15.377/15.424/0.030 ms
For advanced options, use
netstat (Network Statistics) is useful to query the state of your network connections. It is available for Linux, Windows and MacOS. See our netstat troubleshooting guide to check your application.
Try scanning the server with nmap, which is available for all Linux systems via their respective package managers. Windows users can download namp from the official site, which also has a version for MacOS.
Use the Vultr nmap troubleshooting guide for information on scanning your server.
nslookup is used to query internet domain name servers. This is useful to verify your servers name properly resolves to the expected IP address.
Verify the IP address of example.com using the internal name resolver.
# nslookup example.com Server: 127.0.0.53 Address: 127.0.0.53#53 Non-authoritative answer: Name: example.com Address: 18.104.22.168 Name: example.com Address: 2606:2800:220:1:248:1893:25c8:1946
Verify the IP address of example.com using Google's public DNS (22.214.171.124).
# nslookup example.com 126.96.36.199 Server: 188.8.131.52 Address: 184.108.40.206#53 Non-authoritative answer: Name: example.com Address: 220.127.116.11 Name: example.com Address: 2606:2800:220:1:248:1893:25c8:1946
Compare both examples to verify the server resolves the same IP address for example.com as a public name server.
For advanced options, see the nslookup help with
Many Linux systems have replaced nslookup with dig, the Domain Internet Groper. dig also queries domain name servers, but provides more information than nslookup.
# dig example.com ; <<>> DiG 9.11.5-P4-5.1ubuntu2.1-Ubuntu <<>> example.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55898 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 65494 ;; QUESTION SECTION: ;example.com. IN A ;; ANSWER SECTION: example.com. 6521 IN A 18.104.22.168 ;; Query time: 0 msec ;; SERVER: 127.0.0.53#53(127.0.0.53) ;; WHEN: Wed Apr 01 20:07:19 UTC 2020 ;; MSG SIZE rcvd: 56
For advanced options, see the dig help with
After completing these debugging steps, you may still have questions. Please generate an MTR network report in both directions and then open a support ticket. We are happy to assist you.