默认情况系统将进行docker容器存在/var/lib/docker目录下

• 今天，通过监控系统，我发现公司其中一台服务器的磁盘速度很快。我立刻上去看了看，发现/var/lib/docker这个目录特别大。由于上述原因，我们都知道/var/lib/docker存储在相关容器中，因此不能随意删除。
• 然后准备迁移docker存储目录，或对/var扩容设备达到同样的目的。更多关于dockerd详情请点击查看官方文档。
• 但需要注意的是，尽量不要使用软连接，因为有些docker例如，我们熟悉的容器编排系统不支持这样做k8s就在内。/li>

#发现容器启动不了了
ERROR:cannot create temporary directory!

#查看系统存储情况
$ du -h --max-depth=1

# 1、停止docker服务
$ sudo systemctl stop docker

# 2、开始迁移目录
$ sudo mv /var/lib/docker /data/

# 3、添加软链接
$ sudo ln -s /data/docker /var/lib/docker

# 4、启动docker服务
$ sudo systemctl start docekr

# [方式1] 改动docker启动配置文件
$ sudo vim /lib/systemd/system/docker.service
ExecStart=/usr/bin/dockerd --graph=/data/docker/

# [方式2] 改动docker启动配置文件
$ sudo vim /etc/docker/daemon.json
{ 
        
    "live-restore": true,
    "graph": [ "/data/docker" ]
}

在迁移docker目录的时候注意使用的命令，要么使用mv命令直接移动，要么使用cp命令复制文件，但是需要注意同时复制文件权限和对应属性，不然在使用的时候可能会存在权限问题。如果容器中，也是使用root用户，则不会存在该问题，但是也是需要按照正确的操作来迁移目录。

# 使用mv命令
$ sudo mv /var/lib/docker /data/docker

#使用cp命令
$ sudo cp -arv /data/docekr /data2/docker

下图中，就是因为启动的容器使用的是普通用户运行进程的，且在运行当中需要使用/tmp目录，结果提示没有权限。在我们导入容器镜像的时候，其实是会将容器启动时需要的各个目录的权限和属性都赋予了。如果我们直接是cp命令单纯复制文件内容的话，就会出现属性不一致的情况，同时还会有一定的安全问题。

Increase Docker container size from defualt 10GB on rhel7.

容器在导入或者启动的时候，如果提示磁盘空间不足的，那么多半是还真的因为物理磁盘空间真的有问题导致的。如下图所示，我们可以看到/分区确实满了。

# 查看物理磁盘空间
$ df -Th
Filesystem    Size    Used    Avail    Use%    Mounted on
/dev/vda1      40G     40G       0G    100%    /
tmpfs         7.8G       0     7.8G      0%    /dev/shm
/dev/vdb1     493G    289G     179G     62%    /mnt

如果发现真的是物理磁盘空间满了的话，就需要查看到底是什么占据了如此大的空间，导致因为容器没有空间无法启动。其中，docker自带的命令就是一个很好的能够帮助我们发现问题的工具。

# 查看基本信息
# 硬件驱动使用的是devicemapper，空间池为docker-252
# 磁盘可用容量仅剩16.78MB，可用供我们使用
$ docker info
Containers: 1
Images: 28
Storage Driver: devicemapper
 Pool Name: docker-252:1-787932-pool
 Pool Blocksize: 65.54 kB
 Backing Filesystem: extfs
 Data file: /dev/loop0
 Metadata file: /dev/loop1
 Data Space Used: 1.225 GB
 Data Space Total: 107.4 GB
 Data Space Available: 16.78 MB
 Metadata Space Used: 2.073 MB
 Metadata Space Total: 2.147 GB

通过查看系统，我们知道正是因为docker可用的磁盘空间不足，所以导致启动的时候没有足够的空间进行加载启动镜像。解决的办法也很简单，第一就是清理无效数据文件释放磁盘空间(清除日志)，第二就是修改docker数据存路径(大分区)。

# 显示哪些容器目录具有最大的日志文件
$ du -d1 -h /var/lib/docker/containers | sort -h

# 清除您选择的容器日志文件内容
$ cat /dev/null > /var/lib/docker/containers/container_id/container_log_name

