Is there a difference in the response types for these endpoints?

The only difference is the JSON payload structure, not the response type:

// /raw variant - simpler payload
{
status: 'completed',
service: { variant: 'raw' },
result: { /* data */ }
}

// /analyzed or /full variant - includes AI analysis
{
status: 'completed',
service: { variant: 'analyzed' },
result: { /* data */ },
analysis: {
summary: '…',
insights: […],
signals: {…}
}
}

All endpoints use identical handler returning Content-Type: application/json; charset=utf-8.

Live proof:
┌────────────────────┬────────┬─────────────────────────┐
│ Endpoint │ Status │ Content-Type │
├────────────────────┼────────┼─────────────────────────┤
│ /investment-report │ 402 ✅ │ application/json │
├────────────────────┼────────┼─────────────────────────┤
│ /whaleintel │ 502 ❌ │ text/html (nginx error) │
├────────────────────┼────────┼─────────────────────────┤
│ /whaleintel/raw │ 502 ❌ │ text/html (nginx error) │
├────────────────────┼────────┼─────────────────────────┤
│ /tokensniping/raw │ 402 ✅ │ application/json │
└────────────────────┴────────┴─────────────────────────┘
The text/html on blocked endpoints is nginx's 502 error page - request never reaches our app.

Critical: tokensniping/raw and whaleintel/raw use identical code, headers, and response format. Only difference is the path keyword. Both are POST + application/json.

This proves blocking is purely path-pattern based at Metal Edge level.

We do not use nginx to forward traffic for the metal edge.

Both endpoints, working (investment-report) and blocked (whaleintel) requests show identical headers:

• server: cloudflare

• x-proxy: cf-worker

• x-railway-edge: railway/europe-west4-drams3a

  Our app only returns JSON via jsonResponse() - never HTML. The nginx/1.22.1 502 HTML page comes from somewhere in Railway's infra before reaching our container. All 25 endpoints use identical code paths with no path-specific filtering.

  Is there a way to check Railway logs to see if these requests are even reaching our container?

Check the HTTP logs.

Either way, we are not blocking these URL patterns. This is something with Cloudflare or with your application.

502 Issue - Status Update

### Root Cause: Railway Edge Layer (NOT ports, NOT Cloudflare, NOT app)

Evidence:

1. Port configuration verified correct (8080 → nginx → 3402)

2. Direct Railway access shows same 502 (bypasses Cloudflare)

3. Same upstream, same Bun server - partial path failures The issue is likely in Railway's infrastructure, likely at the Metal Edge layer, despite their claim of not blocking these patterns. The nginx/1.22.1 error might be Railway's default error page format.

PROOF: Our application returns 402, client receives 502

Log evidence from 2026-01-14 20:31:23 UTC:

REQUEST: POST /x402/bitquery/whaleintel
APP LOG: "Request completed, status: 402"
CLIENT: Received 502 Bad Gateway (nginx/1.22.1)

^

Hi Railway team,

I wanted to follow up and apologize for the confusion regarding the 502 errors we reported.

After extensive debugging with detailed header logging, we discovered the issue was caused by our own nginx configuration, not Railway's infrastructure.

Root cause: Our nginx proxybuffersize was set to the default 4KB, but our x402 payment protocol headers (containing base64-encoded payment challenges with outputSchema definitions) were exceeding 4KB for certain endpoints (~4.3KB).

Fix: We increased proxybuffersize to 16KB in our nginx config. All endpoints now work correctly.

Thank you for your patience and for confirming that Railway doesn't use nginx for Metal Edge traffic - that key insight helped us redirect our investigation to the right place.

Apologies again for the misdirected investigation. Railway's infrastructure is working exactly as expected.

Glad you found the solution!