Since upgrade, WebUI redirects with NGinx on alternate listen port [Possible Bug] [Work-Around]

Since I upgraded to 6.2.X from 6.1.X, I’m unable to access the webui via my domain. I get a 404 error on So, it appears to be trying to redirect. I am using a custom port, say 7777. So, I key, and I get the 404 error on the URL I mentioned above.

I checked the NGinx log and here is the error I’m getting: ( is an actual IP address in the log, btw. Obscured it here for security purposes.)

2018/03/14 12:37:17 [error] 673#673: *21300 open() “/usr/share/nginx/html/accounts/login” failed (2: No such file or directory), client:, server: localhost, request: “GET /accounts/login?next=/ HTTP/1.1”, host: “

I’ve checked the html folder mentioned, and it doesn’t exist.

The odd thing is, if I use a computer internal to the network, I can key and it lets me log in. But, it will not with my custom port number.

I’ve checked the UI settings and the service URL is set correctly, Same with the service URL in the config files.

I’ve cross referenced my NGinx configuration with the manual and it matches, excepting my listen port is 7777.

There are no errors in the seafile logs. Seafile desktop clients and android app are working perfectly. Uploads, downloads, syncing works perfectly. It’s only the web interface I’m having a problem with.

Any help would be appreciated.

Please let us show your config. Are you using fastcgi instead of proxy_pass? I haven’t the file /usr/share/nginx/html/accounts/login.

Advice: If you use TLS you can use http/2 instead http/1.1, it’s faster.

No… I disabled fastcgi per the instructions in the manual when I upgraded. Which config files do you want me to include here?

Here is my NGinx configuration:

You should look at the following URL’s in order to grasp a solid understanding

of Nginx configuration files in order to fully unleash the power of Nginx.

Generally, you will want to move this file somewhere, and start with a clean

file but keep this around for reference. Or just disable in sites-enabled.

Please see /usr/share/doc/nginx-doc/examples/ for more detailed examples.

Debian Seafile server configuration

server {
listen 7777;

proxy_set_header X-Forwarded-For $remote_addr;

location / {


fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

fastcgi_param PATH_INFO $fastcgi_script_name;

fastcgi_param SERVER_PROTOCOL $server_protocol;

fastcgi_param QUERY_STRING $query_string;

fastcgi_param REQUEST_METHOD $request_method;

fastcgi_param CONTENT_TYPE $content_type;

fastcgi_param CONTENT_LENGTH $content_length;

fastcgi_param SERVER_ADDR $server_addr;

fastcgi_param SERVER_PORT $server_port;

fastcgi_param SERVER_NAME $server_name;

fastcgi_param REMOTE_ADDR $remote_addr;

    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;
    # fastcgi_read_timeout 36000;

  location /media {
    root /home/Seafile-Server/seafile-server-latest/seahub;

# location /seafdav {
#    fastcgi_pass;
#    fastcgi_param   SCRIPT_FILENAME     $document_root$fastcgi_script_name;
#    fastcgi_param   PATH_INFO           $fastcgi_script_name;

#    fastcgi_param   SERVER_PROTOCOL     $server_protocol;
#    fastcgi_param   QUERY_STRING        $query_string;
#    fastcgi_param   REQUEST_METHOD      $request_method;
#    fastcgi_param   CONTENT_TYPE        $content_type;
#    fastcgi_param   CONTENT_LENGTH      $content_length;
#    fastcgi_param   SERVER_ADDR         $server_addr;
#    fastcgi_param   SERVER_PORT         $server_port;
#    fastcgi_param   SERVER_NAME         $server_name;

#    client_max_body_size 0;

#    access_log      /var/log/nginx/seafdav.access.log;
#    error_log       /var/log/nginx/seafdav.error.log;


Ok, so I tried stopping seafile and seahub. When I do that, I get “Bad Gateway”. So, it appears that NGinx is indeed communicating with Seafile since the error is different.

I’m at a complete loss here. I’ve gone through my configuration files for both NGinx and Seafile, and everything appears to be set up properly. There are no errors logged with Seafile and it works perfectly. The only problem I have is accessing the web interface from a different listen port in NGinx. This only began to occur after upgrading from 6.1.X to 6.2.X and disabling fastcgi as recommended in the manual. The only log file that reports anything in with either program is in NGinx, the error.log file located in the var folder that holds logs for NGinx.

Any advice would be appreciated. I’ve enjoyed Seafile over the years, but I may have to consider other options if this isn’t resolved.

More information:

It appears that NGinx or something is redirecting back to port 80. I noticed in the browser when I keyed “sample,”, what pops up next in the browser is “” rather than “”, which explains why there is a “404 Not Found” error, and also an error in error.log rather than seahub.error.log.

I’ve noticed on NGinx threads that others have stated that this happens when an application attempts to force the URL port within it. So, I’m going to assume that either the Seafile manual is missing a critical setting for the NGinx config file or that there is a bug in Seafile Server that is causing this issue.

You’re in the region of undefinied Ports. May Seafile forces port 8000 or 8001 in this region.

Yeah, it worked fine prior to version 6.2.X. The manual still details using an alternate port with NGinx, but it appears that it no longer works with the webui. However, it’s working fine with syncing and file transfers to and from Seafile. I’m hoping that either someone can figure out what I’m doing wrong, or that the programmers can ID the problem.

I don’t know if it’s a problem of the forum, but listen have to stand behind {.
Like there:

server {
_ _ _ _ listen 7777;
_ _ _ _ server_name…

Further info: I’m pretty sure it’s a bug. If I log into Seafile via webui using port 8000, and then open another window and use 21001, it works. The 21001 does not disappear or redirect. It appears that only happens with /accounts/login, when you first initiate the webui from the alternate port. Something has definitely changed somewhere, where the port number is dropped on the initial request to grab the login page.


I’m not certain what you mean… Are you saying use “listen7777” rather than “listen 7777”? I’ve never had to remove that space on any of my web servers.

That was just a misstake. So first you can use port 8000 and then only port 21001 works? May I have an idea.

No… not only port 21001 works if I already logged in, but both do. But, if I do the initial login on 21001, it drops the port number from the URL. The app itself is supposed to handle that, but it isn’t working properly. I’m currently looking at an NGinx work around called proxy_redirect. If it works, I’ll post the solution here, and try to contact a developer to either fix Seafile Server in the next version, or include the solution in their manual.

Unfortunately, I’ve run out of time and I have an appt or two to make today, so I’ll try later this evening and let you know.

Just found another potential solution… proxy_set_header Host $host:$server_port; instead of just plain $host

Or you have to have to delete and create a new ccnet-db. Then Seafile will load everything from ccnet.conf. Maybe there’s a problem.

I’ve never created a new ccnet-db and my conf file is as follows:

ID = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
NAME = Seafile

Also, the service URL is no longer important here. It’s handled elsewhere and can be set from the webui, which now takes precedence over the ccnet file. I have verified that it is correct in the webui settings.

Marking this as resolved. Replacing “proxy_set_header Host $host;” with “proxy_set_header Host $host:$server_port;” solved the problem.

Glad your issue has been solved.
I actually experienced the same behavior and others experienced it too, when running nginx on any other than the default port. I just recently posted the same solution in another thread (german).

I’d love to have the official server manual updated accordingly!

I issued a pull request for an update to the manual last week after coming up with that solution.

1 Like