Trilium: nginx reverse proxy

[affectiosus]

Hello,
I'm trying to run 0.28.3 with Docker behind a nginx reverse proxy, and I can't get the forwarding right. The nginx config suggested in the wiki works only for the setup page, further requests are ignoring /trilium/ in the path, rendering the app unusable. When I choose the username and password and click Finish Setup, the request is made to https://domain.com/api/setup/new-document when it should be made to https://domain.com/trilium/.... The relevant part of the config is (Docker instance port is 5051):

location /trilium/ {
  proxy_pass http://127.0.0.1:5051/;

  proxy_http_version    1.1;
  proxy_cache_bypass    $http_upgrade;

  proxy_set_header Upgrade            $http_upgrade;
  proxy_set_header Connection         "upgrade";
  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-Proto  $scheme;
  proxy_set_header X-Forwarded-Host   $host;
  proxy_set_header X-Forwarded-Port   $server_port;
}

I've tried with various combinations of proxy headers and/or rewrites and still I can't make it work.

Any help is greatly appreciated.

[Belphemur]

This is my config:

upstream trilium  {
      server 127.0.0.1:8080; #Trilium
}

server {
        listen 443 http2 ssl;
        include /etc/letsencrypt/options-ssl-nginx.conf;

        server_name mytrillium.com;
        ssl_certificate /etc/letsencrypt/live/mytrillium.com/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/mytrillium.com/privkey.pem;

        # Path to the root of your installation


        location / {
                proxy_set_header X-Real-IP $remote_addr;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header Host $http_host;
                proxy_set_header X-NginX-Proxy true;
                proxy_http_version 1.1;
                proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "Upgrade";
                proxy_redirect off;
                proxy_set_header        X-Forwarded-Proto $scheme;
                proxy_read_timeout 86400;
                proxy_pass http://trilium/;
                add_header   Front-End-Https   on;
        }
}

With this and let's encrypt taking care of the TLS cert, eveything works.

[MelBourbon]

I have the same issue using a virtual host with Nginx. Which means one host is listening on 443 and taking care of all connections, including SSL. This host then redirects based on the sub-folder (my-domain/sub-folder) to servers listening on localhost. For some services I have a additional config then to catch this (Nextcloud etc.) but for dockers who listen by their own this is normally not needed. For example Wekan is running perfectly on https://my-domain/wekan (different port on localhost).

But with Trilium (https://my-domain/trilium) it is not working even with the same Nginx settings. I only get to the setup page and by clicking "Finish Setup" nothing happens.

In my log only GET /setup is shown. Nothing more.

Nginx Config:

location /trilium/ {
            proxy_pass http://127.0.0.1:8080/;
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection 'upgrade';
            proxy_set_header Host $host;
            proxy_cache_bypass $http_upgrade;
            proxy_set_header Connection $connection_upgrade;
            proxy_set_header X-Forwarded-For $remote_addr; # preserve client IP
   }

[Belphemur]

It's possible trilium doesn't check for the current path when making AJAX request and assume the app is installed at the root.

To avoid those kinds of issue, I always use a subdomain per service and a different file for each service. This way everything is separated and there isn't any work to be done with location.

[affectiosus]

@Belphemur that's one way, yes. However, for example, I don't have control over the domain's DNS zone at all, so I can't use subdomains.

[MelBourbon]

@Belphemur I also have kind of one configuration file for each service with my setup. But I don't need to for example configure every time SSL separately etc. And I don't need to handle subdomains which is also nice. And in some instances using this approach with subfolders brings some security advantages.

[Belphemur]

@affectiosus & @MelBourbon After a cursory look of the code of the frontend (example setup page), I can confirm what I thought.

Trilium, in its current state, can't be installed in a folder.

See Here: https://github.com/zadam/trilium/blob/master/src/public/javascripts/setup.js#L65

It expects the route to be /api/XXX directly at the root of the domain on which it's hosted.

You'll have to see with @zadam if he has any project on letting the user set the path, I gather that would need some refactoring in the whole frontend.

[affectiosus]

@zadam could you clarify if it is planned to allow using Trilium in a folder?

[zadam]

Actually Trilium is meant to be usable inside a folder (or rather non-root path) - what @Belphemur found is a bug (which of course deserves a thank you) specific to setup, otherwise AFAIK the application should work correctly outside of the domain root. I'll fix the bug.

I'm trying to support this setup although it's not that well tested since I'm not personally using it.

[MetroWind]

Any progress? I'm using an Apache proxy, and running into the /api problem @Belphemur mentioned.

[zadam]

This has been fixed in 0.37.4.

[MetroWind]

There seems to be some left over /api issues. I couldn’t upload image. My server is at /trilium, and when I upload an image I see POST requests go to /api/images and fail with 403.

I have an apache setup (running 0.37.4 of course)

RewriteEngine On
RewriteCond %{HTTP:Connection} Upgrade [NC]
RewriteCond %{HTTP:Upgrade} websocket [NC]
RewriteRule /trilium/(.*) ws://localhost:8181/$1 [P,L]
ProxyPass /trilium http://localhost:8181
ProxyPass /trilium/ http://localhost:8181
ProxyPassReverse /trilium/ http://localhost:8181

I also see websocket request go to / and fail with 403.

[zadam]

@MetroWind thanks for reporting these issues! I have just released 0.37.5 which should fix both image upload and websocket issues.