Hi guys, I update everyone with the solution that another user has recommended and that I have adopted.
I took a 1 Gbit/s VPS in another provider (not Hetzner) and I installed a Wireguard server on it, then I installed a Wireguard client on my server where I use Clouddrive and I set it to forward all traffic to and from the intervals IP of Google API in the VPS in this way I have eliminated the errors, I have been using this method for a few weeks and I have not received any more errors.
Side note: When I copy a file from a local disk to a cloud disk the transfer speed that Windows shows me is about 35 MB/s and I don't know if this is a problem related to this solution or to the NVMe disk where the cache resides replaced at the same time as the "Wireguard solution".
I recently moved my Hetzner server from one located in their Finland datacenter, to one located in their German datacenter. And then the 429's started appearing.
I ran this script from another VPS, from another provider (LiteServer.nl if anyone's curious), and then put the IPs into the /etc/hosts file on my German Hetzner server. And it seems to work fine.. For now. Let's hope this will get fixed
Did anyone try and contact Hetzner about this issue?
Okay so I contacted them myself. They're basically saying "GG, we can't do anything". Apparently Google won't let them know what IPs are getting blocked. So they can't do anything on their end.
Hmm, I'm very suspicious now. I have just gotten an email from my Wireguard VPS server hosting company where they say
Deactivation of your server because of a security incident, with this letter we would like to inform you, that our internal monitoring identified a possible security threat to our infrustructure caused by your server with the contract ID xxxxxxx. This threat is made up of distributed computing / mining processes running on this server.
I have this Ubuntu 22.04 very locked down, have nothing other than Wireguard installed and have SSH on a different port and denied to everything but my own static IP
That predates any 429 issues. IPv6 is due to that occasional bad routing Hetzner has to Google with IPv6 and the other script just attempts to benchmark the endpoints and choose one. Both are trying to solve bad peering rather than anything else.
Right but as both this discussion and that script change the IP used they are related and don't necessarily predate, that script has worked well to resolve my issues I was getting which were the same as this thread
I had that issue, it was permission related, running it as root did weird stuff, running it as a non root sudo user worked fine, i am on a heavily modified version of cloudbox (so pre-saltbox) and got it working successfully, another thing to note is make sure you don't have any static entries for www.googleapis.com in your /etc/hosts file and then also delete /etc/hosts.backup to ensure it doesn't restore a "broken" hosts file.
Hmm. I am running it as my non root sudo user, it writes in those IPs successfully into the hosts file, but as mentioned it only adds the hostname 'www.googleapis.com' behind the last IP address in the list.
And weirdly enough, even if it got a 100MB/s test through that endpoint in the benchmark for the last ip in the list, it got a 429 error when trying to upload through rclone later on.
I also have a machine with Hetzner, and the problem is that your source IP has probably been flagged because too many people are connecting from the same source range of IPs.
The DNS changing will "solve" the problem sometimes specially if you set a public DNS server from another country that will return different IPs in the response for nslookup www.googleapis.com.
My solution was to spin up this container https://github.com/wfg/docker-openvpn-client. It will connect to a VPN server in another country and also run a proxy that only accepts local connection. To finish I added to the top of my "move script" the line export https_proxy=http://127.0.0.1:17170.
Unfortunately neither of both solutions mitigate the root cause of the problem because you're still using shared IPs, but for sure it will buy you some time.
I have a VPS configured with wireguard server and rclone (2 config file edits away) configured to use this wireguard VPS server, but currently static IP's are fixing it so lets see.
These were working for me a few months ago but I had to generate a new list today. I'm not sure if it matters that everyone is attempting to use the same ones so you can generate your own instead. Alternatively, you can also try this method posted by another user which worked for me.
I think the problem is this script checks a 500MB test file download from Google, but sometimes the 429 error is not triggered until a certain amount of data has been transferred (although sometimes it's right away.)
Maybe it will work better with a larger test file, that triggers the 429 error before it concludes the test.
For now I'm using static entries with a nslookup of www.googleapis.com from my home location. This seems to work well.
Well, i am running the wireguard VPS Solution i came up with since almost more than a month now and it is working better as expected and without any issues so far.
You can use ever of the VPS which they offer but I recommend taking the Cloud VPS S Nvme or for a little bit better network performance the Cloud VPS M Nvme. I also recommend using Ubuntu 20.04 as OS for the wireguard installation. To make it easier just follow these steps/commands:
Logon to your VPS as root and follow the instructions here:
If you want use also IPv6 with your wireguard you need to look at this instruction in the "Choose an IPv6-Range" Section and combine it with the documention mentioned before:
EDIT: Do not forget to add all these IPv4/6-Ranges to the AllowedIP Line in addition to your wireguard ip-nets into your client-side config:
These ranges will cover all of Googles IP-Adresses used for googleapis.com!
If you have questions or need help setting this up you may contact me directly. Just to inform you: I am NOT running this solution in a docker container, I just run this on the plain OS.
Just to be clear: I tested almost every VPS provider which has VPS located in Germany and except Webtropia there was no other VPS provider which could provide me with at least 400-500mbps throughput to GDrive using wireguard! ThatĀ“s why IĀ“d recommend you renting a Webtropia VPS for this solution.
