IP is blocked on updates.drupal.org

We don’t regularly block clients from accessing updates.drupal.org by IP. Can you send an example of a URL being requested and the full response, including headers? Ideally reproducing the issue with a curl/wget command.

Thanks a lot for your fast reply!

This is the response for
curl -v https://updates.drupal.org/release-history/drupal/current

curl -v https://updates.drupal.org/release-history/drupal/current
* Expire in 0 ms for 6 (transfer 0x5614463d80f0)
* Expire in 1 ms for 1 (transfer 0x5614463d80f0)
* Expire in 0 ms for 1 (transfer 0x5614463d80f0)
* Expire in 1 ms for 1 (transfer 0x5614463d80f0)
* Expire in 0 ms for 1 (transfer 0x5614463d80f0)
* Expire in 0 ms for 1 (transfer 0x5614463d80f0)
* Expire in 1 ms for 1 (transfer 0x5614463d80f0)
* Expire in 0 ms for 1 (transfer 0x5614463d80f0)
* Expire in 0 ms for 1 (transfer 0x5614463d80f0)
* Expire in 1 ms for 1 (transfer 0x5614463d80f0)
* Expire in 0 ms for 1 (transfer 0x5614463d80f0)
* Expire in 0 ms for 1 (transfer 0x5614463d80f0)
* Expire in 2 ms for 1 (transfer 0x5614463d80f0)
* Expire in 0 ms for 1 (transfer 0x5614463d80f0)
* Expire in 0 ms for 1 (transfer 0x5614463d80f0)
* Expire in 2 ms for 1 (transfer 0x5614463d80f0)
* Expire in 0 ms for 1 (transfer 0x5614463d80f0)
* Expire in 0 ms for 1 (transfer 0x5614463d80f0)
* Expire in 2 ms for 1 (transfer 0x5614463d80f0)
* Expire in 0 ms for 1 (transfer 0x5614463d80f0)
* Expire in 0 ms for 1 (transfer 0x5614463d80f0)
* Expire in 2 ms for 1 (transfer 0x5614463d80f0)
* Expire in 0 ms for 1 (transfer 0x5614463d80f0)
* Expire in 0 ms for 1 (transfer 0x5614463d80f0)
* Expire in 2 ms for 1 (transfer 0x5614463d80f0)
* Expire in 0 ms for 1 (transfer 0x5614463d80f0)
* Expire in 0 ms for 1 (transfer 0x5614463d80f0)
* Expire in 2 ms for 1 (transfer 0x5614463d80f0)
* Expire in 0 ms for 1 (transfer 0x5614463d80f0)
* Expire in 0 ms for 1 (transfer 0x5614463d80f0)
* Expire in 2 ms for 1 (transfer 0x5614463d80f0)
* Expire in 0 ms for 1 (transfer 0x5614463d80f0)
* Expire in 0 ms for 1 (transfer 0x5614463d80f0)
* Expire in 2 ms for 1 (transfer 0x5614463d80f0)
* Expire in 0 ms for 1 (transfer 0x5614463d80f0)
* Expire in 0 ms for 1 (transfer 0x5614463d80f0)
* Expire in 2 ms for 1 (transfer 0x5614463d80f0)
* Expire in 0 ms for 1 (transfer 0x5614463d80f0)
* Expire in 0 ms for 1 (transfer 0x5614463d80f0)
* Expire in 2 ms for 1 (transfer 0x5614463d80f0)
* Expire in 1 ms for 1 (transfer 0x5614463d80f0)
* Expire in 1 ms for 1 (transfer 0x5614463d80f0)
* Expire in 2 ms for 1 (transfer 0x5614463d80f0)
* Expire in 1 ms for 1 (transfer 0x5614463d80f0)
* Expire in 1 ms for 1 (transfer 0x5614463d80f0)
* Expire in 2 ms for 1 (transfer 0x5614463d80f0)
* Expire in 1 ms for 1 (transfer 0x5614463d80f0)
* Expire in 1 ms for 1 (transfer 0x5614463d80f0)
* Expire in 2 ms for 1 (transfer 0x5614463d80f0)
* Expire in 2 ms for 1 (transfer 0x5614463d80f0)
* Expire in 2 ms for 1 (transfer 0x5614463d80f0)
* Expire in 4 ms for 1 (transfer 0x5614463d80f0)
* Expire in 2 ms for 1 (transfer 0x5614463d80f0)
* Expire in 2 ms for 1 (transfer 0x5614463d80f0)
* Expire in 4 ms for 1 (transfer 0x5614463d80f0)
* Expire in 3 ms for 1 (transfer 0x5614463d80f0)
* Expire in 3 ms for 1 (transfer 0x5614463d80f0)
* Expire in 4 ms for 1 (transfer 0x5614463d80f0)
*   Trying 151.101.2.217...
* TCP_NODELAY set
* Expire in 149994 ms for 3 (transfer 0x5614463d80f0)
* Expire in 200 ms for 4 (transfer 0x5614463d80f0)
* connect to 151.101.2.217 port 443 failed: Connection timed out
*   Trying 151.101.66.217...
* TCP_NODELAY set
* Expire in 84793 ms for 3 (transfer 0x5614463d80f0)
* After 84793ms connect time, move on!
* connect to 151.101.66.217 port 443 failed: Connection timed out
*   Trying 151.101.130.217...
* TCP_NODELAY set
* Expire in 42396 ms for 3 (transfer 0x5614463d80f0)

The command is still running.

Looks like something must not be allowing the connection to our CDN to completely establish.

https://rubygems.org and https://pypi.org are also on Fastly, do you have any connection issues to those?

Does traceroute or mtr show any hop that might be problematic?

With the code to copy from https://www.fastly-debug.com, we can open a support request with Fastly.

https://rubygems.org and https://pypi.org/ are working fine!

For more information, I need to contact my client's IT department.

@drumm it is working again! It looks like it was a internal problem with my client's infrastructure. Sorry for the inconvenience and thanks a lot for your great help!

Automatically closed - issue fixed for 2 weeks with no activity.