Here is support answer. ıt ıs really hard for me. I am not professor.
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:
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:
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
netstat. These guides outline how to use these programs:
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: