Hey! I had the same question, so I decided to test it myself. The good news is that you're not doing anything wrong.

I built a minimal Node app that calls res.writeEarlyHints() immediately and then delays the final response by about 1.2 seconds, making it easy to see whether the two responses arrive separately. Running it locally with curl -v, I can clearly see the 103 Early Hints being sent before the 200 OK, exactly as expected.

I then deployed the exact same app to Railway and tested it in production using both curl -v and a raw Node https client listening for the information event, just to rule out any client-side behavior. In both cases, the 103 response never arrived. Only the final 200 OK was received about 1.2 seconds later.

The interesting part is that the final response includes a custom header I added, confirming that the app did call writeEarlyHints(). That tells me the request is reaching the application correctly, but the informational response isn't making it back to the client.

Since the response headers show Server: railway-hikari, my best guess is that Railway's edge proxy isn't forwarding 1xx responses at the moment. From what I can tell, the feature works correctly in the application itself, but the proxy appears to be dropping the 103 Early Hints before they reach the client.

It would be great to get confirmation from the Railway team on whether this is a known limitation or something that's planned to be supported in the future.

No, Railway's Edge Proxy and CDN do not currently support passing HTTP 103 Early Hints directly from the origin server to the client. If you want to leverage Early Hints without needing Railway's edge to support it natively, the industry-standard workaround is to place a CDN like Cloudflare in front of your Railway domain.