IPv6 区域标识符在 URL 中是个错误

背景

IPv6 协议的设计引入了一些令人困惑的特性，其中最具争议且容易导致实现混乱的，便是链路本地地址（Link-Local Addresses）与区域标识符（Zone Identifiers）的结合使用。

在 IPv6 中，每个网络接口的链路本地地址通常以 fe80:: 开头。如果一台机器拥有多个网络接口，它们都会拥有以 fe80:: 开头的地址。这就产生了一个歧义问题：如果一个数据包的目标地址是 fe80::4，系统如何知道该将其发送到哪个接口？

为了解决这个地址冲突，IPv6 标准引入了“作用域”或“区域”（Scopes/Zones）的概念。具体的格式取决于操作系统：在 Linux 上，它通常是接口名称（如 eth0）；在 Windows 上，它通常是接口 ID。这使得内核的路由表能够明确如何处理地址范围冲突。

然而，当这种机制被引入到统一资源定位符（URL）的语法中时，由于 URL 编码规则和 IPv6 地址表示法之间的冲突，导致了一系列解析错误和兼容性问题。

核心内容

IPv6 地址与端口的表示

在创建 host:port 绑定主机时，通常使用冒号分隔主机名和端口。但 IPv6 地址本身也使用冒号来分隔十六进制组。为了消除歧义，IPv6 地址通常被包裹在方括号中。

例如，端口 80 上的 fe80::4 应表示为： [fe80::4]:80

当加入区域标识符（Zone ID）后，完整的表示形式如下： [fe80::4%eth0]:80 其中 eth0 是以太网设备的名称。

URL 解析中的冲突

从高层视角看，URL 的格式大致遵循以下结构： <scheme>:[//][<username>[:<password>]@][<hostname>][:<port>][/<path>][?<query>][#<fragment>]

理论上，IPv6 区域标识符应作为主机名的一部分。因此，直觉上 URL 应写为： http://[fe80::4%eth0]:80

然而，在 Go 语言中使用 net/url 包解析此 URL 时会抛出错误：

package main
import "net/url"
func main() {
    if _, err := url.Parse("http://[fe80::4%eth0]:80"); err != nil {
        panic(err)
    }
}

错误信息为： panic: parse "http://[fe80::4%eth0]:80": invalid URL escape "%et"

根本原因：URL 编码规则

这一错误发生的原因是 URL 无法直接表示所有 Unicode 值，任何不符合 URL 语法的字符都必须进行百分号编码（Percent-encoding）。这就是为什么我们在 URL 中经常看到 %20（代表空格，因为空格在 URL 中无效）。

在 fe80::4%eth0 中，百分号 % 被视为转义字符的开始。解析器试图解析 %et，但这不是一个有效的十六进制转义序列，从而导致解析失败。

解决方案与局限

为了绕过这一问题，必须对 IPv6 区域标识符中的百分号进行百分号编码。百分号的编码形式是 %25。

修正后的 Go 代码示例：

package main
import (
    "fmt"
    "net/url"
)
func main() {
    u, err := url.Parse("http://[fe80::4%25eth0]:80")
    if err != nil {
        panic(err)
    }
    fmt.Println(u.Hostname())
}

输出结果为： fe80::4%eth0

标准与现状

尽管 RFC 9884 提供了在用户界面中正确处理 IPv6 区域标识符的指导，但针对 URL 本身的处理却缺乏明确指导。Go 语言的 net/url 库似乎并未遵循这一 RFC。

目前，其他框架、编程语言和库也面临类似边缘情况：

• Nginx: Ticket #623
• Python Requests: Issue #6808
• IETF 草案: draft-schinazi-httpbis-link-local-uri-bcp-03

值得注意的是，浏览器目前不支持 IPv6 区域标识符，因为这会破坏“源（Origin）”的概念，而“源”在许多细微的安全和功能机制中至关重要。上述 IETF 草案试图定义 IPv6 的区域源，以便浏览器能有依据地支持这一功能。

作者指出，为了保持代码简洁并避免分叉 Go 标准库，目前接受这种对边缘情况不太友好的用户体验（UX）是必要的妥协。

关键要点

• 地址歧义：IPv6 链路本地地址（fe80::）在多接口环境下存在歧义，必须通过区域标识符（Zone ID，如 %eth0）来指定具体接口。
• 语法冲突：URL 解析器将 IPv6 地址中的 % 视为百分号编码的起始符，导致包含区域标识符的 URL（如 %eth0）解析失败。
• 编码 workaround：必须在 URL 中对区域标识符的百分号进行二次编码（即 %25），例如 [fe80::4%25eth0]:80，才能被正确解析。
• 标准缺失：目前缺乏针对 URL 中 IPv6 区域标识符处理的统一且广泛遵循的标准，导致各语言库（如 Go）行为不一致。
• 浏览器限制：主流浏览器目前不支持 IPv6 区域标识符，主要因为这会干扰基于“源（Origin）”的安全模型。

意义与影响

• 开发者的痛点：对于需要处理内网或链路本地通信的后端开发者（如使用 Go、Python 等构建微服务或 API 网关），IPv6 区域标识符是一个隐蔽的陷阱。如果不了解百分号编码规则，调试网络连通性问题将变得极其困难。
• 互操作性挑战：由于不同语言库和中间件（如 Nginx）对这一边缘情况的支持程度不同，跨平台或混合技术栈的系统在 IPv6 环境下可能出现不可预见的连接失败。
• Web 安全的复杂性：浏览器对 IPv6 区域标识符的抵制反映了 Web 安全模型（CORS、同源策略等）与底层网络寻址机制之间的深层冲突。解决这一问题需要重新审视“源”的定义，这不仅是技术实现问题，更是标准制定层面的难题。
• 未来展望：随着 IPv6 的普及，这一“错误”或“缺陷”可能会变得更加显著。除非 IETF 能推出更完善的 BCP（最佳当前实践）并被浏览器和主流库广泛采纳，否则开发者仍需手动处理这些编码细节。