• 显然我遇到的不是上一种情况，而是在启动容器的时候，容器启动之后不久就显示unhealthy的状态，通过如下日志发现，原来是复制配置文件启动的时候，提示磁盘空间不足。
• 后面发现是因为CentOS7 的系统使用的docker容器默认的创建大小就是10G而已，然而我们使用的容器却超过了这个限制，导致无法启动时提示空间不足。

2019-08-16 11:11:15,816 INFO spawned: 'app-demo' with pid 835
2019-08-16 11:11:16,268 INFO exited: app (exit status 1; not expected)
2019-08-16 11:11:17,270 INFO gave up: app entered FATAL state, too many start retries too quickly
cp: cannot create regular file '/etc/supervisor/conf.d/grpc-app-demo.conf': No space left on device
cp: cannot create regular file '/etc/supervisor/conf.d/grpc-app-demo.conf': No space left on device
cp: cannot create regular file '/etc/supervisor/conf.d/grpc-app-demo.conf': No space left on device
cp: cannot create regular file '/etc/supervisor/conf.d/grpc-app-demo.conf': No space left on device

# /etc/docker/daemon.json
{ 
        
    "live-restore": true
    "storage-opt": [ "dm.basesize=20G" ] 
}

# 1、 停止docker服务
$ sudo systemctl stop docker

# 2、删除已存在的容器
$ sudo rm -rf /var/lib/docker

# 3、修改docker服务的文件
$ sudo vim /usr/lib/systemd/system/docker.service

# 4、找到启动参数行
ExecStart=/usr/bin/dockerd
修改为
ExecStart=/usr/bin/dockerd --storage-opt dm.basesize=20G

# 5、重启docker服务
$ sudo systemctl daemon-reload
$ sudo systemctl start docker

还有一种情况也会让容器无法启动，并提示磁盘空间不足，但是使用命令查看插线并不是因为物理磁盘真的不足导致的。而是，因为对于分区inode节点数满了导致的。

# 报错信息
No space left on device

因为ext3文件系统使用inode table存储inode信息，而xfs文件系统使用B+ tree来进行存储。考虑到性能问题，默认情况下这个B+tree只会使用前1TB空间，当这1TB被写满后，就会导致无法写入inode信息，报磁盘空间不足的错误。我们可以在mount时，指定inode64即可将这个B+ tree使用的空间扩展到整个文件系统。

• 补充知识 文件存储在硬盘上，硬盘的最小存储单位叫做扇区(Sector)。每个扇区存储512字节(相当于0.5KB)。操作系统读取硬盘的时候，不会一个个扇区地去读取，这样效率太低，而是一次性连续读取多个扇区，即一次性读取一个块(block)。这种由多个扇区组成的块，是文件存取的最小单位。块的大小，最常见的是4KB，即连续八个sector组成一个block块。文件数据都存储在块中，那么很显然，我们还必须找打一个地方存储文件的元信息，比如，文件的创建者、文件的创建日期、文件的大小等等。这种存储文件元信息的区域就叫做索引节点(inode)。每个文件都有对应的inode，里面包含了除了文件名以外的所有文件信息。 inode也会消耗硬盘空间，所以硬盘格式化的时候，操作系统自动将硬盘分为两个区域。一个数据区，存放文件的数据；另一个是inode区(inode table)，存放inode所包含的信息。每个inode节点的大熊啊，一般是128字节或256字节。inode节点的总数，在格式化时就给定，一般是每1KB或每2KB就设置一个inode节点。

# 每个节点信息的内容
$ stat check_port_live.sh
  File: check_port_live.sh
  Size: 225           Blocks: 8          IO Block: 4096   regular file
Device: 822h/2082d    Inode: 99621663    Links: 1
Access: (0755/-rwxr-xr-x)  Uid: ( 1006/  escape)   Gid: ( 1006/  escape)
Access: 2019-07-29 14:59:59.498076903 +0800
Modify: 2019-07-29 14:59:59.498076903 +0800
Change: 2019-07-29 23:20:27.834866649 +0800
 Birth: -

# 磁盘的inode使用情况
$ df -i
Filesystem                 Inodes   IUsed     IFree IUse% Mounted on
udev                     16478355     801  16477554    1% /dev
tmpfs                    16487639    2521  16485118    1% /run
/dev/sdc2               244162560 4788436 239374124    2% /
tmpfs                    16487639       5  16487634    1% /dev/shm

Docker命令需要对/tmp目录下面有访问权限

