企业官网建设流程全解析

搜索"LinkLocalIPv6Address"和"LinkLocalIPv6PrefixLen"这两个词的人，大概率不是日常折腾Docker主机的老手，而是某个下午突然在API返回里撞见这两个字段、或者在某个管理面板里看到一台容器有这么一串IPv6参数的管理员。这两个参数在Docker官方文档里轻描淡写，中文资料更是少得可怜，不少朋友绕来绕去，最后要么靠猜，要么干脆忽略。这篇文章我就把这两个参数讲透：它们是什么、底层对应哪块逻辑、什么时候值得用、怎么配、配完怎么验证，以及我在真实环境里替大家踩过的一些坑。我尽量按一个实操者的角度来说，不写教科书内容。

1. 从名字开始：这俩参数到底在配置哪张网卡

1.1 链路本地地址：IPv6 世界里“邻居说话”的方式

要理解 LinkLocalIPv6Address，得先明白 IPv6 里有一个很特别的概念叫“链路本地地址”。它跟传统的 IPv4 私网地址（比如 192.168.x.x）完全不同，甚至和 IPv6 的 ULA 地址（fd00::/8）也不一样。这种地址只在“一条链路”内有意义，也就是同一个二层网络里的设备之间可以直接用它互相访问，但出了这条链路，就不通了。日常最容易见到的链路本地地址，是接口自动生成的 fe80:: 开头的那一串。

IPv6 协议里，设备的每个接口天生就应该有一个链路本地地址，它在实现邻居发现、无状态地址自动配置、组播协议等底层功能时不可替代。哪怕一个接口没有配置任何全球单播地址，链路本地地址也照样存在。你可以这么理解：链路本地地址相当于一台机器在自己家门口贴的“门牌号”，邻居串门用门牌号找你是完全够用的，可要是让一个外省的人拿着这个门牌号来找你，那肯定没戏，因为门牌号并不属于全国统一地址体系。

Linux 下默认会基于网卡 MAC 地址和接口 ID 自动生成一个 fe80:: 开头的链路本地地址。所以，理论上在开启 IPv6 的网络命名空间里，你不需要手动配什么，容器自己就有一个。问题在于 Docker 出于兼容性考虑，默认并不启用 IPv6。只要宿主机的 Docker 网络栈里没有打开 IPv6，那么容器接口上就连这个自动生成了的 fe80 地址也看不到。于是 LinkLocalIPv6Address 这个参数的意义就变得非常具体：它是用来在 Docker 网络命名空间里，往容器接口上手动加一条 IPv6 链路本地地址的。

1.2 LinkLocalIPv6PrefixLen 为什么总跟着 LinkLocalIPv6Address 出现

搞清楚了 LinkLocalIPv6Address 是“哪块门牌号”，LinkLocalIPv6PrefixLen 就很好理解了。它就是这条地址的前缀长度，放在 IPv4 语境里可以粗暴理解成子网掩码的变体，只不过 IPv4 习惯用 255.255.255.0，而 IPv6 直接写 /64 这样的数字。

在 Docker 创建的容器配置里，这两个字段经常成对出现。比如用 Docker API 创建容器时，可能会看到一段这样的配置：

"LinkLocalIPv6Address": "fe80::aabb:1", "LinkLocalIPv6PrefixLen": 64

对于链路本地地址来说，前缀长度固定写在 fe80::/10 这个范围里，但标准做法是接口标识符也留出 64 位，所以实际几乎总是用 /64。如果你是在命令行下用docker run --link-local-ip来配，CLI 并不会单独让你填前缀长度，Docker 会默认给你补上 /64。只有在对接底层 API 或某些管理平台时，你才会看到一个不依赖默认值的 PrefixLen 字段。

从计算逻辑上看，PrefixLen 决定了这个地址的“网络部分”和“主机部分”的边界，局域网通信会拿它判断目标地址是否和自己在一个网段。IPv6 链路本地地址由于从不被路由器转发，整条链路基本就是一个 /64 广播域，所以你在绝大多数情况下不需要费心改这个值。看到字段时认出来，知道它默认 64，就够了。

2. 什么场景会用到，以及它和 --ip6 的区别

2.1 三个典型场景

在我实际接触过的项目里，会用上 LinkLocalIPv6Address 的无非这么几类情况。

