This should not require a Railway domain whitelist. Railway's documented plan restriction is for outbound SMTP; normal HTTPS egress on port 443 is supported. The useful first step is to preserve the exact exception and test the same destination from inside the running replica without sending the API key.

Run these from the service shell/debug command (or temporarily at startup) and record the result, region and replica ID:

getent ahosts api.inceptionlabs.ai
curl -4 -sS -o /dev/null -w 'ipv4 http=%{http_code} connect=%{time_connect} tls=%{time_appconnect}\n' --connect-timeout 10 https://api.inceptionlabs.ai/v1/chat/completions
curl -6 -sS -o /dev/null -w 'ipv6 http=%{http_code} connect=%{time_connect} tls=%{time_appconnect}\n' --connect-timeout 10 https://api.inceptionlabs.ai/v1/chat/completions

A 401 or 405 is a successful network test here: it proves DNS, TCP and TLS reached the API; no secret-bearing request is needed. The current hostname is dual-stack behind CloudFront. Railway outbound IPv6 is opt-in and, while disabled, an IPv6 attempt can fail with ENETUNREACH. Therefore:

• If curl -4 reaches an HTTP response but curl -6 reports Network is unreachable, Railway is not blocking the domain. Either keep the client on IPv4/fallback correctly or enable Outbound IPv6 in the service Networking settings and redeploy.
• If both probes reach HTTP but the application still fails, log the exception class, errno, connect/read timeout phase and destination IP—not the API key or request body. Also check whether HTTP_PROXY, HTTPS_PROXY, NO_PROXY or a custom CA bundle differs between local and Railway. This is then an application/client configuration issue rather than an egress block.
• If IPv4 times out or receives an access-denied response only from Railway, the likely gate is the provider/CloudFront policy on the service's shared egress address. Ask Inception Labs to inspect the UTC timestamp and resolved CloudFront IP. A Railway Pro service can enable a Static Outbound IP and supply that IPv4 address for provider allowlisting; it becomes active after redeploy. Railway notes that the assigned address can still be shared, so this is for stable allowlisting, not proof of a dedicated IP.

For a clean escalation, include the complete redacted exception, curl -4/curl -6 results, UTC timestamp, service region, replica ID and whether a fresh replica has the same result. Do not publish the bearer token. That evidence tells Railway whether there is an IPv6 configuration issue, a region-specific IPv4 route failure or a third-party WAF/allowlist rejection.

As a current external control, api.inceptionlabs.ai resolves to both CloudFront A and AAAA records and an unauthenticated IPv4/TLS request reaches the endpoint and returns HTTP 405. That does not test Railway egress, but it rules out a globally dead hostname and makes the in-replica split above the decisive test.

Official references:

• https://docs.railway.com/networking/outbound-networking
• https://docs.railway.com/networking/static-outbound-ips
• https://docs.railway.com/observability/logs