Composer Download Timeout: Check Dist and Source

A Composer download timeout needs the first failed transfer, not just the final installation error. Preserve composer.lock, identify whether Composer requested a dist archive or source checkout, and repeat that locked dependency set after separating network, credentials, and rate limits.

Key Takeaways:

• install with an existing lock file and update have different purposes.
• A dist archive and a source clone can use different hosts and credentials.
• HTTP download timeouts and external-process timeouts are separate controls.
• Download completion does not prove that plugins, scripts, or the application work.

Step 1: What should you preserve before a Composer download timeout?

Keep composer.json, composer.lock, and a recoverable copy of the project. Record the original command, working directory, PHP version, Composer version, and whether the command runs locally, inside a container, or on a remote build machine. Keep credentials in their existing protected storage; do not copy them into a public diagnostic note.

php --version
composer --version

With a valid existing lock file, composer install uses its dependency versions. composer update resolves dependencies and writes the lock file, so it is not an equivalent download retry. Without a lock file, installation can resolve a new set; stop and clarify the intended input instead of calling that a locked comparison.［3］

Also note the original development-dependency choice and download preference. Changing --no-dev, package constraints, and dist/source preference together can produce a successful but different installation. Review scripts and plugins before rerunning an untrusted project: dependency installation can execute code, not merely store an archive.

If other applications fail too, first narrow the shared problem with the device and application diagnostic flow. First identify the affected Composer stage.

Do not begin by deleting vendor or all caches. That increases the number of downloads, destroys useful evidence, and may disrupt the working application. A protected disposable copy is a better place for a deliberate test requiring fresh local outputs.

Step 2: What does the first Composer curl error 28 tell you?

Read upward from “installation failed” to the first error involving the selected package. Preserve the package name, locked version or reference, destination role, transfer method, and whether bytes started arriving. Verbose logs can expose tokens and private URLs, so inspect them locally and redact before sharing.

Composer curl error 28 indicates a transfer timeout. The official troubleshooting guidance discusses PHP's default_socket_timeout for HTTP downloads; process-timeout instead limits external processes such as a Git clone. Increasing one does not automatically fix the other. Do not increase every timer without identifying the timed-out operation.［1］［2］

Observed failure	Evidence	Appropriate branch
Dist transfer times out	Archive host and locked package	Compare that content request
Source clone times out	Repository and commit reference	Check Git transport and process limit
401 or 403	Responding service and access requirement	Review credentials and permissions
429 or explicit API quota	Service limit and retry guidance	Respect the limit before retrying
Certificate error	PHP/cURL trust error	Repair approved CA or interception setup
Dependency resolution or script failure	Constraint or script message	Diagnose outside the transfer branch

A slow body transfer is different from a server refusing a credential. Likewise, an error after package extraction should not be described as an archive-host timeout. Copy enough neighboring log context to show the transition, without posting full request URLs containing signed or secret parameters.

Check PHP's loaded configuration for the same execution environment. An IDE, terminal, and container can select different PHP binaries and configuration files. A setting changed on the visible desktop may not reach the process that made the failing request.

Step 3: Why do dist and source behave differently?

Dist usually provides an archive for a package reference; source retrieves a repository checkout. The selected preference is controlled by Composer options and configuration, and current releases can differ in whether fallback is permitted. Read the actual transition in the log rather than assuming every Composer dist download failed message will be followed by a source clone.［2］［3］

The lock file can describe both acquisition forms for the same version. Inspect the affected entry privately to understand its reference and destination roles. Do not manually edit download URLs or package hashes to obtain another archive; an apparently similar package from an untrusted host is not an acceptable substitute.

If the log shows “trying source,” retain both results. The first archive request may have failed while Git later succeeds, or Git may fail for a separate credential or transport reason. A final green installation can therefore hide an unresolved archive-path problem.

On Windows, inspect the surrounding proxy settings, then review what PHP/cURL and Git actually inherit. Environment proxies and application configuration may differ from the browser route. Correcting a stale proxy is a configuration repair; enabling a VPN is a separate network comparison.

process-timeout applies to an external process, not every HTTP request. If a long-running clone is making progress, a controlled limit adjustment may be appropriate, but preserve the original setting and document the reason. If a request never establishes a connection, a longer wait only delays the same failure.［2］

Keep secure-http and TLS verification enabled. For enterprise certificate interception, obtain the approved CA setup from the administrator. A certificate error disappearing after verification is disabled means the protection was removed, not that the connection was safely repaired.

Step 4: Is authentication or rate limiting the actual blocker?

Use the first HTTP response and repository requirement to distinguish authentication from transport. An archive host, API endpoint, and source repository can require different credentials even for one package. Successful browser sign-in does not prove Composer has an authorized token or Git has the right identity.

Review auth.json, global authentication configuration, and environment-supplied credentials privately. Confirm that the credential is valid for the intended host and permitted package; never print a whole authentication file or environment to explain a timeout. Do not embed tokens into a copyable public command.［1］［2］

