Docker pull:TLS握手超时


14

我总是得到这个(Ubuntu 16.04 LTS):

$ docker pull nginx
Using default tag: latest
Error response from daemon: Get https://registry-1.docker.io/v2/: net/http: TLS handshake timeout

但是curl TLS可以正常工作(除了auth错误):

$ curl https://registry-1.docker.io/v2/
{"errors":[{"code":"UNAUTHORIZED","message":"authentication required","detail":null}]}

甚至一个小的golang程序(模仿docker)也可以正常工作:

package main
import (
    "fmt"
    "io/ioutil"
    "net/http"
)
func main() {
    resp, err := http.Get("https://registry-1.docker.io/v2/")
    if err != nil {
        panic(err)
    }
    defer resp.Body.Close()
    body, err := ioutil.ReadAll(resp.Body)
    if err != nil {
        panic(err)
    }
    fmt.Println("Got: ", string(body))
}

Docker TLS超时请求的pcap:

reading from file docker-timeout.pcap, link-type LINUX_SLL (Linux cooked)
00:38:54.782452 IP my-ubuntu.52036 > registry-1.docker.io.https: Flags [S], seq 26945613, win 29200, options [mss 1460,sackOK,TS val 1609360 ecr 0,nop,wscale 7], length 0
00:38:54.878630 IP registry-1.docker.io.https > my-ubuntu.52036: Flags [S.], seq 2700732154, ack 26945614, win 26847, options [mss 1460,sackOK,TS val 947941366 ecr 1609360,nop,wscale 8], length 0
00:38:54.878691 IP my-ubuntu.52036 > registry-1.docker.io.https: Flags [.], ack 1, win 229, options [nop,nop,TS val 1609384 ecr 947941366], length 0
00:38:54.878892 IP my-ubuntu.52036 > registry-1.docker.io.https: Flags [P.], seq 1:156, ack 1, win 229, options [nop,nop,TS val 1609384 ecr 947941366], length 155
00:38:55.175931 IP my-ubuntu.52036 > registry-1.docker.io.https: Flags [P.], seq 1:156, ack 1, win 229, options [nop,nop,TS val 1609459 ecr 947941366], length 155
00:38:55.475954 IP my-ubuntu.52036 > registry-1.docker.io.https: Flags [P.], seq 1:156, ack 1, win 229, options [nop,nop,TS val 1609534 ecr 947941366], length 155
00:38:56.076327 IP my-ubuntu.52036 > registry-1.docker.io.https: Flags [P.], seq 1:156, ack 1, win 229, options [nop,nop,TS val 1609684 ecr 947941366], length 155
00:38:57.280103 IP my-ubuntu.52036 > registry-1.docker.io.https: Flags [P.], seq 1:156, ack 1, win 229, options [nop,nop,TS val 1609985 ecr 947941366], length 155
00:38:59.684095 IP my-ubuntu.52036 > registry-1.docker.io.https: Flags [P.], seq 1:156, ack 1, win 229, options [nop,nop,TS val 1610586 ecr 947941366], length 155
00:39:04.492102 IP my-ubuntu.52036 > registry-1.docker.io.https: Flags [P.], seq 1:156, ack 1, win 229, options [nop,nop,TS val 1611788 ecr 947941366], length 155
00:39:04.879468 IP my-ubuntu.52036 > registry-1.docker.io.https: Flags [F.], seq 156, ack 1, win 229, options [nop,nop,TS val 1611884 ecr 947941366], length 0
00:39:04.976015 IP registry-1.docker.io.https > my-ubuntu.52036: Flags [.], ack 1, win 105, options [nop,nop,TS val 947943890 ecr 1609384,nop,nop,sack 1 {156:157}], length 0
00:39:04.976073 IP my-ubuntu.52036 > registry-1.docker.io.https: Flags [P.], seq 1:156, ack 1, win 229, options [nop,nop,TS val 1611909 ecr 947943890], length 155
00:39:05.275922 IP my-ubuntu.52036 > registry-1.docker.io.https: Flags [P.], seq 1:156, ack 1, win 229, options [nop,nop,TS val 1611984 ecr 947943890], length 155
00:39:05.876104 IP my-ubuntu.52036 > registry-1.docker.io.https: Flags [P.], seq 1:156, ack 1, win 229, options [nop,nop,TS val 1612134 ecr 947943890], length 155

可能出什么问题了?


1
我更换了DSL调制解调器,问题就消失了……我怀疑这是MTU问题。
威廉

Answers:


14

net/http: TLS handshake timeout表示您的互联网连接速度很慢。连接超时的默认值对于您的环境而言太小。不幸的是,码头工人没有任何允许您更改连接超时的设置。您可以尝试在其他地方创建自己的注册表缓存并从中提取图像。


