Fix Composer Could Not Resolve Host Errors

DEV Community

composer could not resolve host ci and the errno that decides

A composer could not resolve host ci failure is a TransportException whose text is half Composer and half libcurl, and the small integer in the middle is the part worth reading, because Composer uses it to decide whether the request is worth another attempt. For the errnos it does retry, reaching you as a failure means four attempts failed rather than one, which changes what the fix should be. Composer retries a fixed set of curl error numbers on GET requests only, up to three times. The middle panel is the branch nobody expects: on error 7 the second attempt is made with the address family forced to IPv4. What this error means A composer install or composer update step stops with a line of the form curl error while downloading : , sometimes wrapped in a [Composer\Downloader\TransportException] banner. The integer is a libcurl error number and the description after the colon is libcurl's own text for that failure, so curl error 6 carries Could not resolve host: and curl error 28 carries a timeout message. Composer prints nothing at all about the attempts it made first: the retry notices are written at debug verbosity, so an ordinary job shows one line for what was four requests. A curl error 7 is worth separating from the rest, because Composer handles it specially in a way that changes the second attempt. ```Reconstructed from the TransportException throw in CurlDownloader::tick, Composer 2.10.3, with the description after the colon as libcurl prints it for errno 6, observed with curl on 2026-09-21 curl error 6 while downloading https://repo.packagist.org/packages.json: Could not resolve host: repo.packagist.org

Common causes

DNS in the job is failing under Composer's own parallelism

Composer downloads with a curl multi handle and runs up to twelve requests at once by default. Twelve simultaneous resolutions of the same and different hosts is enough to expose a small or overloaded resolver, and the result is curl error 6 on some requests while others in the same run succeed. The pattern to look for is a failure that names a different package each time, which points at the resolver rather than at any one host.

IPv6 egress is advertised but not routed

A network that hands out AAAA records but cannot actually route them produces curl error 7 on the first attempt of each connection. Composer retries with IPv4 forced, so many of these recover silently and only the unlucky ones surface. The symptom is a build that is mysteriously slower than it used to be, with occasional failures, rather than a clean break.

A proxy is in the path and is slow rather than broken

An outbound proxy that accepts the connection and then takes its time gives you curl error 28. The distinguishing feature against a DNS problem is that the failure attaches to the large transfers, the distribution zips, rather than to the small metadata requests, because those are the ones with time to run out.

The repository throttled you with a 429

Composer does not retry 429, so the first throttled response ends the run. In our experience this is the version that looks like a sudden regression after a matrix was widened, because the number of jobs hitting one repository in a minute went up while nothing else changed. The error text here is a status code rather than a curl errno, which is itself the clue that you are on the status path and not the transport path.

How to fix it

Turn on verbosity before you decide anything

1. Add -v to the failing Composer call in a scratch branch. The retry notices are debug level, so this is the only way to see whether the single line in your log represents one attempt or four.
2. Read which URLs retried. If every retried URL is a different host, suspect the resolver. If they are all the same large archive, suspect a timeout or a proxy size limit.
3. Leave -v on in CI permanently if the noise is acceptable. A failure that shows its attempts is worth several ...
   
   Powered by Readybot.io