Help with NGINX HTTPS Redirect


#1

Hoping someone can help sort through some of the weird behavior I’m seeing. There are a few things going on so I’ll try to clarify each one. Thanks in advance!

SETUP

  • Seafile 6.1.2 on Ubuntu Server 16.04
  • Let’s Encypt is configured
  • DDNS configured with DuckDNS
  • NGINX is using seafile.conf (default not in use)
  • Router is configured to forward port 443 to my server

WHAT’S WORKING

  • Internal access to server via https://internal-ip:8000
  • Internal access to server via https://myserver.duckdns.org
  • File upload/sync on local wifi using macOS Seafile Client (client configured to use https://myserver.duckdns.org)
  • File upload/sync using iOS Seafile Client over LTE (client configured to use https://myserver.duckdns.org)

WHAT’S NOT WORKING

  1. My computer has myserver.duckdns.org entered in /etc/hosts for SSH purposes. From this system, I can access myserver.duckdns.org in FireFox and it will redirect to https://myserver.duckdns.org and work as expected.
  • In Safari, I must specify ‘https’ for the site to load and something very odd: when I try to access the System Admin page, I get 401 Unauthorized. I can access this page fine in FireFox. I’ve cleared Safari Cache and Web History which makes on difference. Could this be something in my server’s config?
  • Using Edge Browser on a separate Windows computer (with no custom hosts file) accessing myserver.duckdns.org does NOT get passed to the server, but rather stops at my router and prompts me for my router login. Subsequently, I can enter my router login details here and access the router settings…
  1. Accessing myserver.duckdns.org from anywhere outside of my network does not work. Chrome, for example, will tell me ERR_CONNECTION_TIMED_OUT. Looking at /var/log/nginx/error.log on the server I see

2018/01/04 09:31:10 [error] 1124#1124: *13 connect() failed (111: Connection refused) while connecting to upstream, client: 71.33.130.223, server: myserver.duckdns.org, request: "GET /seafhttp/repo/6f376983-94bf-4d56-a4dd-c59696caf53c/commit/HEAD HTTP/1.1", upstream: "http://127.0.0.1:8082/repo/6f376983-94bf-4d56-a4dd-c59696caf53c/commit/HEAD", host: "myserver.duckdns.org"


Some additional info:

$ sudo nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

– seafile.conf –

server {
    listen 443 ssl;
    server_name myserver.duckdns.org;
    proxy_set_header X-Forwarded-For $remote_addr;

location / {
             proxy_pass         http://127.0.0.1:8000;
             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_read_timeout  1200s;

 # 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;
        }

        location /seafhttp {
            rewrite ^/seafhttp(.*)$ $1 break;
            proxy_pass http://127.0.0.1:8082;
            client_max_body_size 0;
            proxy_connect_timeout  36000s;
            proxy_read_timeout  36000s;
            proxy_send_timeout  36000s;
            send_timeout  36000s;
        }
        location /media {
            root /cloud/seafile-server-latest/seahub;
        }

        #listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/myserver.duckdns.org/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/myserver.duckdns.org/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

        # Redirect non-https traffic to https
         if ($scheme != "https") {
             return 301 https://$host$request_uri;
         } # managed by Certbot
    }

– seahub_settings.py –

    # -*- coding: utf-8 -*-
    SECRET_KEY = "*****" ----- REMOVED FOR POST
    FILE_SERVER_ROOT = 'https://myserver.duckdns.org/seafhttp'

    DATABASES = {
        'default': {
            'ENGINE': 'django.db.backends.mysql',
            'NAME': 'seahub-db',
            'USER': 'seafile',
            'PASSWORD': '*****', ----- REMOVED FOR POST
            'HOST': '127.0.0.1',
            'PORT': '3306'
        }
    }

– ccnet.conf –

[General]
USER_NAME = myserver
ID = ******  ------ REMOVED FOR POST
NAME = myserver
SERVICE_URL = https://myserver.duckdns.org:8000

[Client]
PORT = 13419

[Database]
ENGINE = mysql
HOST = 127.0.0.1
PORT = 3306
USER = seafile
PASSWD = ****** ----- REMOVED FOR POST
DB = ccnet-db
CONNECTION_CHARSET = utf8

#2

Just tested removing entry from hosts file, clearing browser cache, and rebooting. After performing this and going to myserver.duckdns.org stops at the router, asking for router login.

However, entering https://myserver.duckdns.org/accounts/login/?next=/ specifically DOES work both internally and externally.

It appears that when it fails to load myserver.duckdns.org there is no ‘/’ after the word login, so it fails on https://myserver.duckdns.org/accounts/login?next=/

EDIT: once I do try to login at the full working login URL, it times out (externally) or proceeds to request my router login details (internally)


#3

I don’t have much time to answer you but go to https://nohatech.se and the. Under guides you can find a guide how to setup seafile with ubuntu it will answer your question.

Edit:
Here is a direct link to the guide
https://nohatech.se/how-to-setup-seafile-with-ubuntu-server-16-04-lts/


#4

Thanks @Calby, though like I said, everything is functioning internally on LAN. I just can’t get the WAN piece working.

It appears that though my router has Port Forwarding set to pass 443 traffic to my seafile server, it’s not doing it. It’s stopping the traffic at the router and prompting to login to the router. I have a Netgear Nighthawk R7000.

I have other port forwards working, but seafile is the only one I’m opening for 443. Not sure if it’s a router setting, or something in the nginx config.


#5

FIXED! Turns out it was indeed my nginx configuration (/etc/nginx/sites-available/seafile.conf per install docs). I rewrote it altogether and got it working.