6 days ago
We are experiencing an issue where requests coming from mobile devices are being blocked, while the same requests work correctly from desktop browsers.
What we observed:
Requests from desktop browsers succeed without issues.
Requests from mobile devices (Android and iOS) are being blocked.
The same API endpoints and authentication are being used.
We suspect the requests are being filtered or blocked somewhere in the Railway infrastructure or networking layer.
Could you help us identify why mobile requests are being blocked? If there are any firewall rules, rate limits, WAF policies, or proxy configurations that could cause this behavior, please let us know.
We can provide request logs, timestamps, headers, IP addresses, and any other information needed to help with the investigation.
4 Replies
6 days ago
This thread has been opened as a bounty so the community can help solve it.
Status changed to Open Railway • 6 days ago
0x5b62656e5d
Are the mobile devices on the same network as the desktops?
6 days ago
Yes. One thing I noticed is that the issue only occurs on physical mobile devices. When I use an Android emulator, everything works as expected.
To rule out any issues with my application, I even created a new account on a different hosting provider this week, deployed the exact same project, and it worked perfectly without any changes.
However, as soon as I deploy the same project on Railway, requests from physical mobile devices are blocked again. This makes me believe the issue is related to the Railway environment rather than the application itself.
If it helps, I can provide logs, request headers, timestamps, or any additional information needed to investigate this issue.
6 days ago
Try using a proxy such as mitm to see where the requests are going and what errors you’re getting. You can also try setting 1.1.1.1 as the DNS server on your mobile devices and see if that fixes it.
6 days ago
Hello @weverson-luan,
Since desktop browsers work but mobile devices fail on the exact same endpoints and auth, this is likely an issue with how the headers or IPs are being interpreted at the edge network (Railway/Cloudflare) or your application layer.
Here are the three most probable causes:
- WAF / Bot Protection (User-Agent): Mobile HTTP clients (OkHttp, Alamofire, Dart, etc.) use default User-Agents that are frequently flagged as bots by edge proxies, resulting in a 403 block.
Quick Test: Try hardcoding a standard desktop browser User-Agent into your mobile app's request headers to see if it bypasses the block.
-
Strict CORS Policies: If these are native mobile apps, they do not send Origin or Referer headers in the same way browsers do. If your backend strictly enforces CORS, it may be rejecting the preflight or the request itself.
-
CGNAT IP Rate Limiting: Mobile networks use shared IP addresses (Carrier-Grade NAT). If you have strict IP-based rate limiting, mobile carrier IPs will hit that limit instantly, returning a 429 error.
Since you offered logs, could you provide the following so we can pinpoint the exact cause?
What is the exact HTTP Status Code returned to the mobile devices (e.g., 403, 429, 502, or a timeout)?
Can you share the full request headers from a failed mobile request (specifically the User-Agent and Origin)?
Does this happen on mobile browsers as well, or exclusively within a native mobile app?
Happy to help analyze those logs once you drop them!