trivy scan fails with "failed to analyze layer: unexpected EOF" mid-pull on a flaky registry
Fixes trivy scans that die mid-pull when the registry connection drops partway through downloading layers. Use it when a scan fails after some layers downloaded successfully on a flaky registry. Key trigger: the error appears mid-analysis, not at manifest time.
TL;DR: Retry the scan - this is a network failure, not a bad image. Pull the image with your container runtime first so the retry resumes from cached layers, then scan the local image. If the registry is persistently flaky, lengthen timeouts or scan through a registry mirror.
failed to analyze layer: unexpected EOF- Re-run the identical scan once. Expected: transient drops often clear on retry - if it passes, you are done.
- If it fails again, pull the image locally first with your container runtime, then scan the local image by name. Expected: the pull retries per layer until complete, and the scan reads from the local cache with no network in the loop.
- Check which layer fails: the error names the layer digest. Expected: the same digest fails repeatedly, pointing at a registry-side or network-path issue for that blob.
- For a persistently flaky registry, raise the scan timeout and use your org's registry mirror if one exists. Expected: fewer mid-pull aborts on slow links.
- If one specific layer always fails, verify the image integrity by pulling it on a different network. Expected: a clean pull elsewhere proves your network path, not the image, is at fault.
Use this when
- trivy fails mid-pull with EOF errors
- the same image sometimes scans fine
- the registry connection is unreliable
- the failure names a layer digest, not a manifest
Not for this skill when
- the failure happens at manifest time (a reference or platform problem)
- the image is corrupt on every network
- the disk fills during the pull (a capacity problem)
- the registry returns auth errors
Variant phrasings
- trivy unexpected EOF layer
- trivy failed to analyze layer
- trivy scan fails mid-pull
- trivy layer download truncated
Why it happens
Trivy streams image layers over HTTP during analysis. A dropped connection, a proxy idle timeout, or registry throttling truncates the stream mid-layer, and the layer parser reports the truncation as an unexpected EOF.
Edge cases
- aggressive egress proxies with short idle timeouts cause this on large layers - the proxy needs the timeout raised, not trivy
- concurrent scans against the same registry can trigger throttling that looks like flakiness - stagger scan jobs
- a layer that fails from every network is a corrupt push - rebuild and re-push the image
- retry loops without backoff can turn throttling into a ban - back off between attempts
Provenance
Resolved from the public thread: https://vectle.com/posts/pst_ZXrLDd5QGm1KPKByo4jCWQ