给系统安装完compose之后，查看版本的时候，提示缺少一个名为libz.so.1的共享链接库。第一反应就是，是不是系统少安装哪个软件包。随机，搜索了一下，将相关依赖包都给安装了，却还是提示同样的问题。

# 提示错误信息
$ docker-compose --version
error while loading shared libraries: libz.so.1: failed to map segment from shared object: Operation not permitted

后来发现，是因为系统中docker没有对/tmp目录下的访问权限导致，需要重新将其挂载一次，就可以解决了。

# 重新挂载
$ sudo mount /tmp -o remount,exec

对dockerd的配置有可能会影响到系统稳定

容器文件损坏，经常会导致容器无法操作。正常的docker命令已经无法操作这台容器了，无法关闭、重启、删除。正巧，前天就遇到了这个的问题，主要的原因是因为重新对docker的默认容器进行了重新的分配限制导致的。

# 操作容器遇到类似的错误
b'devicemapper: Error running deviceCreate (CreateSnapDeviceRaw) dm_task_run failed'

可以通过以下操作将容器删除/重建。

# 1、关闭docker
$ sudo systemctl stop docker

# 2、删除容器文件
$ sudo rm -rf /var/lib/docker/containers

# 3、重新整理容器元数据
$ sudo thin_check /var/lib/docker/devicemapper/devicemaaper/metadata
$ sudo thin_check --clear-needs-check-flag /var/lib/docker/devicemapper/devicemapper/metadata

# 4、重启docker
$ sudo systemctl start docker 

不停止服务器上面的容器，重启dockerd服务是多么好的意见事

默认情况下，当Docker守护程序终止时，它会关闭正在运行的容器。从Docker-ce 1.12开始，可以在配置文件中添加live-restore参数，以便在守护程序变得不可用时容器保持运行。需要注意的时Windows平台暂时还是不支持该参数的配置。

# 在daemon.json中打开live-restore配置
$ sudo vim /etc/docker/daemon.json
{ 
        
    "live-restore": true
}

# 在守护进程停机期间保持容器存活
$ sudo dockerd --live-restore

# 只能使用reload重载
# 相当于发送SIGHUP信号量给docker守护进程
$ sudo systemctl reload docker

# 但是对应网络的设置需要restart才能生效
$ sudo systemctl restart docker

可以通过以下操作将容器删除/重建

# /etc/docker/daemon.json
{ 
        
    "registry-mirrors": ["https://vec0xydj.mirror.aliyuncs.com"],  # 配置获取官方镜像的仓库地址
    "experimental": true,  # 启用实验功能
    "default-runtime": "nvidia",  # 容器的默认OCI运行时(默认为runc)
    "live-restore": true,  # 重启dockerd服务的时候容易不终止
    "runtimes": { 
          # 配置容器运行时
        "nvidia": { 
        
            "path": "/usr/bin/nvidia-container-runtime",
            "runtimeArgs": []
        }
    },
    "default-address-pools": [  # 配置容器使用的子网地址池
        { 
        
            "scope": "local",
            "base":"172.17.0.0/12",
            "size":24
        }
    ]

}

$ vim /etc/docker/daemon.json
{ 
        
  "default-address-pools": [
    { 
        
      "base": "172.240.0.0/16",
      "size": 24
    }
  ]
}

找不到对应容器进程是最吓人的

今天遇到docker容器无法停止/终止/删除，以为整个容器可能有出现了dockerd守护经常托管的情况，但是通过ps -ef <container id>无法查到对应的运行进程。哎，后来开始查supervisor以及Dockerfile中的进程，都没有。这种情况的可能原因是容器启动之后主机因任何原因重新启动，并且没有优雅的终止容器。剩下的文件现在阻止你重新生成旧名称的新容器，因为系统认为旧容器仍然存在。

# 删除容器
$ sudo docker rm -f container_id
Error response from daemon: Conflict, cannot remove the default name of the container

找到/var/lib/docker/containers/下的对应容器的文件夹，将其删除，然后重启一下dockerd即可。我们会发现，之前无法删除的容器没有了

# 删除容器文件
$ sudo rm -rf /var/lib/docker/containers/container_id

# 重启服务
$ sudo systemctl restart docker.service

容器存在问题话，记得优先在官网查询

今天登录之前的MySQL数据库查询，发现使用SQL语句无法查询中文字段，即使直接输入中文都没有办法显示