Respect explicit API rate limits and service retry guidance. Repeated requests, token cycling, or changing the apparent IP to evade a quota are not the network-path comparison described here. Wait or ask the service owner for the supported access method. A 403 can have multiple causes; preserve the response context rather than naming one without evidence.

When the registry supplies metadata but archive content fails, focus on the content host. When private source access fails, use the required organizational route and permissions. A consumer VPN is not a replacement for an internal repository gateway or an approved corporate proxy.

If a check reports a compromised or unexpected package, stop before installation. Network retries cannot establish that a substituted file is trustworthy. Review the original package reference and service information with the owner rather than suppressing the warning to obtain a completed command.

Step 5: How do you repeat the locked download and verify the result?

From a protected, trusted project with an existing lock file, the following is a starting point for observing installation. Preserve the original dev-dependency and acquisition options. It is not a sandbox: plugins and scripts may execute, and skipping them would change the installation being tested.［3］

composer install -vvv

Review the verbose output locally. If no archive or repository request occurs because Composer uses cache or installed files, record that limitation. Do not claim that the failed host recovered from a command that never contacted it. When fresh retrieval is essential, agree on a disposable project copy and isolated outputs instead of clearing a shared cache without a recovery plan.

If the evidence identifies an authorized dist transfer that times out, use AethoVPN to carry that Composer request over another permitted route while leaving composer.lock, credentials, and download preference untouched. Run it on the computer executing PHP: desktop use needs Pro or Premium, with the official Windows package or Debian/Ubuntu x64 .deb; Mac uses website-provided configuration in a VPN client. Select a nearby available app location, enable global mode, and rerun the original installation, recording whether dist completes or source fallback is used. This changes the transport path, not API quota, repository permissions, dependency constraints, or trust requirements.

For a first route comparison, create an account by email and use the new-user 3-day Pro trial, available once per user.

Follow the connection test that includes the application request rather than treating VPN status as the installation result. Confirm container and remote execution routing independently; a host connection indicator does not establish those routes. If direct access succeeds and VPN access fails, keep the working connection and leave this branch.

Check that the requested locked version/reference arrived through the recorded acquisition method. Preserve TLS and any checksums supplied and enforced by the normal package workflow; do not invent a universal archive checksum field where the package has none. Review the lock file afterward for unexpected changes. Extraction, autoload generation, plugins, scripts, and application tests are subsequent results, each with its own failure evidence.

For projects using Java, follow Maven repository and artifact diagnostics. Maven settings are distinct from Composer configuration.

Escalate with package identity when disclosure is allowed, Composer/PHP versions, destination role, transfer method, redacted first error, cache observations, and both route results. Stop when the lock file would change unexpectedly, trust fails, or access policy forbids the comparison. These are useful stopping conditions rather than reasons to try another version at random.

Summary

• Protect the lock file and keep the acquisition method explicit.
• Separate archive downloads, Git processes, credentials, and quotas.
• Repeat an actual request before attributing success to a route change.
• Report transfer, installation, and application outcomes separately.

FAQ

Should I run composer update when install times out?

Use the existing lock file with the original installation task. update resolves versions and changes the dependency input, so its success does not explain why the locked artifact failed. Resolve project changes separately when they are actually intended.

Does process-timeout control curl downloads?

It controls external processes such as Git commands. HTTP timeout handling involves the PHP/download stack and is discussed separately in Composer troubleshooting. Identify the operation before adjusting a timer, then restore or document the setting you changed.

Why can source work after dist fails?

The archive and repository can use different destinations and authentication paths. Source success proves that acquisition path worked for the requested reference; it does not prove the dist host recovered. Record the fallback rather than hiding the first failure.

Can a VPN fix a private repository 403?

A 403 requires analysis of the responding service and your permissions. An alternative permitted route can test transport, but it does not supply a missing credential or authorize restricted content. Follow the repository owner's access procedure.

How can I retry without exposing auth.json?

Keep credentials in their protected configuration and inspect logs locally. Share package and destination roles with secret values, private URLs, and signed query strings removed. Do not dump the authentication file or entire environment into a support request.

Is an unchanged lock file enough to prove recovery?

It is one input check, not the transfer evidence. Confirm the original locked package actually downloaded and note cache use, acquisition form, and applicable integrity checks. Installation scripts or later tests can still fail independently.

When should I stop repeating the installation?

Stop for trust failures, unexplained lock changes, explicit quotas, unauthorized access, or repeated identical failures on both permitted routes. Send a redacted first error and the exact transfer stage to the appropriate service or project owner.

Sources

1. Composer Troubleshooting — https://getcomposer.org/doc/articles/troubleshooting.md
2. Composer Config — https://getcomposer.org/doc/06-config.md
3. Composer Command-line interface / Commands — https://getcomposer.org/doc/03-cli.md

Sources checked 7 October 2026.

Related Articles

• Trace Maven artifact and repository errors
• Check the VPN against a Composer request
• Windows proxy values Composer may use