1
好了,speedtest.netfast.com显示我的网速为90兆比特/秒。那慢吗?我正在拉python:2.7-slim图像。我能够hello-world从集线器中提取,但不能从python中提取。它给了我同样的TLS handshake timeout错误。
Nikhil Chilwant

3
在人们开始做一些戏剧性的事情之前,我想说一句:在图像名称中出现错字也会产生相同的错误。非常具有描述性。
Barafu Albino

1
TLS握手超时通常并不意味着互联网连接会变慢。如果TLS握手由于不同的原因而停止,该消息也会出现。例如,如果一方不喜欢使用特定的TLS版本或由于证书问题而无法进行交谈。
Bndr '19

4

在我的情况下,我的服务器位于nat和proxy之后,并设置为自动检测代理,我在当前终端上所做的操作我具有导出代理设置

root@k8master:~/runner# export http_proxy="http://192.168.10.208:3128"
root@k8master:~/runner# docker pull gitlab/gitlab-runner:latest
latest: Pulling from gitlab/gitlab-runner
7b722c1070cd: Pull complete 
5fbf74db61f1: Pull complete 
ed41cb72e5c9: Pull complete 
7ea47a67709e: Pull complete 
ae336ceeca88: Pull complete 
f9f79780e6cf: Pull complete 
67e622273f37: Pull complete 
bc84c40af701: Pull complete 
69e36092e9de: Pull complete 
Digest: sha256:b1f5387942aaaf8c220f6613a1e96ba2cbcb6c58a5e47ca0df8ae3216720a15e
Status: Downloaded newer image for gitlab/gitlab-runner:latest

3

docker run hello-world第一次遇到了同样的问题,导致使用来下载图片https://registry-1.docker.io/v2/,最后以

docker: Error response from daemon: Get https://registry-1.docker.io/v2/: proxyconnect tcp: net/http: TLS handshake timeout.

在网络上搜索了几个小时,发现这种情况发生在某些使用ubuntu 18.04和当前docker版本,位于代理后面的用户。一种解决方法是删除所有https-proxy配置,以便仅保留http-proxy配置,以强制进行HTTP(而非https)下载。

不知道,真正的原因是什么。

(顺便说一句:我在作曲家和包装专家面前遇到了同样的“ TLS握手”问题。这是因为缺少了cacert.pem文件,默认情况下ubuntu并未提供该文件。也许这个docker问题正朝着同一个方向发展) ?)


3

我遇到同样的问题。然后,Azamat Hackimov的回答为我指明了正确的方向。我的计算机运行缓慢,尤其是在启动时,当我要启动服务时。因此,短暂的超时开始并终止了我的请求。

这是我的解决方法:

docker pull $IMAGE || docker pull $IMAGE ||  docker pull $IMAGE || docker pull $IMAGE

只需根据请求锤击服务器。通常第二个对我来说是成功的。


这不是最终的解决方案,但可以作为一种临时解决方法
Gonzalo Cao

2

如果使用私有注册表,则需要将该证书放置在/etc/docker/certs.d/ 注册表名称/ca.crt下

注册表名称将相应更改

另外,请将MTU大小更改为1300,这也是我解决该错误的一件事。注册表之一,我相信您可能已经做过。更改MTU的命令

ip link set dev eth0 mtu 1300

如果您的互联网速度确实不错,则检查MTU大小对于避免此错误非常重要


那是一个很好的提示,但是没有证书会导致x509: certificate signed by unknown authority错误,而不是TLS handshake timeout
wisbucky

0

对我有用的是使用其他网络接口。我没有通过以太网(有线)进行连接,而是切换到了wifi。问题解决了。

顺便说一句,我正在重新安装Raspbian Stretch。


0

上面的答案都不能解决我的问题,但是我发现下面的https://github.com/helm/helm/issues/5220对我有用!

更改之后,我公司的IT部门找到了解决方案。我将https_proxy环境变量与https:// url一起用于我们的代理。这适用于我们正在使用的大多数工具,但不适用于头盔或较新的kube。他们似乎在TLS握手方面遇到了一些问题。我们从https://切换为http://网址(例如https_proxy = http:// myproxy),现在一切正常。


0

你可以得到TLS handshake timeout错误,如果您的码头工人守护进程代理配置不正确。

# verify docker daemon proxy configuration
/etc/systemd/system/docker.service.d/proxy.conf

# flush changes
sudo systemctl daemon-reload

# restart docker service
sudo systemctl restart docker 

有关更多详细信息,请参见https://docs.docker.com/config/daemon/systemd/#httphttps-proxy

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.