Docker pull:TLSハンドシェイクタイムアウト


13

私はこれを一貫して取得します(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

ただし、カールTLSは正常に機能します(認証エラーは別として)。

$ 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の問題だと思います。
ウィレム

回答:


14

net/http: TLS handshake timeoutインターネット接続が遅いことを意味します。接続タイムアウトのデフォルト値は、ご使用の環境には小さすぎます。残念ながら、Dockerには接続タイムアウトを変更できる設定がありません。独自のレジストリキャッシュを別の場所に作成し、そこからイメージを取得しようとする場合があります。


1
さて、私のインターネット速度が90 Mbit / s であることspeedtest.netfast.com示してください。遅いですか?python:2.7-slim画像を引いています。hello-worldハブからプルすることはできますが、Pythonからはできません。同じTLS handshake timeoutエラーが発生します。
ニキルチルワント

3
人々が何か劇的なことを始める前に、私は発言したい。画像名にタイプミスがあると同じエラーが発生する。とてもわかりやすい。
バラフアルビノ

1
TLSハンドシェイクのタイムアウトは、インターネット接続が遅くなることを意味するものではありません。TLSハンドシェイクがさまざまな理由で停止した場合にも、このメッセージが表示されます。たとえば、一方が特定のTLSバージョンとの通信を好まない場合、または証明書の問題のためです。
Bndr

4

私の場合、私のサーバーはNATとプロキシの背後にあり、プロキシを自動検出するように設定されています現在の端末で行ったことをプロキシ設定をエクスポートしています

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-world1回目に同じ問題を抱えていましたが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リリースを使用している一部のユーザーでプロキシの背後で発生することがわかりました。回避策は、http(プロキシではない)ダウンロードを強制するために、httpプロキシ構成のみを残すために、すべてのhttpsプロキシ構成を削除することです。

本当の理由は何なのか分かりません。

(ところで:私は作曲家とpackagistで同等の「TLSハンドシェイク」問題を抱えていました。これはデフォルトでubuntuによって提供されていなかったcacert.pemファイルがないためです。おそらくこのドッカー問題は同じ方向に向かっています?)


2

プライベートレジストリを使用している場合、その証明書を/etc/docker/certs.d/ registryname /ca.crtの下に配置する必要があります

レジストリ名はそれに応じて変更されます

また、MTUサイズを1300に変更してください。これもエラーを解決するために行ったことの1つです。既に登録済みの可能性があると私は信じています。MTU変更のコマンド

ip link set dev eth0 mtu 1300

MTUサイズは、インターネット速度が本当に良い場合にこのエラーを回避するために確認することが重要です


これは良いヒントですが、証明書がないとx509: certificate signed by unknown authorityエラーになりますTLS handshake timeout
ウィスバッキー

2

同じ問題が発生します。その後、Azamat Hackimovの答えは私を正しい方向に向けました。私のマシンは、特に起動時にサービスを起動したいときに、多少遅くなります。したがって、短いタイムアウトが開始され、リクエストが強制終了されます。

これは私の回避策です:

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

リクエストでサーバーをたたくだけです。通常、2番目は成功します。


一時的な回避策としてではない決定的な解決策が、良い
ゴンサロ・曹操

0

私のために働いたのは、異なるネットワークインターフェースを使用することでした。イーサネット(有線)経由で接続する代わりに、wifiに切り替えました。問題が解決しました。

ところで、私はRaspbian Stretchの新規インストールをしていました。


0

上記の答えのどれも私の問題を解決することはできませんが、https://github.com/helm/helm/issues/5220の下で私のために働くことがわかりました!

その変更の後、私の会社のITアパートが解決策を見つけました。プロキシのhttps:// urlでhttps_proxy環境変数を使用しました。これは、使用しているほとんどのツールで機能しますが、ヘルムや新しいkubeでは機能しません。TLSハンドシェイクにいくつかの問題があるようですhttps://からhttp:// URL(例:https_proxy = http:// myproxy)に切り替えたところ、すべて正常に動作するようになりました。


弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.