Hello,

I could see that your webserver isn’t responding on default ports (80,443). Most probably your webserver daemon is not running. You might want to have a look at its status by logging into the Droplet.

$ nmap -p80,443 167.71.39.164
Starting Nmap 7.70 ( https://nmap.org ) at 2020-01-15 20:12 IST
Nmap scan report for 167.71.39.164
Host is up (0.15s latency).

PORT    STATE  SERVICE
80/tcp  closed http
443/tcp closed https

Nmap done: 1 IP address (1 host up) scanned in 0.57 seconds

In case of further queries, feel free to write back here or to DigitalOcean support.

Ritesh

Here is support answer. ıt ıs really hard for me. I am not professor.

Hello there,

Thank you for contacting DigitalOcean!

Testing shows that the Droplet isn’t responding to HTTP requests currently. This generally indicates a few scenarios. The first indicates that your Droplet web server software may have crashed. This can be anything from resource contention to general issues with software bugs. For resource contention, you will want to log in via SSH or use the web console for the Droplet to evaluate the resource usage of the software while it is running to identify any trends of heavy resource usage. This post outlines some useful tools to help you do this:

https://www.digitalocean.com/community/tutorials/how-to-use-top-netstat-du-other-tools-to-monitor-server-resources

In many cases, trying to confirm if this was a result of previous contention is rather difficult without monitoring tracking the resource usage. Another scenario here is that the web server is not running. This is somewhat related to it having crashed. Especially with memory resource contention and the out of memory manager. You can read more about this kernel level function and how to adjust it here:

https://www.kernel.org/doc/gorman/html/understand/understand016.html

https://lwn.net/Articles/317814/

In both these cases, you will want to first start with restarting the web server. If there is an error, the logs will generally help identify what may be impacting it. From a configuration issue, read-only file system ( in this case, no logging ) or insufficient resources like memory. You’ll want to address these problems individually until the server starts up as expected.

One other scenario that commonly impacts things is the web server itself is running, but the firewall is blocking the Droplet from listening to HTTP requests or the web server isn’t listening to the correct port. This is usually a result of misconfiguration. In most cases, you can verify if the web server is listening to port 80 using a tool such as ss or netstat. These guides outline how to use these programs:

https://www.linux.com/learn/intro-to-linux/2017/7/introduction-ss-command

http://www.thegeekstuff.com/2010/03/netstat-command-examples/

In most cases you can use either command with the options interchangeably. Something like ss -plnt will show listening processes with TCP sockets by numerical ports. This will help identify what processes are listening on what TCP ports to give you an overall idea of the listening services running on the Droplet. If you don’t see the port and address ( a public listening address, not for example 127.0.0.1 or localhost ) you expect, this typically indicates a configuration issue. Re-configure the server and restart the service. Verify the web server is listening on the correct port then test it again.

If you do see the web server is running and listening on the expected port and address the most likely problem here is the firewall. The configuration for the firewall can vary from system to system based on your deployment stack ( fail2ban, CSF, etc ), but these guides will help you work with the firewall to verify the configuration or you can attempt to save your current rules, flush or disable the firewall temporarily and verify if the firewall is the issue:

https://www.digitalocean.com/community/tutorials/iptables-essentials-common-firewall-rules-and-commands