第一类是容器需要提供一个固定不变的接口标识。很多 IPv6 应用会依赖链路上的接口 ID 做身份识别，比如某些组播协议、邻居发现相关功能，或者日志系统里想用固定的 fe80 地址来标记设备身份。如果完全依赖内核自动生成，那么换网卡、换容器栈、或者启用隐私扩展后，这个地址就会变来变去，排查问题时非常难受。手动指定一个固定的链路本地地址，至少在一台容器上能稳定地观察和访问。

第二类是链路内直接通信。如果两个容器挂在同一个自定义 bridge 网络上，并且都不需要对外路由，那完全没有必要消耗全球单播地址。给两边分别配一个 fe80:: 地址，让它们在链路内互相开门见山地访问，是相对干净的做法。虽然 Docker 的嵌入式 DNS 和普通 IPv4 地址已经能解决大部分互访需求，但个别程序只认 IPv6 链路本地地址，这种情况下就必须手动安排了。

第三类是测试 IPv6 协议栈功能。不少开发者在调试 IPv6 代码时并不想申请和暴露公网地址，只想验证 ND、SLAAC、组播这些基础机制。此时手动塞一个 fe80:: 地址，能让协议栈跑起来，又不会让容器变成公网可达节点。对于做网络实验的小环境来说，比去申请一段正式地址方便得多。

2.2 为什么不直接用 --ip / --ip6

很多人看到 LinkLocalIPv6Address 的第一反应是：这不就相当于手动指定 IP 吗？我用--ip6或者--ip不也能固定地址吗？其实两者有本质区别。

--ip和--ip6指定的是容器的“全局寻址地址”，这些地址放在 Docker 网络的子网池里，会被路由器感知、转发甚至对外可见。比如你在自定义网络里给容器固定一个2001:db8:1::10，那就等于告诉整个网络“这台容器在这个子网里有个永久身份”。这个地址是会参与路由的，只要网段规划合理，外部设备也能访问它。

而 LinkLocalIPv6Address 指定的是只对当前链路有意义的地址。它不进路由表，不参与跨网段转发，即使你把它设成某个全球单播地址段里的值（不过一般不建议这么干），它仍然只作为链路本地地址存在，路由器也不会为它发路由通告。换句话说，--ip6解决的是“外部怎么找到你”的问题，LinkLocalIPv6Address 解决的是“同一条链路上怎么稳定识别你”的问题。两者适用边界完全不同。

还有一个比较隐性的差别：你在创建容器时通过--ip6指定的地址，会写进容器的主网络配置里，作为普通地址存在；而--link-local-ip配的地址，内核会把它的 scope 标记为 link，能用的场景天然受限。如果你只是想要一个稳定可路由的 IPv6 地址，那选--ip6就行，没必要非要碰 LinkLocal 相关参数。只有当你明确知道需要的是“链路内固定身份”时，才有必要用这两个冷门字段。

3. 实操：给容器配一个固定 IPv6 链路本地地址

3.1 前提：先让 Docker 的网络带上 IPv6

命令行是--link-local-ip，和文档里的 LinkLocalIPv6Address 对应，但如果你直接给默认的 bridge 网络启动一个带这个参数的容器，十有八九会发现容器里根本没有 fe80 地址。原因我前面提过——Docker 默认没把 IPv6 打开。所以第一步是让守护进程支持 IPv6。

编辑 Docker 守护进程配置：

vim /etc/docker/daemon.json

写入如下内容：

{ "ipv6": true, "fixed-cidr-v6": "2001:db8:1::/64" }

这里fixed-cidr-v6是给默认的 docker0 网桥分配网段用的，我用的是文档里推荐的保留地址段，实际生产环境请替换成自己规划好的网段。改完重启：

systemctl restart docker

注意，只是打开了 daemon 的 IPv6 开关还不够。默认的 docker0 桥虽然有了 IPv6 能力，但在容器互联体验上不如用户自定义网络。所以我更建议再建一个专门的 bridge 网络：

docker network create --ipv6 --subnet=2001:db8:1::/64 my-net

如果没有给 daemon 开 IPv6，那么创建网络时就算你加了--ipv6参数，也可能配置不上。所以这两步按顺序来。到这里，后面启动的容器只要连着my-net，就会自动有一个基于 MAC 生成的 fe80:: 链路本地地址。我们可以先验证一下，再开始手动指定。

3.2 用 docker run 设置 LinkLocalIPv6Address

创建容器时加--link-local-ip参数即可，这个参数可以重复传多次，也可以传逗号分隔的多个地址。我在一台 Ubuntu 的 Docker 20.10 环境里实测：

