Seeing ERR_CONNECTION_REFUSED when I try to load my website

Hey guys,

I can’t access my website? Why?

My free SSL has 90 days, it’s too many days to finish. Can I turn off my droplet? Will my web site delete if I turn off droplet?

My website is I have ssh, I try to connect with Cyberduck but I can’t access.

I see ERR_CONNECTION_REFUSED when I try to load the website. Help me, please.

Submit an answer

This textbox defaults to using Markdown to format your answer.

You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!

Sign In or Sign Up to Answer

These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

Want to learn more? Join the DigitalOcean Community!

Join our DigitalOcean community of over a million developers for free! Get help and share knowledge in Q&A, subscribe to topics of interest, and get courses and tools that will help you grow as a developer and scale your project or business.

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:

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 ss or 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 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:


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
Starting Nmap 7.70 ( ) at 2020-01-15 20:12 IST
Nmap scan report for
Host is up (0.15s latency).

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.