Nginx http to https not functioning remotely

Question

I've attempted to utilize the other answers on this site to fix a http redirect for a YouTrack installation on a DO Droplet, but none have worked so I'm posting this question with a synopsis of what I've found. Because this affects the root domain, I'll stay focused on root domain information and assume that a fix will apply to any subdomains.

I currently have a sites-available config with two files currently enabled.

example

server {
    listen 80 default_server;
    listen [::]:80 default_server;

    server_name *.example.com;
    return 301 https://$host$request_uri;
}
server {

    server_name example.com;

    listen 443;
    #certbot stuff... This works correctly
}

youtrack

server {
    #youtrack certbot https setup. Works correctly.
}

Currently, I can visit https://example.com and https://projects.example.com without any issue. However, when I attempt to visit http://example.com or http://projects.example.com, I get a timed out connection error.

Using curl -I -L http://example.com on the remote server provides this information:

HTTP/1.1 301 Moved Permanently
Server: nginx/1.10.3 (Ubuntu)
Content-Type: text/html
Connection: keep-alive
Location: https://example.com

HTTP/1.1 200 OK
...

However, using curl -I -L http://example.com on a local machine hangs waiting for a response.

Connection timeout usually means bad routing (not probable if the HTTPS connection does work), or firewalling. Maybe someone only opened HTTPS (port 443) and not HTTP (port 80). — wurtel, May 31 '18 at 07:48
This turned out to be the case. I did not even think to check the firewall to see if I was allowing port 80! If you were to post this as an answer I'll mark it correct. Thank you very much! — FefeHern, May 31 '18 at 16:00

score 0 · Accepted Answer · answered Jun 04 '18 at 10:25

Connection timeout usually means bad routing, or firewalling. Bad routing is not probable as the HTTPS connection does work, and routing is in the general case not dependent on packet content(*).

Maybe someone only opened HTTPS (port 443) and not HTTP (port 80) in the firewall, not expecting HTTP to be used.

(*) In Linux you can use iptables to mark packets and then use those firewall marks in the advanced routing capabilities of Linux to route those packets differently, but that would be exceptional.

Nginx http to https not functioning remotely

1 Answers1