Closed vbergae closed 2 years ago
Sorry, it's a system wide problem without relation with docker
@vbergae I had the same issue and I found out that I've turned on the new feature in iCloud "Private Relay". Turning off the option in settings solved my problem.
Thank you @dpetrovaliev - that's useful information (and something we may need to document, and/or see if we can find a workaround for situations where it's enabled)
I have the same issue, but I do not have icloud private relay turned on.
@kutenai there's many possible causes for networking issues, some of which can be specific to your environment (proxies, VPNs, switching between WiFi networks, etc.) so it may be better to open a new ticket with exact steps to reproduce, and if possible a diagnostic ID.
(networking issues are hard, and "having the same issue" may have unrelated causes, so trying to prevent possibly unrelated issues from being mixed in a single ticket š )
I run the elixir container, just to have a Docker container to run from. I tried curl http://deb.debian.org and got nothing. I then tried curl https://deb.debia.org, and got output from that.
I can ping deb.debian.org just fine
PING debian.map.fastlydns.net (199.232.162.132) 56(84) bytes of data. 64 bytes from 199.232.162.132 (199.232.162.132): icmp_seq=1 ttl=37 time=111 ms 64 bytes from 199.232.162.132 (199.232.162.132): icmp_seq=2 ttl=37 time=109 ms 64 bytes from 199.232.162.132 (199.232.162.132): icmp_seq=3 ttl=37 time=105 ms
I am on an M1 Mac, I'm just. not sure if that's part of the issue or not.
@dpetrovaliev @vbergae I'm curious to know whether HTTP works from the host with private relay enabled.
If you have a moment, could you try using curl
and nc
from a terminal:
dave@m1 ~ % curl -vvv http://deb.debian.org
* Trying 151.101.18.132:80...
* Connected to deb.debian.org (151.101.18.132) port 80 (#0)
> GET / HTTP/1.1
> Host: deb.debian.org
> User-Agent: curl/7.77.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Server: Apache
< X-Content-Type-Options: nosniff
< X-Frame-Options: sameorigin
< Referrer-Policy: no-referrer
< X-Xss-Protection: 1
< Permissions-Policy: interest-cohort=()
< Last-Modified: Thu, 26 Oct 2017 07:34:58 GMT
< ETag: "735-55c6e3596516e"
< X-Clacks-Overhead: GNU Terry Pratchett
< Content-Type: text/html
< Content-Length: 1845
< Accept-Ranges: bytes
< Date: Fri, 05 Nov 2021 14:02:14 GMT
< Via: 1.1 varnish
< Age: 0
< Connection: keep-alive
< X-Served-By: cache-lcy19249-LCY
< X-Cache: MISS
< X-Cache-Hits: 0
< X-Timer: S1636120935.856068,VS0,VE17
< Vary: Accept-Encoding
<
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<TITLE>Welcome to deb.debian.org (fastly instance)!</TITLE>
</HEAD>
...
and
% nc deb.debian.org 80
GET / HTTP/1.0
-- it should give you a HTTP/1.1 500 Domain Not Found
response.
The curl request just times out. So does nc.. it does nothing
Note that I do NOT have private relay enabled.
If non-TLS (http://
) connections don't work from the host either, sounds like something else is blocking them; is this a corporate network you're on? (any VPN and/or Proxy that's used?)
This is my home, business internet. No corporate firewalls install. I do have a corporate VPN.
Hmm. Well, I turned that VPN off (I swear I'd tried that before.... ) and now the debian works. I'm an idiot. Seriously, I am! That should have been the first thing I tried.. and, I"m sure I did... but, obviously, NOT.
The thing that threw me is that my original build failed even with the VPN off, but, upon closer examination, the failure is different...
Isolating this down to just a debian issue was helpful, as it gave me a base case, and it appears the corporate VPN was causing the issue.
@kutenai glad you managed to figure it out! We have a "self-diagnose" program in Docker Desktop. I'll have a look to see if it checks host network connectivity.
I'll have a look to see if it checks host network connectivity.
Good idea!
Hmm. Well, I turned that VPN off (I swear I'd tried that before.... ) and now the debian works.
Great! Good to hear it's resolved
I'm an idiot. Seriously, I am! That should have been the first thing I tried.. and, I"m sure I did... but, obviously, NOT.
š don't be too hard on yourself!
@vbergae I had the same issue and I found out that I've turned on the new feature in iCloud "Private Relay". Turning off the option in settings solved my problem.
The same for me ;-).
As the behavior is similar to the one described e.g. here, I guess that apple uses a kind of proxy internally to implement their private relay feature. But I don't know if one can one can find out what the address of the proxy is :-(
Closed issues are locked after 30 days of inactivity. This helps our team focus on active issues.
If you have found a problem that seems similar to this, please open a new issue.
Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows. /lifecycle locked
Expected behavior
From a container http and https requests should work
Actual behavior
All http requests performed from containers ends in timeouts
Information
Steps to reproduce the behavior
docker run -it debian /bin/bash
# apt-get update
Try http vs https connections:
Pull elixir image
docker run -it elixir /bin/bash
Run
curl http://google.com
Pull elixir image
docker run -it elixir /bin/bash
Run
curl https://google.com