[SOLVED]Nginx seafile https redirected to http

I am migrating to nginx from apache2 and I cannot get the https to work. I followed these tutorials but it does not help:

I am also running a http server other than nginx so I cannot bind to that port as in the tutorials.

proxy_set_header X-Forwarded-Proto https; seems to be ignored?
When visiting the https of my seafile website it redirects to my http server with different contents. I cannot disable that http server so I cannot do the redirect http to https or Strict transport security in the tutorials. Is there any other way to redirect https to https and not https to http.

here is the curl output:
$ curl -I https://myserver.com
HTTP/2 302
date: Mon, 02 Apr 2018 07:03:15 GMT
content-type: text/html; charset=utf-8
vary: Accept-Language, Cookie
location: http://myserver.com/accounts/login?next=/
content-language: en
server: myhttpserver

here is the stripped config: of seafile nginx
server {

     include /etc/nginx/mime.types;
        listen 443 ssl http2;
        ssl on;
        # certs sent to the client in SERVER HELLO are concatenated in ssl_certificate
        ssl_certificate /etc/letsencrypt/live/xxxx.com/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/xxxx.com/privkey.pem;
        ssl_session_timeout 1d;
        ssl_session_cache shared:SSL:50m;
        ssl_session_tickets off;

        # Diffie-Hellman parameter for DHE ciphersuites, recommended 2048 bits
        ssl_dhparam /etc/nginx/dhparam.pem;

       # intermediate configuration. tweak to your needs.
        ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
        ssl_prefer_server_ciphers on;

        ## verify chain of trust of OCSP response using Root CA and Intermediate certs
        ssl_trusted_certificate /etc/letsencrypt/live/xxxx.com/chain.pem;

     server_name xxxx.com;
     access_log /var/log/nginx/seafile.access.log;
     error_log /var/log/nginx/seafile.error.log;
     error_page 500 502 503 504 404 403 501 401 xxxx/error.html;


      proxy_set_header X-Forwarded-For $remote_addr;

  #add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";
  #add content security policy,secure headers here OWASP
      location / {

             proxy_set_header   Host $host;
             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 $server_name;
             proxy_set_header   X-Forwarded-Proto https;

             # used for view/edit office file via Office Online Server
             client_max_body_size 0;

             access_log      /var/log/nginx/seahub.access.log;
             error_log       /var/log/nginx/seahub.error.log;
             proxy_read_timeout  1200s;

        location /seafhttp {

            rewrite ^/seafhttp(.*)$ $1 break;
            client_max_body_size 0;

            proxy_connect_timeout  36000s;
            proxy_read_timeout  36000s;
            proxy_send_timeout  36000s;

            send_timeout  36000s;
        location /media {
            root /home/seafile/seafile-server-latest/seahub;


I discovered a very similar problem a week or so ago and found a solution. I posted it in the forums… Here it is:

Change this line:

         proxy_set_header   Host $host;

to this:

         proxy_set_header   Host $host:$server_port;

Try that and let me know if it works.

It returns to http again with 400 bad request.

400 Bad Request
The plain HTTP request was sent to HTTPS port

$ curl -I https://zxxxxxx.com
HTTP/2 302 
date: Mon, 02 Apr 2018 07:57:19 GMT
content-type: text/html; charset=utf-8
vary: Accept-Language, Cookie
location: http://xxxxx.com:443/accounts/login?next=/
content-language: en

Ok… What happens if you try with a different browser? Does it do the same thing? I don’t see anything else wrong with your NGinx configuration, so it could be a browser history/autocorrect thing.

Yes, I have tried other browsers. It does not redirect to https that is the problem, I also did not added this line in the port 80 since http is used for some other web service:

server {
    listen       80;
    server_name  seafile.example.com;
    #redirect http to https
    rewrite ^ https://$http_host$request_uri? permanent;    # force redirect http to https

    # Enables or disables emitting nginx version on error pages and in the "Server" response header field.
    server_tokens off;

the proxy_set_header X-Forwarded-Proto https;
is not obeyed by nginx?

Your Nginx config is very similar to mine. I don’t see a problem with it and mine is working ok. Have you checked your service_url in the config files for Seafile, and also within the admin interface? Also, after that last edit to Nginx, I’m assuming you restarted NGinx.

Yes, I have checked and crosschecked my ccnet and seahub_settings has https in the site name, I have restarted nginx and seafile as well.

BTW, you may want to add this line to your NGinx file just below the first listen. It allows IPV6 connections to be encrypted as well… Doubt that’s going to solve your problem, but it’s really the only thing different between your config and mine:

listen [::]:443 http2;

But, what about the web interface, admin settings? Those now take priority over the ccnet and seahub settings files.

I have not changed that it is still pointing to https mysite. I am not using Ipv6.

I NAILED IT! IT WAS SQUID PROXY blocking X-Forwarded options. I wasted much time here.

Did you obtain new certificates from letsencrypt or are you using the same ones you had with Apache?

I used the certs in apache, it was renewed recently. anyway the squid proxy was the problem.

Ok. That may be your problem. Apache places the chains in separate files. NGinx expects them in one file. You’ll either need to concatenate the existing chains, or obtain new certificates more friendly to NGinx. Here is how to concatenate, about 1/3 of the way down the page where it talks about chains, but it would probably be easier to obtain new ones for NGinx…


I obtained the ceritficate by the standalone option not tailored for apache nor nginx. Anyway it works now, it was the local squid proxy caused the problem

Yeah, I just saw that… .It’s 4 am and I’ve had a couple of glasses of wine… The words on my monitor are playing tricks on me. :wink:

Can you place [SOLVED] at the beginning of the title for us? I’ll have someone also mark your solution as the… well… solution. :slight_smile:

@shoeper - Please mark Zoro’s solution as the solution. Thanks in advance.

You can configure the reverse proxy to listen on the HTTPS port (e.g., 443) and forward the requests to the Seafile Nginx server (running on a different port like 8000).
Configure the reverse proxy then Set up a virtual host or server block in the reverse proxy configuration for your domain (myserver.com ).
Within the reverse proxy configuration for your domain, use the proxy_pass directive to forward requests to the Seafile Nginx server running on a different port (e.g., 8000).

The proxy_set_header directives are correctly set within the reverse proxy configuration to pass the necessary headers to the Seafile Nginx server. This includes the X-Forwarded-Proto header to indicate that the original request was made via HTTPS.

you dig up posts more than 5 years old on which a solution has been provided