0

OMG! I just solved problem just change this return 301 https://example.dev$request.uri; to this value return 301 https://example.dev$request_uri;

More specifically request.uri was invalid !!!


My aim is to redirect all requests to the https://example.dev

  • http://example.dev successfully redirects to the https://example.dev
  • http://www.example.dev successfully redirects to the https://example.dev
  • https://www.example.dev fails when redirecting to the https://example.dev

In the firefox:

An error occurred during a connection to www.example.dev.

The page you are trying to view cannot be shown because an error in the data transmission was detected.

    Please contact the website owners to inform them of this problem.

GoogleChrome redirects to the https://example.devget%20/%20HTTP/2.0.uri. And fails again.

Here is the my nginx configuration:

# Load dynamic modules. See /usr/share/doc/nginx/README.dynamic.
include /usr/share/nginx/modules/*.conf;

events {
    worker_connections 1024;
}
http {
    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    access_log  /var/log/nginx/access.log  main;
    ...
    ...
    server {
        listen       80;
        listen       [::]:80 ipv6only=on;
        server_name  www.example.dev example.dev;
        return 301 https://example.dev;

        # Load configuration files for the default server block.
        include /etc/nginx/default.d/*.conf;

        error_page 404 /404.html;
        location = /404.html {
        }

        error_page 500 502 503 504 /50x.html;
        location = /50x.html {
        }
    }

    server {
        listen 443 ssl http2;
        server_name www.example.dev;
        ssl_certificate /etc/letsencrypt/live/example.dev/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/example.dev/privkey.pem;

        return 301 https://example.dev$request.uri;
    }

    server {
        listen 443 ssl http2;
        server_name example.dev;
        ssl_certificate     /etc/letsencrypt/live/example.dev/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/example.dev/privkey.pem;

        location / {
                proxy_pass http://localhost:8080/;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header X-Forwarded-Proto $scheme;
                proxy_set_header X-Forwarded-Port $server_port;
        }
   }

}
monstereo
  • 830
  • 11
  • 31

1 Answers1

0

I have a similar config, and to redirect all to https I just:

server {

    server_name  example.dev www.example.dev *.example.dev;
    charset     utf-8;

    location / {
        ...
    }

    listen 443 ssl; # managed by Certbot
    ssl_certificate /path/to/fullchain.pem; # managed by Certbot
    ssl_certificate_key /path/to/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
}


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

Where the critical part is the second server block that catches everything with default_server (this tells nginx to use this block for urls that do not match anything else*) and redirects to https.

* Note that in this config there is only one listen 80 block, so that would always be the default even without explicitly using default_server :)

Also, if you are wondering why server_name example.dev www.example.dev *.example.dev; is so verbose, here's this excerpt from nginx docs, regarding how patterns are matched to the server names:

Regular expressions are tested sequentially and therefore are the slowest method and are non-scalable.

For these reasons, it is better to use exact names where possible. For example, if the most frequently requested names of a server are example.org and www.example.org, it is more efficient to define them explicitly:

rosaqq
  • 426
  • 4
  • 16
  • Thank your for your answer. But I solved the problem. I shouldn't use request.uri. It should be request_uri :) (It was a typo issue) – monstereo Oct 05 '21 at 20:35