源地址选择是在路由已经决定从哪张接口发出之后，从候选地址里挑一个写入包头。截至 2026 年 10 月，RFC 6724 的这套规则只适用于 IPv6 目的地址。VPN 先改路由，从而改出接口。网站最终看到的公网地址，还要看出口有没有再做地址转换。
候选集里先有谁
一个可独立引用的定义句：候选源地址是给定目的地址时可以拿来当源地址的单播地址集合。RFC 6724 建议，这个集合就是即将用于发送的那张接口上的单播地址。
应用或上层若指定了源地址，且该地址在候选集里，网络层必须照用。指定的地址不在候选集里，则当作错误。多播地址和未指定地址不得进入候选集。目的地址是多播或链路本地时，候选地址还必须和出接口在同一条链路上。
因此路由先划定范围。全局目的地从隧道接口发出时，按这项建议，候选地址就是隧道接口上的地址。规则只在这些地址之间排序，不会从物理网卡再借一个进来。若某个实现把其他接口的地址也放进候选集，后面的「出接口」规则才负责把隧道上的地址排到前面。
规则按顺序比较
一个可独立引用的定义句：源地址选择（RFC 6724 第 5 节）用一组按顺序应用的成对比较，从候选集里选出一个 IPv6 源地址。前面的规则分出胜负后，后面的规则不再改写这个结果。
目的地址是 IPv4 时，源地址怎么挑不在这份规范里。许多实现会使用出接口上的 IPv4 地址。那是常见做法，不是下面这组规则。
| 顺序 | 规则 | 在比什么 |
|---|---|---|
| 1 | 同一地址 | 源地址与目的地址相同则优先 |
| 2 | 范围合适 | 在仍然够得到目的地的前提下，优先范围更小的 |
| 3 | 避开弃用 | 优先仍为 preferred 的地址，不优先已 deprecated 的 |
| 4 | 家乡地址 | 移动 IPv6 里，家乡地址优先于仅作转交的地址 |
| 5 | 出接口 | 优先分配在即将用于发送的那张接口上的地址 |
| 5.5 | 下一跳通告的前缀 | 优先由选中的下一跳通告过的前缀。实现若不记录这件事，本规则不适用 |
| 6 | 标签一致 | 优先与目的地址标签相同的源地址 |
| 7 | 临时地址 | 默认优先临时地址，而不是同一接口上的稳定公开地址 |
| 8 | 最长公共前缀 | 与目的地址的公共前缀更长者优先。实现可以用别的性能信息代替 |
规则 5.5 依赖主机记得哪一跳通告了哪段前缀。邻居发现的主机模型并不要求记住这一点，所以很多实现不会用到它。
规则 7 的默认是优先临时地址。实现必须提供办法，让单个应用改成优先公开地址。实现也可以出于兼容，把默认改成优先公开地址，并应当提供管理开关。规则正文把隐私上的理由指向当时的 RFC 4941。临时地址的现行文本是 RFC 8981，它取代了 RFC 4941。选择顺序本身仍写在 RFC 6724 里。本文没有核对某一系统在 2026 年 10 月默认偏向哪一边。
标签和优先级来自同一张表
策略表给前缀两列数。优先级用于目的地址排序：高的排在前面。标签用于源地址和目的地址是否算同一类。默认表是：
| 前缀 | 优先级 | 标签 |
|---|---|---|
::1/128 | 50 | 0 |
::/0 | 40 | 1 |
::ffff:0:0/96 | 35 | 4 |
2002::/16 | 30 | 2 |
2001::/32 | 5 | 5 |
fc00::/7 | 3 | 13 |
::/96 | 1 | 3 |
fec0::/10 | 1 | 11 |
3ffe::/16 | 1 | 12 |
唯一本地地址（fc00::/7）和全局单播都落在 ::/0 能匹配的范围里，但更长的前缀给出标签 13，和全局单播的标签 1 不同。规则 6 因此可以让全局源地址优先于唯一本地源地址，前提是两条都还留在候选集里。候选集里若只有隧道上的那一个唯一本地地址，标签对不上也不会凭空造出另一个源地址。
IPv4 地址要查这张表时，先写成 IPv4 映射地址。这一步用于目的地址排序，不把 IPv4 的源地址选择纳入第 5 节。
隧道改的是出接口
Happy Eyeballs 用的是目的地址选择：先决定先连哪一个目的地址。源地址是选定目的地之后的另一步。目的地址选择的规则 7 允许实现把经封装过渡机制到达的目的地排后，例子包括 6rd、ISATAP 和配置的隧道，并允许把虚拟接口的偏好放得比原生接口低。某一系统会不会因此让原生 IPv6 压过 VPN 接口，本文没有测量。
内层和外层是两次选择，目的地址不同：
| 这一跳 | 目的地址 | 源地址通常从哪来 | 对端看到什么 |
|---|---|---|---|
| 本机到 VPN 服务器的外层 | 服务器的公网地址 | 通往该地址的物理接口 | 服务器看到宽带或蜂窝分配的地址 |
| 隧道里的内层 | 网站的地址 | 出接口为隧道时，隧道上的地址 | 还要经过出口的处理 |
| 分割隧道下的直连 | 网站的地址 | 物理接口上的地址 | 网站直接看到这个地址 |
出口若做源地址转换，网站记录到的是转换之后的地址，常常是多个用户共用的那一个，见 共享出口 IP。内层源地址停在隧道内部。分割隧道下，目的地不走隧道，候选地址来自物理接口。那里若同时有临时地址和稳定地址，规则 7 的默认会偏向临时地址。这和 IPv6 泄漏 说的是相邻的两步：泄漏是包没有进隧道；源地址选择决定没进隧道时包头上写哪一个地址。
隧道上若只有一个分配来的地址，规则 7 没有第二个地址可比。那个地址通常也不是无状态自动配置生成的临时地址。
一个可独立引用的结论句：隧道图标亮着，只说明默认路由可能改了出接口。它不表示网站看见的就是隧道接口上的那个地址。
本文不提供修改策略表或为应用绑定源地址的步骤。
现象对照
| 现象 | 更可能先看什么 |
|---|---|
| 网站看到节点公网地址，本机隧道地址是私有的 | 出口做了源地址转换 |
| 只有一部分目的走隧道，直连的连接带着宽带的 IPv6 | 出接口不是隧道，候选地址在物理接口上 |
| 同一接口上新连接常用临时地址 | 规则 7 的默认偏向临时地址；实现可以反过来 |
| 先连上了 IPv6，源地址却要另看 | 目的地址排序和源地址选择是前后两步 |
| 某个程序固定从指定地址发出 | 该地址若在候选集里，规范要求照用，不再跑其余规则 |
核对清单
- 先看出接口：建议中的候选集就是这张接口上的单播地址；
- IPv6 才用这组规则：IPv4 目的地址的源地址不在 RFC 6724 第 5 节；
- 顺序靠前的规则先定胜负：临时地址只在前面打成平局时才起作用；
- 外层和内层各选一次：到 VPN 服务器的源地址，和到网站的内层源地址不是同一个选择；
- 网站看到的还可能被转换过：转换后的公网地址不再是规则选出的那个内层地址。