Sync requests timing out at ~170 s behind reverse proxy I’ve been working to deploy Joplin

Support
1

Operating system

Linux

Joplin version

3.4.2

Sync target

Joplin Server

What issue do you have?

I’ve been working to deploy Joplin Server behind a reverse proxy (Caddy), and I’m running into persistent timeouts.

Problem

Sync requests from clients will hang and then fail after ~170 s.

Joplin Server logs show the TaskService loop (Process shared items) completing quickly (20–30 ms), so the app itself isn’t stuck.

The issue appears only when going through the proxy. Direct access to the server port works instantly.

Environment

Joplin Server v3.4.2 running in Docker

Reverse proxy: Caddy, terminating TLS, forwarding to joplin-server:22300

What I’ve tried

Verified that /api/ping through proxy responds correctly.

Observed that sync (/api/sync) hangs until proxy closes at ~170 s.

Adjusted proxy timeouts (read/write) higher, which avoids the cutoff, but sync shouldn’t take that long in the first place.

Confirmed there’s no database load (Postgres queries return immediately).

Questions

Has anyone else seen sync requests hang when proxied, but not direct?

Could this be related to app_base_url or forwarded headers (X-Forwarded-Proto, X-Forwarded-Host)?

What’s the recommended proxy configuration for Joplin Server to handle sync reliably?

Any advice from those successfully running Joplin Server behind a reverse proxy would help. Right now I’m stuck between raising proxy timeouts artificially high or watching sync fail at ~170 s.

2

I’m running through a caddy reverse proxy without any such issues. I would suspect some dns problems affecting your setup, but of course there is a limitless amount of other possibilities related to your operating systems across all OSI spectrum.

3

Would you mind sharing your Caddy block? Mine is

(tls_cloudflare) {
        tls {
                dns cloudflare {env.CADDY_CLOUDFLARE_API_TOKEN}
        }
}

# ############################ JOPLIN NOTES #########################
joplin.example.com {
        import tls_cloudflare

        request_body {
                max_size 1GB
        }

        reverse_proxy http://joplin-server.home.arpa {
                header_up Host {host}
                #header_up Origin {scheme}://{host}

                # Allow large uploads
                transport http {
                        read_buffer 64MB
                        response_header_timeout 10m
                        dial_timeout 30s
                }
        }
}
4

it’s not clear to me why do you limit request_body max_size and i don’t set any transport settings, i have header_up as well and IP address instead of domain - which again repeats my DNS-related suspicions.

5

Both max body size and the explicit transport setting were attempts to diagnose the issue.

DNS resolves properly in both the joplin-server container and in the proxy. To be sure I had changed from name to IP, but it had no effect -- so I reverted that change.

6

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