Suddenly getting 1034 errors from Cloudflare #985
Comments
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
|
@hernil To be honest, I'm not sure what we can do to work around this. The tool has completed the HTTP connection to obtain the content, except that the content includes the string "error code: 1034." How frequently are you checking your IP address? It's really hard for me to imagine that you could trigger Cloudflare's rate limit. My hunch is that maybe there are some internal hiccups within Cloudflare. Are you still getting the error now? |
|
For another data point, I am getting this as well from my 2 instances, one to the Boston, US Cloudflare COLO and one to the Melbourne, AUS COLO. And they are not consistent or at the same time as each other. My thought too is there are issues inside Cloudflare causing this. |
|
I also started getting these starting yesterday. It is about once per hour if I had to guess. |
|
getting the same error here today. suspect something changes in cloudflare structure. but i am not really sure. |
|
same rip |
I'm checking every 5 minutes for two different domains hosted on the same machine / IP. At the time of writing they've had 38 and 41 errors respectively in the last ~31,5 hours so if my morning coffee has kicked in that gives Here's the truncated logs with failure timestamps for both domains: logsCloudflare is only providing DNS for this setup btw. There's no tunnelig, proxying or other things being served through Cloudflare. Let me know if there's other bits of information that could be useful! Footnotes
|
|
FYI: I added a FAQ in README about this error (#987) while we are still trying to figure it out. |
|
Don't know if really relevant but manually browsing to screenshots
Is a really weird error as it looks like Cloudflare is trying to resolve an IP? |
|
I would guess that someone screwed up the code to check whether the "owner" of the IP |
|
That's a fair theory and I agree on not doing anything drastic before knowing more about the issue.
|
Could we make the default behavior point to '1.1.1.1' for the updater, but configurable to use |
Perhaps it has just been resolved? I just tested |
|
from my side. issue still persist. |
Weird, I am not getting it at all from that link. But I am still getting it from cloudflare-ddns. So yeah definitely not fixed. |
|
Inspired by @bpbradley's suggestion, I implemented a temporary feature (#988) to hopefully shut down the error messages:
I'm a bit reluctant to make this feature permanent yet. The code is good, but the design is not well-thought-out. Thanks to everyone who helped me diagnose the problem. Let's hope Cloudflare can just fix it. |
Well done! I will give it a try now. Edit: Updated. I will check back in a few hours to verify that it worked. Edit: Haven't had an issue in 5 hours. I'm thinking this worked. |
|
Applied the edge channel to one of my two instances about six hours ago and I've not seen that one error out since 😊 |
this solve my problem. thank you. |
|
where do i put this cloudflare.trace:https://one.one.one.one/cdn-cgi/trace, this error popped up for me also about 4 days ago |
|
|
thanks @bpbradley |
|
Hopefully unrelated, I switched to the I generally do not have high latency, nothing else changed on my network, so not sure if one.one.one.one might respond differently (when working) than 1.1.1.1 ? |
|
Was hoping by now CF would have things fixed but maybe this is the new norm. Is there a config to change how often it polls in the off chance it is some sort of rate limiting though i cant see how for a service like this 5 minutes is too often. |
|
Maybe another option would be to use a different Cloudflare service for IP lookup? Cloudflare owns icanhazip.com as well. Not the best or most professional URL but gets the job done. |
Change provider in an attempt to fix missing ipv4 domain records. This is being tracked here: favonia/cloudflare-ddns#985
Set the env variable e.g I have done this, i still get the error but not as often, like once a day by reducing it to hourly. Not a fix but just helps alerts instead of when it was 5 mins and failing a lot. It's documented nicely here: https://github.com/favonia/cloudflare-ddns?tab=readme-ov-file#%EF%B8%8F-all-settings under "Scheduling of IP detections and updates" for more options or explaining how to pick cron friendly names if you want to set something else. |
|
Thanks @apat183 went looking but completely missed it. While poking around I saw the option to change and use a different URL so I'm giving that a try now with icanhazip to see how that works. So far so good, it at least detected the IP. |
|
I had the same problem reported in this issue and have tried manually switching the url as suggested. Ideally I don't want to increase the timeout value, alternatively is it possible to configure retry attempts before giving up? Apologies if I missed it in the documentation. |
|
Had the same today |
|
@tsrats @GIG0i @hansenc0705 Thanks for the reporting. It's curious that multiple of you experienced high latency simultaneously with different servers. Was there a global network slowdown? How frequently the failures are? @GIG0i The "retry" is for the HTTP server to instruct the updater to try again later. The updater will comply with such retry instructions. However, that doesn't seem to be the problem here. In this case, it seems the issue is that the network isn't working as expected, and thus retrying might not be helpful. Increasing the timeout value won't slow down the normal detection when everything works as expected, and the value is really for the worst-case scenario. Therefore, if you want the tool to retry, it indicates that you're actually okay with a large timeout value. It will make the updater wait longer before giving up. An interesting idea that just came to my mind is whether a failed detection should trigger a shorter wait before the next detection. I suppose it's possible but requires careful design. So far, it seems there have been many unfortunate events (Cloudflare's internal errors, network latency, etc.), and I feel sorry that you've had to endure them. On the other hand, I haven't seen anything that should be changed in the tool yet. |
|
Just to let you know, i remove the old image and tried to reinstall the default latest image - and its working. I wonder whats Cloudflare doing in the background. |
|
@hernil @tsrats @bpbradley @andrewkolda @Spyderkat @GIG0i I can no longer trigger the error. It seems Cloudflare just fixed it. Could you possibly revert back to the |
|
Hi @favonia, I reverted back to my prior set up, using latest (specifically 1.15.0) tag and 1.1.1.1 as the provider, and got a failure within 2 hours: Failed to find the IP address in the response of "https://1.1.1.1/cdn-cgi/trace": error code: 1034 |
|
So I switched for a few days to just URL and used icanhazip and that was fine, no errors. Today i switched to cloudflare.doh and its been OK so far. |
I reverted and got an error within about 10 minutes :( |
|
(Just to clarify, |
Ah good to know. Will switch back to the url method with icanhazip then. |
|
Okay, the issue is back. |
|
Finally, I got my error 1034 as well. As this issue has remained open for three weeks, I am leaning towards changing the default The reason is that we will be contacting the API server anyways. As for After these changes, I believe we can drop all the complicated code about Hope these changes will solve the problems with minimum friction. |
I will certainly be willing to test this for you when it's ready, I've been seeing errors almost hourly still (sometimes multiple an hour) |
I have changed the default URLs in the development version. The |
|
Just updated both of my images to |
|
Is there anyone testing |
I am on |
This night I started getting 1034 responses from Cloudflare. It's not every request - I've had roughly 20 of them between two domains since about 02:00 CET (UTC+1). I have the two instances of cloudflare-ddns (one per domain) pinging every five minutes.
The full errors look like this:
The Cloudflare docs say Error 1034: Edge IP Restricted which suggest some rate limiting, but that's not really what the description says as far as I can understand - more in the way of configuration issues.
I have not started trying fixes yet (not sure if I can override the DNS endpoint by config) but I wanted to get this out here in case others are experiencing the same thing.
Additional info in case it's useful:
I'll use the opportunity to say that it's a great little project you've made @favonia. It's clear from the image trimming and change logs that you take great care in maintaining this. Thanks a lot! 😊
The text was updated successfully, but these errors were encountered: