a year ago
Any idea why my headers may not be arriving on the backend?
{
admin off
persist_config off
auto_https off
log {
format json
}
servers {
trusted_proxies static private_ranges
}
}
(lb_settings) {
lb_policy round_robin
lb_retries 100
lb_try_duration 10s
lb_try_interval 250ms
}
(passive_health_checks) {
fail_duration 60s
max_fails 300
unhealthy_latency 5s
unhealthy_request_count 200
}
:{$PORT} {
log {
format json
}
reverse_proxy {
dynamic a {
name {$FRONTEND_DOMAIN}
port {$FRONTEND_PORT}
refresh 1s
dial_timeout 30s
versions ipv4 ipv6
}
import lb_settings
import passive_health_checks
header_up Host {upstream_hostport}
header_up X-Real-IP {http.request.remote.host}
}
handle_path {$BACKEND_PATH:/api}/* {
reverse_proxy {
dynamic a {
name {$BACKEND_DOMAIN}
port {$BACKEND_PORT}
refresh 1s
dial_timeout 30s
versions ipv4 ipv6
}
import lb_settings
import passive_health_checks
header_up Host {upstream_hostport}
header_up X-Real-IP {http.request.remote.host}
}
}
}16 Replies
a year ago
322ea2ee-d764-421d-9d11-77dde0980f62
a year ago
I rarely use Caddy, so it could be something totally obvious
a year ago
if I bounty this will you try to help op?
a year ago
a year ago
!t
a year ago
no bounty possible 😦
a year ago
ohkay
a year ago
Would it be acceptable to post this also directly on the station to get it bountified :D
a year ago
This thread has been escalated to the Railway team.
Status changed to Awaiting Railway Response brody • 12 months ago
a year ago
oop
a year ago
hey now I can bounty it
a year ago
Caddy’s header_up directive is correct for passing headers to the upstream, but some headers (like Host and X-Real-IP) can be overwritten or filtered by Caddy or by the backend itself.
Make sure your backend is actually reading the headers you’re sending. For example, some frameworks expect X-Forwarded-For instead of X-Real-IP, to try adding X-Forwarded-For and X-Forwarded-Proto, and make sure your backend is looking for the right headers
a year ago
It looks like you're forwarding Host and X-Real-IP, which is good — but some headers like Authorization or X-Forwarded-For aren’t being passed, and those are often needed by backends for auth or logging.
If your backend depends on things like bearer tokens or real client IPs, it helps to explicitly pass Authorization, X-Forwarded-For, and X-Forwarded-Proto in both reverse_proxy sections.
Also worth making sure your backend is actually reading and logging all incoming headers, just to confirm what’s arriving. That usually makes it much easier to see what’s missing and adjust accordingly.
a year ago
The screenshot I sent shows a log of all incoming headers. Headers are seen and printed correctly locally.
a year ago
Oh. The screenshot didn't attach.
Here it is. Just a screenshot of what headers my backend is receiving. 
Attachments
a year ago
When hosting Caddy locally, with the same config, this issue does not exist. It appears to be a Railway issue.
a year ago
Issue also occurs with Nginx.
More reasons to believe it has nothing to do with the proxy config.
If I bypass either proxy and go straight to the backend, it works as expected.