# 查看容器支持的字符集
root@container_ip:# locale -e
C
C.UTF-8
POSIX

Docker部署的MySQL系统使用的是POSIX字符集。然而POSIX字符集是不支持中文的，而C.UTF-8是支持中文的只要把系统中的环境LANG改为C.UTF-8格式即可解决问题。同理，在K8S进入pod不能输入中文也可用此方法解决。

# 临时解决
docker exec -it some-mysql env LANG=C.UTF-8 /bin/bash

# 永久解决
docker run --name some-mysql \
    -e MYSQL_SOOT_PASSWORD=mysql-secret-pw \
    -d mysql:tag --character-set-server=utf8mb4 \
    --collation-server=utf8mb4_unicode_ci

了解Docker的四种网络模型

在本机部署Nginx容器想代理本机启动的Python后端服务程序，但是对代码服务如下的配置，结果访问的时候一直提示502错误。

# 启动Nginx服务
$ docker run -d -p 80:80 $pwd:/etc/nginx nginx

###nginx.conf###
server { 
        
    ...
    location /api { 
        
        proxy_pass http://localhost:8080
    }
}

• 后面发现是因为nginx.conf配置文件中的localhost配置的有问题，由于Nginx是在容器中运行，所以localhost为容器中的localhost,而非本机的localhost。所有导致无法访问。
• 可以将nginx.conf中的localhost修改为宿主机的IP地址，就可以解决502的错误。

server { 
        
    ...
    location /api { 
        
        proxy_pass http://宿主机IP:8080
    }
}

• 当容器使用host网络时，容器与宿主机共用网络，这样就能在容器中访问宿主机网络，那么容器的localhost就是宿主机的localhost了。

# 服务的启动方式有所改变(没有映射出来端口)
# 因为本身与宿主机共用了网络，宿主机暴露端口等同于容器中暴露端口
$ docker run -d --network=host $PWD:/etc/nginx nginx

总线错误看到的时候还是挺吓人的

在docker容器中运行程序的时候，提示bus error错误。

# 总线报错
$ unv app.user_op --name=test
Bus error (core dumped)

原因在docker运行的时候，shm分区设置太小导致share memory不够。不设置--shm-size参数时，docker给容器默认分配的shm大小为64M,导致程序启动时不足。具体原因还是因为安装pytorch包导致了，多进程任务的时候，docker容器分配的共享内存太小，导致torch要在tmpfs上面放模型数据用于子线程的共享不足，就出现报错了。

# 问题原因
root@18...35:/opt/app# df -TH
Filesystem     Type     Size  Used Avail Use% Mounted on
overlay        overlay  2.0T  221G  1.4T   3% /
tmpfs          tmpfs     68M     0   68M   0% /dev
shm            tmpfs     68M   41k   68M   1% /dev/shm

# 启动docker的时候加上 --shm-size 参数(单位为b,k,m或g)
$ docker run -it -rm --shwm-size=200m pytorch/pytorch:lastet

# 在docker-compose添加对应配置
$ shm_size: '2gb'

还有一种情况就是容器内的磁盘空间不足，也会导致bus error这样的报错，所以就出现了，清楚多余文件何目录或者分配一个大的磁盘空间，就可以解决了。

# 磁盘空间不足
$ df -Th
Filesystem     Type     Size  Used Avail Use% Mounted on
overlay        overlay    1T    1T    0G 100% /
shm            tmpfs     64M   24K   64M   1% /dev/shm

NFS挂载之后容器程序是使用异常为内核版本太低导致的

从下面的信息得知，要在Linux中使用flock()的话，就需要升级内核版本到2.6.11+才行。后来才发现，这实际上是由RedHat内核中的一个错误引起的，并在kernel-3.10.0-693.18.1.el7版本中得到了修复。所以对于NFSv3和NFSv4服务而已，就需要Linux内核版本才能够解决这个问题。

# https://t.codebug.vip/questions-930901.htm
$ In Linux kernels up to 2.6.11, flock() does not lock files over NFS (i.e.,
the scope of locks was limited to the local system). [...] Since Linux 2.6.12,
NFS clients support flock() locks by emulating them as byte-range locks on the entire file.

启动 的容器网络无法相互通信，很是奇怪

