Connection timed out

[EvKoh]

I have this problem since yesterday midnight :

$ php composer.phar self-update

You are already using composer version d0ff016.

$ php composer.phar update

The "https://packagist.org/packages.json" file could not be downloaded: failed to open stream: Connection timed out
https://packagist.org could not be fully loaded, package information was loaded from the local cache and may be out of date

[Composer\Downloader\TransportException]
The "http://packagist.org/p/provider-2013$cf2677ffd4e77b2b311e7472f978ca6ba
c654427d739010868d1afec9b29684a.json" file could not be downloaded: failed
to open stream: Connection timed out

[Seldaek]

@EvKoh can you check if curl --ipv6 'https://packagist.org/packages.json' and curl --ipv4 'https://packagist.org/packages.json' work?

[EvKoh]

curl --ipv6 'https://packagist.org/packages.json'

curl: (7) Failed to connect to packagist.org port 443: Connexion terminée par expiration du délai d'attente

curl --ipv4 'https://packagist.org/packages.json'

{"packages":[],"notify":"/downloads/%package%","notify-batch":"/downloads/","providers-url":"/p/%package%$%hash%.json","search":"/search.json?q=%query%","provider-includes":{"p/provider-2013$%hash%.json":{"sha256":"ba307417cd9bf0f23a3c8f584b4cc68ec45bf5b2b1d76ce608203e75d35d38cd"},"p/provider-2014$%hash%.json":{"sha256":"4a1819cda30d7bf6db2de08e7ecd4db89801ac898fd7be9266961aac0ac5ba46"},"p/provider-2014-10$%hash%.json":{"sha256":"8d4f27c19c518e342cb0a7bfa9297d777dd1e361302b8fb9b0af2e7bc28f02fc"},"p/provider-2015-01$%hash%.json":{"sha256":"1d8469fc950f455e678aed427ae34bd6d3636e4bc0aa67cc68422593a6278cb7"},"p/provider-2015-04$%hash%.json":{"sha256":"2d1c07ec6668fdf759d8f23cd8ab6056a6c1604e7d8f1e35e120c38b4ec1a24c"},"p/provider-archived$%hash%.json":{"sha256":"dfa1d92d2697fc375a1d522ab573634ee18807646f4abc322b6933157a07b829"},"p/provider-latest$%hash%.json":{"sha256":"e7a18aa1b3f8b9d8328f8a66ba2c0469309f6026958086ac2f9a74c6ba70e092"}}}

[jcoby]

I had the same issue. It's some sort of ipv6 issue with the router not responding to ipv6 routing requests. traceroute6 -vvvv packagist.org showed no responses from the ff02::1: which is an odd address to multicast too.

I "solved" it by disabling ipv6 at the router.

[EvKoh]

It works for me 👍

[svsa]

Broken again for ip6

$ curl --ipv6 'https://packagist.org/packages.json'
curl: (7) Failed to connect to packagist.org port 443: Operation timed out
$ curl --ipv4 'https://packagist.org/packages.json'
{"packages":[],"notify":"\/downloads\/%package%","notify-batch":"\/downloads\/","providers-url":"\/p\/%package%$%hash%.json","search":"\/search.json?q=%query%","provider-includes":{"p\/provider-2013$%hash%.json":{"sha256":"8e003046b2d50dff1c31c2044727528673b51a751b5c902cb81516b659d8e123"},"p\/provider-2014$%hash%.json":{"sha256":"2f58b1f07e07b9e6ba13d672aceddcaf1ac4f9e0439d5c23703b66a677bf48d7"},"p\/provider-2014-10$%hash%.json":{"sha256":"2a152ae312320cc1d04e8302d54a13a1c059641686be683e588d7d9992eab625"},"p\/provider-2015-01$%hash%.json":{"sha256":"077c6ffefdaf2d0de8cdb1ac08da5e6b4bc226d5ef1be190f4122bd11f69484e"},"p\/provider-2015-04$%hash%.json":{"sha256":"1cbac5ce210884e738ccc84fbfe4ec4fd96914e5feecb35ef2fb19f620934910"},"p\/provider-2015-07$%hash%.json":{"sha256":"4a7f2dd59f74db7cf29257bf06ccbab0f183efaf5b2ded50fa9ab1bef342653e"},"p\/provider-archived$%hash%.json":{"sha256":"d042ff1465dd924ca3814e4c9a999aa349e51a041c74f81e55266afd489833b4"},"p\/provider-latest$%hash%.json":{"sha256":"e3ddb28de29d05b9d3fc00b9d84d7ba52213dc2a21b52857474058f9fb28e1eb"}}}

