do you use serverless? could it be a cold start? how are the metrics when you see long response times?

Hi there! To answer your question right up front: No, this is not a bandwidth problem in the Railway routing layer, nor is it noisy neighbors. Your Rust service and the Railway infrastructure are actually performing perfectly.

The key to understanding what's happening lies in comparing two specific metrics in your Envoy proxy logs:

• upstreamRqDuration: 1: This means your Rust backend received the request, processed it, and handed the entire ~326 KB response (txBytes: 326911) back to Railway's edge proxy in exactly 1 millisecond. Your service is lightning fast.

• totalDuration: 29157: This is the total time from when Railway's edge proxy received the request from Vercel until the connection was finally closed.

Because the internal hop took only 1ms, Railway's edge router essentially spent ~29 seconds waiting on the downstream connection to Vercel. Since cloud-to-cloud bandwidth between Vercel and Railway is massive, this isn't a general network bottleneck. The delay is almost certainly happening on the Vercel client side.

Here are the three most likely culprits:

1. Vercel Serverless Timeout (Most Likely) Your totalDuration of 29.1 seconds is suspiciously close to the standard 30-second execution timeout limit for many Vercel Serverless functions. If your Vercel Node client initiates the fetch but fails to properly consume or close the response stream (e.g., a missing await, or an unhandled promise), Railway's proxy will hold the connection open until Vercel forcefully kills the stalled function at the ~30-second mark.

2. TCP Backpressure from a Pass-Through Proxy If your Vercel app acts as a pass-through and streams this API response directly to an end-user, Vercel can only read the data from Railway as fast as the end-user can download it. If the end-user is on a slow network, that TCP backpressure travels up the chain, forcing Railway's proxy to slowly trickle the 326 KB out over 29 seconds.

3. Node.js Event Loop Blocking If Vercel downloads the payload but immediately runs heavy, synchronous processing (like massive JSON parsing) before the stream fully finishes, the Node.js event loop blocks. It stops draining the TCP buffer, and Railway has to wait for Vercel to free up before it can push the rest of the bytes over the wire.

Next Steps: I highly recommend checking the Vercel code making the /search request. Look for hanging promises, unconsumed streams, or synchronous blocks directly after the fetch call.