pecl.php.net tiemout from eu-west-1 region in AWS

Description

PECL is not working from my VPC in aws eu-west-1.
It worked some hours ago.

I am getting a timeout.

$ curl -v --max-time 10 https://pecl.php.net/channel.xml

* Host pecl.php.net:443 was resolved.
* IPv6: (none)
* IPv4: 87.249.137.50
*   Trying 87.249.137.50:443...
* Connected to pecl.php.net (87.249.137.50) port 443
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / X25519 / id-ecPublicKey
* ALPN: server accepted h2
* Server certificate:
*  subject: CN=pecl.php.net
*  start date: Aug  8 13:03:22 2026 GMT
*  expire date: Nov  6 13:03:21 2026 GMT
*  subjectAltName: host "pecl.php.net" matched cert's "pecl.php.net"
*  issuer: C=US; O=Let's Encrypt; CN=YE2
*  SSL certificate verify ok.
*   Certificate level 0: Public key type EC/prime256v1 (256/128 Bits/secBits), signed using ecdsa-with-SHA384
*   Certificate level 1: Public key type EC/secp384r1 (384/192 Bits/secBits), signed using ecdsa-with-SHA384
*   Certificate level 2: Public key type EC/secp384r1 (384/192 Bits/secBits), signed using ecdsa-with-SHA384
*   Certificate level 3: Public key type EC/secp384r1 (384/192 Bits/secBits), signed using ecdsa-with-SHA384
* using HTTP/2
* [HTTP/2] [1] OPENED stream for https://pecl.php.net/channel.xml
* [HTTP/2] [1] [:method: GET]
* [HTTP/2] [1] [:scheme: https]
* [HTTP/2] [1] [:authority: pecl.php.net]
* [HTTP/2] [1] [:path: /channel.xml]
* [HTTP/2] [1] [user-agent: curl/8.5.0]
* [HTTP/2] [1] [accept: */*]
> GET /channel.xml HTTP/2
> Host: pecl.php.net
> User-Agent: curl/8.5.0
> Accept: */*
> 
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
* Operation timed out after 10002 milliseconds with 0 bytes received
* Connection #0 to host pecl.php.net left intact
curl: (28) Operation timed out after 10002 milliseconds with 0 bytes received

It works in my home, where DNS is resolving another IP:

curl -v --max-time 10 https://pecl.php.net/channel.xml

* Host pecl.php.net:443 was resolved.
* IPv6: 2400:52e0:1e06::895:1
* IPv4: 185.93.3.244
*   Trying 185.93.3.244:443...
* Connected to pecl.php.net (185.93.3.244) port 443
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / X25519 / id-ecPublicKey
* ALPN: server accepted h2
* Server certificate:
*  subject: CN=pecl.php.net
*  start date: Aug  8 13:03:22 2026 GMT
*  expire date: Nov  6 13:03:21 2026 GMT
*  subjectAltName: host "pecl.php.net" matched cert's "pecl.php.net"
*  issuer: C=US; O=Let's Encrypt; CN=YE2
*  SSL certificate verify ok.
*   Certificate level 0: Public key type EC/prime256v1 (256/128 Bits/secBits), signed using ecdsa-with-SHA384
*   Certificate level 1: Public key type EC/secp384r1 (384/192 Bits/secBits), signed using ecdsa-with-SHA384
*   Certificate level 2: Public key type EC/secp384r1 (384/192 Bits/secBits), signed using ecdsa-with-SHA384
*   Certificate level 3: Public key type EC/secp384r1 (384/192 Bits/secBits), signed using ecdsa-with-SHA384
* using HTTP/2
* [HTTP/2] [1] OPENED stream for https://pecl.php.net/channel.xml
* [HTTP/2] [1] [:method: GET]
* [HTTP/2] [1] [:scheme: https]
* [HTTP/2] [1] [:authority: pecl.php.net]
* [HTTP/2] [1] [:path: /channel.xml]
* [HTTP/2] [1] [user-agent: curl/8.5.0]
* [HTTP/2] [1] [accept: */*]
> GET /channel.xml HTTP/2
> Host: pecl.php.net
> User-Agent: curl/8.5.0
> Accept: */*
> 
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
< HTTP/2 200 
< date: Mon, 07 Sep 2026 18:03:50 GMT
< content-type: application/xml
< content-length: 648
< vary: Accept-Encoding
< server: BunnyCDN-ES1-895
< cdn-pullzone: 5890715
< cdn-requestcountrycode: ES
< vary: Accept-Encoding
< cache-control: public, max-age=180
< etag: "288-654705e9c691d"
< last-modified: Wed, 17 Jun 2026 10:17:40 GMT
< cdn-proxyver: 1.62
< cdn-requestpullsuccess: True
< cdn-requestpullcode: 200
< cdn-cachedat: 09/07/2026 09:01:01
< cdn-edgestorageid: 895
< cdn-requestid: e2205b4d703060efeb58b8e38cde773d
< cdn-cache: HIT
< cdn-status: 200
< cdn-requesttime: 0
< accept-ranges: bytes
< 
<?xml version="1.0" encoding="UTF-8"?>
<channel version="1.0" xmlns="http://pear.php.net/channel-1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://pear.php.net/channel-1.0
http://pear.php.net/dtd/channel-1.0.xsd">
 <name>pecl.php.net</name>
 <suggestedalias>pecl</suggestedalias>
 <summary>PHP Extension Community Library</summary>
 <validatepackage version="1.0">PEAR_Validator_PECL</validatepackage>
 <servers>
  <primary>
   <rest>
    <baseurl type="REST1.0">https://pecl.php.net/rest/</baseurl>
    <baseurl type="REST1.1">https://pecl.php.net/rest/</baseurl>
   </rest>
  </primary>
 </servers>
</channel>
* Connection #0 to host pecl.php.net left intact
```


### PHP Version

```plain
Not relevant.
```

### Operating System

Ubuntu 24.04

Aucun fichier source PHP ni aucun test n’est identifié. Commencez par reproduire la requête curl signalée depuis une VPC AWS eu-west-1 et comparez son adresse IP résolue et sa réponse avec le résultat fonctionnel obtenu depuis le réseau domestique. C’est terminé lorsque le timeout régional est isolé et que le propriétaire approprié du service ou du repository dispose d’un diagnostic confirmé.