3

I am trying to reroute from http to https. For example you visit example.com and you will be automatically redirected to https://example.com.

I tryed using this one:

server {
      listen         80;
      return 301 https://$host$request_uri;
}

as well as this one:

server {
      listen         80;
      server_name    example.com;
      return         301 https://$server_name$request_uri;
}

as found here : In Nginx, how can I rewrite all http requests to https while maintaining sub-domain?

But neither of seem are wokring for me. I am staying on example.com.

Anyone got an idea?

Community
  • 1
thotho
  • 31
  • 1
  • 1
  • 4
  • Did you clear your browser cache? – Michael Hampton Apr 05 '15 at 18:28
  • Yes, I also tryed it on other devices that have never visited the site before. – thotho Apr 05 '15 at 18:41
  • Just to cover the basics, you reloaded the nginx service? Does running `# nginx -t` tell you of any errors? Is there anything in your error logs? Are you connecting to the server from an IPv4 address? – Paul Apr 05 '15 at 19:48
  • nginx -t is is telling me that the syntax is ok and that the test was succesfull and the error logs aren't showing anything either. And yes I am only using IPv4 addresses. – thotho Apr 05 '15 at 19:55
  • Actually you problem lies in somewhere else. This piece of code is working. Add logging to your server definition and check nginx logs for access and errors. – Navern Apr 06 '15 at 09:17
  • @Navern my error log is telling me this :`2015/04/05 19:54:42 [notice] 3221#0: signal process started 2015/04/06 13:27:48 [notice] 868#0: signal process started ` – thotho Apr 06 '15 at 14:50

3 Answers3

6

You haven't defined a server name for your host. 

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

otherwise your host is not called. When you look to the example you can see that there is a server name defined in both cases.

René Höhle
  • 1,418
  • 3
  • 17
  • 26
4

I had a similar fault. Instead of redirecting the page kept 404.

Turned out to be a conflict between the configurations.

My config were put in /etc/nginx/conf.d/. What I did not notice was that in /etc/nginx/sites-enabled/ a default config was located which also listened on port 80 wich had higher precenednce than my conf in conf.d. Simply by removing the default config resolved my issue and the redirect worked properly.

christofferp
  • 41
  • 1
  • 1
    i have a default in ./sites-enabled and removing it solved my problem, but it works fine on one server and not on the other. Removing default makes it work but I cannot figure out why it is conflicting. – chovy Nov 11 '18 at 22:13
0

Your second example will work for any requests going to http://example.com, however remember that www.example.com and example.com are different so if you needed to redirect for anything at example.com you could do 

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

or else redirect for each host, i.e.

server {
      listen         80;
      server_name    www.example.com example.com images.example.com cdn.example.com;
      return         301 https://$server_name$request_uri;
}

Make sure you both test the config via nginx -t and reload the configuration when you make changes via a nginx reload. You can test what your getting via either live http headers or curl

The below output is what I see when trying a http header request to a domain that we direct to https with the exact server block above.

$ curl -I -L http://host.domain.com
HTTP/1.1 301 Moved Permanently
Server: nginx/1.6.2
Date: Mon, 06 Apr 2015 03:26:39 GMT
Content-Type: text/html
Content-Length: 184
Connection: keep-alive
Location: https://host.domain.com/

HTTP/1.1 200 OK
Server: nginx/1.6.2
Date: Mon, 06 Apr 2015 03:26:41 GMT
Content-Type: text/html; charset=utf-8
Connection: keep-alive
Vary: Accept-Encoding
X-Powered-By: PHP/5.5.22
Set-Cookie: PHPSESSID=dca72682392e7ac96d4b7703ea7a1eb1; path=/; domain=domain.com; secure; HttpOnly
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Set-Cookie: PHPSESSID=c910822f8007fe8c0424715a24aa4728; path=/; domain=domain.com; secure; HttpOnly
Jchieppa
  • 168
  • 3
  • 10
  • Thank you very much, the first version was working for me! – thotho Apr 06 '15 at 13:32
  • sadly too early.. it worked on my notebook and phone once but now it's not working anymore.. – thotho Apr 06 '15 at 14:48
  • `curl -I -L http://example.com` is giving me this unreadable reply: oU<▒ ▒▒x8▒▒▒▒S#vR▒*▒ ▒▒w▒K~jO▒▒▒▒C9L▒▒/.▒S▒9tU▒▒▒1▒▒▒͚Ø)$E▒▒p!▒7|▒Hy▒o▒8 – thotho Apr 06 '15 at 15:19
  • Check curl -V to see if libz is included, my guess is compressed content and curl cannot decode it. Otherwise that server block is correct, so start checking outside factors including making sure the dns entry is correct and requests are actually going to this nginx host. Check the backend if nginx isn't your primary webserver and you should also check for any other server blocks in nginx with the same server as they may be setup for port 80 and grabbing precedence. More information about your infastructure may help us provide you with better ideas. – Jchieppa Apr 06 '15 at 16:14
  • Well I'd guess nginx is working correctly and no other servers are using Port 80 because I am getting this message `Welcome to nginx on Debian! If you see this page, the nginx web server is successfully installed and working on Debian. Further configuration is required.` when opening http://example.com. Let me tell you my setup. I got a Raspberrry Pi 2 with the base of OSMC. Ontop of it I installed my own cloud with Seafile and I have Seafile running behind nginx. Also pyLoad running on Port 8000. So that shouldn't interfere either. If visiting https://example.com everything is working fine! – thotho Apr 06 '15 at 19:27