docker run -d --name ipv6-box \ --network my-net \ --link-local-ip fe80::aabb:1 \ nginx:alpine

启动后进入容器看看网卡状况：

docker exec ipv6-box ip -6 addr show eth0

输出大致是：

6: eth0@if7: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP inet6 fe80::aabb:1/64 scope link inet6 2001:db8:1::2/64 scope global inet6 fe80::42:acff:fe11:2/64 scope link tentative

能看到除了自动生成的 fe80::42... 地址，多了一个手动指定且 scope 为 link 的 fe80::aabb:1/64。前缀长度就是默认的 64，也就是 API 里 LinkLocalIPv6PrefixLen 的行为。

要是你更习惯在创建网络时就规划好，也可以在同一网络的另一个容器里直接测试访问。这里我先提醒一句：IPv6 链路本地地址不具备全局唯一性，你完全可以给多个容器的 fe80 配同一段地址，只要在访问时用对网卡接口就行。不过同一个网络里最好还是别重复，免得后续看日志时分不出谁是谁。

3.3 通过 API/SDK 和 Compose 的落地方式

CLI 只是浅层封装，如果大家是通过编程方式管理容器，那一定是直接和 API 或者某语言 SDK 打交道。以官方 Python SDK 为例，大致这样传参：

import docker client = docker.from_env() container = client.containers.run( "nginx:alpine", name="ipv6-box-api", network="my-net", host_config=client.create_host_config( link_local_ipv6_address="fe80::aabb:2", link_local_ipv6_prefixlen="64" ), detach=True )

各个版本的 SDK 参数名可能略有差异，我看到有的版本把 link_local_ipv6_prefixlen 单独作为 HostConfig 字段，有的版本则只接受 link_local_ipv6_address。遇到报错时多看一眼你手里 SDK 版本的源码，确认它正确映射到 API 的哪个字段就行。底层原理不变：一个字段指定地址，一个字段指定前缀长度。

用 docker compose 管理的人可能要失望了。在我看过的 Compose 规范里，没有直接暴露 link-local 地址配置的字段。尝试往 compose 文件里硬塞一个不存在的键，Compsoe 大概率会直接报 schema 非法。我通常的做法是：把这类容器的创建单独抽到脚本里，用 docker run 或 SDK 做，其余普通容器继续用 compose 管理。这样既不破坏编排一致性，也能在需要的时候精确控制这几个参数。

4. 真实环境里踩过的坑

4.1 地址“配上了”却没有效果

一位朋友曾经遇到很奇怪的问题：容器配置里明明填了 LinkLocalIPv6Address，在管理面板里也查到这台容器有这条记录，但进容器执行ip -6 addr show时，却看不到对应的地址。我把他的环境完整看了一遍，发现是他把参数配在了容器模板上，但容器所连的那个网络根本没有启用 IPv6。Docker 在创建容器时看到网络不支持 IPv6，会非常安静地忽略掉这条地址配置，不会报错，也不会在事件日志里留下任何痕迹。

这个坑很容易让人怀疑人生。排查思路也比较简单：先确认网络层面开没开 IPv6，再确认容器所在的网络是不是真正有 IPv6 子网。由于容器网络栈是个独立命名空间，你可以直接进去看：

docker run --rm -it --network my-net nginx:alpine ip -6 addr

如果没有任何 inet6 行，那问题大概率出在网络本身。如果连自动生成的 fe80 都没有，那多半是 sysctl 把 IPv6 禁用了，或者容器镜像本身裁剪了 IPv6 协议栈。我在选用精简版镜像时遇到过后者，这种镜像里连ip命令都没有，更别说调试 IPv6 了。

4.2 多个 fe80 地址导致的地址选择问题

Linux 一个接口上允许存在多个同类型的 IPv6 地址，链路本地地址也没例外。手动指定了一个 fe80::aabb:1 之后，内核自动生成的另一个基于 MAC 的 fe80:: 地址并不会消失，而是和手动地址共存。这在日常访问里可能会埋雷。

Linux 的处理方式是：当一个应用请求绑定或者访问链路本地地址时，系统会从接口上多个候选地址里挑一个作为源地址。在某些比较老的内核版本上，源地址选择策略并不总是优先你手动指定的那个，于是就会出现一种很诡异的现象：明明容器里有 fe80::aabb:1，但你从另一台机器访问它的时候，通通发到了自动生成的那个地址上，而自动生成的地址往往又语言不通，最终表现为ping6超时或者连接被拒。

