We need an engineering-confirmed proxy trust boundary for an isolated Customer API using Fastify request.ip for security-sensitive rate limiting. Three controlled marked requests observed these nearest-to-farthest chains: - Socket 100.64.0.10 -> rightmost XFF 152.233.68.97 -> client address. - Socket 100.64.0.5 -> rightmost XFF 152.233.68.98 -> client address. - Socket 100.64.0.22 -> rightmost XFF 152.233.15.120 -> client address. Synthetic XFF/XReal inputs were absent; XReal matched leftmost XFF. We do not consider three samples sufficient to establish stable trusted ranges. Please confirm: 1. The supported exclusive ingress source ranges or another durable authenticated mechanism for recognizing your final proxy, including IPv6 behavior. 2. The operator and supported trust boundary of these 152.233 intermediary hops. 3. Header stripping/overwrite/append semantics with and without CDN routing, including whether the route/hop count can change. 4. Whether another private-network service can reach the application and supply forwarding headers, and how to prevent or distinguish such bypass traffic. 5. If address-based trust cannot be supported, your recommended secure design for this use case without trusting arbitrary forwarded headers. We can supply project/service/deployment IDs privately through an approved support channel. No client public IP, credentials, request bodies or customer data are included.

Engineering confirmation: secure proxy trust boundary for Fastify behind Railway

vaughnoryt

HOBBYOP

7 hours ago

We need an engineering-confirmed proxy trust boundary for an isolated Customer API using Fastify request.ip for security-sensitive rate limiting.

Three controlled marked requests observed these nearest-to-farthest chains:

Socket 100.64.0.10 -> rightmost XFF 152.233.68.97 -> client address.
Socket 100.64.0.5 -> rightmost XFF 152.233.68.98 -> client address.
Socket 100.64.0.22 -> rightmost XFF 152.233.15.120 -> client address.

Synthetic XFF/XReal inputs were absent; XReal matched leftmost XFF. We do not consider three samples sufficient to establish stable trusted ranges.

Please confirm:

The supported exclusive ingress source ranges or another durable authenticated mechanism for recognizing your final proxy, including IPv6 behavior.
The operator and supported trust boundary of these 152.233 intermediary hops.
Header stripping/overwrite/append semantics with and without CDN routing, including whether the route/hop count can change.
Whether another private-network service can reach the application and supply forwarding headers, and how to prevent or distinguish such bypass traffic.
If address-based trust cannot be supported, your recommended secure design for this use case without trusting arbitrary forwarded headers.

We can supply project/service/deployment IDs privately through an approved support channel. No client public IP, credentials, request bodies or customer data are included.

$10 Bounty

2 Replies

Railway

BOT

7 hours ago

This thread has been opened as a bounty so the community can help solve it.

Status changed to Open Railway • about 7 hours ago

vaughnoryt

HOBBYOP

7 hours ago

Railway team: please remove the $10 bounty designation from this thread. We want to keep the technical support question open, but do not want it listed as a bounty. Thank you.

0x5b62656e5d

MODERATOR

7 hours ago

Traffic comes from Railway's proxies (100.0.0.0/8; https://docs.railway.com/guides/spa-routing-configuration#option-1-caddy-recommended). To recognize the client, you'd just use the X-Real-IP header.
Railway's proxies lie within 100.0.0.0/8.
Railway overwrites headers such as XFF and XReal at the edge; hop count can vary.
Yes, another private network service can reach the application and supply forwarding headers. For prevention, unless the application was built to make such requests, users won't be able to access the private network to make requests from service A to service B over private networking.
You can use API tokens (for example) to issue rate limiting instead of just IP addresses.

Welcome!