Undici项目中DNS拦截器与HTTPS请求的兼容性问题分析

问题背景

在使用Undici这个Node.js的HTTP/1.1客户端库时，开发者发现当结合DNS拦截器(dns interceptor)发起HTTPS请求时会出现证书验证失败的问题。具体表现为ERR_TLS_CERT_ALTNAME_INVALID错误，提示主机名/IP与证书的备用名称不匹配。

问题现象

当开发者尝试以下代码时：

import { getGlobalDispatcher, interceptors, request } from "undici";

await request("https://example.com", {
    dispatcher: getGlobalDispatcher().compose(interceptors.dns()),
});

系统会抛出TLS证书验证错误，指出IP地址不在证书的备用名称列表中。进一步测试发现，如果禁用TLS证书验证(process.env.NODE_TLS_REJECT_UNAUTHORIZED = '0')，虽然能绕过证书错误，但会返回404 Not Found或其他异常响应。

技术分析

根本原因

经过代码审查发现，问题出在DNS拦截器的实现上。当前版本的DNS拦截器在处理请求时，会完全覆盖请求的原始主机信息。具体来说，在dns.js文件的第357行附近，拦截器将请求的origin信息清除了，这导致了两个严重问题：

1. TLS证书验证失败：当建立HTTPS连接时，Node.js的TLS模块会验证服务器证书中的Subject Alternative Name (SAN)是否包含连接使用的主机名。由于DNS拦截器处理后，连接直接使用解析后的IP地址而非原始域名，而证书通常只包含域名不包含IP地址，因此验证失败。

2. HTTP主机头问题：即使绕过证书验证，由于原始主机信息丢失，服务器接收到的请求可能缺少正确的Host头或包含错误的Host信息，导致服务器无法正确路由请求，返回404等错误。

解决方案方向

正确的实现应该：

1. 保留原始主机名信息用于TLS连接和SNI(Server Name Indication)
2. 确保HTTP请求中包含正确的Host头
3. 仅将DNS解析结果用于实际的TCP连接建立

技术影响

这个问题会影响所有使用Undici DNS拦截器发起HTTPS请求的场景。对于需要自定义DNS解析但又需要保持HTTPS安全性的应用(如某些测试环境或特殊网络配置)，此问题会导致功能不可用。

临时解决方案

在官方修复发布前，开发者可以：

1. 避免在HTTPS请求中使用DNS拦截器
2. 或者修改本地undici库代码，移除导致问题的origin清除逻辑
3. 对于测试环境，可以临时设置NODE_TLS_REJECT_UNAUTHORIZED=0(不推荐生产环境使用)

最佳实践建议

当需要在Node.js应用中实现自定义DNS解析时，建议：

1. 考虑操作系统级的DNS配置修改
2. 评估是否真的需要拦截DNS请求，或者可以使用其他网络层解决方案
3. 如果必须使用拦截器，确保其实现正确处理了TLS/HTTPS相关参数

这个问题提醒我们在设计网络中间件时，需要全面考虑各网络协议层的交互影响，特别是安全相关功能如TLS证书验证的完整性。