Saving links is slow with nginx as reverse proxy

[taeganwarren]

I have set up an nginx reverse proxy with linkding with ssl on my domain. When I access the app over the ip and port, everything works fine, the app is fast as expected with all tasks such as adding/deleting links, etc.

When using an nginx reverse proxy with ssl, the app slows down greatly, often taking over 30 seconds to add a new bookmark. This is most likely an issue with my nginx configuration but I am not sure what I need to change.

I set up linkding with the docker commands:
docker volume create linkding_data
docker run --name linkding -p 9001:9090 -v linkding_data:/etc/linkding/data -d sissbruecker/linkding:latest

Then adding my nginx configuration

server {
        listen 443;

        server_name linkding.mydomain.com;

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

        location / {
                proxy_set_header Host $http_host;
                proxy_set_header X-Forwarded-Proto https;
                proxy_pass http://localhost:9001;
        }
}

The app looks as expected with styling and everything, but the saving of links is very slow. What do I need to change or add in this configuration?

[sissbruecker]

Mhh I'm afraid I can't help you there, I'm not familiar with this. Two things you could check:

• What happens when saving? Maybe there's some redirect loop in the browser or in nginx? Although that would probably never resolve then.
• Enable verbose logging in nginx and check if there is some indication what is taking up the time.
• Try to reproduce your setup with a different proxy server like Caddy to maybe narrow down the problem to nginx.

[wadimklincov]

I had the same issue and using a separate upstream statement fixed it for me:

upstream linkding_server {
  server 127.0.0.1:9090;
}
[...]
  location / {
    proxy_pass http://linkding_server;
    proxy_set_header Host $http_host;
    proxy_set_header X-Real-IP $remote_addr;
    ...
  }

I haven't debugged it a lot, but looking at the linkding output it seemed like the /api/booksmarks/check and /bookmarks/new calls took quite some time and I haven't seen any other requests, so no loops or similar:

[pid: 13|app: 0|req: 10/101] 172.31.0.1 () {48 vars in 1105 bytes} [Sun Mar 21 20:24:39 2021] GET /api/bookmarks/check/?url=https%3A%2F%2Fsome.site.com%2Fmodules => generated 140 bytes in 10027 msecs (HTTP/1.0 200) 5 headers in 150 bytes (1 switches on core 1)
[pid: 17|app: 0|req: 39/102] 172.31.0.1 () {56 vars in 1124 bytes} [Sun Mar 21 20:24:42 2021] POST /bookmarks/new => generated 0 bytes in 10049 msecs (HTTP/1.0 302) 5 headers in 152 bytes (1 switches on core 1)
[pid: 17|app: 0|req: 40/103] 172.31.0.1 () {50 vars in 1021 bytes} [Sun Mar 21 20:24:52 2021] GET /bookmarks/close => generated 2960 bytes in 7 msecs (HTTP/1.0 200) 4 headers in 124 bytes (1 switches on core 0)

[sissbruecker]

@wadimklincov Interesting observation, one guess would be that the function that tries to load the website title + description (called in both /check and /new) either times out or is very slow. Reasons could be:

• website can not be resolved
• website responds very slowly (unlikely, that would not be reproducable)
• some other network issue that stalls requests made by the Django server

[taeganwarren]

In my case, my docker was not configured correctly and was by default blocking every outgoing request from every container, so the requests from linkding to the bookmarked websites were timing out. I just had not noticed as no other container I had needed to make any outgoing requests. After fixing this configuration, linkding worked correctly. My apologies!