Our production website cannot complete Discord OAuth because its running Railway service receives HTTP 429 from Discord. A single authorization-code exchange failed at approximately 2026-09-30 00:44 UTC. We stopped retrying authorization codes.

A subsequent single read-only request from that same website container to https://discord.com/api/v10/gateway returned:

• HTTP 429
• Content-Type: text/html; charset=UTF-8
• Retry-After: 50979 seconds (about 14 hours)
• No X-RateLimit-Scope or X-RateLimit-Global header

The same public endpoint returned HTTP 200/application-json from our existing bot service on Railway. Normal Discord gameplay continues there. This establishes different behavior on the two services' network paths, but we have not established which traffic caused the restriction.

The affected service uses the us-east4-eqdc4a region, with static outbound IPs disabled on the Hobby plan. We have not cycled IPs, changed regions, added another proxy, or retried authorization codes to bypass the restriction. The application makes one token-exchange attempt per callback and honors provider backoff. We are also correcting a UI defect that shortened long provider waits to one hour.

Could Railway investigate the website service's outgoing network path and advise on a durable resolution? Is there a way to prevent unrelated shared-egress traffic from affecting this integration? The static-outbound-IP documentation says those IPs may still be shared, so merely enabling that feature is not a proven remedy.

The affected service is selected in this request's service field. This public text intentionally omits project/service IDs, credentials, tokens, cookies, authorization codes and player data.