我们使用Docker启动服务的时候，发现有时候服务之前可以相互连通，而有有时启动的多个服务之前却出现了无法访问的情况。究其原因，发现原来是因为使用的内部私有地址网络不一样导致的。有的服务启动到了172.17 - 172.31的网段，有的服务跑到了192.169.0 - 192.168.224的网段，这样导致服务启动之后出现了无法访问的情况(默认情况下，有下面这两个网段可供其使用)。

上述问题的处理方式，就是手动指定Docker服务的启动网段，二选一就可以了

# 查看docker容器配置
$ cat /etc/docker/daemon.json
{ 
        
    registry-mirrors": ["https://vec0xydj.mirror.aliyuncs.com"], "default-address-pools":[{"base":"172.17.0.0/12", "size":24}], "experimental": true, "default-runtime": "nvidia", "live-restore": true, "runtimes": { "nvidia": { "path": "/usr/bin/nvidia-container-runtime", "runtimeArgs": []
        }
    }
}

使用docker-compose命令各自启动两组服务，发现服务会串台

在两个不同名称的目录目录下面，使用 docker-compose 来启动服务，发现当 A 组服务启动完毕之后，再启动 B 组服务的时候，发现 A 组当中对应的一部分服务又重新启动了一次，这就非常奇怪了！因为这个问题的存在会导致，A 组服务和 B 组服务无法同时启动。之前还以为是工具的 Bug，后来请教了 “上峰”，才知道了原因，恍然大悟。

# 服务目录结构如下所示
A: /data1/app/docker-compose.yml
B: /data2/app/docker-compose.yml

在编写脚本的时候常常会执行 docker 相关的命令，但是需要注意使用细节！

CI 更新环境执行了一个脚本，但是脚本执行过程中报错了，如下所示。通过对应的输出信息，可以看到提示说正在执行的设备不是一个 tty。

• 随即，查看了脚本发现报错地方是执行了一个exec的 docker 命令，大致如下所示。很奇怪的是，手动执行或直接调脚本的时候，怎么都是没有问题的，但是等到 CI 调用的时候怎么都是有问题。后来好好看下，下面这个命令，注意到 -it 这个参数了。

# 脚本调用docker命令
docker exec -it <container_name> psql -Upostgres ......

• 我们可以一起看下 exec 命令的这两个参数，自然就差不多理解了

docker exec 的参数 -t 是指Allocate a pseudo-TTY的意思，而 CI 在执行 job 的时候并不是在 TTY 终端中执行，所以 -t 这个参数会报错。同时在 『stackoverflow』也有人给出原因，可以自行查看。

在 Crontab 定时任务中也存在 Docker 命令执行异常的情况！

今天发现了一个问题，就是在备份 Mysql 数据库的时候，使用 docker 容器进行备份，然后使用 Crontab 定时任务来触发备份。但是发现备份的 MySQL 数据库居然是空的，但是手动执行对应命令切是好的，很奇怪。

# Crontab定时任务
0 */6 * * * \
    docker exec -it <container_name> sh -c \
        'exec mysqldump --all-databases -uroot -ppassword ......'

后来发现是因为执行的 docker 命令多个-i导致的。因为 Crontab 命令执行的时候，并不是交互式的，所以需要把这个去掉才可以。总结就是，如果你需要回显的话则需要-t选项，如果需要交互式会话则需要-i选项。

compose 里边环境变量带不带引号的问题！

• 使用过 compose 的朋友可能都遇到过，在编写启服务启动配置文件的时候，添加环境变量时到底是使用单引号、双引号还是不使用引号的问题？时间长了，我们可能会将三者混用，认为其效果是一样的。但是后来，发现的坑越来越多，才发现其越来越隐晦。
• 反正我是遇到过很多问题，都是因为添加引号导致的服务启动异常的，后来得出的结论就是一律不使引号。裸奔，体验前所未有的爽快！直到现在看到了Github中对应的 issus 之后，才终于破案了。

# 在Compose中进行引用TEST_VAR变量，无法找到
TEST_VAR="test"

# 在Compose中进行引用TEST_VAR变量，可以找到
TEST_VAR=test

# 后来发现docker本身其实已经正确地处理了引号的使用
docker run -it --rm -e TEST_VAR="test" test:latest

