Docker容器没有curl怎么排查网络

在 Docker 容器中排查接口连接问题时，很多人会先执行 curl，却发现容器里根本没有这个命令。

例如：

curl: not found

或者：

exec: "curl": executable file not found in $PATH

这时可以启动一个自带 curl 的临时容器，让它接入需要检查的网络，再测试目标地址。

本文介绍两种方式：共享目标容器的网络环境，以及加入已有的 Compose 网络。选对方式，才能避免“测试地址一样，实际访问位置却不同”的问题。

1. 没有 curl，不代表容器无法联网

一些镜像只包含运行应用所需的文件，并未安装 curl、ping 或 bash。

因此，看到 curl: not found，首先说明的是命令不存在，不能据此判断：

DNS 是否正常。
目标端口是否可达。
HTTPS 证书是否有效。
应用是否能正常调用接口。

直接进入业务容器安装工具，还可能遇到没有包管理器、权限不足或容器重建后工具消失等情况。

对于临时检查，可以使用专门的 curl 镜像完成测试，避免修改业务镜像。

2. 操作前准备什么

本文以 Linux 服务器上的 Docker Engine 为例，适用于常见的 bridge 网络及 Docker Compose 项目。

在服务器终端执行：

docker --version

查看正在运行的容器：

docker ps --format 'table {{.Names}}\t{{.Status}}\t{{.Ports}}'

记下需要排查的容器名称。后文使用：

myapp

作为示例，执行时必须替换为实际容器名称。

如果尚未安装 Docker，可以先参考本站的：

服务器上安装 Docker 和 Docker Compose 教程

本次使用 curl 项目提供的容器镜像，示例固定为已核对存在的 8.23.0 标签。

先拉取镜像：

docker pull curlimages/curl:8.23.0

确认工具可以启动：

docker run --rm curlimages/curl:8.23.0 --version

如果镜像下载失败，应先处理 Docker 拉取镜像的问题。此时测试容器尚未运行，不能把下载失败当成目标业务容器的网络测试结果。

如果需要独立的测试环境，可以使用莱卡云 Linux 云服务器进行操作。

查看官网购买链接： https://www.lcayun.com

9折优惠码：bloglcayun

3. 借用目标容器的网络测试外部地址

假设需要排查的容器名为 myapp，可以执行：

docker run --rm --network container:myapp \
  curlimages/curl:8.23.0 \
  --connect-timeout 5 --max-time 15 \
  --silent --show-error --output /dev/null \
  --write-out 'HTTP=%{http_code}\n' \
  https://example.com

将最后的地址替换为需要检查的网站或接口。

这里的关键参数是：

--network container:myapp

它让临时容器直接使用 myapp 的网络栈，包括网络接口、路由和回环地址。Docker 官方支持通过 container:容器名称或ID 指定这种网络模式。

其他参数含义如下：

参数	作用
`--rm`	命令结束后自动删除临时容器
`--connect-timeout 5`	连接阶段最多等待 5 秒
`--max-time 15`	整个请求最多运行 15 秒
`--silent --show-error`	隐藏进度条，但保留错误信息
`--output /dev/null`	不显示响应正文
`--write-out`	输出 HTTP 状态码

这些超时参数限制的是 curl 请求过程，不包含 Docker 下载镜像的时间。

请求正常时，可能看到：

HTTP=200

这只是输出示例，实际状态码取决于访问的地址。

如果显示：

HTTP=000

说明没有取得有效的 HTTP 状态码，应结合同时出现的 curl 错误信息继续判断。

4. 检查业务容器自己的本机端口

假设业务程序在容器内监听 8080 端口，可以执行：

docker run --rm --network container:myapp \
  curlimages/curl:8.23.0 \
  --connect-timeout 5 --max-time 15 \
  --silent --show-error --output /dev/null \
  --write-out 'HTTP=%{http_code}\n' \
  http://127.0.0.1:8080/

这里的 8080 要替换为应用实际监听的端口，路径也应根据实际接口调整。

因为临时容器共享了 myapp 的网络环境，此时访问 127.0.0.1，可以检查该网络环境中的本机监听服务。

如果只是启动一个普通临时容器，却没有添加：

--network container:myapp

那么它访问的 127.0.0.1 通常只是临时容器自己，无法据此判断业务程序是否正常。

另外，容器的本机地址与宿主机地址需要区分。如果真正需要连接的是服务器宿主机上的服务，可以参考本站的：

Docker容器访问宿主机怎么配置？地址设置与连接排查

5. 检查 Compose 项目内的服务连接

如果需要判断同一 Compose 网络中的服务能否互相访问，可以让临时容器加入该项目的网络。

先查看业务容器连接了哪些网络：

docker inspect --format '{{range $name, $_ := .NetworkSettings.Networks}}{{println $name}}{{end}}' myapp

假设其中一个网络名称为：

