Like the help template says, we’ll need your full unredacted config. It’s impossible for us to answer your question without it. That’s true generally, and especially in your case since each matcher is different.
lemmy.tld {
header {
# Only connect to this site via HTTPS for the two years
Strict-Transport-Security max-age=63072000
# Various content security headers
Referrer-Policy same-origin
X-Content-Type-Options nosniff
X-Frame-Options DENY
X-XSS-Protection "1; mode=block"
# disable FLoC tracking
Permissions-Policy interest-cohort=()
}
@encode_mime {
header Content-Type text/css
header Content-Type application/javascript
header Content-Type image/svg+xml
}
encode @encode_mime gzip
request_body {
max_size 8MB
}
@pictshare_regexp path_regexp pictshare_regexp \/pictshare\/(.*)
redir @pictshare_regexp /pictrs/image/{re.pictshare_regexp.1} permanent
@backendpath {
path /api/*
path /pictrs/*
path /feeds/*
path /nodeinfo/*
path /.well-known/*
}
@acceptheader {
header Accept application/*
}
@backendmethod method POST
reverse_proxy @acceptheader backend:1234
reverse_proxy @backendmethod backend:1234
reverse_proxy @backendpath backend:1234 {
transport http {
versions 1.1
}
header_up Upgrade {http.request.header.upgrade}
header_up Connection upgrade
header_down -Transfer-Encoding
header_up X-Real-Ip {http.request.remote.host}
}
reverse_proxy frontend:1234
}
Essentially, I’m trying to translate this nginx config to Caddy. It is working, but I was curious to know if there was a way to avoid writing those three lines.
This doesn’t really do anything for you. Caddy will negotiate the HTTP version with the upstream automatically. It enables HTTP 1.1 and HTTP 2 support, and turning off HTTP 2 support has no benefit really.
Remove these. Caddy passes through headers transparently, and supports websocket upgrades automatically.
You don’t need this either, Caddy’s proxy sets the X-Forwarded-For header which has the IP address of the remote connection.
Why do you remove this header? I doubt this is necessary.
It was a necessary fix for a downstream service, but I believe it has been fixed there and that directive is likely no longer needed.
mm, that’s certainly a way to do it yeah, but it’s rather messier. What would you do?
Would be really nice if Caddy had first party support for explicit AND’ing and OR’ing matchers.