No route to port 80 while HTTPS works

Question

I can't figure out how to troubleshoot this. Whenever I try opening a website using HTTP, I get something like:

$ wget example.com
Connecting to example.com (example.com)|<IP_HERE>|:80... failed: No route to host.

Meanwhile, HTTPS works fine:

$ wget https://example.com
Connecting to example.com (example.com)|<IP_HERE>|:443... connected.

Of course, my first places to look were my firewall and nginx configs. However, ufw shows port 80 as an already open port:

$ ufw allow http
Skipping adding existing rule
Skipping adding existing rule (v6)

...and the logic behind redirecting to HTTPS in my nginx config seems rather good to me:

listen 80; # managed by Certbot

listen 443 ssl; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem; # managed by Certbot
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

if ($scheme != "https") {
    return 301 https://$host$request_uri;
} # managed by Certbot

I have also tried nmap-ing the (Ubuntu 16.04) server both from the machine itself (nmap localhost) and from the external location (nmap <ip-here>). Surprisingly, HTTP seems to be closed from the external location. Disabling firewall also didn't help. netstat -lnp | grep "80" shows me that nginx is indeed listening on port 80:

tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      8845/nginx -g daemo

There's nothing written in the nginx logs.

I'm not sure where else to look. I can't pinpoint this issue.

Answer 1

Upon a server re-start, I've discovered that there was something wrong with nginx (I couldn't start it).

I then looked at journalctl -xe and discovered that nginx was missing one of the dependencies for a separate nginx config (php7.0-mbstring), which was preventing it from starting. The weird thing here is that doing nginx -t and restarting nginx via systemd didn't discover that error before the restart.

After the restart, I've made sure to install that missing PHP dependency. That made nginx start properly and the HTTP traffic forwarded to HTTPS from that point on.

My assumption to the core of this problem is that some PHP process had to be restarted (perhaps php7.0-fpm, I'm really not familiar with the PHP ecosystem) for the nginx to notice the dependency change, and that a combo of those two problems caused some really unexpected consequences.