0

I'm trying to configure nginx to work as following: Top-level domain, say example.com, being accessed by HTTP, redirects to HTTPS. All its subdomains must also redirect to HTTPS (obviously, subdomain must redirect to itself, but HTTPS).

Here is the configuration (file default):

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

        server_name example.com *.example.com;

        return 301 https://$host$request_uri;
}

server {
        listen 443 ssl default_server;
        listen [::]:443 ssl default_server;
        include snippets/ssl-example.com.conf;
        include snippets/ssl-params.conf;

        server_name example.com www.example.com;

        root /home/user/wwwroot;

        index index.html index.htm index.nginx-debian.html;

        location / {
                # First attempt to serve request as file, then
                # as directory, then fall back to displaying a 404.
                try_files $uri $uri/ =404;
        }
}

Here is the configuration for the 'yt' subdomain (file yt)

server {
   listen 443 ssl;
   server_name yt.example.com;

   location ^~ /.well-known {
      allow all;
      root /home/user/wwwroot;
   }

   location / {
       proxy_set_header        X-Real-IP       $remote_addr;
       proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
       proxy_set_header X-Forwarded-Host $http_host;
       proxy_set_header X-Forwarded-Proto $scheme;


       proxy_pass http://localhost:8080;
   }

}

As one can see, yt.example.com just passes the request to an application (Youtrack in this case).

Redirect for example.com and www.example.com works fine, but for yt.example.com it behaves strangely. When I access http://yt.example.com, nginx redirects to https://yt.example.com, but serves content root /home/user/wwwroot specified at the default file. When I hit the refresh button, my browser reloads the page at https://yt.example.com and then nginx passes the request to the application as I've expected. So when it redirects HTTP to HTTPS it does not pass the request, but when the request is already using HTTPS it successfully redirects.

I'm not an nginx-guru, so I need some help.

UPD.

@Tim asked to use "curl -i", so here is the input of curl -i yt.example.com:

HTTP/1.1 301 Moved Permanently
Server: nginx/1.10.0 (Ubuntu)
Date: Thu, 06 Apr 2017 09:08:26 GMT
Content-Type: text/html
Content-Length: 194
Connection: keep-alive
Location: https://yt.example.com/

<html>
<head><title>301 Moved Permanently</title></head>
<body bgcolor="white">
<center><h1>301 Moved Permanently</h1></center>
<hr><center>nginx/1.10.0 (Ubuntu)</center>
</body>
</html>

This is all of the curl's output.

Now logs of nginx. Error log is empty (the request is not in the error log), access log contains the following line for the request:

188.242.1.152 - - [06/Apr/2017:09:17:12 +0000] "GET / HTTP/1.1" 301 194 "-" "curl/7.40.0"

And the access log does not contain anything else.

UPD2.

I'm so sorry about that, I forgot to clear browser's cache after configuring nginx. So the browser actually did no request to my server.

0

In your http server, change the server name to only the subdomains you need.

server_name example.com www.example.com whatever.example.com;

I'm not sure this will work, but this is something to rule out first.

If it doesn't help please use "curl -i" to demonstrate the problem, with matching Nginx access and error logs. You should also check your application logs.

Incidentally, you probably don't want to serve content on https://example.com and https://www.example.com. You could have a block like this to forward www to the root domain.

server {
    listen 443 ssl default_server;
    listen [::]:443 ssl default_server;
    include snippets/ssl-example.com.conf;
    include snippets/ssl-params.conf;

    server_name www.example.com;

    return 301 https://example.com$request_uri;
}

Of course you need to remove that domain from the other server block. It's trivial to swap things around if you want to serve on www and forward the root domain.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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