Compose: UnixHTTPConnectionPool（host ='localhost'，port = None）：读取超时。 （读取超时= 60）

试试这个

export DOCKER_CLIENT_TIMEOUT=120
export COMPOSE_HTTP_TIMEOUT=120

看来现在已经解决了这个问题

人们在此线程中提到的其他解决方案：

• 重新启动Docker
• 增加Docker CPU和内存

如果您关闭WiFi，会发生这种情况吗？ 可能与https://github.com/docker/docker-py/issues/1076相关

另一个理论，如果您的服务启用了tty: True ，则可能是＃3106

我在Mac的最新Beta版中看到了完全相同的问题。 如果我运行docker-compose create则会出现相同的错误

这可能与图像中有一个非常大的图层有关吗？ （非常长的npm install操作，在Docker构建映像时需要大约一分钟的时间将其展平）

我们还使用带有6个容器的docker compose文件[docker-compose版本1.8.1，内部版本878cff1]在Windows和Mac [版本1.12.2-rc1-beta27（内部版本：12496）]上也看到了此问题。
179c18cae7]

增加docker可用资源似乎减少了它发生的机会（延长超时vars也是如此），但从未消除过。

我们也有一些大型层（最大240MB，这是主软件包的install命令），并且我们绑定到一个主机目录，该目录包含几个容器中120MB的文件。

通过解决此问题的不同尝试，我发现了一些可能可以解决的问题：

首先，我的情况看起来像这样：

app:
  build: .
  volumes:
    - ${PWD}:/usr/src
    - /usr/src/node_modules

我的挂载路径包括许多包含大型静态文件的目录，就代码重载而言，我并不需要真正挂载这些目录。 所以我最终换成这样的东西：

app:
  build: .
  volumes:
    - ${PWD}:/usr/src
    - /usr/src/static  # large files in a long dir structure
    - /usr/src/node_modules

这让运行安装所有我的大静态文件，这使得服务启动方式更快的了。

我从中了解到的是：装入的文件越多，尤其是它们挂载的文件（MB中的映像而不是Bs / KB中的源文件）越大，加载时间就会增加很多。

希望这可以帮助

+1
我每周都会看到一次超时问题，通常是在一个空闲的周末之后，而当我尝试连接到我的容器时，它超时了...
我必须终止正在运行的docker proc并重新启动才能解决....

+1
每当我尝试重新启动容器时，都会发生这种情况，因为它们在一天后不再响应。 我不确定我的情况是否与安装有关，因为我试图停止容器。

用nginx修饰符Up 47 hours包装。
适用于Mac的Docker Version 17.03.1-ce-mac12 (17661) Channel: stable d1db12684b 。

version: '2.1'
services:
  nginx:
    hostname: web
    extends:
      file: docker/docker-compose.yml
      service: nginx
    ports:
      - 80:80
      - 443:443
    volumes:
      - ./src:/var/www:ro

  php:
    build:
      dockerfile: "./docker/web/php/Dockerfile"
      context: "."
    volumes:
      - ./src:/var/www

$ docker-compose kill nginx
Killing project_nginx_1 ... 

ERROR: for project_nginx_1  UnixHTTPConnectionPool(host='localhost', port=None): Read timed out. (read timeout=60)
ERROR: An HTTP request took too long to complete. Retry with --verbose to obtain debug information.
If you encounter this issue regularly because of slow network conditions, consider setting COMPOSE_HTTP_TIMEOUT to a higher value (current value: 60).

感谢@gvilarino ，我相信大文件装载是我的Linux服务器上此问题的原因。 如果容器中不需要大文件，则您的代码段可能是一种解决方法。

但是，我想知道为什么Docker中的挂载速度很慢？ 也许触发磁盘复制？ 但为什么？

@cherrot我不会说我非常精通该主题，但是我相信这与Docker使用的存储驱动程序以及它在内部如何使层保持秩序有关。 使用docker info来查看守护进程正在使用什么存储驱动程序（可能是aufs ，这是最慢的），根据您的主机操作系统，您可以更改它，以便进行其他更改（ overlay是一个更好的选择（如果支持）。 有一些更快的替代方案，例如LCFS，但是Docker在商业上不支持它们，因此您可以独自一人。

我们也看到了这种超时。 似乎也是由于我们使用的数量。

我们需要一些容器来访问某些SMB网络共享。 因此，我们将这些共享安装在主机系统上，并将它们绑定安装在容器中。 但是有时Windows Server和我们的Linux主机之间的通信被暂停了（请参阅https://access.redhat.com/solutions/1360683），这阻止了我们的容器的启动或停止，而这只是在一段时间后超时。

我还没有修复。 我正在寻找支持SMB的批量插件，或者使SMB上的停顿通信问题消失。 但还没有真正的解决方案。

FWIW：对于通过搜索引擎登陆这里的人们找到他们的解决方案，我已经可以通过_did尝试将其关闭然后再次打开来解决此问题？ 我已经重新启动了Docker Mac OS客户端。

+1，我在运行4个容器的实例上进行压力测试，即使docker ps -a docker也挂起，所以我试图重新启动容器，但我得到了
UnixHTTPConnectionPool(host='localhost', port=None): Read timed out和

