v0.40.6-rc1：传输层支持代理重定向目标

容器镜像的分发链路里，registry 经常把请求重定向到 CDN 或镜像加速节点。当客户端处于正向代理之后时，这套「先解析、再锁定 IP」的传输逻辑就会出问题——本地 DNS 解析出的地址可能根本不可达，真正能连通的是代理侧的解析结果。v0.40.6-rc1 的这次提交（#19065）正是针对这一场景，调整了传输层的代理行为。

改动核心：有代理时把 DNS 交给代理

提交说明的第一句就点明了策略分叉：Behind a proxy, defer redirect-target DNS to the proxy; without one, keep the resolve-and-pin path.

也就是说，当检测到请求走代理时，客户端不再自己对重定向目标做 DNS 解析并把结果固定下来，而是把这一步让给代理处理。没有代理时，原有的「解析并固定 IP」路径保持不变。这一分叉避免了在代理环境下本地解析结果与实际出口不一致导致的连接失败，同时也保留了对直连场景的既有保护。

正向代理在这里指的是客户端主动配置、替客户端向外部发起请求的中间服务，常见于企业内网与 CI 环境，HTTP 代理通过 CONNECT 建立隧道，HTTPS 请求则往往由代理代为完成 DNS 解析。容器镜像拉取中，registry 常以 302/307 重定向把 blob 请求指向对象存储或 CDN，客户端随后需要解析新的重定向目标主机名。这一跳是否会经过代理、由谁来做 DNS，直接决定了连接能否建立。本次改动正是在这一环节判定是否存在代理，从而选择本地解析还是交由代理解析，属于传输层对「重定向目标」而非「原始 registry 地址」的处理策略调整。

为什么「锁定 IP」在代理下会失效

「resolve-and-pin」是一种常见的传输加固手段：先解析主机名，拿到具体 IP 后在后续连接中固定使用，从而降低 DNS 重绑定之类的风险。但它的前提是客户端的网络出口与 DNS 解析环境一致。

引入正向代理后这个前提被打破。客户端的 DNS 服务器可能无法解析 registry 重定向目标的域名，或者解析到的是内网不可达的地址，而真正生效的解析发生在代理所在网络。此时继续 pin 住本地解析的 IP，等于把请求指向一条走不通的路。把解析权交还代理，是让两者重新对齐的合理做法。

DNS 重绑定（DNS rebinding）是一种针对网络解析层的攻击：攻击者控制一个域名，让其 TTL 极短的 DNS 记录在两次解析之间返回不同 IP，第一次用合法地址通过校验，第二次指向内网或恶意地址，从而绕过基于主机名的访问限制。「解析并固定 IP」正是为压制这类攻击而生的防御手段——一旦解析出 IP 就写死在连接里，后续不再重新解析，攻击者便失去了切换目标的窗口。代价是这条连接被绑定在某个具体的 IP 上，任何导致该 IP 不可达的环境变化（例如出口网络不同、解析结果因网络位置而异）都会让连接直接失败。因此在代理场景下，把解析环节整体交给代理，本质是用「信任代理侧的解析环境」换取「连接可达性」，同时代理通常会自行做缓存与校验，重绑定风险并未被完全放弃。

默认 registry / CDN 主机名的信任处理

改动还涉及主机名信任逻辑：Trust default-registry/CDN hostnames with no local DNS.

对于默认 registry 以及已知 CDN 的主机名，在本地无法解析的情况下允许直接信任，而不是因为解析失败就中断流程。结合上一条看，这实际上是在收紧直连场景的 pin 策略、放宽代理与已知可信主机名的场景，让不同网络拓扑下都有可用的传输路径。

容器镜像的 registry 与 CDN 主机名属于一套相对固定、由基础设施方掌控的可信集合，例如 Docker Hub 及常见云厂商的镜像加速域名。传统做法依赖一个预置的可信主机名列表，但当本地 DNS 无法解析这些名字时（内网 DNS 未配置外部递归、或域名被本地策略拦截），严格校验会直接判定为不可信而中断拉取。允许「本地解析失败也信任」相当于把可信判定的依据从「能否解析」转向「主机名是否在白名单内」，这既避免因 DNS 环境缺失造成的误伤，也意味着信任边界更多依赖白名单的维护准确性，而非运行时的解析证据。

顺带修掉一个 nil CancelFunc 崩溃

除代理相关改动外，提交还修复了 blobDownload.release 中的一处空指针崩溃：释放路径上调用到了一个 nil 的 CancelFunc。blob 下载是拉取镜像层的关键环节，这类崩溃往往出现在取消或错误清理路径上，复现条件相对隐蔽，属于典型的边界 bug 修复。

谁需要关注这个版本

如果你在 CI 环境、企业内网或任何强制走正向代理的场景下拉取镜像，这次改动直接关系到重定向目标能否连通。对于纯直连环境，传输行为基本不变，但仍能从 nil CancelFunc 崩溃修复中受益。作为 rc 版本，建议先在测试链路验证代理配置下的镜像拉取，再考虑在正式环境推广。