Custom domain name with reverse proxy?

[Roemer]

Describe your issue

I am using a custom nginx reverse proxy and custom compose stacks for deployments.
In my nginx, I have this entry:

# Wikidocs
server {
    listen      443 ssl;
    server_name wiki.mydomain.com;
    include conf.d/ssl.conf;

    location / {
        proxy_pass              http://wikidocs:80;
        client_max_body_size    0;
    }
}

and wikidocs looks like:

services:
  wikidocs:
    image: zavy86/wikidocs:1.0.81
    container_name: wikidocs
    environment:
      - PUID=1000
      - PGID=1000
    volumes:
      - wikidocs-data:/datasets
    networks:
      - service-net

volumes:
  wikidocs-data:

networks:
  service-net:
    external: true

Nginx is also in the service-net network.

This basically works but when I try to login in wikidocs, it redirects the browser to http://wikidocs/homepage?auth. Is this because my service or container is named like this? Is there a way to override this url? Most other services provide an environment variable like BASE_URL or WIKIDOCS_HOST or WIKIDOCS_URL or something that allows to manually set the url that should be used to build all links.

Device and settings

Running wikidocs in Docker with Compose

Steps to reproduce

See description

Screenshots (optional)

No response

Extra fields

• I'd like to work on this issue

[leomoon]

This is the server section I have as reverse proxy in nginx for wikidocs.

Is the nginx reverse proxy on the same host? then it must be referenced with 127.0.0.1:port#
If it is another host in the same LAN, then the IP of that host with wikidocs' port...

server {
        allow 127.0.0.1;
        allow 192.168.50.0/24;
        allow 10.8.0.0/24;
        deny all;
    listen               443 ssl http2;
    include              /etc/nginx/snippets/security_headers.conf;
    server_name          wiki.domain.ext;
    recursive_error_pages on;
    ssl_certificate      /etc/letsencrypt/live/wiki.domain.ext/fullchain.pem;
    ssl_certificate_key  /etc/letsencrypt/live/wiki.domain.ext/privkey.pem;
    # ssl_stapling         on;
    # ssl_stapling_verify  on;
    ssl_protocols        TLSv1.2 TLSv1.3;
    ssl_ciphers          'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384';
    ssl_session_cache    shared:SSL:10m;
    ssl_session_timeout  10m;
    add_header           X-Frame-Options "SAMEORIGIN";
    add_header           X-XSS-Protection "1; mode=block";
    add_header           X-Content-Type-Options "nosniff";
    add_header           Referrer-Policy "origin";
    add_header           Permissions-Policy "camera=(), microphone=(), geolocation=()" always;
    add_header           Strict-Transport-Security "max-age=31536000; includeSubDomains; preload;" always;
    # no cache
    add_header           Last-Modified $date_gmt;
    add_header           Cache-Control 'no-store, no-cache, must-revalidate, proxy-revalidate, max-age=0';
    if_modified_since    off;
    expires              off;
    etag                 off;
    error_page 400       /error/400.html;
    error_page 401       /error/401.html;
    error_page 403       /error/private.html;
    error_page 404       /error/404.html;
    error_page 500       /error/500.html;
    error_page 502       /error/502.html;
    error_page 503       /error/503.html;
    location ~ /\.(git|env|htaccess|htpasswd) {
        deny all;
        return 404;
    }
    location / {
        client_max_body_size 10m;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $http_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-Proto https;
        proxy_pass http://127.0.0.1:3030; #proxyPass
        proxy_redirect off;
        proxy_buffering off;
    }
    location ^~ /error/ {
        internal;
        alias /var/www/default/error/;
        allow all;
    }
}

[Roemer]

I did some more research and found how the url is set:

define("HOST",(isset($_SERVER['HTTPS'])?"https":"http")."://".$_SERVER['HTTP_HOST']);
...
define("URL",HOST.PATH);

So it uses the host from the request. Fortunately, this can be overriden in nginx with proxy_set_header Host $host;
so my new nginx config looks like:

# Wikidocs
server {
    listen      443 ssl;
    server_name wiki.mydomain.com;
    include conf.d/ssl.conf;

    location / {
        proxy_pass              http://wikidocs:80;
        proxy_set_header    Host $host;
        client_max_body_size    0;
    }
}

and now it seems to work correctly.

[Zavy86]

can I close the issue?

[Roemer]

Maybe we should document the nginx configuration somewhere? But beside that, yes it can be closed.

[Roemer]

There are some more headers that should probably be set:

# Wikidocs
server {
    listen      443 ssl;
    server_name wiki.mydomain.com;
    include conf.d/ssl.conf;

    location / {
        proxy_pass              http://wikidocs:80;
        proxy_set_header        Host $host;
        proxy_set_header        X-Forwarded-Host $host;
        proxy_set_header        X-Forwarded-Proto $scheme;
        proxy_set_header        X-Forwarded-Port $server_port;
        client_max_body_size    0;
    }
}

[Zavy86]

Hi @leomoon, when you have time, could you update the nginx part, you who are more experienced?

https://github.com/Zavy86/WikiDocs?tab=readme-ov-file#nginx-configuration

[Roemer]

There are a few more issues.
For example if I expose my nginx with a different port eg:
8443:443
Then most of the links are wrong (eg. Edit Document or print) but some are also correct like Settings or Add new document.
It seems that the wrong ones use $DOC->URL which just uses the host and igores the ports from the proxy and those that work seem to use $APP->PATH. Maybe that should be unified?

[leomoon]

The only way that I know this works is to do specific IP for proxy pass.
proxy_pass http://127.0.0.1:3030; #proxyPass

Or other how in the LAN
proxy_pass http://192.168.1.x:3030; #proxyPass

[Roemer]

This should not work as wikidocs is served on port 80 or can this be changed (like to 3030 in your example)?

[leomoon]

Since your wikidocs is using port 80 I'm guessing it is not the same nginx host (nginx needs 80 and 443).

Then please try this
proxy_pass http://lan-ip-of-wikidocs-host:80/; #proxyPass

[Roemer]

Both nginx and wikidocs run in Docker so I can give them whatever ports I want.
Wikidocs runs on an internal network on port 80 and nginx on port 8443:443 (so externally 8443 and from Docker networking side internally on 443) so I just use proxy_pass: wikidocs:80
The proxy part works but when accessing the wikidocs page on port 8443, some links correctly append this port to urls and some don't, which then don't work.

[ffiesta]

Hi,

I found this on another webpage,

@Roemer please check if you can cobfigure ngnix proxy.

"... NGINX
This is a minimal example of a config that configures NGINX as a reverse proxy. The full documentation about NGINX as reverse proxy can be found here.

It's assumed that An Otter Wiki is running either in a docker container or as a uwsgi process and listening on port 8080.

server {
    server_name wiki.domain.tld;
    listen 80;
    location / {
        proxy_set_header Host $http_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 $http_host;
        proxy_pass http://127.0.0.1:8080;
        client_max_body_size 64M; # for attachments of a size up to 64 Mb
    }
}