0

I keep getting too many redirects error when I try to redirect non https. Read lots of other questions but I can't find what I'm doing wrong.

Is there a way to log the redirects to debug this?

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

server {
  listen 443 ssl;
  listen [::]:443 ssl;
  server_name *.example.com;
  return 301 $scheme://example.com$request_uri;
}

server {
  listen 443 ssl;
  listen [::]:443 ssl;  
  server_name example.com;

  include /etc/nginx/include.d/ssl-example.conf;

  root /var/www/example/public;
}

Not sure what I'm missing compared to this: https://serverfault.com/a/821888/86582

netstat -plutn

Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 127.0.0.1:25            0.0.0.0:*               LISTEN      30386/master    
tcp        0      0 0.0.0.0:443             0.0.0.0:*               LISTEN      12585/nginx -g daem
tcp        0      0 0.0.0.0:2589            0.0.0.0:*               LISTEN      26976/sshd      
tcp        0      0 127.0.0.1:3306          0.0.0.0:*               LISTEN      4892/mysqld     
tcp        0      0 127.0.0.1:11211         0.0.0.0:*               LISTEN      16417/memcached 
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      12585/nginx -g daem
tcp6       0      0 ::1:25                  :::*                    LISTEN      30386/master    
tcp6       0      0 :::443                  :::*                    LISTEN      12585/nginx -g daem
tcp6       0      0 :::2589                 :::*                    LISTEN      26976/sshd      
tcp6       0      0 :::80                   :::*                    LISTEN      12585/nginx -g daem
udp        0      0 213.138.111.4:123       0.0.0.0:*                           5945/ntpd       
udp        0      0 127.0.0.1:123           0.0.0.0:*                           5945/ntpd       
udp        0      0 0.0.0.0:123             0.0.0.0:*                           5945/ntpd       
udp6       0      0 fe80::fcff:ff:fe00::123 :::*                                5945/ntpd       
udp6       0      0 2001:41c8:51:604::4:123 :::*                                5945/ntpd       
udp6       0      0 ::1:123                 :::*                                5945/ntpd       
udp6       0      0 :::123                  :::*                                5945/ntpd  

Update: sorry I've now discovered that if I remove the redirects and try to server a basic https at https://example.com/ it wont recognise this server block and displays the default server block.

If I uncomment the listen 80 it reads this block. Any ideas what I could of done wrong?

server {
  #listen 80;
  #listen [::]:80;
  listen 443 ssl;
  listen [::]:443 ssl;

  server_name example.com;

  ssl on;

  ssl_certificate /etc/nginx/ssl/example/cert.pem;
  ssl_certificate_key /etc/nginx/ssl/example/key.pem;

  ssl_trusted_certificate /etc/nginx/ssl/sf_bundle-g2-g1.crt;

  ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
  ssl_ciphers 'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH';
  ssl_prefer_server_ciphers on;
  ssl_dhparam /etc/nginx/ssl/dhparam.pem;

  root /var/www/example/public;

  access_log /var/log/nginx/example.access.log;
  error_log  /var/log/nginx/example.error.log; 

  location ~ \.php$ {
    fastcgi_param PHP_VALUE open_basedir="/var/www/example/public/:/tmp/:/tmp/:/usr/share/";
    include /etc/nginx/include.d/php.conf;
  }

  location / {
    try_files $uri $uri/ /index.php$is_args$args;
  }
}

Curl output:

$ curl -I -L http://example.com
HTTP/1.1 200 OK
Date: Thu, 29 Nov 2018 16:18:37 GMT
Content-Type: text/html; charset=UTF-8
Connection: keep-alive
Set-Cookie: __cfduid=da26b551f0feb6bc34fb453d0596a312c1543508317; expires=Fri, 29-Nov-19 16:18:37 GMT; path=/; domain=.example.com; HttpOnly
Vary: Accept-Encoding
Strict-Transport-Security: max-age=63072000; includeSubdomains
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
Server: cloudflare
CF-RAY: 4816642ae74d641b-FRA

$ curl -I -L https://example.com
HTTP/2 200 
date: Thu, 29 Nov 2018 16:18:44 GMT
content-type: text/html; charset=UTF-8
set-cookie: __cfduid=d2caa15ab5204aadd1e0ca0279f0d79b21543508324; expires=Fri, 29-Nov-19 16:18:44 GMT; path=/; domain=.example.com; HttpOnly
vary: Accept-Encoding
strict-transport-security: max-age=63072000; includeSubdomains
x-frame-options: DENY
x-content-type-options: nosniff
expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
server: cloudflare
cf-ray: 48166452efc1641b-FRA
  • 1
    What is the URL you're tyring to access? Just example.com? www.example.com? something-else.example.com? – Oldskool Nov 29 '18 at 9:22
  • I want to redirect everything to example.com – John Magnolia Nov 29 '18 at 9:57
  • Yeah, I see that, but what is the URL that ends up in a redirect loop? All of them? Can you post the output of a curl -I -L some.example.com in the question as well? Would help to see what is actually happening. – Oldskool Nov 29 '18 at 9:58
  • 1
    Please be aware that a Permanent Redirect (a redirect with HTTP response code 301) is exactly that: permanent. Such a redirect will be cached by all common web browsers. - If you made a mistake in your server configuration and don't clear your caches (or don't do each new test in a new anonymous/incognito/private window) then any changes you make in the server configuration won't become apparent as your webbrowser will both use the stale cached redirect and change the request you enter in the URL bar for you even before it gets sent to a server. – HBruijn Nov 29 '18 at 10:26
  • @HBruijn comment makes complete sense. And also. Open your developer tools in your browser and in "Network" You can decide to keep the logs and see the exact redirects your server is sending you. Also curl -v $YOUR_ADDRESS will show the redirect, with more typing involved. – Oct Nov 29 '18 at 15:58
1

Your updated question shows as part of the header:

Server: cloudflare

A fairly typical problem is that you forward both the plain http and the https version of your site from your CDN CloudFlare to a http only back end. Even when the client uses https it will only be between their browser and cloudflare.

When on your server you try to enforce https that can never happen.

You should change your cloudflare settings to go to the https site on your backend server and also do the redirect to https from cloudflare.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.