2 months ago
Hi Railway Support,
we have a reproducible networking issue affecting only this Railway service when calling OpenAI - MTA-Group Project
What we confirmed:
1. From our local machine:
- GET https://api.openai.com/v1/models works correctly
- POST https://api.openai.com/v1/embeddings works correctly
- TLS handshake and certificate validation complete successfully
- the OpenAI API key is valid
2. From this Railway-hosted service:
- DNS resolution works for api.openai.com
- but outbound requests to OpenAI time out before TCP/TLS is established
- our diagnostics show DNS timing, but no TCP connect time and no TLS timing
- this affects both:
- GET /v1/models
- POST /v1/embeddings
- official OpenAI Node SDK requests
Example behavior from our service diagnostic endpoint:
- hostname resolves
- no HTTP status is returned
- request times out
- this happens consistently from the Railway environment for this specific service
Important point:
- this is not a global OpenAI issue
- this is not a local-network issue on our side
- this is not caused by an invalid API key
- the problem appears specific to outbound connectivity from this Railway service/environment
Could you please investigate:
- outbound HTTPS connectivity from this specific service/environment to api.openai.com:443
- whether there is any issue with egress routing, firewalling, NAT, or connection establishment for this service
- whether this service is on a problematic host/node or network path compared to other working Railway services
If needed, we can provide:
- exact timestamps in UTC
- deployment/service/environment IDs
- diagnostic output from the Railway-hosted endpoint
- local test output showing successful access to the same OpenAI endpoints
Thanks.
Pinned Solution
2 months ago
Hello tomaszkadziela-repulse,
i think what's happening is that your service resolves api.openai.com, gets an ipv6 address back first, railway can't route it, tcp never connects , which is exactly why you see dns timing but no tcp or tls timing.
to fix this add this env variable to your railway service and redeploy
NODE_OPTIONS=--dns-result-order=ipv4first
this forces node.js to prefer ipv4 when resolving hostnames
source: https://docs.railway.com/guides/public-networking (outbound networking section)
Hope this help you :)
2 Replies
Status changed to Awaiting Railway Response Railway • about 2 months ago
Status changed to Open brody • about 2 months ago
2 months ago
Hello tomaszkadziela-repulse,
i think what's happening is that your service resolves api.openai.com, gets an ipv6 address back first, railway can't route it, tcp never connects , which is exactly why you see dns timing but no tcp or tls timing.
to fix this add this env variable to your railway service and redeploy
NODE_OPTIONS=--dns-result-order=ipv4first
this forces node.js to prefer ipv4 when resolving hostnames
source: https://docs.railway.com/guides/public-networking (outbound networking section)
Hope this help you :)
2 months ago
Hi,
it worked perfectly 👍
Adding the NODE_OPTIONS=--dns-result-order=ipv4first resolved the issue right away.
Thanks a lot for your help — really appreciate it! 😊
Status changed to Solved sam-a • about 2 months ago