得到的结论就是，因为Compose解析 yaml 配置文件，发现引号也进行了解释包装。这就导致原本的 TEST_VAR="test" 被解析成了 'TEST_VAR="test"'，所以我们在引用的时候就无法获取到对应的值。现在解决方法就是，不管是我们直接在配置文件添加环境变量或者使用 env_file 配置文件，能不使用引号就不适用引号。 需要注意的是环境变量配置的是日志格式的话(2022-01-01)，如果使用的是 Python 的 yaml.load 模块的话，会被当做是 date 类型的，这是如果希望保持原样信息的话，可以使用 '/" 引起来将其变成字符串格式的。

无法删除镜像，归根到底还是有地方用到了！

清理服器磁盘空间的时候，删除某个镜像的时候提示如下信息。提示需要强制删除，但是发现及时执行了强制删除依旧没有效果.

# 删除镜像
$ docker rmi 3ccxxxx2e862
Error response from daemon: conflict: unable to delete 3ccxxxx2e862 (cannot be forced) - image has dependent child images

# 强制删除
$ dcoker rmi -f 3ccxxxx2e862
Error response from daemon: conflict: unable to delete 3ccxxxx2e862 (cannot be forced) - image has dependent child images

后来才发现，出现这个原因主要是因为 TAG，即存在其他镜像引用了这个镜像。这里我们可以使用如下命令查看对应镜像文件的依赖关系，然后根据对应 TAG 来删除镜像。

# 查询依赖 - image_id表示镜像名称
$ docker image inspect --format='{ 
        {.RepoTags}} { 
        {.Id}} { 
        {.Parent}}' $(docker image ls -q --filter since=<image_id>)

# 根据TAG删除镜像
$ docker rmi -f c565xxxxc87f

# 删除悬空镜像
$ docker rmi $(docker images --filter "dangling=true" -q --no-trunc)

切换 Docker 启动用户的话，还是需要注意下权限问题的！

我们知道在 Docker 容器里面使用 root 用户的话，是不安全的，很容易出现越权的安全问题，所以一般情况下，我们都会使用普通用户来代替 root 进行服务的启动和管理的。今天给一个服务切换用户的时候，发现 Nginx 服务一直无法启动，提示如下权限问题。因为对应的配置文件也没有配置 var 相关的目录，

# Nginx报错信息
nginx: [alert] could not open error log file: open() "/var/log/nginx/error.log" failed (13: Permission denied)
2020/11/12 15:25:47 [emerg] 23#23: mkdir() "/var/cache/nginx/client_temp" failed (13: Permission denied)

后来发现还是 nginx.conf 配置文件，配置的有问题，需要将 Nginx 服务启动时候需要的文件都配置到一个无权限的目录，即可解决。

user  www-data;
worker_processes  1;

error_log  /data/logs/master_error.log warn;
pid        /dev/shm/nginx.pid;

events { 
        
    worker_connections  1024;
}

http { 
        
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;

    gzip               on;
    sendfile           on;
    tcp_nopush         on;
    keepalive_timeout  65;

    client_body_temp_path  /tmp/client_body;
    fastcgi_temp_path      /tmp/fastcgi_temp;
    proxy_temp_path        /tmp/proxy_temp;
    scgi_temp_path         /tmp/scgi_temp;
    uwsgi_temp_path        /tmp/uwsgi_temp;

    include /etc/nginx/conf.d/*.conf;
}

Docker 服务在启动的时候，将地址绑定到 IPv6 地址上面了，提示报错信息！

物理机器更新了对应补丁之后，重启了服务，导致原本可以正常启动的 docker-compose 服务提示如下报错信息。不清楚是否修改了操作系统的相关配置，还是对应 docker 进行的其他方面的配置，比如修改 /etc/docker/daemon.json 或者 docker 的 service 启动文件。

# Docker的报错信息
docker run -p 80:80 nginx:alpine succeeds. Previously, this was failing with Error \
starting userland proxy: listen tcp6 [::]:80: socket: address family not supported by protocol.

通过如上所示的报错信息，可以看到服务的启动端口绑定到了 tcp6 上面了，但是对应的 socket 发现系统本身并不支持。这时，我们一看下对应的操作系统 ipv6 的设置，发现系统禁用了，所有的 ipv6 地址。需要了解的朋友，可以参考fix port forwarding with ipv6.disable=1和 cannot start if ipv6 is disabled on host 这两个 issus 来获取更多信息。