最初我的docker容器能够连接到外部互联网(这是一个运行在Amazon EC2上的docker服务/容器)。

由于我的应用程序是一个API，我随后创建了我的容器(它成功地拉出了所需的所有包)，更新了我的IP表，将所有流量从端口80路由到端口，我的API(在docker上运行)正在监听。

后来，当我试图重建容器时，它失败了。经过一番努力，我发现我的上一个步骤(设置IPTable端口转发规则)搞乱了docker的外部网络功能。

解决方案:停止IPTable服务:

Sudo服务iptables停止

重启Docker守护进程:

Sudo服务docker重启

然后，尝试重新构建容器。希望这能有所帮助。

跟进

我完全忽略了一点，我不需要打乱IP表，就可以将进入的流量转发到80，到运行在docker上的API正在运行的端口。相反，我只是将端口80别名为docker中API正在运行的端口:

Docker运行-d -p 80:<api_port> <image>:<tag> <command to start api>

我使用DOCKER_OPTS="——dns 8.8.8.8"，后来发现我的容器不能直接访问互联网，但可以访问我的公司内部网。我把DOCKER_OPTS改为如下:

DOCKER_OPTS="--dns <internal_corporate_dns_address"

替换internal_corporate_dns_address与我们的DNS的IP地址或FQDN和重启docker使用

sudo service docker restart

然后生成我的容器并检查它是否可以访问互联网。

首先在docker容器中运行cat /etc/resolv.conf。如果存在无效的DNS服务器，例如nameserver 127.0.x。X，那么容器将无法将域名解析为IP地址，因此ping google.com将失败。

要检查的第二件事是在主机上运行cat /etc/resolv.conf。每次容器启动时，Docker都会将主机的/etc/resolv.conf文件复制到容器中。所以如果主机的/etc/resolv.conf是错误的，那么docker容器也会错误。

如果你发现主机的/etc/resolv.conf是错误的，那么你有两个选项:

在daemon.json中硬编码DNS服务器。这很简单，但如果您希望DNS服务器更改，则不太理想。 修复主机的/etc/resolv.conf文件。这有点棘手，但它是动态生成的，并且您没有对DNS服务器进行硬编码。

1. 在docker daemon.json中硬编码DNS服务器

编辑/etc/docker/daemon.json ｛ "dns": ["10.1.2.3"， "8.8.8.8"] ｝ 重新启动docker守护进程使这些更改生效: Sudo systemctl restart docker 现在当你运行/启动一个容器时，docker会用daemon.json中的值填充/etc/resolv.conf。

2. 修复主机的/etc/resolv.conf文件

A. Ubuntu 16.04及更早版本

对于Ubuntu 16.04及更早的版本，/etc/resolv.conf由NetworkManager动态生成。 注释掉/etc/ networkmanager /NetworkManager.conf中的dns=dnsmasq(带#)行 重启NetworkManager重新生成/etc/resolv.conf: Sudo systemctl restart network manager 在主机上检查:cat /etc/resolv.conf

B. Ubuntu 18.04及以上版本

Ubuntu 18.04 changed to use systemd-resolved to generate /etc/resolv.conf. Now by default it uses a local DNS cache 127.0.0.53. That will not work inside a container, so Docker will default to Google's 8.8.8.8 DNS server, which may break for people behind a firewall. /etc/resolv.conf is actually a symlink (ls -l /etc/resolv.conf) which points to /run/systemd/resolve/stub-resolv.conf (127.0.0.53) by default in Ubuntu 18.04. Just change the symlink to point to /run/systemd/resolve/resolv.conf, which lists the real DNS servers: sudo ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf Verify on the host: cat /etc/resolv.conf

现在你应该在主机上有一个有效的/etc/resolv.conf文件供docker复制到容器中。

其他回答指出，docker0接口(桥接)可能是问题的根源。在Ubuntu 20.04上，我观察到接口缺少它的IP地址(用IP addr show dev docker0检查)。仅仅重新启动Docker并没有帮助。我不得不手动删除桥接接口。

sudo ip link delete docker0
sudo systemctl restart docker

经过几个小时的努力，我终于解决了问题

问题是linux使用旧版本的libseccomp2

获取签名密钥以验证新包，否则将无法安装

rpi ~$ sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 04EE7237B7D453EC 648ACFD622F3D138

将Buster后台端口存储库添加到apt sources.list

rpi ~$ echo 'deb http://httpredir.debian.org/debian buster-backports main contrib non-free' | sudo tee -a /etc/apt/sources.list.d/debian-backports.list

rpi ~$ sudo apt update
rpi ~$ sudo apt install libseccomp2 -t buster-backports

在这次尝试之后

rpi ~$ docker run -it --rm alpine:3.15.0
(alpine shell)# apk update

Apk更新将获取，因此您连接到互联网

我在用

Linux raspberrypi 5.10.63-v7l+ #1496 SMP Wed Dec 1 15:58:56 GMT 2021 armv7l GNU/Linux

您可以使用uname -a进行检查

最近几天我也遇到了类似的问题。对我来说，原因是systemd、docker和我的托管提供商的组合。我正在运行最新的CentOS(7.7.1908)。

我的主机提供程序自动为systemd-network生成配置文件。从CentOS 7的当前版本systemd 219开始，systemd-network控制了与网络相关的sysctl参数。Docker似乎与这个版本不兼容，并且每次容器启动时都会重置IP-Forwarding标志。

我的解决方案是在提供者生成的配置文件的[Network]部分中添加IPForward=true。这个文件可能在几个地方，最有可能在/etc/systemd/network中。

这个过程在官方docker文档https://docs.docker.com/v17.09/engine/installation/linux/linux-postinstall/#ip-forwarding-problems中也有描述