Traceback (most recent call last):
  File "/usr/bin/docker-compose", line 9, in <module>
    load_entry_point('docker-compose==1.8.0', 'console_scripts', 'docker-compose')()
  File "/usr/lib/python2.7/dist-packages/compose/cli/main.py", line 61, in main
    command()
  File "/usr/lib/python2.7/dist-packages/compose/cli/main.py", line 113, in perform_command
    handler(command, command_options)
  File "/usr/lib/python2.7/contextlib.py", line 35, in __exit__
    self.gen.throw(type, value, traceback)
  File "/usr/lib/python2.7/dist-packages/compose/cli/errors.py", line 56, in handle_connection_errors
    log_timeout_error()
TypeError: log_timeout_error() takes exactly 1 argument (0 given)

只有即时重新启动docker服务似乎可以解决，有什么主意吗？

+1

`正在重新启动web-jenkins_jenkins_1 ...

错误：对于web-jenkins_jenkins_1 UnixHTTPConnectionPool（host ='localhost'，port = None）：读取超时。 （读取超时= 130）
错误：HTTP请求花了太长时间才能完成。 使用--verbose重试以获得调试信息。
如果由于网络状况缓慢而经常遇到此问题，请考虑将COMPOSE_HTTP_TIMEOUT设置为更高的值（当前值：120）。

我重新启动码头工人，它解决了。 但每天我都需要重新启动

重新启动Docker对我有用。

+1重新启动docker也为我工作。

在构建一个很大的Docker映像，然后尝试将其推送到远程注册表时，我遇到了这个问题。 重新启动Docker不是适用的解决方案，但是@bodaz的答案为我解决了这个问题： https :

@ rodrigo-brito-我已经出现了一段时间，并且重新启动docker deamon已经解决了这个问题-自从我向项目中添加了另一项服务以来，没有更多了。

我有同样的问题，但是我有一个相当简单的设置。
我只有一个基于164 MB大小的图像的verdaccio 3容器。
这是非常令人失望的：/

我正在使用2015年的MBP Pro 13

发生在我的原因是端口范围很大，实际上每个端口都创建一个规则...。

一个简单的sudo service docker restart每次发生时都会为我持续解决。

同样发生在我身上，在我的情况下， docker-compose push （甚至不尝试运行应用程序）都在Azure DevOps上进行。

我的其他构建不使用docker-compose，而是普通的docker push

我删除了docker的kubuntu 18.04.1 docker.io版本并安装了docker-ce 18.09.0
问题消失了。

我只是将docker-compose推送步骤转换为单独的推送。

通过docker-compose或docker-py库运行容器时，我们看到了这个超时（即使将超时延长到2分钟也超时）； 但是，通过Docker CLI运行时，我们看不到错误（容器立即启动）。 我们也仅在Linux CI服务器上而不是在Mac上看到该问题。 我们正在努力构建一个最小的可复制示例。

在macOS主机上的Debian VM上有docker-compose kill问题，请直接从docker安装。 （Docker版本18.09.0，内部版本4d60db4）

使用rloglog端口不可用时，使用日志驱动程序启动docker时出现相同的错误：syslog。
Error starting container 0ba2fb9540ec6680001f90dce56ae3a04b831c8146357efaab79d4756253ec8b: UnixHTTPConnectionPool(host='localhost', port=None): Read timed out. (read timeout=60)

重新启动Docker对我有用。

@ rodrigo-brito重新启动不是解决方案...

发生在我的原因是端口范围很大，实际上每个端口都创建一个规则...。

对我来说完全一样。 发生错误后，docker守护程序会继续吃掉内存直到耗尽。 我需要systemctl stop docker在我的系统死机之前。 （Docker版本18.09.3，内部版本774a1f4）

    ports:
      - "10000-20000:10000-20000"

简单重启docker为我解决了这个问题...

在最新的docker-ce版本中似乎仍然存在该问题。 我正在启动〜5个容器，其中一个较慢的容器具有指向NFS共享的docker卷安装。 没有容器公开任何端口，是否有人发现这是否是有效错误（ port=None似乎可疑）？

~~~
客户：
版本：18.09.5
API版本：1.39
Go版本：go1.10.8
Git提交：e8ff056dbc
建成时间：2019年4月11日星期四04:44:28
操作系统/ Arch：linux / amd64
实验性：错误

服务器：Docker引擎-社区
发动机：
版本：18.09.5
API版本：1.39（最低版本1.12）
Go版本：go1.10.8
Git提交：e8ff056
建造时间：2019年4月11日星期四04:10:53
操作系统/ Arch：linux / amd64
实验性：错误
~~~

从--verbose添加了更多输出。 我认为这里没有任何用处，只是说很长时间，某些容器创建操作正在等待很长时间。 显然，它正在使用轮询，因为以下消息的打印速度约为1x / sec：

〜compose.parallel.feed_queue：待处理：set（）〜

我认为localhost / port = Node有点像一个红色鲱鱼，因为连接是通过docker.sock完成的，所以它并不是隐藏在某个地方的nil错误。 我认为这需要在docker内部进行跟踪，而不是在这里对此请求进行docker-compose处理是最佳的。

Docker-compose似乎缺少可以记录的某种请求ID，因此我们知道哪个请求正在停止。 例如，我知道我的api容器无法在超时内创建，但是请求日志根本没有帮助。 也许其他人可以在这里添加一些信息：

~~~
urllib3.connectionpool._make_request：http：// localhost：无“ POST /v1.25/containers/create?name=api-memcache HTTP / 1.1” 201 90
urllib3.connectionpool._make_request：http：// localhost：无“ POST /v1.25/networks/proxy/disconnect HTTP / 1.1” 200 0
compose.cli.verbose_proxy.proxy_callable：docker create_container-> {'Id'：'22b774d0451c7aea118ba928a9a87177be09e63286f1d4eeaf009ddfe3c4c44f'，
“警告”：无}
compose.cli.verbose_proxy.proxy_callable：docker offline_container_from_network->无
compose.cli.verbose_proxy.proxy_callable：docker inspect_container <-（'22b774d0451c7aea118ba928a9a87177be09e63286f1d4eeaf009ddfe3c4c44f'）
compose.cli.verbose_proxy.proxy_callable：docker connect_container_to_network <-（'ba67095c5ea718af13a09798bc2f5ab24f5d0b54ce684b6f4cb248ab705df900'，'proxy'，别名= ['redis'，'ba67095N5_n = one_one_address_one
urllib3.connectionpool._make_request：http：// localhost：None“ GET /v1.25/containers/22b774d0451c7aea118ba928a9a87177be09e63286f1d4eeaf009ddfe3c4c44f/json HTTP / 1.1” 200无
urllib3.connectionpool._make_request：http：// localhost：无“ POST /v1.25/containers/create?name=api HTTP / 1.1” 201 90
compose.cli.verbose_proxy.proxy_callable：docker create_container-> {'Id'：'1b67251d494199cfd4ba9855f20d41b6b0be8544757c2d5d416a90d044f4d0ec'，
“警告”：无}
compose.cli.verbose_proxy.proxy_callable：docker inspect_container <-（'1b67251d494199cfd4ba9855f20d41b6b0be8544757c2d5d416a90d044f4d0ec'）
compose.parallel.feed_queue：待处理：set（）
urllib3.connectionpool._make_request：http：// localhost：无“ POST /v1.25/networks/proxy/disconnect HTTP / 1.1” 200 0
urllib3.connectionpool._make_request：http：// localhost：无“ POST /v1.25/networks/proxy/connect HTTP / 1.1” 200 0
compose.cli.verbose_proxy.proxy_callable：docker inspect_container-> JSON ...
urllib3.connectionpool._make_request：http：// localhost：None“ GET /v1.25/containers/1b67251d494199cfd4ba9855f20d41b6b0b8544757c2d5d416a90d044f4d0ec/json HTTP / 1.1” 200无
compose.cli.verbose_proxy.proxy_callable：docker offline_container_from_network->无
compose.cli.verbose_proxy.proxy_callable：docker connect_container_to_network->无
compose.cli.verbose_proxy.proxy_callable：docker offline_container_from_network <-（'22b774d0451c7aea118ba928a9a87177be09e63286f1d4eeaf009ddfe3c4c44f'，'proxy'）
compose.cli.verbose_proxy.proxy_callable：docker connect_container_to_network <-（'7d81ef23610f1b8f7ac95837cbf6c9eef977b5b0846fea24be5c7054e471df39'，'proxy'，别名= ['v's _，_ n_地址，] __ one，= 7，_n
compose.cli.verbose_proxy.proxy_callable：docker inspect_container-> JSON ...
urllib3.connectionpool._make_request： http：// localhost ：无“ POST /v1.25/containers/create?name=api-comments-db HTTP / 1.1” 201 90
compose.cli.verbose_proxy.proxy_callable：docker start <-（'ba67095c5ea718af13a09798bc2f5ab24f5d0b54ce684b6f4cb248ab705df900'）
compose.parallel.feed_queue：待处理：set（）
compose.parallel.feed_queue：待处理：set（）
compose.cli.verbose_proxy.proxy_callable：docker offline_container_from_network <-（'1b67251d494199cfd4ba9855f20d41b6b0be8544757c2d5d416a90d044f4d0ec'，'proxy'）
compose.cli.verbose_proxy.proxy_callable：docker create_container-> {'Id'：'ff8c5cc4cb87ba04aca3be5fcd3c6adcd08f5f4e6de5680857cbab37fd3027af'，
“警告”：无}
urllib3.connectionpool._make_request： http：// localhost ：无“ POST /v1.25/networks/proxy/disconnect HTTP / 1.1” 200 0
urllib3.connectionpool._make_request： http：// localhost ：无“ POST /v1.25/networks/proxy/connect HTTP / 1.1” 200 0
compose.cli.verbose_proxy.proxy_callable：docker inspect_container <-（'ff8c5cc4cb87ba04aca3be5fcd3c6adcd08f5f4e6de5680857cbab37fd3027af'）
compose.cli.verbose_proxy.proxy_callable：docker offline_container_from_network->无
compose.parallel.feed_queue：待处理：set（）
compose.cli.verbose_proxy.proxy_callable：docker connect_container_to_network->无
compose.cli.verbose_proxy.proxy_callable：docker connect_container_to_network <-（'22b774d0451c7aea118ba928a9a87177be09e63286f1d4eeaf009ddfe3c4c44f'，'proxy'，aliases = ['ipcache]，'22b774N0451 _] _ one_one
compose.parallel.feed_queue：待处理：set（）
urllib3.connectionpool._make_request： http：// localhost ：无“ GET /v1.25/containers/ff8c5cc4cb87ba04aca3be5fcd3c6adcd08f5f4e6de5680857cbab37fd3027af/json HTTP / 1.1” 200无
urllib3.connectionpool._make_request： http：// localhost ：无“ POST /v1.25/networks/proxy/disconnect HTTP / 1.1” 200 0
compose.cli.verbose_proxy.proxy_callable：docker start <-（'7d81ef23610f1b8f7ac95837cbf6c9eef977b5b0846fea24be5c7054e471df39'）
compose.parallel.feed_queue：待处理：set（）
compose.cli.verbose_proxy.proxy_callable：docker offline_container_from_network->无
compose.cli.verbose_proxy.proxy_callable：docker inspect_container-> JSON ...
urllib3.connectionpool._make_request： http：// localhost ：无“ POST /v1.25/networks/proxy/connect HTTP / 1.1” 200 0
compose.cli.verbose_proxy.proxy_callable：docker connect_container_to_network <-（'1b67251d494199cfd4ba9855f20d41b6b0be8544757c2d5d416a90d044f4d0ec'，'proxy'，别名= ['api'，'1b67251N494_1]
compose.cli.verbose_proxy.proxy_callable：docker offline_container_from_network <-（'ff8c5cc4cb87ba04aca3be5fcd3c6adcd08f5f4e6de5680857cbab37fd3027af'，'proxy'）
compose.cli.verbose_proxy.proxy_callable：docker connect_container_to_network->无
compose.cli.verbose_proxy.proxy_callable：docker start <-（'22b774d0451c7aea118ba928a9a87177be09e63286f1d4eeaf009ddfe3c4c44f'）
compose.parallel.feed_queue：待处理：set（）
urllib3.connectionpool._make_request：http：// localhost：无“ POST /v1.25/networks/proxy/disconnect HTTP / 1.1” 200 0
urllib3.connectionpool._make_request：http：// localhost：无“ POST /v1.25/networks/proxy/connect HTTP / 1.1” 200 0
compose.cli.verbose_proxy.proxy_callable：docker offline_container_from_network->无
compose.cli.verbose_proxy.proxy_callable：docker connect_container_to_network->无
compose.cli.verbose_proxy.proxy_callable：docker connect_container_to_network <-（'ff8c5cc4cb87ba04aca3be5fcd3c6adcd08f5f4e6de5680857cbab37fd3027af'，'proxy'，别名= ['ff8c5cc_c__one_ip_n，地址ip_N_，地址ip_n = 6，n_ip_n = ip_n没有）
compose.cli.verbose_proxy.proxy_callable：docker start <-（'1b67251d494199cfd4ba9855f20d41b6b0be8544757c2d5d416a90d044f4d0ec'）
urllib3.connectionpool._make_request：http：// localhost：无“ POST /v1.25/networks/proxy/connect HTTP / 1.1” 200 0
compose.cli.verbose_proxy.proxy_callable：docker connect_container_to_network->无
compose.cli.verbose_proxy.proxy_callable：docker start <-（'ff8c5cc4cb87ba04aca3be5fcd3c6adcd08f5f4e6de5680857cbab37fd3027af'）
compose.parallel.feed_queue：待处理：set（）
compose.parallel.feed_queue：待处理：set（）
compose.parallel.feed_queue：待处理：set（）
compose.parallel.feed_queue：待处理：set（）
...
-省略〜30行
...
创建api注释...完成
compose.cli.verbose_proxy.proxy_callable：泊坞窗启动->无
compose.parallel.parallel_execute_iter：完成处理：ServiceName（project ='api'，service ='comments'，number = 1）
compose.parallel.feed_queue：待处理：set（）
compose.parallel.parallel_execute_iter：完成处理：
compose.parallel.feed_queue：待处理：set（）
创建api-memcache ...完成
urllib3.connectionpool._make_request：http：// localhost：None“ POST /v1.25/containers/22b774d0451c7aea118ba928a9a87177be09e63286f1d4eeaf009ddfe3c4c44f/start HTTP / 1.1” 204​​ 0
compose.cli.verbose_proxy.proxy_callable：泊坞窗启动->无
compose.parallel.parallel_execute_iter：完成处理：ServiceName（project ='api'，service ='memcache'，number = 1）
compose.parallel.feed_queue：待处理：set（）
compose.parallel.parallel_execute_iter：完成处理：
compose.parallel.feed_queue：待处理：set（）
compose.parallel.feed_queue：待处理：set（）
compose.parallel.feed_queue：待处理：set（）
compose.parallel.feed_queue：待处理：set（）
urllib3.connectionpool._make_request：http：// localhost：无“ POST /v1.25/containers/ff8c5cc4cb87ba04aca3be5fcd3c6adcd08f5f4e6de5680857cbab37fd3027af/start HTTP / 1.1” 204​​ 0
compose.cli.verbose_proxy.proxy_callable：泊坞窗启动->无
创建api-comments-db ...完成
compose.parallel.feed_queue：待处理：set（）
compose.parallel.parallel_execute_iter：完成处理：
compose.parallel.feed_queue：待处理：set（）
compose.parallel.feed_queue：待处理：set（）
compose.parallel.feed_queue：待处理：set（）
compose.parallel.feed_queue：待处理：set（）
compose.parallel.feed_queue：待处理：set（）
-省略〜15行
创建api-redis ...完成
compose.parallel.feed_queue：待处理：set（）
urllib3.connectionpool._make_request：http：// localhost：None“ POST /v1.25/containers/ba67095c5ea718af13a09798bc2f5ab24f5d0b54ce684b6f4cb248ab705df900/start HTTP / 1.1” 204​​ 0
compose.cli.verbose_proxy.proxy_callable：泊坞窗启动->无
compose.parallel.parallel_execute_iter：完成处理：ServiceName（project ='api'，service ='redis'，number = 1）
compose.parallel.feed_queue：待处理：set（）
compose.parallel.parallel_execute_iter：完成处理：

compose.parallel.feed_queue：待处理：set（）

-省略了100多行
compose.parallel.parallel_execute_iter：失败：ServiceName（project ='api'，service ='api'，number = 1）
compose.parallel.feed_queue：待处理：set（）

错误：对于api UnixHTTPConnectionPool（host ='localhost'，port = None）：读取超时。 （读取超时= 60）
compose.parallel.parallel_execute_iter：失败：
compose.parallel.feed_queue：待处理：set（）

错误：对于api UnixHTTPConnectionPool（host ='localhost'，port = None）：读取超时。 （读取超时= 60）
compose.cli.errors.log_timeout_error：HTTP请求花费太长时间才能完成。 使用--verbose重试以获得调试信息。
如果由于网络状况较慢而经常遇到此问题，请考虑将COMPOSE_HTTP_TIMEOUT设置为更高的值（当前值：60）。
~~~

@titpetric可以确认我也遇到这个问题。

恕我直言，这个问题是在docker方面，而不是在docker-compose方面。 有人应该在docker deamon上打开调试日志记录，并指出那里的延迟，然后向上游提出问题。 我不确定如果没有这一点，是否可以轻松重现。

如果有人愿意花时间，我建议通过创建一个用于卷挂载的完全加载的文件夹（应该有大约100000个文件/文件夹的东西）来复制此文件，以查看是否可以可靠地重现该问题可以实现。 docker守护程序或内核绑定本身可能会预先缓存一些inode数据。 哪个...很不幸。

如果是网络文件系统（samba，nfs），则tcpdump也可能会确认这一点。

同样的错误在这里

ERROR: for docker_async_worker__local_1  UnixHTTPConnectionPool(host='localhost', port=None): Read timed out. (read timeout=70)

ERROR: for docker_elasticsearch__local_1  UnixHTTPConnectionPool(host='localhost', port=None): Read timed out. (read timeout=70)

ERROR: for docker_web__local_1  UnixHTTPConnectionPool(host='localhost', port=None): Read timed out. (read timeout=70)

Docker重新启动也为我修复了它。

重新启动不是修复人员.....
如何永远避免这种情况？

面对同样的问题。 对于组织对等方的所有docker容器，均出现以下错误：

错误：对于DNS UnixHTTPConnectionPool（host ='localhost'，port = None）：读取超时。 （读取超时= 60）

是否由于撰写文件中的某些端口不匹配或分配？

是的，我自己经常遇到这个问题。 我同意重启不是解决方案，但是似乎没有其他方法可以解决这个问题：/

仅供参考，就我而言，仅使用docker-compose重试往往可以解决
它。 我认为我从未重启过dockerd，这个问题不会持续存在
我。

在2019年8月2日星期五下午1：39，Alex [email protected]写道：

是的，我自己经常遇到这个问题。 我同意重启不是
一个解决方案，但似乎没有其他办法可以解决问题：/

-
您收到此邮件是因为有人提到您。
直接回复此电子邮件，在GitHub上查看
https://github.com/docker/compose/issues/3927吗
或使线程静音
https://github.com/notifications/unsubscribe-auth/AABY7EA3NTUP5SNZRTFWFEDQCQMHBANCNFSM4CPDX2DQ
。

我也面临这个问题:(
UnixHTTPConnectionPool(host='localhost', port=None): Read timed out. (read timeout=60)

同样的问题，重启Docker实际上也挂了。 唯一的办法是杀死泊坞窗/或重新启动，但不能成为解决方案。

@bitbrain是的，这在我身上已经发生了相当长的时间。

我在MacOS上找到了一个很好的解决方案

对我而言，这种情况一直存在的原因是Docker的可用内存很少。

内存从2GB增加到8GB对我来说解决了这个问题。

在运行docker-compose up然后运行docker-compose down几次后，出现此错误。 我尝试了此线程中的所有操作。 碰撞资源，重新启动我的Mac，然后重新安装最新的Docker。 重新启动我的机器后，我可以使docker-compose up再次运行，但是循环几次这些命令后，它将回到此错误，并且我无法使docker-compose up运行。

我的问题似乎与绑定到端口80的另一个服务（ pow ）发生冲突，而我的一个容器也绑定到端口80时。我卸载了pow，现在已经三天没有问题了。

3年后才打开这张票，但仍未解决。 即使将客户端连接增加到120秒，问题仍然会发生。

刚好发生在我们的服务器上，自2016年以来一直未解决，wtf

重新启动Docker对我有用。

@ rodrigo-brito重新启动不是解决方案...

我的男人

现在也正在经历这个。 野生。

尝试docker-compose up或docker-compose down时遇到相同的问题。 我通过停止mysqld服务来解决它，一旦容器启动，就启动mysql。 RAM使用率为20％。

运行适用于Mac的Docker桌面社区v2.1.0.5

我遇到了这个问题，并通过增加分配给Docker的内存量（并减少了CPU量）来解决。
您可以在Docker-> Preferences-> Advanced中执行此操作。
对于我的特定设置，我从8个CPU和2GB RAM变为4个CPU和16GB RAM。

在Ubuntu Server 18.04 LTS上遇到此问题。 重新启动docker无法解决问题，同样设置环境变量也是如此。 有任何想法吗？

@bpogodzinski您是否尝试过增加Docker中的内存设置？ 我将它们从2GB增加到8GB，这为我解决了问题。

一般而言，当容器需要的内存大于Docker中配置的可用内存时，似乎会发生此问题，然后东西才挂起。

我们遇到了这个问题，并且（对于我们而言）似乎与包含许多文件的命名卷有关。 我不理解，但是对于我们来说，有一种服务的docker-compose（为简便起见而编辑）是这样的情况：

   serviceA:
        ...
        volumes:
            - serviceA_volume: /srvA/folder

   volumes:
       - serviceA_volume:

在serviceA的Dockerfile内是看似无害且无效的命令：

...
RUN mkdir -p /srvA/folder && chown -R user /srvA/folder
...

请注意，这会在/ srvA / folder中递归更改所有者，该文件夹在命名卷中是一个具有100K文件的大型文件系统。 但是，当生成映像并且该文件夹为空时，会发生这种情况。 使用命名卷时，它似乎继承了图像本地文件的权限，然后继续更改命名卷的权限。

这是相当不错的优势，可能不是每个人都遇到的相同问题，但这是我们的问题（切换行会触发错误）。 结果是此HTTP超时可能是由多种原因造成的。

在我的情况下，重新启动docker永远无法解决问题，增加资源确实可以解决。

根据我的经验，这个问题通常出现在小型云实例上，在正常运行期间，RAM的数量非常合适，但是在docker或docker-compose操作期间证明不足。 您可以轻松增加RAM，但可能会大大增加小型VM的成本。

在每种情况下，添加交换分区甚至交换文件都可以为我解决此问题！

刚在树莓派上发生在我身上。 没有大量文件或任何东西的卷。
实际上，我已经在树莓上产卵了一段时间了（一两年）。
不知道发生了什么变化。
似乎有点“出乎意料”。

问题仍然出现在MacOs上的Docker桌面2.2.0.3上

我通过以下命令解决了我的问题：
docker volume prune
docker system prune
（仅这些命令之一就足够了，但是暂时无法重现...）

我通过以下命令解决了我的问题：
docker volume prune
docker system prune
（仅这些命令之一就足够了，但是暂时无法重现...）

@amaumont的解决方案有所帮助，尽管我认为这将继续加班。
正如其他人所说的那样，重启docker并不是一个合适的解决方案，这是一个创可贴。

docker-compose也有多个问题。

在sshd_config中设置MaxSessions 500之后（请参阅＃6463），我们现在还获得了读取超时。
将两个超时都设置为120秒可以解决下一次运行DOCKER_HOST=xxx<strong i="8">@yyy</strong> docker-compose up -d 。

在第二次运行期间，由于超时，docker-compose命令失败之前，机器负载高达30 （sic！）。 Docker重新启动并不能解决此问题，甚至不是暂时解决。
服务器是具有足够CPU /磁盘/ NetIO等的AWS EC2实例，撰写文件包括1个traefik和3个带mailhog的服务，因此这里没有什么特别的。 直接在服务器上使用相同的docker-compose.yml文件运行docker-compose up -d可以可靠地工作，并且符合预期。
使用--verbose运行可显示包含compose.parallel.feed_queue: Pending: set()数千行连续行。

我将尝试将docker-compose文件rsync到远程服务器，并在该计算机上直接运行docker-compose作为解决方法。

对我来说，它有助于重启docker。

尝试从bitbucket管道推送到我的私有注册表时，对我来说经常发生。 从本地PC推入时效果很好。
重新启动docker可能会有所帮助，但是此“ while”持续最多10分钟：c

更新。 设置DOCKER_CLIENT_TIMEOUT和COMPOSE_HTTP_TIMEOUT似乎有帮助，但是我不知道要花多长时间

自从在启用缓存的情况下切换到Docker Edge以来，我就开始获取它们

自从我2-3年前开始使用Docker以来，这一直在持续发生。 容器运行一段时间后，它将变成僵尸，并且需要重新启动整个Docker引擎，以使事情再次变得敏感。 这感觉像某种资源泄漏，因为空闲时间似乎与经验丰富的行为非常相关。

如果没有容器在运行，或者它们只运行了很短的时间，那么几天或几周的一切似乎都可以正常工作。 但是，一旦我让一个容器运行了几个小时，它就变得无响应，我必须在命令行中强制停止它，并且任何与docker或docker-compose进行通信的尝试都将失败。超时。 重新启动是唯一可行的解​​决方案。

docker-compose version

docker-compose version 1.25.5, build 8a1c60f6
docker-py version: 4.1.0
CPython version: 3.7.5
OpenSSL version: OpenSSL 1.1.1f  31 Mar 2020

docker version

Client: Docker Engine - Community
 Version:           19.03.8
 API version:       1.40
 Go version:        go1.12.17
 Git commit:        afacb8b
 Built:             Wed Mar 11 01:21:11 2020
 OS/Arch:           darwin/amd64
 Experimental:      false

Server: Docker Engine - Community
 Engine:
  Version:          19.03.8
  API version:      1.40 (minimum version 1.12)
  Go version:       go1.12.17
  Git commit:       afacb8b
  Built:            Wed Mar 11 01:29:16 2020
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          v1.2.13
  GitCommit:        7ad184331fa3e55e52b890ea95e65ba581ae3429
 runc:
  Version:          1.0.0-rc10
  GitCommit:        dc9208a3303feef5b3839f4323d9beb36df0a9dd
 docker-init:
  Version:          0.18.0
  GitCommit:        fec3683

docker-compose config

services:
  portal:
    container_name: developer_portal
    image: swedbankpay/jekyll-plantuml:1.3.8
    ports:
    - published: 4000
      target: 4000
    - published: 35729
      target: 35729
    volumes:
    - .:/srv/jekyll:rw
    - ./.bundle:/usr/local/bundle:rw
version: '3.7'

macOS Mojave 10.14.6。

我遇到了同样的问题，甚至我将资源从4GB RAM，1GB交换增加到6GB RAM，2GB交换。

我也面临着同样的问题

也有同样的问题

我一直在使用HTTPS的Ubuntu 18.04 LTS（8 GB RAM）上遇到相同的问题。

我可以使用docker-compose up生成容器，但是一旦部署，我将无法停止具有docker-compose down容器。 重新启动docker守护程序或重新启动VM已被证明是无效的。 添加超时环境变量（ DOCKER_CLIENT_TIMEOUT ， COMPOSE_HTTP_TIMEOUT ）也没有任何作用。

我能够分别与容器交互和停止容器，可以检查容器，将容器连接到容器以及其他任何东西，但是我无法使用docker-compose命令停止或杀死它们。

错误消息始终是相同的：

msg: 'Error stopping project - HTTPSConnectionPool(host=[ommited], port=2376): Read timed out. (read timeout=120)

当我在docker-compose.yml中包含以下内容时，我遇到了相同的问题：

logging:
      driver: "json-file"
      options:
        max-size: 100m
        max-file: 10

当我在“ 10”附近添加引号时，错误消失了。 docs中指出，max-file和max-size的值必须为字符串，但仍为字符串。 该错误信息是非常令人误解的。

当我在docker-compose.yml中包含以下内容时，我遇到了相同的问题：

logging:
      driver: "json-file"
      options:
        max-size: 100m
        max-file: 10

当我在“ 10”附近添加引号时，错误消失了。 docs中指出，max-file和max-size的值必须为字符串，但仍为字符串。 该错误信息是非常令人误解的。

你救了我的一天。 非常感谢！

当我在docker-compose.yml中包含以下内容时，我遇到了相同的问题：

logging:
      driver: "json-file"
      options:
        max-size: 100m
        max-file: 10

当我在“ 10”附近添加引号时，错误消失了。 docs中指出，max-file和max-size的值必须为字符串，但仍为字符串。 该错误信息是非常令人误解的。

我正在docker守护程序级别配置日志记录驱动程序。 我使用fluentd作为日志记录驱动程序，因此很遗憾，此修复程序不适用于我。 = /

试试这个

export DOCKER_CLIENT_TIMEOUT=120
export COMPOSE_HTTP_TIMEOUT=120

看来现在已经解决了这个问题

人们在此线程中提到的其他解决方案：

• 重新启动Docker
• 增加Docker CPU和内存

好吧，除了超时选项外，对我没有任何帮助。

因为我开始在一个容器中使用NFS挂载目录，所以我得到了这个。 该NFS安装目录位于慢速链接上（位于具有低带宽连接的远程位置）。 可能是问题所在吗？

我在Mac上的Docker 2.4.0.0上经常在两个具有不同docker-compose.yml配置的不同项目中遇到这种情况。 我不记得它是在〜1周前升级到2.4.0.0之前发生的。 有回归吗？

我尝试将超时时间增加到600，将RAM增加到16GB并交换到4GB，重新启动Docker，重新启动我的整个Macbook，似乎没有任何效果，除非随机尝试一次又一次，然后偶尔会起作用。 但是，下次我需要重新启动或重建容器时，同样的问题:(

在Mac上也从2.4.0.0开始看到这一点。 我的解决方法是重新启动docker，但稍后会再次运行。

同样在这里！ 随着更新至2.4.0，有时我们的设置有时根本不会出现上述Read timed out.错误，有时只有一些容器启动，而另一些容器则抛出此错误。 我已经在考虑降级了！

只需提及：此问题会影响使用NFS共享的设置以及使用“正常”安装卷的项目

同样的问题，在Mac和2.4.0更新之后也是如此。 我目前正在尝试降级是否有帮助。

更新：降级到以前的版本，删除缓存并重建可解决此问题。

最近我也从未见过这个问题（Mac，2.4.0.0）。 运行docker image prune使问题消失了几天，但现在又回来了。

从2.4.0更新开始（在Mac OS Mojave 10.14.5上）也开始频繁出现此超时错误。

自从在MacOS Catalina上更新到Docker Desktop 2.4.0.0（48506）以来，这种情况的出现频率也在增加。

从Mac OS上的2.4.0.0开始，我遇到了相同的超时问题。 我以前从未遇到过这个问题。
我尝试了边缘构建2.4.1.0（48583），但仍然遇到相同的问题。

我遇到了同样的问题，并重启了docker，将其修复为MacOs Catalina（10.15.5）和Docker版本2.4.0.0

同样在这里，在更新到Docker桌面2.4.0.0之前没有问题。
重新启动Docker桌面是可行的，但这只是一种解决方法。

同样在这里，也从v2.4.0开始

更新：降级到以前的版本，删除缓存并重建可解决此问题。

会尝试的。 甚至不确定如何完成。 我认为是通过卸载和下载早期版本来实现的？

是的，我卸载了2.4，然后下载/重新安装了2.3。 现在它可以工作了，我可以照常启动容器了。
我从那里得到了2.3： https: //docs.docker.com/docker-for-mac/release-notes/#docker -desktop-community-2302

是的，也可以确定对我来说有所不同。 肯定是v2.4以某种方式归咎于此。

如果由于网络状况较慢而经常遇到此问题，请考虑将COMPOSE_HTTP_TIMEOUT设置为更高的值（当前值：60）。

到底慢速网络的1Gbps是多少？

降级也对我有用。 对于那些通过Homebrew管理Docker的人

brew uninstall docker
brew install https://raw.githubusercontent.com/Homebrew/homebrew-cask/9da3c988402d218796d1f962910e1ef3c4fca1d3/Casks/docker.rb

如果由于网络状况较慢而经常遇到此问题，请考虑将COMPOSE_HTTP_TIMEOUT设置为更高的值（当前值：60）。

到底慢速网络的1Gbps是多少？

就我而言，这是由于安装了NFS的网络驱动器而发生的。
网络速度“缓慢”的根本原因是使用NFS而不是物理链接速度。
但这肯定表明实现中存在问题，如果更改HTTP_TIMEOUT可以解决问题，我将感到惊讶。

同样在这里。 容器创建速度显着放慢，导致在Docker for Mac v2.4上出现上述HTTP超时错误。 设置COMPOSE_HTTP_TIMEOUT = 120可以，但是容器创建缓慢仍然是一个新问题。 降级到v2.3也可以解决此问题。

自从我在Docker for Mac v2.4上安装以来，我可以确认同样的问题。
我还可以确认，仅在运行Docker守护程序的情况下，即使在空闲时，RAM和CPU消耗也显着增加。 但是我想与compose包本身没有任何关系。

我有同样的问题。 从@ddesrousseaux提到的链接中卸载了2.40，并安装了2.3，我再也没有超级缓慢或启动容器超时的情况。

https://docs.docker.com/docker-for-mac/release-notes/#docker -desktop-community-2302

Docker v。 2.4.3.0仍然存在此问题。

我还从2.4降级到2.3，以解决2.4版本中的大量缓慢问题。 很高兴提供任何日志可能对调试此处发生的事情有用。

与上述内容相呼应的是，对于我来说，这在2.4.2.x中开始发生。 从2.3升级时发生了一些变化。

我在Linux环境中进行了测试，并且遇到了类似的问题。 我安装了最新的docker-compose二进制文件（v1.27.4），并遇到了您报告的超时问题。

降级至1.27.2（适用于Mac 2.3的Docker）后，问题消失了。

Ubuntu 20.04上的当前版本存在相同问题。

我的问题是我用snap和apt安装了docker和docker-compose。 我卸载了它们，然后重新启动，然后按照https://docs.docker.com/engine/install/ubuntu/和https://docs.docker.com/compose/install/上的官方安装说明进行操作

自从2.4.0更新以来，我仍然仍然经常遇到超时错误，但在2.5.0中仍未修复

是的，这里也是。 在过去两年中，这对我来说一直很好。 但是2个月前突然，当我想要1个实例并启动另一个docker项目时，它会抛出：
对于apache UnixHTTPConnectionPool（host ='localhost'，port = None）：读取超时。

重新启动Docker可解决此问题。 但是当我必须在一天内多次在项目之间切换时，这确实是一个痛苦

自2.4以来出现同样的问题，CPU始终为300％，2.5一直无济于事，降级回2.3，一切正常。 这是最新的Macbook w / i7 cpu和32g ram

我刚刚升级到最新的Docker for Mac版本（v2.5.0.1），问题似乎已解决。
没有更多的UnixHTTPConnection错误，也没有更多的100％CPU使用率。

不知道是否有人可以确认。

你是怎么得到的？ 在Mac上打开Docker并执行“检查更新”仍然说我拥有最新的2.4.2.0。

我刚刚升级到最新的Docker for Mac版本（v2.5.0.1），问题似乎已解决。
没有更多的UnixHTTPConnection错误，也没有更多的100％CPU使用率。

不知道是否有人可以确认。

我刚刚在v2.5.0.1上遇到了问题。 重新启动docker似乎（至少暂时）解决了该问题。

你是怎么得到的？ 在Mac上打开Docker并执行“检查更新”仍然说我拥有最新的2.4.2.0。

自从我已经升级以来，我无法显示任何屏幕截图，但是我认为从计算机上获取更新可能会遇到一些麻烦，因为先前的v2.5.0版本已有一个多星期可用了。

您可以在Docker for Mac发行说明中检查它（并从那里获取任何新的安装程序）。

我正在运行Edge。 这可能解释了这一点。

可以确认v2.5.0.1至少略胜一筹。 不再在每次启动时都超时，并且自从今天早上更新以来还没有遇到超时。 但是，容器启动时间似乎仍然比2.3慢得多。

编辑：在我的docker-compose项目重启大约4或5次之后，只是再次遇到了超时错误。 还遇到了2.5.0.1的新错误： Cannot start service <container name>: error while creating mount source path <local mount path>: mkdir <local mount path>: file exists

可以确认v2.5.0.1至少略胜一筹。 不再在每次启动时都超时，并且自从今天早上更新以来还没有遇到超时。 但是，容器启动时间似乎仍然比2.3慢得多。

编辑：在我的docker-compose项目重启大约4或5次之后，只是再次遇到了超时错误。 还遇到了2.5.0.1的新错误： Cannot start service <container name>: error while creating mount source path <local mount path>: mkdir <local mount path>: file exists

好的，我在2.5.0.1版本中仍然遇到一些问题。 与v2.3.x相比，CPU使用率仍然很高，并且速度也相当慢。

Docker团队中的任何人都可以承认并参与其中吗？

天哪，四年过去了，这个问题仍然没有解决，而且一直在我身上发生