Remember a debug process — connection

Written byKalanKalan
💡

If you have any questions or feedback, pleasefill out this form

This post is translated by ChatGPT and originally written in Mandarin, so there may be some inaccuracies or mistakes.

Introduction

About a few months ago, I started experiencing inexplicable connection refused issues with my Google Chrome. Sometimes certain web pages just wouldn't load, while they worked perfectly fine on other devices. Although it felt odd, I thought it might be a server configuration issue, and since it didn't cause any major inconvenience, I continued using it as is.

Setting Up a Custom Domain

Later, after casually purchasing a .dev domain, strange things began to happen. I set up the CNAME and confirmed that the SSL was active, but no matter how many times I refreshed in Chrome, it kept showing CONNECTION_REFUSED. Typically, this problem can arise from a couple of sources: either the server isn't opening the port, or there might be a firewall configuration issue. I checked these two settings and found nothing amiss. To be extra cautious, I used dig xxx.dev +nostats +nocomments +nocmd to verify if the CNAME was set up correctly. Everything was fine.

Next, I looked into the SSL issue. I used the SSL checker to check if the SSL was configured correctly, and it was.

Okay, maybe it just takes a while for the settings to propagate, so I waited 10 minutes and tried again, but still no luck; Chrome still displayed the dreaded CONNECTION_REFUSED. I then checked on my mobile device and found that I could access the webpage successfully.

At this point, I began to suspect that there might be an issue with some settings on my computer, so I started checking relevant configurations. First, I ran curl blog.kalan.dev to see what would happen. I encountered the following error:

curl: (7) Failed to connect to blog.kalan.dev port 80: Connection refused

Hmm, the results from Chrome matched what I got from curl, further confirming that there was something wrong with my computer's settings. I then used wget to investigate further.

wget https://blog.kalan.dev
--2019-03-18 23:11:46--  https://blog.kalan.dev/
Resolving host blog.kalan.dev (blog.kalan.dev)... 127.0.0.1, 0.0.0.1
Connecting to blog.kalan.dev (blog.kalan.dev)|127.0.0.1|:443... failed: Connection refused.
Connecting to blog.kalan.dev (blog.kalan.dev)|0.0.0.1|:443... failed: No route to host.

Wait a minute, it resolved the host to 127.0.0.1? Does this mean I added this domain to my hosts file? I had no recollection of doing that, but I decided to check both the /etc/hosts and /private/etc/hosts files.

The result was the same; I hadn't set the domain in my local hosts file, but at least I had an idea of what was going wrong. It appeared that some configuration had caused blog.kalan.dev to resolve to 127.0.0.1. At this point, I was completely baffled as to the possible causes. However, while experimenting, I noticed something strange: any xxx.dev domain exhibited the same issue, while other domains did not.

Then it hit me. About four years ago, I had downloaded Powder to learn Ruby on Rails. In short, it allows you to conveniently start a server while accessing a website, which is incredibly handy! So I happily installed it back then.

But then I took a closer look at the official documentation and found that session 3_1 states:

The POW_DOMAINS environment variable specifies a comma-separated list of top-level domains for which Pow will serve DNS queries and HTTP requests. The default value for this list are the two test,dev domains, meaning Pow will configure your system to resolve *.test and *.dev to 127.0.0.1 and serve apps in ~/.pow under the .test and .dev domains.

Oh, so that's it! It turns out you redirected my IP to 127.0.0.1, and since my computer wasn't opening port 443, I ended up with a CONNECTION_REFUSED error. So, the web pages I couldn't access might also be using the .dev domain.

Here are a few things to note:

  • When you see CONNECTION_REFUSED, use wget to check the host connection.
  • Alternatively, use curl --ipv4 -v “your.site.com” to inspect the host connection.

If you found this article helpful, please consider buying me a coffee ☕ It'll make my ordinary day shine ✨

Buy me a coffee