Frequent 502 errors when using radicale behind nginx reverse proxy

[claman]

I've looked through the available issues and discussions and haven't been able to find anything that seems to mirro to my situation.

• both radicale and nginx start and run as expected, reading from their respective config files
  • radicale is set up to operate at cal.mydomain.net/radicale (not the actual URL)
  • nginx is serving another different subdomain with zero issues
• for the first couple of minutes that both are running, I can access the radicale instance through the web interface and sync calendars with clients
• after about 2-3 minutes (haven't timed it specifically) the web interface login page errors out (502 error), but the base URL is still completely accessible
  • i.e., cal.mydomain.net can still be opened normally (shows the expected default "nginx is working" page) but cal.mydomain.net/radicale is inaccessible
• after this point, Thunderbird cannot sync with the server, but the iOS calendar still seems to be able to sync normally
• completely restarting both radicale and nginx resolves the issue and clients are once again able to sync, but then the connection errors out again within 2-3 minutes

There is every chance that this is some simple user error on my part, but I've tried all of the relevant fixes I could find here and nothing has worked. Happy to give more errors logs, etc. if that's helpful.

---

radicale config

[auth]
type = htpasswd
htpasswd_filename = ~/.config/radicale/users
htpasswd_encryption = bcrypt
# Average delay after failed login attempts in seconds
delay = 1

[server]
hosts = 0.0.0.0:5232
max_connections = 20
# 100 Megabyte
max_content_length = 100000000
# 30 seconds
timeout = 30
# add SSL encryption
ssl = True
certificate = /etc/letsencrypt/live/redactedURL/fullchain.pem
key = /etc/letsencrypt/live/redactedURL/privkey.pem

[storage]
filesystem_folder = ~/calendars

# [rights]
# type = from_file
# file = ~/.config/radicale/rights

nginx config

server {
    server_name     redactedURL;

    location /radicale/ {
        proxy_pass              https://localhost:5232/;
        proxy_set_header        X-Script-Name /radicale;
        proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header        Host $http_host;
        proxy_pass_header       Authorization;
    }

    listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/redactedURL/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/redactedURL/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

}
server {
    if ($host = redactedURL) {
        return 301 https://$host$request_uri;
    } # managed by Certbot


    server_name     redactedURL;
    listen 80;
    return 404; # managed by Certbot
}

error from nginx log -- this error is repeated several times

2024/11/06 22:33:44 [error] 22412#22412: *8728 connect() failed (111: Connection refused) while connecting to upstream, client: [ip address redacted], server: redactedURL, request: "PROPFIND /radicale/[user]/ HTTP/1.1", upstream: "https://[::1]:5232/[user]/", host: "redactedURL"

[pbiering]

from your configuration I see

• nginx is listen on 443 with TLS enabled
• radicale is listen on 0.0.0.0:5232 (explicit IPv4 "any")
• nginx is forwarding the request to localhost:5232

From log I see that nginx tries to connect (suddenly) to https://[::1]:5232/... with result "connection refused"

The "connection refused" is expected because radicale is neither listen on IPv6 "any" nor on IPv6 "localhost"

The nginx behavior is somehow expected because localhost can resolve to 127.0.0.1 or ::1 (and therefore causes this flapping)

Proposed fix:

• radicale config (not really required, but securing config):

- hosts = 0.0.0.0:5232
+ hosts = 127.0.0.1:5232

• nginx config:

- proxy_pass              https://localhost:5232/;
+ proxy_pass              https://127.0.0.1:5232/;

Please reopen if issue still exists afterwards.