a month ago
Hello,
Our Railway application cannot download the public regional outline at
https://download.geofabrik.de/europe/poland/mazowieckie.poly.
On 2026-09-08, both staging and production workers resolve the hostname correctly.
An initial plain HTTPS test from staging returned HTTP 200 (12880 bytes).
After the planned feature-flag deployment, the guarded application PLAN again
failed before any map import. Production continues to fail. This is intermittent
or environment-dependent; we cannot establish the responsible network component.
All four IPv4 destinations refuse TCP/443 before TLS:
95.216.245.185, 95.217.45.61, 95.217.63.98, 95.216.245.233.
The four subsequent IPv6 attempts return ENETUNREACH. Standard Python urllib and
requests behave identically. HTTPS to www.geofabrik.de and docs.railway.com works
from the same worker. The exact outline URL returns HTTP200 from our local machine.
No proxy, alternate IP routing, custom DNS, or disabled TLS verification is used.
Could you confirm whether an egress filter, routing issue, or a blocked source
address range causes these refusals, and advise an approved resolution? We have
paused map activation and will respect any download policy or required backoff.
The application is intended to cache bounded regional data, without sending GPS
coordinates to the map provider.
Worker/environment and exact timestamps/egress addresses can be supplied privately.
Diagnostic evidence: plan21-production-map-transport.log,
plan21-staging-map-transport.log, plan21-stage-pilot-plan.log, and earlier
release375-staging-map-connect-order.log. The application build is unchanged
(8b9a4cec2ca7730ea731399b927794b83e336369). There is no HTTP response or TLS alert;
the failure occurs at TCP connection establishment.
Thank you.
1 Replies
a month ago
This thread has been opened as a bounty so the community can help solve it.
Status changed to Open Railway • 27 days ago
a month ago
Hi @pawelmamcarz, I took a look at your logs/symptoms and along side Claude Code: a few things point potentially to the cause:
Maybe it's Geofabrik-side IP blocking, not a Railway network fault.
The key signal is that you're getting TCP RST (connection refused) before TLS even starts, not a timeout. A silent drop (routing/firewall-in-the-middle) times out; an active refusal means something is deliberately rejecting the connection at the destination. Combined with the facts that:
www.geofabrik.de and docs.railway.com work fine from the same worker (rules out DNS, TLS, egress routing, or a blanket Railway issue)
It worked once (HTTP 200) and only started failing later, so it's not a static config problem
It's specific to download.geofabrik.de, their bulk-download server, not their marketing site
This matches a documented Geofabrik behavior: they reactively block whole IP netblocks when they detect abusive/high-rate automated downloading hitting that server. There's precedent for exactly this pattern — see this OSM forum thread where an entire ISP netblock got blocked after one bad actor hammered the server with Wget, and this thread with your exact symptom.
Most likely root cause: Railway's default outbound IPs are shared across many customer workloads (even the paid Static Outbound IPs add-on gives no guarantee of a non-shared address, per Railway's own docs). If another Railway tenant sharing your egress range hit Geofabrik too aggressively: no backoff, generic User-Agent, high frequency. Geofabrik's abuse detection would block that whole range, and you get caught in the crossfire. That fits every symptom you've listed, including why it's IPv4-only and intermittent by environment (different workers may currently egress through different shared IPs).
Suggested path:
Enable Static Outbound IPs on the affected service (Settings → Networking, or railway outbound-network in the CLI). This stabilizes which address(es) you use: a prerequisite for step 2.
Email Geofabrik directly with your specific source IPs + timestamps (you've already got the logs for this) and ask them to allowlist/unblock. This is a destination-side decision, nothing on Railway's end can undo it.
Set a descriptive User-Agent on your requests instead of the default urllib/requests UA. That's exactly the kind of traffic their abuse detection flags, and identifying yourself helps if you ever need to request an allowlist again.
Since you're already planning to cache the bounded region data, fetch-once into durable storage (Railway volume / object storage) rather than re-fetching per deploy or worker — that removes the recurring dependency on an IP-reputation-sensitive endpoint entirely.
Geofabrik also publishes mirrors which is worth using one for any automated/repeated pulls instead of hitting the primary download server directly.
The IPv6 ENETUNREACH you're seeing is a separate, unrelated non-issue. Railway just doesn't have an IPv6 egress route configured, so those never even reach Geofabrik.