tldr: It seems hikari compresses responses (and therefore drops Content-Length) but railway-edge doesn't?

What we’re seeing

Our service’s responses come back from two different edge proxies at different times — the Server: header moved between railway-hikari and railway-edge — with no deploy or config change on our side. The two behave differently:

• railway-edge (legacy): no response compression. Content-Length preserved, no chunking.
• railway-hikari (new): compresses responses on the fly (gzip/brotli) whenever the request carries Accept-Encoding: gzip/br. Side effects: Content-Length is dropped, response switches to Transfer-Encoding: chunked.

Reproduction (GET any object, direct to the *.up.railway.app domain):

• Accept-Encoding: identity → Content-Length: , no Content-Encoding (both proxies).
• Accept-Encoding: gzip → on railway-hikari: Content-Encoding: gzip, no Content-Length, Transfer-Encoding: chunked. On railway-edge: unchanged, Content-Length still present.

The compression is done by the proxy, not our app (our app returns identical bytes/headers either way — even a small text/plain response gets gzipped through hikari). It also compresses binary/octet-stream payloads, which are already compressed — so it adds cost and breaks Content-Length for no benefit.

Why it’s a problem

We sit behind a CDN (Cloudflare) that always sends Accept-Encoding: br, gzip to the origin, so on hikari every response loses Content-Length. Strict HTTP clients that require Content-Length then fail. The proxy assignment seems to have changed so behavior is intermittent.

Questions:

• Is there a supported way to disable response compression on the new proxy (per service)? Does it honor Cache-Control: no-transform from the origin?
• Why does the proxy assignment change between railway-hikari and railway-edge with no deploy/config change? Is it stable, or auto-migrated?
• Can we pin a service to a specific proxy?