myproject_default

项目中需要测试的服务名为 app，应用在容器内监听 8080，执行：

docker run --rm --network myproject_default \
  curlimages/curl:8.23.0 \
  --connect-timeout 5 --max-time 15 \
  --silent --show-error --output /dev/null \
  --write-out 'HTTP=%{http_code}\n' \
  http://app:8080/

需要替换三处：

myproject_default：实际网络名称。
app：目标服务在该网络中的服务名或别名。
8080：目标应用的容器内部端口。

Compose 默认网络中的服务可以通过服务名互相发现。这里使用容器内部端口，不需要绕到服务器公网 IP 或宿主机映射端口。

两种方式可以这样选择：

检查目标	使用方式	示例地址
目标容器自己的本机监听	`--network container:myapp`	`http://127.0.0.1:8080/`
同一项目网络中的其他服务	`--network myproject_default`	`http://app:8080/`

如果本机端口测试成功，但按服务名访问失败，应进一步检查网络成员关系、服务名和监听地址。

例如，应用只监听自己容器内的 127.0.0.1 时，同网络中的其他容器通常无法通过容器 IP 访问它。应根据应用配置，将服务监听在需要提供访问的接口上。

6. 如何判断 curl 的测试结果

排查时，需要同时区分 curl 错误编号和 HTTP 状态码。

curl 错误编号

常见输出	含义	优先检查
`curl: (6)`	无法解析目标主机名	域名拼写、DNS、服务名与网络
`curl: (7)`	连接目标失败	地址、端口、服务监听和访问规则
`curl: (28)`	请求达到超时限制	网络路径、连接或响应耗时
`curl: (35)`	TLS 握手出现问题	协议、TLS 配置及详细错误
`curl: (60)`	证书验证失败	域名、有效期、证书链和信任 CA

这些错误描述的是不同阶段的问题，不能统一归结为“Docker 没网”。

HTTP 状态码

状态码	通常说明什么
`200`	请求取得成功响应，仍需确认内容符合预期
`301`、`302`	收到重定向，需检查跳转目标
`401`、`403`	收到认证或权限相关响应
`404`	收到响应，但请求路径或资源不匹配
`502`、`503`	网关或服务端返回异常，需要继续检查后端

例如，收到 401，说明已经有 HTTP 服务返回了认证要求。接下来通常应该检查鉴权配置，而不是继续修改 DNS。

本文命令没有使用 --fail，因此即使返回 404，curl 也可能正常退出。命令退出码为 0，不等于业务接口一定健康。

7. 临时容器能访问，为什么应用仍然失败

共享网络环境，有助于缩小排查范围，但不能完全复制业务程序的运行条件。

需要继续对照：

应用是否配置了 HTTP 或 HTTPS 代理。
应用使用的地址、端口和协议是否相同。
请求是否需要 Token、Cookie 或特定请求头。
应用使用的是 GET、POST，还是其他请求方法。
应用是否使用独立的证书信任库。
应用的连接和请求超时是否更短。

临时 curl 请求成功，只能证明这一次请求在相应条件下成功，不能直接推断所有业务请求都会正常。

需要查看更多连接信息时，可以执行：

docker run --rm --network container:myapp \
  curlimages/curl:8.23.0 \
  --connect-timeout 5 --max-time 15 \
  --verbose --output /dev/null \
  https://example.com

将地址替换为实际目标，观察连接地址、TLS 信息和响应头。分享调试日志前，应去除其中的认证信息。

如果出现证书错误，应修复证书、域名或信任链配置。-k 会跳过证书验证，不应把它作为 HTTPS 问题的长期解决方法。

8. 使用临时诊断容器时还要注意什么

目标容器需要处于运行状态

使用 --network container:myapp 前，先确认目标容器正在运行。

如果目标容器不断重启，应先查看它的启动日志。临时网络测试不能替代应用启动故障排查。

不需要额外开放公网端口

本文命令用于从容器发起请求，没有使用 -p 发布端口，也不需要为了运行 curl 新增公网入站规则。

退出后自动删除的是临时容器

--rm 会清理本次临时容器，业务容器不会因此被删除。下载到服务器上的 curl 镜像仍会保留，方便下次使用。

临时工具不能补齐业务容器的健康检查命令

如果 Compose 的 healthcheck 在业务容器内部执行 curl，那么 curl 仍然必须存在于该业务镜像中。

另外启动一个临时 curl 容器，并不会让业务容器自动获得这个命令。

9. 写在最后

容器里没有 curl 时，可以先借助临时诊断容器完成网络检查。

检查目标容器自己的本机端口，使用 --network container:容器名称；检查 Compose 服务之间的访问，加入实际项目网络，再使用服务名和容器端口连接。

得到结果后，再区分 DNS、连接、TLS 和 HTTP 响应问题。这样既能减少对业务环境的改动，也能让后续排查更有依据。