2 months ago
I ran across both of these and am having a similar error. I cannot get services to connect cross platform that worked prior to the new caching/dns changes in the Friday release. I keep getting the cloudlfare 1000 error. All SSL is set to full only. I have Kong making an outbound call to another project (which, like I said has worked for 7 weeks). As I was doing a final round of testing before scheduling demo with C suite, I started getting this error today. Last weeks testing was fine.
Call is going to cal-api.int.twu556tech.com which is for our other project served thru a tunnel with mlts.
I tried direct cname to railway with and without mlts and it doesn't work.
Again, has worked for 7 weeks and something in the last changeset on Friday caused the issue.
Thanks,
2 Replies
Status changed to Awaiting Railway Response Railway • about 2 months ago
2 months ago
This thread has been marked as public for community involvement, as it does not contain any sensitive or personal information. Any further activity in this thread will be visible to everyone.
Status changed to Open Railway • about 2 months ago
2 months ago
This is a Cloudflare error 1000 ("DNS points to prohibited IP"), which means Cloudflare is refusing to resolve/proxy the request because the DNS record points to an IP address that Cloudflare considers restricted or loopback adjacent.
most likely the issue is cause by init subdomain through a tunnel.The fastest fix is probably greying out orange cloud(via your dashboard) on that specific CNAME record. The tunnel handles its own encryption, so you lose nothing by doing this,but before you do this make sure to check what your cname resolves to,Run this outside of Cloudflare:
dig +trace cal-api.int.twu556tech.comIf any hop in the chain lands on a 198.41.x.x, 104.x.x.x, or 172.64.x.x (Cloudflare IPs), that's your sign.
ahmad0001
This is a Cloudflare error 1000 ("DNS points to prohibited IP"), which means Cloudflare is refusing to resolve/proxy the request because the DNS record points to an IP address that Cloudflare considers restricted or loopback adjacent. most likely the issue is cause by init subdomain through a tunnel.The fastest fix is probably greying out orange cloud(via your dashboard) on that specific CNAME record. The tunnel handles its own encryption, so you lose nothing by doing this,but before you do this make sure to check what your cname resolves to,Run this outside of Cloudflare: ``` dig +trace cal-api.int.twu556tech.com ``` If any hop in the chain lands on a `198.41.x.x`, `104.x.x.x`, or `172.64.x.x` (Cloudflare IPs), that's your sign.
2 months ago
also if it doesn't seem to work properly you can also try these fixes:
If you're using a Cloudflare Tunnel (cloudflared) The tunnel already handles TLS,you don't need Cloudflare to also proxy the DNS record. Set the CNAME to DNS only and let the tunnel do its job.
If you're pointing directly at Railway: Railway gives you a public hostname. Use that as your CNAME target and set it to DNS only (grey cloud), not proxied. Railway handles HTTPS on its end.
Verify your Kong upstream URL is using the correct external hostname and not accidentally routing through an internal/loopback address that Cloudflare now rejects.