10 months 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
10 months ago
322ea2ee-d764-421d-9d11-77dde0980f62
10 months ago
I rarely use Caddy, so it could be something totally obvious
10 months ago
if I bounty this will you try to help op?
10 months ago
10 months ago
!t
10 months ago
no bounty possible 😦
10 months ago
ohkay
10 months ago
Would it be acceptable to post this also directly on the station to get it bountified :D
10 months ago
This thread has been escalated to the Railway team.
Status changed to Awaiting Railway Response brody • 10 months ago
10 months ago
oop
10 months ago
hey now I can bounty it
10 months 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
10 months 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.
10 months ago
The screenshot I sent shows a log of all incoming headers. Headers are seen and printed correctly locally.
10 months ago
Oh. The screenshot didn't attach.
Here it is. Just a screenshot of what headers my backend is receiving. 
Attachments
9 months ago
When hosting Caddy locally, with the same config, this issue does not exist. It appears to be a Railway issue.
9 months 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.