Introduction

If curl does not run inside a Docker container, the problem is usually one of three things: the tool is not installed, the container has networking or DNS issues, or the command is running in a stripped-down image with different package conventions than you expected. The fastest fix is to separate “is curl present” from “does the network request work.”

First Confirm Whether curl Exists

Many minimal images do not include curl at all. Test that first.

docker exec -it my-container sh -c 'which curl || echo "curl not found"'

If it is missing, install it using the image’s package manager.

Debian or Ubuntu based image:

FROM ubuntu:24.04
RUN apt-get update && apt-get install -y curl && rm -rf /var/lib/apt/lists/*

Alpine based image:

FROM alpine:3.20
RUN apk add --no-cache curl

Those are different because the base images are different. apt-get does not exist in Alpine, and apk does not exist in Ubuntu.

Distinguish Tool Installation from Request Failure

Once curl exists, run a controlled command with verbose output.

docker exec -it my-container sh -c 'curl -v https://example.com'

Now you can see what kind of failure it is:

• command not found
• DNS lookup failure
• TLS certificate issue
• connection refused
• timeout

Those are very different problems. Installing curl fixes only the first one.

Check Container Networking and DNS

If curl is installed but cannot reach hosts, inspect the container’s network setup.

docker inspect my-container --format '{{json .NetworkSettings.Networks}}'

Then test simple cases from inside the container:

docker exec -it my-container sh -c 'cat /etc/resolv.conf'
docker exec -it my-container sh -c 'ping -c 1 8.8.8.8 || true'
docker exec -it my-container sh -c 'curl -v http://host.docker.internal:8080 || true'

If IP connectivity works but hostnames fail, you likely have a DNS problem. If neither works, the container network or upstream route is the problem.

Remember That Minimal Images May Lack CA Certificates

Another common surprise is that HTTPS requests fail because CA certificates are missing, not because curl itself is broken.

For Alpine:

FROM alpine:3.20
RUN apk add --no-cache curl ca-certificates

For Debian or Ubuntu:

1FROM ubuntu:24.04
2RUN apt-get update && \
3    apt-get install -y curl ca-certificates && \
4    rm -rf /var/lib/apt/lists/*

Without CA certificates, HTTPS requests may fail with certificate verification errors even though DNS and TCP connectivity are fine.

Use the Right Base-Image Expectations

Containers are not full virtual machines. BusyBox, Alpine, distroless, and slim runtime images intentionally omit many debugging tools. That means your application image may be designed not to include curl.

When debugging, one useful trick is to run a temporary diagnostic container on the same network:

docker run --rm -it --network container:my-container curlimages/curl:8.8.0 \
  curl -v https://example.com

This lets you test network behavior without bloating the production image just for troubleshooting.

Common Pitfalls

• Assuming every base image already contains curl is wrong, especially for slim or Alpine-style images.
• Using the wrong package manager for the base image leads to confusing “command not found” build errors.
• Treating all curl failures as installation issues hides DNS, TLS, or routing problems.
• Forgetting CA certificates causes HTTPS failures even when the curl binary exists.
• Installing curl into the runtime image permanently when a temporary diagnostic container would be cleaner increases image size unnecessarily.

Summary

• First check whether curl is present at all inside the container.
• Install it with the correct package manager for the chosen base image.
• Use verbose output to separate tool problems from DNS, TLS, or network failures.
• Add CA certificates if HTTPS requests fail due to trust issues.
• For debugging, consider a temporary sidecar or diagnostic container instead of permanently bloating the runtime image.