New Install - Invalid origin error

I have tried it with Joplin Server 1.75 and the beta 2.05 but i get the same result

when i attempt to login i get

no matter what i try its the same result

I am using a postgres db
Any help would be appreciated

All tests were fresh installs, no residual data.
Using docker

Got the same error on Server 2.0.5 when the server listened behind a reverse proxy, but the domain the server was listening on was not the domain specified in the Docker's env vars.
Maybe check you have all those set correctly.

I have been using the Joplin server docker image behind an nginx reverse proxy. The last version I got to work was, 2.0.1 beta (using the SQLite db). I also had to use florider's version as the official one always started with data already in the admin account and an additional "user1" account. Even after a complete new, clean ubuntu / docker install!!

I then moved onto the later 2.x series using the same .env file and I always got "Invalid origin" regardless of the version. This suggests that the proxy and the Joplin server are not on speaking terms. If I reverted to the 2.0.1 version of the server it worked again. I am not a fan of the Docker concept and so it is currently a bit of a dark art to me and is likely to remain so. I didn't have the knowledge to troubleshoot the issue so I gave up.

Not exactly helpful but just to let you know that you are not the only one who has come across this... assuming it's the same problem :slight_smile:

Yes sorry this is not currently documented, but you need to make sure that your reverse proxy passes the origin properly to the Docker image.

I think it means having this on the Nginx config:

proxy_set_header host $host;

And this on Apache:

ProxyPreserveHost on
1 Like

Yep, that's it for nginx.

In case it helps anyone, this works for me:

server {

    location / {
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Forwarded-Port $server_port;
        proxy_set_header X-Forwarded-Host $host;
        client_max_body_size 400M;

I'm not saying all of those are needed, mind: I just set them by default to avoid trouble. :smiley:

edit: you may need to add Listen directive for ports. I just let certbot deal with it (and redirect to https.)


Thanks for sharing your config, the "client_max_body_size" property is important too. I guess once the server gets more stable we can put a sample Nginx and Apache config in the doc.

That we definitely should. It's always a hassle to figure out/troubleshoot when projects don't do that.


(Server now working :slight_smile: )

1 Like

In case anyone is interested this is an nginx "sites-available" reverse-proxy file that uses self-signed certs, diverts port 80 to 443, adds a bit of hardening and also logging. It does work with 2.0.6-beta.

    listen 80;

    return 301$request_uri;

server {
    listen 443 ssl http2;

    proxy_read_timeout 720s;
    proxy_connect_timeout 720s;
    proxy_send_timeout 720s;

    client_max_body_size 50m;

    # Proxy headers
    proxy_set_header X-Forwarded-Host $host;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Real-IP $remote_addr;

    # SSL parameters
    ssl_certificate /path/to/certs/;
    ssl_certificate_key /path/to/certs/;
    ssl_protocols  TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers on;

    # log files
    access_log /var/log/nginx/;
    error_log /var/log/nginx/;

    # Handle / requests and redirect to a specific port on localhost
    location / {
       proxy_redirect off;

Replace with your domain and /path/to/certs/ and /path/to/certs/ with the real thing.

Then, with the real thing, sudo ln -s /etc/nginx/sites-available/ /etc/nginx/sites-enabled/

I got to this by butchering other examples, I am not an nginx expert.

1 Like

I'm kind of screwed, I'm using IIS 8 Url Rewrite

<?xml version="1.0" encoding="UTF-8"?>
        <httpRuntime requestPathInvalidCharacters="" />
        <pages validateRequest="false" />
                <rule name="ReverseProxyInboundRule1" stopProcessing="true">
                    <match url="(.*)" />
                    <action type="Rewrite" url="{R:1}" />
                        <set name="HTTP_X_ORIGINAL_ACCEPT_ENCODING" value="HTTP_ACCEPT_ENCODING" />
                <rule name="fix" preCondition="NeedsRestoringAcceptEncoding">
                    <match serverVariable="HTTP_ACCEPT_ENCODING" pattern="^(.*)" />
                    <action type="Rewrite" value="{HTTP_X_ORIGINAL_ACCEPT_ENCODING}" />
                    <preCondition name="NeedsRestoringAcceptEncoding">
                        <add input="{HTTP_X_ORIGINAL_ACCEPT_ENCODING}" pattern=".+" />


I'm getting the same result :frowning:
I have the variable APP_BASE_URL set to the url of the reverse proxy

Even if i try to hit it directly "" i get Invalid origin

I found a solution for us forced IIS users, you need to turn preserve host header on (Its off by default)
C:\Windows\system32\inetsrv\appcmd.exe set config -section:system.webServer/proxy -preserveHostHeader:true /commit:apphost

In a future version I'll probably remove this Origin check as it's only useful when there are different domains for main website, API, and user content. But when self-hosting you don't really need this.


I would really appreciate that - I currently have two setups (with and without proxy, which I use for note re-sync when necessary) and currently it means I have to stop the server and reconfigure APP_BASE_URL variable. Or make it an optional check that could be disabled.

1 Like

I would also highly appreciate removing the origin check or to add the possibility of a whitelist.

In my case the nginx proxy is served/configured by Opnsense which is unfortunatly not able to add the host header (at least not without doing some additional manual config operations).

So currently I have to stick to 2.0.1-beta version :frowning:

Hello all - I’m trying to migrate to the newest joplin server. I’m an embedded developer, so I suck at web stuff. What I’ve tried thus far:

I’ve stood up a new digital ocean ubuntu 20.04 instance, installed nginx, and setup a reverse proxy (successfully, I believe). I then attempted to perform the fix suggested by @laurent, but I am still getting the “Invalid origin” error. Below are my configuration files:

joplin-server .env file

# Example of local config, for development:

# Example of config for production:

nginx reverse proxy config file:

cat /etc/nginx/sites-available/reverse-proxy.conf 
server {
    listen 80;
    server_name localhost;
    location / {
        proxy_pass http://localhost:22300;
        proxy_set_header Host $host;

Don’t trash my configuration too hard :slight_smile: I’m learning web stuff

1 Like

Hello again everybody - I managed to get everything working, based on this guide in another thread. I also found that the latest desktop version of 2.1.7 only plays nice with the latest beta of joplin server (2.1.6-beta) according to this post. You can change which version of joplin server docker pulls down by changing the "latest" tag in the docker-compose.yml file to "2.1.6-beta". Current versions of apps/server playing happy together below:

Joplin Server: 2.1.6-beta
Android: 2.1.3
Windows Desktop: 2.1.7
iOS (ipad OS on iPad Pro 2020): 12.0.2
Ubuntu 2020.04: 2.1.7

Thanks all, and let me know if I can help.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.