[alcohol]

@svsa But what do you expect us to do about that? We are not your internet provider. We cannot fix your connection.

[alcohol]

rob@robbast ~ $ curl --ipv6 'https://packagist.org/packages.json'
{"packages":[],"notify":"\/downloads\/%package%","notify-batch":"\/downloads\/","providers-url":"\/p\/%package%$%hash%.json","search":"\/search.json?q=%query%","provider-includes":{"p\/provider-2013$%hash%.json":{"sha256":"8e003046b2d50dff1c31c2044727528673b51a751b5c902cb81516b659d8e123"},"p\/provider-2014$%hash%.json":{"sha256":"2f58b1f07e07b9e6ba13d672aceddcaf1ac4f9e0439d5c23703b66a677bf48d7"},"p\/provider-2014-10$%hash%.json":{"sha256":"2a152ae312320cc1d04e8302d54a13a1c059641686be683e588d7d9992eab625"},"p\/provider-2015-01$%hash%.json":{"sha256":"077c6ffefdaf2d0de8cdb1ac08da5e6b4bc226d5ef1be190f4122bd11f69484e"},"p\/provider-2015-04$%hash%.json":{"sha256":"1cbac5ce210884e738ccc84fbfe4ec4fd96914e5feecb35ef2fb19f620934910"},"p\/provider-2015-07$%hash%.json":{"sha256":"0a98e3c0be070fc25928f230c4c954f0c2a5963dc77666a141b23d1d395d7b4c"},"p\/provider-archived$%hash%.json":{"sha256":"d042ff1465dd924ca3814e4c9a999aa349e51a041c74f81e55266afd489833b4"},"p\/provider-latest$%hash%.json":{"sha256":"8bd24e026352ce5d827cb662136bddad84f4f8b3a5886f8c9b205ed68c4cf49a"}}}

[alcohol]

Well, it works for thousands of others. It doesn't work for you. Pretty sure you are the exception, not the rule. So yes, your provider should be contacted.

[svsa]

Likewise its been working for me for many months and when I google this new-to-me error I see multiple reports of this failure, hence I thought I was being helpful in noting it was no longer working.
Didn't expect such a response.

[alcohol]

What were you expecting? (sincere question)

[svsa]

So just to follow up. Obviously its something in composer because I deleted ~/.composer and re-added my global requires, and global update works now.

I didn't delete the ~/.composer on another of my Macs on the same network, and it still exhibited the problem.

I have now deleted ~.composer and successfully updated that Mac too.

[alcohol]

Well... it would have been nice if you shared any relevant details about what is different in your local ~/.composer and that Mac's ~/.composer before deleting it. Now I guess we will never know if that was actually at all related to your issue or just merely a coincidence.

[alcohol]

Also, the contents of ~/.composer have zero impact on a curl request to packagist.

[cgrossde]

Is there a way to force composer to use IPv4?

[Seldaek]

@cgrossde see composer/composer#4142 (comment)

[cgrossde]

Using a Mac -.- I have IPv6 in my LAN but we don't have an IPv6 uplink. So no IPv6 connection to the rest of the internet. It would be nice to disable the use of IPv6 in a config file or at least fallback to IPv4 if a connection is not established within ~5s.

UPDATE:

Workaround for Mac OS X:

Get name of your network device:

networksetup -listallnetworkservices

Disable IPv6 on that device (in my case "Wi-Fi")

networksetup -setv6off Wi-Fi

Do your composer thingy ....

You can enable IPv6 again with:

networksetup -setv6automatic Wi-Fi

[countextreme]

