Sorry, I am not sure what you mean when you say you switched to Firefly. Could I ask you to elaborate?

Hello — here's a community post from another user experiencing the same issue: https://station.railway.com/questions/error-1000-dns-points-to-prohibited-ip-73b68465

To clarify my earlier message — I incorrectly said "Firefly." I believe the relevant infrastructure change is Railway's migration to Fastly for edge proxying and WAF, rolled out following the February 2026 DDoS incidents.

To be precise about my topology: my planner app is hosted on Railway (proxied through Cloudflare at planner.erichandamber.com). It makes server-side HTTP requests to Mealie, which runs on a DigitalOcean droplet — not on Railway — behind Cloudflare proxy at mealie.erichandamber.com. The Mealie DNS record is a straightforward A record pointing to a DigitalOcean IP. There is no double-Railway loop here.

Since the Friday release, those server-side requests from Railway to the Mealie endpoint now fail with Cloudflare Error 1000 (DNS points to prohibited IP). The most likely cause is that Railway's new Fastly-based proxy layer is either (a) routing egress traffic through Cloudflare-owned IP ranges, or (b) injecting a CF-Connecting-IP header into outbound requests — both of which Cloudflare treats as a prohibited loop condition.

I worked around this by disabling Cloudflare proxy on mealie.erichandamber.com, which resolves the error but exposes my origin IP and removes DDoS protection and caching — not an acceptable long-term solution.

My question: Is Railway's new edge layer known to inject Cloudflare-specific headers or route egress through Cloudflare IPs? Is there a supported configuration to prevent this, so that Railway-hosted apps can make outbound requests to Cloudflare-proxied external origins without triggering Error 1000?

We do not route traffic through Cloudflare, and we do not add Cloudflare specific headers.

From your message above, you are the one who is routing traffic through Cloudflare, you are doing the loop yourself.

The Problem: Cloudflare Error 1000

A little over a week ago, Railway released their new edge proxy network (powered by Fastly) for DDoS protection and WAF. After this rollout, users started reporting that their Railway apps were throwing Cloudflare Error 1000 ("DNS points to prohibited IP") when their app tried to make outbound, server-side network requests to external APIs or services.

Specifically, this breaks if:

1. Your Railway app makes an API call to api.external-service.com.
2. That external-service.com is also using Cloudflare as its proxy.

Why? Cloudflare has strict loop detection. Because edge networks like Fastly and Cloudflare map traffic across huge shared IP pools, the new Fastly routing (or the HTTP headers Fastly attaches, like CF-Connecting-IP) is making Cloudflare think the request is looping back into its own network illegally, so it aggressively blocks it.

Current Workarounds / Solutions

Since this is a clash between two massive edge networks (Fastly and Cloudflare), there is no magic button inside Railway to fix it just yet, but you have a few options:

1. The Confirmed Fix: "Grey-Cloud" the Target DNS If you own the domain you are trying to talk to (e.g., your Railway app is a frontend hitting your own backend hosted elsewhere), you need to go into the Cloudflare dashboard for the target backend.

• Find the DNS record.
• Toggle the proxy status from Proxied (Orange Cloud) to DNS Only (Grey Cloud).
• Note: This fixes the Error 1000 immediately, but it does expose the origin IP of that server.

2. Audit Outbound Proxy Headers If your Railway app itself is acting as a proxy (using something like Nginx, Kong, or custom Node.js middleware), ensure you are stripping out Cloudflare-specific headers (CF-Connecting-IP, CF-Ray, X-Forwarded-For) before the request leaves your Railway app. If you pass those headers downstream, Cloudflare's edge will see them and immediately trigger the loop protection block.

Railway engineers are currently looking into adjusting how Fastly handles egress traffic to play nicer with Cloudflare, but right now, bypassing Cloudflare proxying on the receiving end is the only surefire way to stop the blocks.