这里没有特别通用的解法。我的习惯是，如果业务真的强依赖固定的链路本地地址，那就别让 Linux 同时保留两个地址。可以在容器的 entrypoint 里或者创建容器时关掉自动生成：

sysctl -w net.ipv6.conf.eth0.autoconf=0

再把自动生成的 fe80 地址删掉或忽略。Docker 容器内的 sysctl 可以在运行时用--sysctl参数注入，部分配置在创建时就能生效。需要注意的是，这种方式带有一点侵入性，必须在组网方案设计时就做好决策，别等到流量异常了再去改。

4.3 重启、重建与保留策略

还有两个高频疑问顺便一起说清楚。第一，容器用docker run指定的--link-local-ip，在容器 restart 之后会不会丢？答案是只要容器定义不变，重启不会丢，因为地址配置属于容器创建配置的一部分，Docker daemon 会重新把它们应用回去。但如果你在容器内部用ip addr add fe80::x手动加了一个地址，重启容器后按定义重建网络栈，这个手动加的就没了。这算我们日常运维里最常搞混的一层。

第二，容器重建后地址保留吗？如果重建时重新指定了相同的 LinkLocalIPv6Address，当然保留。但如果你依赖 Docker 默认分配，它只会给 IPv4 自动分配地址，IPv6 链路本地地址一般仍以自动生成的方式存在。所以要想长期固定，还是把这个参数写进创建模板里，形成“配置即事实”。随手动改随用，最后一定会有人踩到“地址漂移”的坑。

4.4 常见问题速查表

5. 让固定链路地址真正派上用场

5.1 容器之间用 fe80 地址互访的正确姿势

很多人第一次在容器里用 fe80 地址做互访时会栽在同一个细节上：ping 链路本地地址必须带接口标识，不然内核不知道走哪张网卡。在同一个自定义网络里的容器，从 box2 访问 box1 的命令是这样：

docker exec ipv6-box2 ping6 -c 3 fe80::aabb:1%eth0

在容器内部，%eth0就是链路出口标识。不同网络命名空间里，即使你看到的 eth0 编号相同，含义也是各自独立的。所以容器 A 访问容器 B 时用的接口名，以 A 自己的网络栈为准。这个%接口名的写法在几乎所有 Linux 工具和上层应用里都通用，连接串里也需要带一路。

如果容器里没有ping6，装 iputils-ping 或者改用curl、nc之类的工具验证都是可以的。关键是理解链路本地地址寻址必需“目标地址 + 接口标识”这一个组合。这是 IPv6 链路本地地址机制本身的限制，跟 Docker 没多大关系。

5.2 组播协议与设备发现场景的扩展思路

链路本地地址在很多 IPv6 组播场景里扮演的是“身份牌”的角色。举个例子，UDP 组播发现协议的基础就是每个节点有一个可达的链路本地地址，这样设备在同一个广播域里不必依赖 DHCP 或者 DNS 分配，就能直接通过 ND 协议发现彼此。Docker 容器默认的 bridge 网络虽然把端口隔离做得比较严实，但 IPv6 组播依然是可以穿过容器网络的。你在容器里跑 mDNS 这类服务时，如果希望容器对外有稳定的链路本地身份，那 LinkLocalIPv6Address 的作用就体现出来了。

有趣的是，Docker 的端口映射对于 IPv6 组播并不天然友好，所以更常见的做法还是给容器直接建一个 host 类型网络，或者用 macvlan 让容器以独立二层身份进入物理网络。在这类拓扑下，手动固定一个链路本地地址，比在容器里反复依赖自动生成的 MAC 地址要可控得多。比如做边缘网关的设备容器，每次重启后链路本地地址都不变，与上下游组播邻居的会话就能少很多重连开销。

5.3 一句来自实操的话

按照我的经验，这两个参数绝大多数项目里根本用不上。它们属于那种“不知道不犯错、知道了能救命”的冷门配置。真要到了排查链路本地地址类问题的时候，能分清楚 LinkLocalIPv6Address 和普通 IPv6 地址的区别，能摸到 PrefixLen 的默认值与作用，调度层交付过来的一串 JSON 参数就不会再是一堆天书。如果你最终决定在容器里启用它们，记得先把网络的 IPv6 能力打开，再想清楚是“链路内身份”还是“可路由地址”的需求，最后再决定用哪种方式赋地址。这几步走顺了，后续遇到的绝大部分异常都能迎刃而解。