So I hate to be the bearer of bad news, but I'm having this issue (old ticket is old, I know). The issue does appear to be either at your VPS or on OVH's end and not on the user side. I've tried to get to packagist.org from several of my VPS's and the last hop I can see is at their router, be50-7.bhs-3a-a9.qc.ca (2607:5300::126).

OVH Looking Glass shows that my hosting provider's ASN is unreachable from 3 of their nodes (oddly, it looks like it can find a route for BHS but still won't complete a traceroute): https://lg.ovh.net/prefix/bhs+rbx+sbg+gra/ipv6?q=2604%3A180%3A2%3A%3Ad2a1%3A3da5

(the provided IP is the LG for RamNode New York: http://lg.nyc.ramnode.com )

IPv4 to packagist.org works fine. IPv6 requests on my VPS's to google.com work fine.

Can you please open a ticket with OVH for this issue? (UPDATE: They have a Twitter listed on their LG page, so I sent them a tweet: @as16276 can you please fix your route to AS3842? Thanks! http://lg.nyc.ramnode.com/ https://lg.ovh.net/prefix/bhs+rbx+sbg+gra/ipv6?q=2604:180:2::d2a1:3da5 …)

If IPv6 connectivity is continuing to be unreliable for some users, perhaps it would be best to delete the AAAA record until it's stable? It would likely break zero users and fix several.

[connor11528]

Same thing, having issues because cannot connect to packagist via https. Any solution here?

$ composer diagnose
Checking composer.json: WARNING
require.laravel/nova : unbound version constraints (*) should be avoided
Checking platform settings: OK
Checking git settings: OK
Checking http connectivity to packagist: OK
Checking https connectivity to packagist:
The "https://packagist.org/packages.json" file could not be downloaded: failed to open stream: Operation timed out
Retrying with degraded mode, check https://getcomposer.org/doc/articles/troubleshooting.md#degraded-mode for more info
OK
Checking github.com rate limit: OK

[fdelapena]

The solution is: migrate from OVH to a serious provider. I've wasted too much months contacting support about broken routes randomly. Even Let's Encript OCSP responders for stapling cache were failing from different nodes for different IPv6 from the same subnet, getting TLS handshake timeouts while serving.

To sum up: move your VPS to a provider which takes IPv6 networking seriously.

[shakaran]

For server or linux users, you probably could try to disable iptables, but it seems that it is not a problem blocking the ips.

For me, the real problem was that CentOS 6, 7 and 8 prior the traffic with ipv6 instead ipv4. So the following command will prior the traffic to ipv4 and works for me now:

sudo sh -c "echo 'precedence ::ffff:0:0/96 100' >> /etc/gai.conf"

See docs about "Operation timed out (IPv6 issues)"

Also useful this reply

[Ahed91]

Yesterday I've downloaded packages with no problem .
Today I couldn't install any package so I tested my IPv6 connectivity using "https://test-ipv6.com/"

Test with IPv4 DNS record ok (0.704s) using ipv4
Test with IPv6 DNS record bad (0.252s)
Test with Dual Stack DNS record ok (0.710s) using ipv4
Test for Dual Stack DNS and large packet ok (0.742s) using ipv4
Test IPv6 large packet bad (0.240s)
Test if your ISP's DNS server uses IPv6 timeout (15.009s)
Find IPv4 Service Provider ok (0.314s) using ipv4 ASN 199046
Find IPv6 Service Provider bad (0.305s)

So i think my ISP have problem,

curl --ipv6 'https://packagist.org/packages.json'
curl: (7) Couldn't connect to server

curl --ipv4 'https://packagist.org/packages.json'
{"packages":[],"notify":"https://packagist.org/...}

I think composer should use IPv4, though.

[drzraf]

Years later, OVH BHS datacenter (Quebec) IPv6 connectivity is still very problematic. Googleapis and Gitlab networks are particularly affected (= not working for months over IPv6). Support didn't considered yet this issue as "grave enough".

Having an --ipv4 flag specific in composer (or by composer repository) would be nice to deal with such situations.

[Seldaek]

@drzraf see composer/composer#11791